Each project is presented as evidence of a problem-solving method:
what question existed;
what I assumed;
what I tested or built;
what failed;
what the evidence showed;
what changed because of it.
Some projects continue. Some are finished. Some are useful because the answer was "do not build this."
Three worked examples
King Nuggets — Verified Market Research System
running
Turned a subjective multi-factor market framework into a repeatable research system with explicit state, validation, provenance and point-in-time history.
Problem
Market analysis can combine useful judgment with stale data, subjective definitions and narratives that are difficult to evaluate later.
Capability
Systems thinking · data workflows · validation · controls · research design · AI implementation
How it worked
Assumption
That a market view is worth producing whenever a model can write one.
What I did
I translated a multi-factor market framework into explicit state, repeatable calculations, validation rules and a point-in-time archive. The system separates deterministic market state from model-generated interpretation and records data freshness, missing inputs and other conditions that affect whether a report should be produced.
Evidence
Deterministic state; validation/freshness rules; point-in-time reports; regime history; public/private state separation; research artifacts and a pre-registered null result.
Failure / surprise
A pre-registered test of one momentum screen came back null: the top decile minus the bottom decile straddled zero across every group and horizon tried. It stays a screen, not an edge.
What changed
The project moved from "generate a market view" toward "establish whether the system has enough valid evidence to produce a view."
Limit
This project does not claim market outperformance.
Closed-Loop Automation — Verifying the Work, Not the Model
running
Designed a verification layer around AI-assisted automation so task completion is established by checks and evidence rather than by the model's own claim.
Problem
An automated task can look complete even when its inputs were stale, a calculation failed or the model produced a plausible result from incomplete evidence.
Capability
Automation · AI evaluation · control design · operational risk · troubleshooting · system architecture
How it worked
Assumption
That a model's completion message is good evidence that the task succeeded.
What I did
I designed a lightweight verification pattern around existing AI-assisted workflows: trigger → input checks → execute → deterministic verification → bounded retry → approval where required → deploy → persist state. The goal was to stop treating a model's completion message as proof that the task succeeded.
The counter-example is Hermes, in the list below: I never built the layer around it, and it never did the job it was built for.
What changed
The automation architecture shifted from output generation toward explicit success conditions, machine-readable failure states and human approval boundaries.
Limit
This was developed in personal/local workflows, not represented as an enterprise production deployment.
Used pre-defined kill tests to evaluate three plausible ideas; two were parked before build work began and the third was deliberately reduced to one public artifact.
Problem
AI makes it cheap to turn almost any plausible idea into a prototype, which makes it easier to spend time validating the wrong thing after the build has already started.
Capability
Research design · experimentation · evidence evaluation · scope control · decision discipline
How it worked
Assumption
That a plausible idea, plus how fast AI can build it, is reason enough to start building.
What I did
I defined continuation thresholds before researching three consulting/product ideas. The research separated problem evidence, consequence, current workaround, spending evidence, dissatisfaction, and fit with the proposed deliverable.
Evidence
Pre-defined scoring rubric; research packs; PASS/HOLD/KILL decision logic; final decision memo.
Failure / surprise
Two research runs scored the same idea on opposite sides of the line. The score alone could not make the call.
What changed
Two ideas were parked before build work began. A third advanced only to one bounded public artifact rather than a product. That artifact is not published yet.
Limit
Desk research can justify a field test. It does not prove willingness to pay.
Everything else, by status
A live look inside my head: what I've built over the past year and what state each thing is currently in. Statuses are honest — some of this runs every day, some is specced and waiting, some is parked on purpose. Updated when reality changes, not on a schedule.
running — in use nowspecced — defined, not builtparked — deliberately stopped
The Build Log
runningweekly · since Jul 2026
A weekly public log of the actual work — what got built, what broke, what I almost sent and didn't. The constraint is the product: every week, whether the week was impressive or not. The streak trains a muscle two decades of institutional work never did.
The workspace behind the research: methodology write-ups, a status board, and point-in-time archives — documented while being built, not after it works. The structure is live; entries land as systems get verified against the archive. No scripts, self-hosted fonts, every section its own citable URL.
A design experiment: the same brief handed to three frontier models, four single-page answers, published side by side with their code intact. One of them became the King Nuggets Lab. The house rule applies to the exhibits too — read what the code does, not what it says it does.
The note's cover: five stages, from Enable to Reconfigure.
The arithmetic behind a Florida hurricane kit
runningpublished September 28, 2026
Every official checklist tells you what to buy and never how much. Here's the math for a family of four in Florida, what it costs, and where the standard advice falls short.
Market research built on cycle methodology — counts measured trough to trough, anchors and invalidations stated up front. The archive grows every day whether anything publishes or not; issues go out only when the analysis clears the bar. One rule underneath it all: the model interprets, it never decides.
The pipeline that feeds King Nuggets: a first version of the data engine runs, but only against sealed and hand-built inputs. It has never pulled from a live official source, and that first run waits on my sign-off. Built under a standing rule: no infrastructure without a named analytical or publishing requirement.
Agents and automations
runningnever formally audited
Half a dozen scheduled jobs run in the background — a capture system feeding the second brain, an inbox scanner, a policy-headline monitor, and feeds pulling frontier-model and macro signals each morning. The one worth admitting is Hermes. It was built to run research, understand what it found, and get better at it. It does none of that, because I never built the layer around it that would let it — and I never built that layer because every time I approached it I got friction instead of a path, and taking the friction as a verdict was easier than pushing through it. That's what happens when you let the low-resistance direction pick the roadmap.
Statuses use three words on purpose: running, specced, parked. If something sits parked for long enough, it either gets a requirement or gets deleted — that's the point of saying so in public.
