From Objective to Proof

Code Is Cheap.Proof Should Be Too.

Anyone can ship code now. Proving it does what your strategy demands is the hard part. Follow the thread.

Pull the thread ↓
The Bottleneck Has Moved

Black-Box Engineering: messes at machine speed.

AI now ships work that looks finished — and nobody can show which objective it served. When a developer can produce plausible code at near-zero marginal cost, generation stops being the constraint. Governance, proof of performance, and economic alignment become the constraints.

more likely to duplicate than refactor, reversing the 2022 ratioGitClear, 2026
66%of developers name “almost right, but not quite” their top AI frustrationStack Overflow Developer Survey, 2025
90%now use AI at work. Delivery stability still declines.DORA, 2025

DORA's explanation: acceleration exposes whatever your control systems couldn't already catch.

The Antidote Is Older Than the Problem

I didn't invent this.

Avionics, medical devices, and rail have worked this way for decades. Every requirement carries an ID, every ID traces to the test that proves it, and code that names nothing doesn't ship. It never spread past those industries because it cost too much. The links lived in tools like HP ALM, in a system running parallel to the work rather than derived from it. Even with compliance staff watching, the record always lagged the code. Minutes at best.

One thread, four links: Objective → Intent → Build → Proof. The objective settles why the work exists. The intent is minted from it with a durable ID. The build marks which intent it serves. The proof answers for the intent by name. The Golden Thread is the provenance running through all four, enforced by pipeline gates, not policy decks.

The question is no longer whether you can afford this rigor. It's whether you can afford to generate code without it.

Live Production Evidence

The model, running in public.

HomesFlow is a working iOS app that was built, in public, using this discipline. Every feature traces a written requirement through to the code that implements it, to the test that checks it. When that chain breaks, the build refuses to merge — and you can open the repository and watch the refusal happen.

You'll notice what's not here: no customer logos, no "reduced defects by 40%." Claims like that wouldn't be clickable — and the whole point of this practice is that claims end in something you can click. What's clickable is the repository itself. Read HomesFlow's own trace-manifest in Loupe →

Pick any feature you shipped last quarter. Can anyone prove, with evidence rather than recollection, which strategic objective it served? If the answer takes longer than a coffee, the thread is already broken.

Try it on your own repo: SpecAssay installs on stock Spec Kit in minutes. Or bring me in: I'll run it with one of your teams, on your codebase, for a few weeks, and you'll know whether it holds.