Inside the Iron Pipeline: nine stages, three gates, and why the order matters
The engineering phase of our operating model runs every change through nine stages and three human gates, each with an owner agent that alone can record its verdict. Here is each stage, who owns it, what it produces, and why the tests are written and locked before a line of production code exists.
The Iron Pipeline is the engineering phase of our operating model: the part between an accepted, clickable set of acceptance criteria and code running dark in production. It is called a pipeline because the order is the point. Each stage has an owner agent, only that owner can record the stage's verdict, and the stages cannot be skipped or reordered, because hooks will refuse it.
Here it is, start to finish.
S0 · Intake
Owner: the routers and the records agent. The story is classified, the specialist agents and the models that will run are chosen, and the work is linked to the tracker. Nothing creative happens here; it is the manifest for everything that follows, and it is where the model routing table is applied so that, for example, the security auditor is never assigned a weaker model class.
S1 · Acceptance criteria
Owner: the product and domain experts. Given/When/Then for every happy path, every sad path and every idempotency case. A compliance agent co-authors them and signs the exact version. If the story came through the working mock, most of this already exists and was vetted by people using the feature; this stage makes it precise.
H1 · Human gate
The first typed gate. A named person approves the acceptance criteria as their own message. Not a thumbs-up in a tool, not a phrase in a file, not an agent saying "approved on behalf of." A hook captures the gate only from a human-typed message. No agent can open it.
S2 · Red
Owner: the QA agent. Failing tests are written first, mapped one-to-one to the acceptance criteria, and run. The red run is captured as evidence. This is the stage that makes everything downstream honest: we now have a definition of done that exists independently of the code that will try to satisfy it.
H2 · Human gate
The named person acknowledges the tests. From this moment they are hash-locked. The engineer agents cannot edit them; if they could, "make the tests pass" would be a trivial instruction.
S3 · Green
Owner: the engineer agents. This is the only stage in the pipeline where production code is written, and it is written in the story's own worktree, until every mapped test passes. The engineers' job is narrow on purpose: make the locked tests green without touching them.
S4 · Verify
Owner: the QA verifier, the security auditor and the diff auditor. Mutation checks on the hard gates prove the tests still bite. The security audit and the diff audit each run on a different model from the engineer that wrote the code; a dispatch guard denies them otherwise. Nobody grades their own homework.
S5 · Dev
Owner: the GitOps agent, the only agent allowed to push, merge and deploy. Deploy to the shared dev environment, run the suite, open the pull request, wait for CI.
S6 · AC verify
Owner: the verifier agent, again on a different model. Every acceptance criterion is checked over HTTP against the running system. Not "the tests passed" but "the behavior the human approved is observable in the deployed service."
S7 · Staging
Owner: GitOps and QA. Merge to main, full suite, test maintenance until every domain is above the coverage bar. Every merge deploys, dark, behind a toggle. The mutation checks run again here, which is the second line of defense against drift.
S8 · Record
Owner: the records agent. The tracker is updated, the release record is written, and each agent's lessons from the story are published as a pull request for a human to merge. This is how the agents get better: not by retraining, but by a reviewed memory that compounds.
H3 · Human gate
The named person releases it. The code is already deployed; this decision turns it on. Because deploy and release are decoupled, the release is reversible in seconds, which is what makes a human comfortable making it quickly.
Why the order is the model
Reorder any two of these and the guarantees fall apart. Tests after code and they describe the code rather than the requirement. Audit before deploy-to-dev and you audit something that may not run. Release coupled to deploy and the human gate becomes a bottleneck people route around. The pipeline is iron because the sequence is enforced, not recommended.
Documentation-only changes take a shorter lane with the same gates. Everything else takes the whole road.