plumbspec → building something new
Greenfield · no legacy behaviour to preserve
Decision records first. Seventy thousand words later, nothing had settled.
A bleeding-edge greenfield system, built from nothing, where the only thing standing between a model and an unreviewable codebase was the specification. The governance playbook came first — architecture decision records, a formal process, a maintained backlog — and it collapsed under its own churn in four weeks. Every figure below is measured from that project's own repositories, including the ones that do not flatter the method.
This is where the method came from. The specification gate built to rescue this project is the prototype that became goldspec. What it demonstrated — that on a system an AI is writing at volume, a requirement has to be proven rather than claimed — is the reason the rest of this site exists.
Four weeks of governance
What a formal decision process actually cost
If you have run a programme, you have tried some version of this: write the decisions down, number them, review them, and keep a backlog of what is left. This project did it properly for a month. Here is what that produced.
It was not the writing that failed. It was that nothing settled.
- 21 amendments landed on 16 of the 49 records. Five were amended more than once. Four were amended on the day they were filed. One was superseded the day after filing. estimate ±2
- After eight days the record types had to be reorganised. Process decisions had crept into the architecture stream, so eight records were renumbered into a new kind and 88 cross-references had to be re-pointed by hand. measured
- Four records were never accepted at all — written, numbered, reviewed, and left in limbo. measured
- At least one record was written after the code it describes, then amended to settle a question the code had already answered. measured
- The backlog document churned 6.7× its own size. A 3,068-line file took 11,826 lines of additions and 8,908 of deletions. measured
None of that is an argument against writing decisions down. It is a measurement of what a decision record is: a document whose truth has to be maintained by a person, competing for that person's attention with the system it describes. At forty-nine of them, the maintenance won.
The change
The specification became the thing that runs
The shift was not a better document format. It was making the specification executable: every requirement is a test, and its status comes from the live run rather than from a field somebody updates. Nothing is a hand-kept list, so there is nothing to drift. The gate written to do that here is the direct ancestor of goldspec — what you would buy today is this, generalised and hardened.
Two consequences followed immediately, and both are mechanical rather than cultural.
- The specification can outlive the decisions. A test gate bars it from citing decision records, epics or governance documents at all — so it stands on its own, can be published, and does not rot when the reasoning behind it is superseded.
- Code that maps to no requirement becomes a strip candidate. Two days in, three dead subsystems came out: an unused publish/subscribe fan-out, a dead receive surface and an orphaned client module. Nobody had noticed they were unreachable.
And the decision records stopped being written. In the three months after the change, two commits touched a decision file across the whole project, and one new record was filed — a note of future ideas, marked proposed. The product repository carries zero citations to a decision record.
What that does not prove
Overall activity fell sharply over the same period — the product repository went from 1,072 commits before the change to 57 after. This is not a controlled comparison, and a quieter project writes fewer documents of every kind.
So the honest claim is the narrow one: formal decision records stopped being needed, and the specification carried the load instead. No percentage reduction is claimed here, because the measurement cannot support one.
Where it stands today
Fifty-seven built. Seven proven. We know the difference, and that is the product.
A run on 15 October against the current commit: 123 tests, no failures, and 115 requirements in the specification. The status breakdown is the thing worth your attention, because it is unflattering and it is the whole argument.
| Status | Count | What it means |
|---|---|---|
| Specified, not built | 58 | Written down as a target, no implementation yet. Visible rather than forgotten. |
| Built | 57 | The target is expressible in the system today. |
| Built and proven | 7 | Backed by a requirement-tagged test against the real implementation. Five in one chapter, two in another. |
| Built but unbacked | 50 | Looks done. Nothing is holding it. This is the number every project has and almost none can see. |
Fifty of fifty-seven. On a system where the method was applied from the first commit, by the people who wrote the method. That is not a failure of the approach — it is the approach working. Every other project in this position reports fifty-seven done, because nothing tells it otherwise.
The number that matters is not how many are proven. It is whether you can tell the difference.what the measurement is for
It mirrors exactly what the measurement found on an unrelated live system: there, a passing suite of nineteen hundred tests was holding nothing for 38 of 49 written requirements. Same defect, found the same way, in a mature codebase and a new one.
Provenance, since it matters: these figures come from this project's own specification gate — the prototype the goldspec method was derived from. The released tooling reads a different annotation, so the numbers above are the prototype's rather than a run of the shipped product; enforcement of the requirement-to-test link is switched on in one chapter so far. Unlike the live-system case study there is no expensive catch to report here: no incident this found that review had missed. Scale, for context: 238 production Java files, 215 test files, 989 test methods, and 20 specification chapters.
What this costs
Three dollars per contracted hour, on a seat you already staff
The tools are Apache-2.0 and run on a laptop, in your CI, or on-premise, with no call out to us and no credential. What is priced is the hosted AI-assisted step, and the unit is a seat: $3 a contracted hour per seat, from one week at $120 — $6,000 for a full-time year, the form that fits a proposal line.
For a new build the argument is the one measured above. The governance overhead a greenfield programme spends on keeping documents true — a quarter of all commits, on the project measured here — is work the specification does for itself once it executes.