When are two specs the same spec?

Specs won. We are not here to reargue it.

By mid-2026 every major coding agent ships some flavour of spec-driven development and the phrase of the year is the spec is the prompt. Good. That consensus is the starting condition, not the product — because every one of those specs is prose. Structured Markdown, held together by convention and good intentions, reviewed by a person. The tools disagree about format and lifecycle and agree completely about substance.

Which leaves the two hardest questions untouched: when are two specs the same spec, and what shows a run obeyed one? A review meeting answers the first. A passing suite is a sample, not a record of what happened, and that is the second. We think both deserve arithmetic.

Identity, not diff review.

A spec canonicalizes to a graph; the graph derives a name. Reformat the document, reorder the clauses, rename freely — the name holds. Change what the spec claims and the name moves. The figure below is that property drawn out, using the one identity this stack has actually measured.

Three things exist here, at three different rungs, so they are not in one list.

A single status for this domain would be false in one direction or the other. One artifact answers on a deployed host, one is a pair of parsers with test suites, one is a document. The rung chip on each says which.

The compiler that would join the two halves of this page does not exist.

The machinery derives identities from canonical graphs. The front end parses Markdown (§3) and speaks MCP (§4.2). Nothing turns one into the other, so today a SpecPrompt spec is a validated document and not a checksummed one. Stated first, at full size, because it is the thing a reader would otherwise assume works.

Every count below was produced by running the suite, not typed onto this page.

This build shells out to mix test and to vitest, parses what they print, and refuses to emit the page if either number disagrees with the frozen record beside it. A count cannot be hand-written onto this site; the only way to move one is to change what the tests do.

Each row was produced by executing the suite named in it and parsing what the runner printed — mix test against the Elixir toolchain in lib/, and npx vitest run against the TypeScript parser in npm/. Two parsers of one format (§4.8) is the strongest claim in this repository and it is still one team’s work. The counts are re-derived on every build; the frozen record beside them is what they are checked against, never their source.

And the rows that are a name rather than a thing.

Same table shape, honest column. built · superseded is used where something is deployed and running but replaced by the argument above — taking neither credit for it nor pretending it was never there.

Where this stands, and what would move it.

Status

live_deployed — The SPEC.md toolchain is deployed and answering. app.specprompt.com returns 200, its health-bearing MCP endpoint at POST /mcp returns a well-formed JSON-RPC error rather than a web-server error, and the two reference parsers this repository ships agree with their own suites.

Last verified

2026-08-17

Source

Four measurements on 2026-08-17. (1) mix test in specprompt.com — 71 tests, 0 failures. (2) npx vitest run in specprompt.com/npm — 22 tests, 0 failures. (3) curl https://app.specprompt.com/ — 200. (4) curl -X POST https://app.specprompt.com/mcp with a JSON-RPC tools/list body — 406 without an event-stream Accept header, and with one a JSON-RPC envelope carrying code -32600, which is the MCP server refusing an uninitialised session rather than a page failing to serve.

Limit

This establishes that the prior toolchain runs on this domain and that two parsers agree with the tests written for them. It does not establish the claim this page is built on — that a spec has a derivable identity — because no compiler joins the Markdown front end to WRL. It does not establish that the deployed MCP server does anything useful past refusing an uninitialised call; no tool was invoked end to end. And the one identity measured across two operating systems was derived by a single implementation twice, which is not two implementations agreeing.

Next rung

external — A second implementation, written by someone who is not us, that derives the same sem- identity from the same canonical graph — or a spec whose identity this one gets wrong. Either moves the semantics off self-report. Nothing else will, and shipping the compiler will not: it would make the claim testable, not tested.

Specs on this domain with a derivable identity

0. The deployed toolchain validates prose. The compiler that would give a validated document a content-addressed name is not built, so nothing served here has one — including this page's own claims.

Implementations of the semantics that are not ours

0. One codebase derived the demo world's identity on two operating systems. That is the same program run twice. A second implementation is what would turn a portability result into a semantics result.

Three rungs, three lists. Nothing asks you to use what is not built.

If a number on this page is wrong, that is the message we most want.

This page is generated from a record and gated, which catches a value that drifted from its witness. It cannot catch a witness that was wrong to begin with. If you maintain specs for agents and did the meaning change costs your team meetings, that is also worth hearing — it shapes what the compiler would have to accept.

Or file it in public: github.com/c-u-l8er/specprompt.com/issues. Both reach the same people.