Software engineer · systems builder

I turn messy problems into systems that surface what matters.

I work across AI, infrastructure, data, and product—usually where information is abundant, the signal is unclear, and a better model can make the next decision easier.

See the systems ↓ How I think ↓

Selected systems

Three domains. One way of working.

These projects look different on the surface. Underneath, each starts by turning an ambiguous, information-heavy domain into a model that can support better decisions.

01 / INFRAPORTALBuilt system

Turn scattered infrastructure state into an operational system.

A hybrid infrastructure platform that makes cloud and on-prem state observable, queryable, and useful for automation.

Problem

Operational state lived across servers, cloud tools, services, tickets, and manual checks.

Decision

Maintain a current model of infrastructure state and let that state—not human memory—drive monitoring and automation.

Result

Infrastructure becomes inspectable as a system, with machine-verifiable state feeding alerting, ticketing, AI-assisted operations, and deployment workflows.

System architectureTechnical ownershipCloud & hybrid systemsReliability

Show more engineering evidence

Multi-cadence state collection, persistent snapshots, structured logging, alert grace periods and auto-resolution, Jira reconciliation against live state, AWS SSM/EC2/Bedrock integration, auditable command execution, and deployment automation with service verification.

02 / CAREER EVIDENCE ENGINEWorking prototype

Turn messy work history into a defensible capability model.

An evidence-first product for answering a difficult career question: what does someone’s actual work prove they can do?

Problem

Résumés make claims, but rarely show how those claims were reached or how strong the underlying evidence is.

Decision

Treat real work as evidence, map each example to capabilities, preserve uncertainty, and make every conclusion inspectable.

Result

The model can distinguish demonstrated strength, partial evidence, and unknowns without forcing every capability into a flattering answer.

AI engineeringProduct architectureEvidence modelingUX judgment

Show more product evidence

The prototype models raw work evidence → evidence objects → capability mapping → confidence → market relevance → gap analysis, then exposes the reasoning behind each rating rather than presenting an opaque score.

03 / WHAT TO WATCH FORProduct concept

Turn a week of college-football noise into a five-minute briefing.

A recurring intelligence product organized around a fan’s actual question: what deserves my attention next?

Problem

Schedules, rankings, injuries, results, news, lines, and context are abundant. Attention is not.

Decision

Organize the experience around three recurring needs: what happened, what changed, and what matters next.

Result

A product model that separates data gathering, significance ranking, AI synthesis, and presentation into a repeatable editorial workflow.

Product thinkingAI systemsInformation architectureData synthesis

Show more product evidence

The concept defines a recurring report cadence, models the information needed for each report, and treats AI as a synthesis layer over structured evidence rather than as a generic chatbot.

One useful idea

Separate evidence from interpretation.

A principle I’m trying to apply both to life and to technical work.

When something happens, I tend to experience two things almost simultaneously: the event itself and my explanation of what the event means. Those aren’t the same thing.

What do I actually know?

What am I interpreting?

What evidence would change my interpretation?

That distinction matters in production systems too: start with observed behavior, gather evidence, isolate dependencies, test a hypothesis, and make the smallest defensible change.

How I work

Principles that shape the work.

The point is not to collect quotes. It’s to identify ideas strong enough to change how I behave.

Face reality early.

Bad news gets more expensive with time. Surface state and failure while there are still options.

Separate evidence from interpretation.

Diagnose before changing things. Observed behavior and the story about it are different artifacts.

Turn recurring problems into systems.

If the same manual intervention keeps appearing, I start asking whether the workflow itself is the problem.

What I’m exploring now

How should AI participate in systems people need to trust?

I’m interested in AI as a reasoning and synthesis layer—especially when evidence, reviewability, and auditability matter.

Useful AI should make the system more legible, not less.

The current question is where AI can reduce cognitive load without hiding the evidence, removing human judgment from consequential steps, or making system behavior impossible to reconstruct later.

Evidence before conclusionKeep important outputs grounded in inspectable inputs.

Human review as stakes riseGenerated actions should remain reviewable before execution.

Audit the behaviorMake consequential outputs and actions explainable after the fact.

Operating system

What I’m trying to optimize for.

PurposeCreate meaningful impact.

PracticeGrow through self-mastery.

DirectionCharacter → Self-mastery → Faithfulness → Influence → Impact

Contact

If this way of thinking fits a problem you’re working on, I’d like to hear about it.

I’m especially interested in engineering work involving systems, AI, infrastructure, complex information, and products where clearer models lead to better decisions.

Message me → Review the work ↑