Code Is Cheap.
Proof Is Not.
Anyone can ship code now. Proving it does what your strategy demands is the hard part. Follow the thread.
Black-Box Engineering: messes at machine speed.
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.
DORA's explanation: acceleration exposes whatever your control systems couldn't already catch.
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.
The model, running in public.
HomesFlow is a real iOS app built for fewer than twelve users. The app was never the point. Code that serves an intent names it. Every acceptance criterion carries a named proof or an admitted debt. CI fails the build when the thread breaks. Not a slide: a repository, refused at merge, on every push.
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.