Generative Specification: A Discipline of Derivability for the Stateless Reader
Author: Juan Carlos Ghiringhelli (PragmaWorks) Version: 5.0 · Date: September 2026
If you build with AI agents, this paper defines a discipline for describing a system precisely enough that the agent can derive it, and reports what the evidence does and does not show. The scarce skill stops being writing code and becomes specifying it. What follows is the method, a seven-property test of whether a specification meets it, and the evidence, each result stated with its design, its registration status and its number of runs: one author-run three-condition comparison (five generations per condition), small mechanism studies, single-run demonstrations, and observational reports. All of it is exploratory; none was preregistered with an external timestamp. The aim is that what the AI builds becomes a verified, auditable, governable process; the evidence supports parts of that aim (§5) and not others (§5.4, §6).
Abstract
The dominant failure mode of AI-assisted software development is architectural drift: an AI agent, capable of generating a system in a single session, resolves a thousand implicit decisions — units, field ordering, layer ownership, error semantics — silently, drawing on everything it has read about how such systems are usually built. Each decision is locally reasonable; in aggregate, across session, team, and service boundaries, they diverge. The cause is structural, not a model defect: the AI is a stateless reader that begins each session with none of the memory, shared context, or ability to ask that a human colleague uses to compensate for an underspecified system.
Generative Specification (GS) is a discipline of removal in Robert C. Martin’s precise sense — like structured, object-oriented, and functional programming, it is defined by a freedom it takes away. But where those disciplines constrained control flow, data access, and mutability for a human reader, GS constrains a different axis: it removes the freedom to leave architectural intent implicit, for a reader that cannot recover it — requiring a specification from which a stateless reader can derive correct output unaided. (The word paradigm is used below only in Martin’s narrow, technical sense — a discipline of removal; we make no Kuhnian claim about the field, and no claim that GS succeeds its forerunners in a lineage rather than constraining an orthogonal axis — see §2.) The discipline is operationalized as seven properties (Self-describing, Bounded, Verifiable, Defended, Auditable, Composable, Executable), each named for a failure mode observed in production and graded per property on a letter scale from A to F (§3.2).
The method rests on three ideas that are the author’s own contribution (§2.3): the bridge — why externalizing intent into structure actually produces correct derivation, and why the load moves to the model’s stronger side; the sentinel navigational tree — how a session’s context is bounded so it stays clean enough to derive from; and phase collapse — specification, implementation, and verification converging into a single derivation step once the specification is complete and the executor is capable. The rest of the discipline is the author’s honest synthesis of an industry already converging toward these practices (§2.3).
We also propose a theoretical home for the discipline — the pragmatic tier of the semiotic hierarchy (Morris, 1938), the relation of signs to an interpreter that carries no context, a tier prior programming disciplines left vacant. We offer that placement as a conceptual contribution, distinct from and not required by the empirical results: the discipline stands on what it measurably produces, whatever one calls it.
The empirical program is exploratory throughout: no study was preregistered with a verifiable external timestamp, and every result is stated with its design type, registration status, number of runs, models and benchmarks, and statistical status (§5, box “How to read the evidence statements”). The strongest comparison, AX, is an author-run three-condition comparison (five generations per condition, one benchmark, one model, one author; pre-specified in intent, not registered); it shows that a structured specification separates cleanly from unstructured use (layer-boundary violations, median 45 versus 0; files emitted, 21 versus 55) and does not separate from a strong expert prompt on median quality (blind-audit score 11 [6.5, 12] versus 10 [9.5, 11]; the two tie at the ceiling, so that contrast is uninformative and the experiment log marks it INVALID-DESIGN); the observed difference is that the expert prompt breached the layer boundary in 2 of 5 runs and the full cascade in none, which five runs cannot establish as an effect. The headline “3/14 to 14/14” trajectory of earlier versions of this work came from iterated post-hoc conditions designed with knowledge of each prior condition’s gaps; it is reported as a diagnostic series, not as an effect size, and of the ten predictions registered for the original single-run design three were confirmed. Single-run feasibility demonstrations show the method deployable and operable (EX), independently regenerable (RX) and derivable at the formal tier (ALX); a retrieval study (KX, supported on tokens and cost on one model, not on accuracy) and two behavior-preserving twin studies (TX, SX) are mechanism demonstrations that decompose the read-and-modify cost into a navigation lever and a bounding lever and bound the read-cost claim; a cross-vendor structural comparison (AX2, an internal conceptual replication of AX’s structural contrast) finds the separation from unstructured use on every vendor tested, and a capacity ladder on an invented benchmark (CR, k = 3) shows duplication and complexity differences that point to a benefit largest at the weakest rung and about zero at the frontier (about +14.5 points of duplication against about 0) but that are inconclusive at that sample size, with behaviour and the layer metric uninformative; two single-shot experiments (MX, RND-1, n = 1) are exploratory. The production projects from which the method was derived and a practitioner workshop (§5.3) are observational and are not evidence of effect. The exact figures are set out in §5.
For a working developer, the shape of the payoff is simple: describe the system well once, and the building, the regenerating, and the verifying stop being where your time goes. The next section names the constraint that makes this possible.
1. Introduction: The Stateless Reader
On September 23, 1999, the Mars Climate Orbiter completed a nine-month, 416-million-mile crossing — then entered the Martian atmosphere roughly 170 kilometers lower than intended (a periapsis near 57 km, against a planned ~226 km) and was lost, presumably destroyed by atmospheric heat and drag. The cause was not a bug in any module. One team reported thruster impulse in pound-force seconds; the flight computer expected newton-seconds. Both components were internally correct, and no test caught it — the code compiled cleanly. The failure lived only at the boundary: the seam where two internally-coherent systems had to agree on a shared language they were never required to write down. The contract had been assumed, not written. The orbiter cost $327.6 million and two years to build.
Today an AI assistant produces an equivalent interface in thirty seconds. The code compiles, types check, unit tests pass — and embedded in the output is a set of implicit assumptions the model resolved silently. The Orbiter problem did not go away; the velocity of producing it increased by orders of magnitude.
This is not an argument against AI-assisted development. It is an argument for what it requires. The Jacquard loom did not eliminate weaving craft — it relocated it upstream, into the card, where the pattern could be expressed once and executed at machine speed. Software construction is undergoing the same relocation. An AI agent with command-line access can read a codebase, write tests, run migrations, and commit, all in one session, starting from nothing — a capability now measured at scale on benchmarks such as SWE-bench (Jimenez et al., 2024). The executor is extraordinarily capable. The open question is what governs it across the session boundaries it cannot see, the team context it was never given, and the decisions made in conversations it was not part of.
The answer is a specification precise enough that a stateless reader — one with no memory of your intentions, no shared context, no ability to ask a clarifying question — can derive correct output from it alone. That discipline is what this work defines.
Naming the reader as stateless is a small move with a large consequence. The condition is not new — every AI session has always begun from nothing — but it went unnamed, treated as an inescapable fact of the tools rather than a solvable constraint. The three failures practitioners report — no reliable process, no warranted trust, unreliable results — are its symptoms. Naming the constraint is the precondition for removing them.
This work requires an AI agent with direct CLI access — not a chat assistant, but an agent that can read and write files, run tests, commit, and execute commands (Claude Code, Cursor, and agentic IDE modes qualify). The methodology does not apply to chat-based interfaces.
The arc. GS began as a way to make an investment viable: write the specification, derive the rest from it, and verify the result without a person writing or reading every line. To do that, what matters had to be moved out of people’s heads and out of the model’s context into files and checks: the specification, the document cascade, the sentinel, the gates, and the lock that ties each artifact to the version of the specification it came from (the substrate). That substrate produced, without being designed to, two forms of governance: continuity (what was decided and why survives who did it and who left, so code can be regenerated with knowledge of cause) and state (where each project stands against its requirements and the rubric can be known at any time). We suspect, and have not measured, that this lowers the dependence of average quality on individual talent. That is a thesis, not a result (Compendium §1.1).
Contributions. (1) The derivability obligation — naming implicit-context removal as the defining structural constraint of AI-assisted development. (2) The seven-property rubric — a teachable instrument derived from failure modes observed in six production projects and applied, in its earlier 0–2 form, in the experiments below; it has not been validated as a measurement instrument beyond the small BX cross-check (§5.2). (3) The three load-bearing mechanisms — the bridge and its asymmetry (why externalized intent is derivable, and why the load moves to the model’s stronger bank — the read-asymmetry is its reading-side face), the sentinel navigational tree (how a session’s context is bounded so it stays derivable), and phase collapse (specification, implementation, and verification collapsing into a single derivation step when the spec is complete and the executor is capable). (4) The substrate — the externalized composite (specification, document cascade, sentinel, gates, and verification harness), rooted in a contract-form specification, from which the system is derived and regenerated. (5) Capacity-relative scaffolding — the honest bound: the benefit is largest where the model is weak relative to the task and recedes as the model strengthens. (6) Cost inversion and the token economics of authored structure — tokens-per-correct-output, not tokens-generated, as the binding metric. (7) A layered validation program (AX, BX, EX, KX, ALX, RX, TX, SX, MX, RND-1), each result stated with its design, registration status and number of runs (§5), whose experiments probe distinct sources of circularity without closing them (§6).
Among the method’s ideas, three are the ones the method turns on and the ones the author offers as his own contribution: the bridge and its asymmetry, the sentinel navigational tree, and phase collapse (§2.3). None is claimed as a new property of software or as a priority discovery; each rests on prior art named in §2 and §8, and what is new is the organizing criterion, the naming and the measurement. The rest are named framings and coinages (the derivability obligation, the read-asymmetry, cost inversion and its token economics) and the validation program: the author’s naming and synthesis of a practice the industry was already converging toward, offered honestly as such. §2.3 draws that line explicitly.
Terms used throughout. The stateless reader is an executor that begins each session with no memory of earlier sessions and no way to ask a question. The sentinel is the root instruction file of a project (CLAUDE.md, AGENTS.md or .cursor/rules) together with the tree of scoped child files it routes to, so that a session loads only the slice a task needs. The substrate is the externalized composite that keeps intent outside the model and outside the session: the specification, the document cascade (§7), the sentinel, the gates that enforce the rules, and the verification harness. A gate is an automated check whose failure blocks a change. Derivable means that a stateless reader can determine the correct output from the artifacts alone. Ratification is the act by which a person accountable for a project accepts something into force (a criterion, a change to the specification, a derived artifact that has become stale): it states a reason, appends who, when, what and why to a record that only grows, and is performed by a person and not by the executor. Governed is defined in §3.2; the lock and the other coherence mechanisms in §4.3.
2. A Discipline of Removal, and Its Theoretical Place
A paradigm, in Robert C. Martin’s precise sense, is defined by what it removes from programmer freedom. Structured programming removed goto. Object-oriented programming removed unconstrained access to internal data. Functional programming removed unrestricted reassignment. Generative Specification removes the freedom to leave architectural intent implicit.
This removal differs in kind, and in axis, from the earlier disciplines. Structured, object-oriented, and functional programming each constrained a property of the code itself — control flow, data access, mutability; GS constrains a property of the specification’s relationship to its reader. The axes are orthogonal: a functional or an object-oriented program can be fully GS-compliant or wholly non-compliant, because derivability for a stateless reader is independent of which control-flow or data disciplines the code obeys. GS is therefore a peer of those disciplines in the removal sense, not a successor in a progression. And where they constrained freedoms for human readers who could still compensate for gaps through memory, collaboration, and institutional context, GS’s removal is absolute for its reader: a stateless executor that begins each session with none of those recovery mechanisms. What prior disciplines made inconvenient, GS makes structurally absent — because the reader that would have compensated does not exist.
2.1 Structural Disciplines: The Raw Material
Before the discipline can be explained, its raw material has to be named. A structural discipline is any long-established engineering practice that forces intent out of a developer’s head and into the durable structure of the artifact — into names, boundaries, types, contracts, and recorded decisions. The canon is familiar to every senior engineer:
- Intentional (clean-code) naming — a name states what a thing is and does, so the reader need not trace its uses to find out.
- SOLID — single-responsibility, open-closed, Liskov substitution, interface segregation, dependency inversion: forces roles and seams to be explicit.
- Domain-driven design’s ubiquitous language — the code speaks the business’s vocabulary, so meaning is not translated in someone’s head.
- Design by contract — preconditions, postconditions, and invariants stated at the boundary rather than assumed.
- Type-driven design — making illegal states unrepresentable, so the type is the specification.
- Test-driven development (TDD) — the test, the executable contract, is written before the code, giving constant validation and making implicit contracts explicit.
- Hexagonal (ports-and-adapters) layering — the core’s dependencies point inward and are declared, not discovered.
Each of these is encoded veteran wisdom: a practice distilled from decades of expensive failure, the shared knowledge senior engineers reach for precisely because they have seen what its absence costs. GS does not invent these disciplines. Its move is to force them — to make their presence the measurable, gated definition of a well-specified system — because, as §4 argues, they are exactly the structures a stateless reader needs in order to derive correctly. Everything in this paper stems from that: we force the structural disciplines. The bridge (§4.1) is why forcing them works.
2.2 Phase Collapse: What the Discipline Buys
The reason to force these disciplines is not tidiness. It is phase collapse. In conventional development, specification, implementation, and verification are three phases separated in time, owned by different moments and often different people, with hand-offs and drift at every seam. When the specification is complete enough for a stateless reader to derive from, and the executor is capable enough to derive, the three phases collapse into a single derivation step: you write the specification, the agent generates the implementation, and the verification harness proves it — in one motion, repeatable on demand. And the collapse need not be confined to spec → implementation → verification: EX (§5.2) demonstrates it can extend across the whole operational lifecycle. Everything a running system requires becomes a derivation from the same specification rather than a separately hand-managed phase — the implementation and its verification harness, the environment it runs in (containers, services, configuration, secrets), the data it consumes (fixtures, seeds, migrations), its external integrations and derived assets, its deployment pipeline, and the living documentation regenerated from all of it. The seams between build, test, provision, deploy, and operate — each historically a separate phase carrying its own drift — collapse into derivations from one source. This is the differentiator. It is why getting the specification right is worth the front-loading: the specification is no longer a document that precedes the work; it is the artifact from which the work is regenerated. Phase collapse is introduced here because everything downstream — cost inversion (§4.2), specification bandwidth, the whole economic argument — is a consequence of it.
2.3 What Is Ours, and What Is the Field’s
Honesty about provenance strengthens the parts that are genuinely new. Much of this discipline is the author’s synthesis of an industry already converging toward it, and the paper says so plainly:
- Specification-as-driver is not novel. Spec-driven development predates AI assistants by decades; it is the everyday practice of any team that writes the design before the code. GS’s contribution is not the idea that the spec comes first.
- The stateless-reader condition is not the author’s discovery — every practitioner has lived with it. What is the author’s is the naming and the wrapping: turning an unexamined fact of the tooling into a named, solvable constraint with a discipline attached.
- The structural disciplines (§2.1) are the field’s — SOLID, DDD, design by contract, and the rest are prior art. GS’s move is to force them for a new reason.
- The compact-knowledge-graph (CKG) framing and term are McCreary’s (Yarmoluk & McCreary, 2026), not the author’s; GS borrows and generalizes it (§4.3).
Against that, the author’s genuine contributions are three, and they carry the method:
- The bridge, and its asymmetry (§4.1) — the positive premise for why externalizing intent into structure produces correct derivation, and why encoding intent in human-conceptual terms routes the hard half of the problem through the model’s strong half.
- The sentinel navigational tree (§4.1) — the concrete mechanism, a canonical navigational tree (CNT) embedded in the agent’s prompts, that bounds a session’s context so it does not degrade.
- Phase collapse (§2.2) — the biggest differentiator, and the economic hinge of the whole method.
Alongside these sit a handful of smaller coinages inside larger topics — the read-asymmetry (§4.1), the naming of the stateless reader, the ratchet, the specification query — the author’s contributions inside otherwise convergent territory. The map is deliberately modest: it is easier to trust a method whose author tells you which parts he invented.
2.4 The Theoretical Place
This work also proposes a theoretical placement — the pragmatic tier of the semiotic tripartition (Morris, 1938), the relation of signs to a contextless interpreter, a tier prior disciplines left vacant. That placement is a conceptual argument, not required by the empirical results and developed as a separate position piece; the discipline and its measured effects in §5 stand whether or not a reader accepts it. The word paradigm is used here only in Martin’s narrow, technical sense (a discipline of removal), with no Kuhnian claim about the field.
GS is also distinct from the spec-driven tooling now entering the mainstream — Amazon’s Kiro and GitHub’s Spec Kit, which scaffold a requirements → design → tasks document workflow for an agent. Those tools supply a place to write the specification; GS supplies the obligation the specification must meet — derivability by a stateless reader — and a measurable test of whether it is met (the seven-property rubric). A Kiro design.md can be GS-compliant or wholly non-compliant; the workflow does not decide it. GS is the discipline a spec-driven workflow needs in order to be more than a folder of prose.
The Framework
Sections 3 and 4 together constitute the methodology: §3 defines the seven-property test of whether a specification meets the discipline, and §4 explains why meeting it produces correct derivation.
3. The Seven Properties
The discipline is operationalized as seven properties, each named for a class of failure observed in production, each graded as set out in §3.2. The rubric is the teachable spine of the method: a project is graded the way an AI reads it. Each property below is anchored to a public, verifiable exemplar — drawn from the open experiments or the public pragmaworks reference project, so a reader can inspect the evidence directly.
| # | Property | What it removes | Public exemplar |
|---|---|---|---|
| 1 | Self-describing | Hidden purpose; the reader must infer what the system is | pragmaworks CLAUDE.md — a navigation root where every document location announces its domain (screaming architecture) |
| 2 | Bounded | Unbounded surface and context; the reader must scan everything | KX (experiments/kx): a routed navigation tree loads only the slice a query needs — measured cheaper per structural query than dumping the whole codebase or searching it (on one model; accuracy not claimed) |
| 3 | Verifiable | Unchecked correctness; “it compiles” mistaken for “it works” | AX (experiments/ax): a post-experiment Stryker check on the services layer took the mutation score from 58.6% to 93.1% MSI over two rounds of test fixes, showing that detection is a different measure from line execution (the 93.1% coverage in the model’s own documentation was never measured; measured line coverage was 27.6%) |
| 4 | Defended | Advisory rules the model treats as optional | AX (experiments/ax): Defended moved 0/2 → 2/2 only once gates were emitted as fenced file templates (the “First Response Requirements”) — structural enforcement, measured |
| 5 | Auditable | Lost rationale; intentional decisions look like debt | pragmaworks ADR library (docs/adrs/0001…0006, each with context/decision/consequences) plus conventional-commit history |
| 6 | Composable | Tangled coupling that cannot recombine | AX (experiments/ax): interface-based dependency injection — the GS contribution over expert prompting — lets a stateless reader work a unit in isolation |
| 7 | Executable | Specifications that are never run against reality | EX (experiments/ex): Hurl probes + slo-ramp-summary.json — behavioral contracts run against a live runtime, not assumed from compilation |
The seven are grouped in two ways, and the two groupings answer different questions. By who can inspect them: five are audit-facing (Self-describing, Auditable, Verifiable, Executable, Defended), properties that a non-engineer accountable for the system can check over its life; two form the engineering layer (Bounded, Composable) that keeps the five true under change. By what the disciplines that satisfy them do (§4.3): verify (Verifiable, Defended, Executable) and retrieve (legibility: Self-describing, Composable; bounding: Bounded; decision memory: Auditable). The first grouping classifies properties by audience and the second classifies disciplines by function; they cut across each other on purpose (Composable is engineering-layer but legibility-role), and neither is a claim that the properties are independent of one another. Two — Self-describing and Bounded — carry disproportionate weight, because a bounded, self-describing specification activates the model’s relevant domain knowledge (a schema-fit effect: Bransford & Johnson, 1972) rather than its full prior distribution.
The Verifiable and Defended properties are not new instruments; they are the obligation to apply the standard quality toolchain and gate on it. The verification layer draws on the standard quality toolchain, grouped by what each gate catches: static analysis (type checkers, linters such as ESLint), coverage and complexity gates (test-coverage and cyclomatic-complexity thresholds), fault detection (mutation testing, e.g. Stryker), supply-chain scanning (dependency-vulnerability audits such as npm audit), and aggregate quality-gate platforms (SonarQube). GS does not reinvent these — it specifies which gates apply where and makes passing them the definition of done for a stateless executor that otherwise reports success on byte-write, not on correctness.
Crucially, the project-specific gates are a ledger of paid-for incidents: each encodes a real production failure the discipline already paid for once — a field finding promoted to a named forbidden pattern and then to a versioned, shareable gate that carries the original incident as provenance. The rule set accumulates from observed failure, not opinion, which is what makes it cumulative and falsifiable. This is the ratchet: it does not reverse — every defect resolved becomes a test and a permanent rule, every ambiguity an ADR that closes a decision for good.
Concretely, this is the routine that turns a single production incident into permanent grammar across three properties: the practitioner adds a regression test for the failure (closing Verifiable), writes a post-mortem / incident record capturing what happened and why (closing Auditable), and promotes the field finding to a forbidden pattern → gate that shrinks the reachable surface (closing Bounded). One incident, three durable artifacts, none of which reverses.
A defect, in this frame, is not evidence the method failed but a specification query — what constraint, had it been present, would have ruled this out? — and once that constraint is written, the class of output that produced the defect becomes unreachable. Those same tools, being rubric-independent, double as external corroboration of the GS scores (§6).
The properties also name their own failures. Each property has a headline failure mode, and the failure mode is that property’s lowest grade: Empty Map (Self-describing: intent lives in the author’s head), Spreading Boundary (Bounded: files outgrow what the reader can see), Unbound Spec (Verifiable: tests that assert nothing behavioural), Open Gates (Defended: rules that can be skipped under pressure), Amnesia Stack (Auditable: no recorded rationale, so intentional trade-offs are “corrected” away), Tangled Web (Composable: a change cascades through unseen coupling), and Frozen Spec (Executable: the specification describes behaviour the system no longer has). A fuller catalogue of named pathologies is kept in the Compendium; nothing in this paper’s argument depends on it, and it is not used as evidence.
3.1 The Seven Properties Cover Everything: A Concept Map
The method introduces several named concepts. They are not additions to the seven properties — each is carried by one or more of them. The map below is how the reader can see the seven cover the whole discipline.
| Concept | Carried by (properties) | How |
|---|---|---|
| The bridge (§4.1) | Self-describing, Composable | Structure that a human-fluent reader can cross in both directions is exactly what makes a spec self-describing and its parts recombinable. |
| The sentinel navigational tree (§4.1) | Bounded, Self-describing | Each node declares its own scope (Self-describing) and routes so a session loads only its slice (Bounded). |
| The read-asymmetry (§4.1) | Bounded, Self-describing | Comprehension comes from a small high-signal structural surface, not all the code — which is what Bounded + Self-describing provide. |
| Phase collapse (§2.2) | Verifiable, Executable | The loop closes in one step only because verification is machine-checkable against a running system. |
| The lock, ratification and the coherence checks (§4.3) | Auditable, Verifiable, Defended | The lock ties each derived artifact to the specification version it came from (Auditable); the co-change gate and the inverse inventory are checks that block or report divergence (Verifiable, Defended). Design only. |
| The ratchet / specification query (§3) | Defended, Verifiable, Auditable | Each resolved defect becomes a permanent gate (Defended, Verifiable) with recorded rationale (Auditable). |
| Cost inversion / near-reconstructability (§4.2) | Auditable | The document cascade and recorded decisions are what let a compliant codebase reconstruct its own spec. |
| Generative execution (§4.3) | Executable, Verifiable | The verify step — the full pyramid plus multimodal QA against the live app. |
| Contract sufficiency (§4.2) | Verifiable, Composable | Convergence against a contract, not line-by-line inspection, presupposes verifiable and composable units. |
3.2 How a project is graded, and what “governed” means
The current instrument grades each of the seven properties with a letter from A to F, like a school report card; each letter comes with the evidence behind it (the file and line) and one step that would raise it. A is the top band (90 to 100 out of 100): the property is enforced, with no silent way around the check, and tied to the running system. F names the failure mode instead of a number (for example Empty Map for Self-describing, Open Gates for Defended). A finer instrument adds an overall maturity level from L1 to L5; this paper uses two of those levels. L4 means enforced and bound: enforced with no silent skip path and tied to reality. L5 is a trend and not a state: L4 sustained across at least three dated snapshots (a provisional convention). A project is governed as of a date when, at one commit and against one version of its specification, each of the seven properties is at L4, none is below L3, and the evidence is in the audit trail; a team that aims lower reports “L3 declared”, never “governed”, and a project can be governed against a thin specification (Compendium §8.19).
These are definitions. No experiment in this paper measured the letter or level scales, and we report no reliability for them. The experiments used the earlier instrument that scored each property 0, 1 or 2 (a 14-point total), which is retired as a scorecard and kept only because the AX results were measured with it; its totals appear in §5.2 and are labelled as such.
4. Why It Works
4.1 The Bridge, the Sentinel, and the Read-Asymmetry
The negative premise of GS is the stateless reader (the problem). The positive premise — why externalizing intent into structure actually produces correct derivation — is the bridge.
The bridge. Every structural discipline (§2.1) is a bridge between human conceptual language and executable code — the framing Gordon (2024) calls the linguistics of programming. Intentional naming, the specification, SOLID, domain-driven ubiquitous language, type-driven design, design by contract: each encodes human meaning in a form the machine can act on, and machine behavior in a form the human can verify. These disciplines were built to carry intent across that gap for the next human reader. Skilled human programmers were always fluent on both banks — human-conceptual language and code — and that dual fluency is the craft; it is not new. What the transformer adds is that it is the first tireless machine executor with that same dual fluency, now available at scale: it can read intent encoded as structure and emit code that encodes intent, tirelessly and on demand. And — crucially — it shares the human asymmetry. Like a human, it comprehends an explanation of behavior far more reliably than it reconstructs that behavior from raw code, and code carries no record of the historical reasons and context behind a decision. This is exactly why GS supplies the executor a bridge in plain text, inside the codebase — intent, the why, and structure expressed as ADRs, Mermaid diagrams, DB/API schemas, or whatever conveys it — which serves the machine executor precisely as it serves the next human reader. GS works because it makes building and maintaining that bridge the primary act of development. This is why we force the structural disciplines: they are the bridge.
The asymmetry is the sharper claim. The training corpus is overwhelmingly natural language; code is a small, exact, fragmented slice — every language its own precise rules, one wrong token breaks it. The model is therefore far stronger on human-conceptual meaning than on exact code. The leverage of the disciplines is not merely that they connect both banks: it is that encoding intent in human-conceptual terms routes the hard half of the problem (exact code) through the model’s strong half (human meaning it is fluent in). The discipline moves load from the model’s weak bank to its strong bank.
The read-asymmetry is the same asymmetry, seen from the reading side, and it does more work than its brevity suggests. You do not comprehend a system by reading all of its code and inferring behavior and interactions line by line. You comprehend it by reading its structural surface — contracts, unit tests, interfaces, design patterns, ADRs — a small, high-signal slice that states what the code does and why, so the behavior need not be reconstructed from the implementation. This is the read side of the bridge: the reader derives understanding from the surface, not from the code, exactly as the reader derives output from the specification. It is why Bounded matters (a smaller, higher-signal surface is a cheaper read), why the sentinel works (it routes the reader to the right slice of that surface), and why KX (§5.2) measures what it measures (navigating an authored surface beats searching the code). The read-asymmetry is part of derivability: a stateless reader that can derive understanding from the structural surface can be given a far smaller, far cleaner context and still derive correctly.
The bridge builds what the rubric grades — and that is why strong models do not retire it. The read side has an honest boundary, and naming it sharpens the rest. Two behavior-preserving twin studies (TX and SX, §5.2) decompose it. TX, varying organization at fixed content, found disciplined layering alone did not lower a stateless reader’s cold-read cost: the read economy there belongs to the authored navigation (the sentinel) and the contracts, not to layering. SX, varying content quality (a twin bloated to industry-average duplication and dead code), found the complement: removing that surface (the Bounding lever) lowers task cost even with the sentinel present on both twins, a cost no map recovers and only refactoring supplies. Reorganizing at fixed content does not cheapen reading; de-inflating does. What the disciplines contribute to construction is a different and durable thing.
Applying them imposes an order on a codebase, and that order is exactly the shape the seven properties measure: the disciplines are the constructive route to a correct system, the properties are the evaluative description of the same destination. This looks circular but is not — it is a constructive method paired with its conformance test, and the disciplines (derived for human readers) and the properties (derived from stateless-reader derivability) converge because both track the same real thing, legible structure.
The measured mechanism is capacity-relative scaffolding: Bounded units keep a fallible model coherent (given a cross-cutting change, a weak model silently regenerated an undisciplined God-class in truncated form, dropping most of its endpoints while still compiling, and handled the disciplined twin’s small units intact), and type and test contracts act as a gate that turns the model’s error into a caught failure instead of a shipped defect. The benefit is largest where the model’s capacity is smallest relative to the task and shrinks to nothing on a strong model at small scale (TX on one system; CR on a second, non-memorized benchmark, on structural cleanliness only; §5.2) — which is why the frontier-model era does not retire the bridge but relocates its value, from making a weak model read cheaply to making any system, built by any model, one a stateless reader can keep deriving.
What it means: the refactor that lowers your future cost to an AI and the refactor that raises your rubric score are the same refactor, because the AI is a stateless reader with the same needs the disciplines were built to serve.
Where the value goes as models strengthen (the honest bound). The strong-model era is absorbing the capacity side of construction: larger context windows, subagent orchestration, and native planning increasingly perform the navigation, the phase collapse, and the in-session generation the disciplines once supplied — a mechanical advantage that is capacity-relative and receding. The honest evidence is that on tractable work, disciplined structure and a strong expert prompt (which is GS content delivered through the prompt, without the persistent substrate) tie on single-shot median quality (§5.2); the one observed difference, architecture failures in 2 of 5 expert-prompt runs against none, is not statistically supported, and whether the substrate matters over a long horizon is an open hypothesis (§5.4). So the base claim is deliberately bounded: GS does not reliably produce better code than a frontier model, and increasingly need not. What it does produce — and what does not recede — is a system whose correctness a reader can ratify from outside the implementation: verified against a live runtime, auditable in its decisions, and regenerable from its specification. And the cost is stated plainly: it costs more to generate and recovers that in reading, changing, and auditing; the mechanical portion cheapens on its own as models strengthen. The stronger claim — that as models strengthen, the externalized, non-LLM guarantee and the regenerable spec imprint become the durable core of the discipline’s value — is developed as its own paper (The Externalized Guarantee); here it is only the honest bound that frames the evidence that follows. This stronger claim is a hypothesis (H-G), not a result. The one existence proof in this program is EX, a gate that caught fifteen defects in a single deployment. Against it, the independent-verification arm of RND-1 returned an honest null with a strong model (the model did not reward-hack and its own tests agreed with the held-out oracle), so the conditions under which an external non-LLM gate catches what model self-verification misses are not established; that is the experiment the claim is owed (Compendium §4.6).
The sentinel, and why it keeps the reader from degrading. Derivability is the goal — a stateless reader must be able to derive correct output from the specification alone. But there is a mechanism question underneath it: an AI session’s working context degrades as it fills — the more a session loads, the more its attention smears across irrelevant material and the less reliably it derives anything. Derivability in principle is worthless if the reader’s context is too polluted to exercise it. The mechanism that keeps the context clean is the sentinel navigational tree: a hierarchy of specification files (a canonical navigational tree, CNT, embedded in the agent’s prompts) in which each node declares its own scope and routes to its children, so a session loads only the slice the task needs instead of the whole corpus. Paired with a deliberately bounded tool surface — a small number of MCP tools rather than a sprawling set — it holds the working context small and high-signal. A well-formed tree carries five categories — architectural identity, standards, constraints and prohibitions, tool sequencing, and routing; tool sequencing is the most commonly absent and the most consequential gap, because a tree that lists tools without stating when to prefer one over another forces unreliable inference. The link is the point: derivability is the what, the sentinel plus bounded context is the how. The spec makes correct output derivable; the sentinel keeps the reader’s context clean enough to actually derive it.
The walls are correctness. Picture the verification pyramid — unit at the base, then integration, then end-to-end, contract, and non-functional at the peak. In GS its walls are made of correctness, and what raises them is the structural disciplines: the encoded, hard-won wisdom of expert veterans, shown to the agent as the shape it must build within. GS does not ask the agent to be a veteran. It shows the agent what veterans already know — the bridge is how that wisdom crosses over — and gates the output against it.
4.2 Cost Inversion
In traditional development, implementation accumulates a sunk cost; when a specification conflicts with a built system, the rational response is to amend the specification, because the code is load-bearing and the specification is not. GS inverts this. When regeneration is near-free, implementation carries no sunk cost: fix the specification and regenerate. Code becomes an implementation residue. The scarce resource is no longer the ability to write code; it is the ability to specify correctly. And specifying correctly is not a tooling skill — it is the hard-won experience of techniques, strategies, patterns, and concepts held above tools and syntax: the judgment of a serious practitioner about what a correct system is, which no framework or syntax fluency substitutes for. That capacity is the contended human value, and it is exactly what does not regenerate for free.
The specification’s canonical form is a contract. At its most precise the specification is not prose but an obligation-bearing contract — the top rung of the abstraction ladder that runs binary → assembly → high-level language → framework → specification, each rung trading mechanism for intent. It borrows two established formalisms: the requirement levels of RFC 2119/8174 (MUST, SHOULD, MAY and their negations, carrying force only in the uppercase) and the measurable-obligation structure of a service-level agreement (defined terms, testable acceptance criteria, consequences). What it takes is the rigor of a contract, not the verbosity of legalese — obligations a stateless reader can derive against and a gate can check, in plain language. From that contract root the document cascade derives; it is the form that makes the substrate’s specification precise enough to close the output space.
This raises an apparent contradiction worth resolving directly, because it is a feature in disguise. From an ordinary, non-GS codebase, the specification is not reliably recoverable: the decisions, the alternatives considered, and the accumulated rationale were never written down and resist reconstruction. But a codebase that fully satisfies the seven-property rubric is near-reconstructable — you can recover the specification from it, precisely because it is Auditable and carries the document cascade (ADRs, conventional commits, the navigation tree, the recorded rationale). Compliance is what closes the gap. So the two statements are not in tension: the spec is unrecoverable from a non-GS codebase; a fully compliant one is near-reconstructable — and that near-reconstructability is exactly what the discipline is for. It is a feature. The more of the seven properties a codebase earns, the less its specification depends on a separate document to survive.
At portfolio scale this compounds into specification bandwidth — the binding constraint shifts from execution capacity to the rate at which intent can be correctly externalized into a durable specification. A project in a waiting state (deploy running, output under review) demands no execution from the practitioner, so portfolio size is bounded by status management, not execution load. And because the specification certifies what a valid implementation state is while the executor supplies the how within that boundary, the correctness criterion becomes convergence, not inspection — what we call contract sufficiency: the reader navigates and verifies against the contract instead of reading the derivation line by line.
A directional model formalizes this: I ∝ (1−S)/S, where S is specification completeness — the fraction of the output space the specification closes — and I is the expected number of correction iterations. It is a mental model, not a formal result: no units, no proportionality constant, no magnitude prediction. What it communicates is direction — each freedom the specification leaves unclosed is an additional correction cycle, and the cost rises sharply as S falls toward zero. No experiment here tests it: the AX conditions were iterated by the author, so a rising score across them is the treatment being improved, not an independently measured S, and we do not offer that series as support (§5.2). Full treatment in Compendium §9.4.
The specificity dial (a design heuristic, untested). Completeness (how much of what must be true a specification states) and specificity (how much of the how it pins) are independent axes, and the second is a dial. At low specificity the generator has wide latitude and human verification can be light; at high specificity the latitude narrows, the specification grows denser and verification grows heavier, because a pinned mechanism must be checked against the pin. The proposal is not to maximize specificity but to set it to the required assurance of each component: over-specifying a low-stakes component wastes authoring and review effort, and under-specifying an irreversible one admits defects or moves the cost to review (Compendium §4.5.1). The Compendium reads the AX treatment-versus-expert difference as a move up the dial; we do not, because that difference is not statistically supported (§5.2). No experiment here varies specificity; a test would hold completeness fixed and vary specificity across components of different stakes, measuring defects that escape and human review time. Until then the dial is a mental model.
4.3 Token Economics and the Discipline-Role Taxonomy
The one substantive objection GS meets in the field is token expenditure: writing the specification, the cascade documents, and the tests, then regenerating, all appear token-expensive. The honest reconciliation has two parts. First, the binding metric is tokens-per-correct-output, not tokens-generated: without authored structure, a session burns tokens on discarded wrong code, re-explained context every cold start, and drift repair. Second — and observed directly in the field — under inversion of control the absolute spend rises because the practitioner advances faster; what is purchased is time, not tokens. Both are true and not in tension. The per-correct-output economy is a reasoned argument, not an end-to-end measurement: KX (§5.2) measures the retrieval component directly — authored structure navigated rather than re-derived — but the full-session figure is not measured here. A widely-circulated ~70% token-reduction claim was conceded unproven in the field (§6; see also Experiment Supplement §S13) and is deliberately not asserted; the defensible claim is the KX-measured retrieval economy plus the reasoned downstream argument.
The mechanism is retrieval economics. An authored specification is a member of the compact-knowledge-graph (CKG) family — a small, enumerable, closed-vocabulary structure the reader navigates instead of re-deriving from prose at every query. The term and the framing are Dan McCreary’s (Yarmoluk & McCreary, 2026), who benchmark it directly for knowledge retrieval: a pre-authored CKG costs ≈11× fewer tokens at ≈3.8× higher accuracy than chunked-prose RAG or query-time graph extraction, concluding that “when expert structure is available, the dynamic extraction step is wasted computation.” GS borrows the framing and generalizes the CKG’s single prerequisite relation to the executor’s full operating path: navigation across cascade documents, dependency direction, applicable disciplines, and inviolable constraints.
The same principle appears, unprompted, in production at scale. Uber’s public engineering account of its internal “software factory” (2026) reports an authored context graph its agents consult instead of re-deriving structure at query time (one structural query falling from over twenty minutes to under a minute), routes well-specified bounded subtasks to weaker, cheaper models while reserving a frontier model for decomposition, and denominates cost in outcomes — cost per merged pull request, revert rate — rather than raw tokens. Those are, respectively, the CKG/sentinel thesis, the model-tiering lever, and the tokens-per-correct-output metric of this section, converged on independently by a program of that scale. Their figures are cited as theirs and as corroboration of direction, never adopted as measurements here; the value is that the mechanism recurs where it was not looking for confirmation.
This frames a GS session as retrieve → generate → verify. The read side is a retrieval problem — the read-asymmetry (§4.1) made operational — attacked from both ends: authoring the structure (the navigation tree) and shaping the code to be retrievable (the disciplines), with a code-search engine as the traversal. The harness is the categorically distinct verify step — generative execution: the full test pyramid (unit, integration, E2E, mutation, contract, NFR) plus multimodal-AI-as-QA exercised against the live application, not assumed from compilation — which checks output against the specification. GS is therefore retrieval-augmented and verified generation, with the retrieval authored rather than inferred.
The verify step also covers the coherence of specification and code over time (design, with no measured effect). Divergence between the two is a verification problem and not a generation problem: it does not matter how the code was generated, it matters to detect that code and document stopped saying the same thing, and the mechanism has to live in files and in checks on the shared branch because a session forgets. The Compendium (§8.20) defines five checks that use no model. (1) Identifiers in both directions: every acceptance criterion has an identifier and a passing check, and every test that cites an identifier cites a live one, so an orphaned test (green, proving something no longer asked) is found. (2) The lock: each derived artifact carries a tag naming the specification section it came from, and one file records the hash of each section and of the version each artifact was derived against, so that a changed section marks its derived artifacts stale until they are regenerated or ratified. (3) A co-change gate: a commit that changes behavior cites a criterion, stages the specification change that is its citation, or declares itself a refactor and passes its parent’s tests unchanged. (4) An inverse inventory: every element of the public surface is claimed by some rule of the specification. (5) An intent diff in review: a report for the person who signs, listing the criteria touched, the derived artifacts that became stale and the criteria with no test. Only a ratification moves the hash of an existing artifact. Status: the five checks were implemented as deterministic scripts in one sample project and verified on 35 crafted scenarios (the assertions of one self-test script in that project, which grew from 22 to 35 when the lock scenarios were added) and on the recorded states of that project. That shows that they detect what they are defined to detect and not that they reduce defects; no effect was measured. False positives and costs were found (a typo fix in a criterion needs a ratification; inserting a criterion shifts positional identifiers and marks later artifacts stale; the refactor proof does not see an edge that no test pins). The checks detect that specification and code stopped coinciding. They cannot detect that the specification is wrong or that a test proves nothing, and an agent could run a ratification itself, so the real enforcement is a person’s review of the ratification record on the shared branch.
This sorts the seven properties by functional role:
- Verify (secure correctness): TDD, BDD, design by contract, type-driven design, and the enforcement gates → Verifiable, Defended, Executable. Enforced by hooks, CI, and the harness.
- Retrieve (the bridge), in three sub-roles:
- Legibility — read the what: naming, SOLID interfaces, hexagonal layering, ubiquitous language → Self-describing, Composable. Enforced by the navigation tree and a structural code index.
- Bounding — leave less to read: DRY/deduplication, dead-code elimination, YAGNI, small units → Bounded. A second, independent lever on token cost (a smaller surface, not just better navigation), enforced by automated deduplication and dead-code detection over the dependency graph. SX (§5.2) measures this lever directly: removing that surface lowers task cost even with the sentinel present on both twins — a cost no navigation map recovers.
- Decision-memory — read the why: ADRs, conventional commits, engineering decision records → Auditable. Enforced by the cascade documents.
Terminology: guides and sensors. Böckeler (2026) divides an agent’s harness into guides (feedforward) and sensors (feedback), each computational or inferential. Here the sentinel, specifications, instruction files and skills are guides; tests, linters, structural checks and gates are sensors, and “harness” used for the verification layer means the sensors. An instruction file is advisory, a hook is deterministic; both layers should derive from the same ratified specification, with the guides kept minimal. Böckeler, B. (2026). Harness engineering for coding agent users. martinfowler.com. https://martinfowler.com/articles/harness-engineering.html
A discipline may serve more than one role; the grouping is by dominant function. Naming the role explains why a codebase strong on verification yet weak on legibility and bounding still reads expensively; it classifies disciplines, whereas the audit-facing and engineering-layer grouping of §3 classifies the properties.
A corollary sharpens the boundary with prompt engineering. Much of what works in prompt engineering works because the prompt states constraints the model would otherwise leave open; to that extent an expert prompt is specification content delivered through a transient channel (§5.4). A few-shot example, likewise, is often a constraint not yet written down. GS’s claim is therefore about where that content should live (in durable, versioned, enforced artifacts, where it persists across sessions and people), not that prompting stops mattering: RND-1 (§5.2) shows that the wording of the specification itself, descriptive against prescriptive, changed the outcome from 0/3 to 3/3. We do not claim that a complete specification makes prompt engineering unnecessary; we claim that what a good prompt contains is specification, and that specification belongs in the substrate. The narrower claim we hold is a hypothesis (not yet tested, design only): a complete specification and substrate can simplify prompting to pure behavioral intent, because the structure (architecture, conventions, constraints, gates, decisions) lives in the substrate and is not repeated in each prompt. The single-shot expert-prompt tie does not test it; the long-horizon experiment H-S (§5.4) does, and it has not been run. The claim is capacity-relative: a stronger model needs fewer words of intent either way.
5. Evidence
The evidence is of different epistemic weight, so every result below states, in plain terms, how it was obtained and what it can support. We use the vocabulary of the ACM SIGSOFT Empirical Standards (Ralph et al., 2020) and of registered-report practice rather than a letter scale.
How to read the evidence statements
- Confirmatory or exploratory. A confirmatory study states its hypotheses and analysis plan before the data exist and can show a verifiable external timestamp (preregistration at a public registry, or a registered report accepted in principle; Chambers, 2013; Nosek et al., 2018; Empirical Standards, Registered Reports supplement). Anything else is exploratory: it can generate and illustrate hypotheses but does not test them. Every study reported here is exploratory. Where a design was committed to the repository before the data, we say so; a repository commit is not an external timestamp, and we do not call it preregistration.
- Design type. Controlled comparison: conditions assigned by the researcher, one factor varied (here without human participants; the Empirical Standards reserve “controlled experiment” for studies with participants). Quasi-experiment: comparison without random assignment. Observational: reported without a comparison condition or researcher control. Demonstration without comparison: one run showing that something can be done. Design only and not yet tested mark proposals.
- Runs, models, benchmarks, sites. We state the number of independent generations per condition (k), the number of models and benchmarks, and whether the work was done by one author. A run is one generation, not a participant.
- Replication. Following the Empirical Standards, a replication repeats a study with new data. It is internal when the same team does it and external when a different team does, and exact, methodological or conceptual by how closely it follows the original. No result here has been replicated externally. Runs repeated by the author are internal replications at best.
- Statistical status. Where a difference is tested we give the test, the corrected p and the effect size or interval; where it is not, we write “not distinguishable” (the data do not separate the conditions) or “not tested”. With five runs per cell the smallest exact two-sided p is 0.008, so a significant result means “no overlap in five draws”, not a precisely estimated magnitude.
- Logbook labels. The project’s experiment logbook keeps its own internal registration tiers and outcome labels (SUPPORTED, NULL, INCONCLUSIVE, INVALID-DESIGN, DEMONSTRATION), which say how far a design could have been bent and what the outcome licenses. This paper names the outcome in words; the logbook README in the repository (
docs/experiments/LOGBOOK) holds the internal tiers.
| Experiment | Design type | Registration | Runs, models, benchmarks | Statistical status |
|---|---|---|---|---|
| AX, three base conditions | Controlled comparison, no human participants | Exploratory. Design and ten predictions committed before the original single run (author-attested, no external timestamp); the k = 5 analysis pre-specified in intent only | k = 5 per condition, one model, one benchmark, one author | Naive versus GS distinguished on structural metrics (Holm p = 0.024, Cliff’s delta = 1.0); GS versus expert prompt not distinguishable |
| AX, post-hoc series (v2 onward) | Iterated diagnostic, each condition designed after seeing the last | Exploratory | One run per condition | Not tested; not an effect size |
| AX2 | Controlled comparison across vendors; an internal, conceptual replication of AX’s structural contrast | Exploratory | 45 runs: 3 vendors, 3 conditions, 5 per cell; one benchmark; one harness | Medians only; naive separated from both structured conditions on static metrics; GS versus expert prompt not distinguishable (saturated); runtime metrics withdrawn |
| CR | Controlled comparison along a capacity ladder, invented benchmark | Exploratory. Prediction committed to the repository before the first run (no external timestamp) | k = 3 per cell, one weak model to three frontier models, one benchmark | Duplication and complexity point as predicted but are inconclusive at k = 3; behaviour and layer metric uninformative |
| KX | Controlled comparison of retrieval conditions | Exploratory | One model, one system, a fresh session per query | Tokens and dollars per query lower with the routed map on this model; accuracy is not reported as evidence because the answer key derives from the structure under test |
| TX | Twin comparison (behaviour-preserving), single system | Exploratory | One system, one small and one capable model | Not tested; mechanism demonstration |
| SX | Twin comparison, surface axis | Exploratory | n = 2, one frontier model, one system | Not tested; mechanism demonstration (search cost lower with the map; surface residual inconclusive) |
| BX | Observational cross-check | Exploratory | n = 3 implementations, one rubric | Not tested; no validity evidence yet |
| EX | Demonstration without comparison | Exploratory | One run, one system | Not applicable |
| RX | Demonstration without comparison (reproduction recipe) | Exploratory | One recorded regeneration; no external replication reported | Not applicable |
| ALX | Demonstration without comparison | Exploratory; backfilled from the ledger | One derivation, six correction phases | Not applicable |
| MX | Single-run comparison of two models | Exploratory | n = 1 per arm, one benchmark | Not tested; both arms at the ceiling |
| RND-1 | Single-shot comparison (descriptive versus prescriptive specification) | Exploratory | n = 1 per condition | Not tested; the prescriptive result is close to definitional |
| Production projects and the workshop | Observational | Not applicable | Six projects; one eight-developer cohort | Not applicable |
The six production projects are the source from which the methodology was derived (observational). The controlled and demonstration experiments were conducted after the methodology stabilized; their design commitments are described per experiment below, including where those commitments cannot be independently timestamped. Two of them, TX and SX, form a matched pair on the read-and-modify side: TX varies organization at fixed content (and finds layering alone does not cheapen reading), SX varies content quality (and finds that de-inflating a codebase does), together decomposing the economy into a navigation lever and a bounding lever.
The experiments at a glance. Each row’s claim is independently checkable against the linked evidence; the final column states, in plain terms, what the result means for a practitioner.
| Experiment | Claim it tests | Key result | What it means |
|---|---|---|---|
| AX | Structured specification beats unstructured use, and an expert prompt | Three base conditions, k = 5: layer violations 45 → 0, files 21 → 55 vs naive; no difference from an expert prompt on median quality (audit 11 vs 10; a tie at the ceiling). The 3/14 → 14/14 path comes from iterated post-hoc runs, not an effect size | Structure beats no structure on structural and completeness metrics. A strong expert prompt ties it on single-shot median quality: the separation is naive-to-disciplined. |
| EX | Deployable and operable in production | 13/13 behavioral probes (1,013 assertions), 6/6 SLO gates on a live runtime | The generated system actually shipped and held its performance targets under load. |
| KX | Authored structure is cheaper to retrieve from | tokens per query 78.6k vs 100k vs 234k (1.3× and 3.0× fewer); dollars per query $0.10 vs $0.56 vs $0.24 (5.5× and 2.4× lower), on one model. Accuracy is not reported as evidence: the answer key came from the structure under test | Navigating an authored map was cheaper per structural query than dumping the code or searching it, on this model. Nothing is claimed about accuracy. |
| TX (twin, organization axis) | What disciplined layering contributes at fixed content | layering alone did not cut read cost; on a weak model, Bounded units + contract gates preserved correctness where the undisciplined twin silently shipped broken | Reorganizing at fixed content is not the win — the authored map and the gates are, and they matter most on weaker models and larger, tangled tasks. |
| SX (twin, surface axis, n=2) | What surface (duplication, dead code) costs, vs navigation | with the map on both twins, the industry-average-bloated twin still cost ~2.4x tokens and 3.5x edits (7 vs 2); the sentinel fixes search, not surface | De-inflating the code (removing duplication) cuts cost beyond what any map can — the bounding lever, and it holds on a frontier model. |
| AX2 (cross-vendor; naive, expert, GS; n = 5 per cell) | The structural separation is not a single-model artifact | median layer violations 30 to 35 → 0 on all three vendors; duplication and complexity down; the expert prompt ties GS; runtime metrics withdrawn | Structure beats no structure across vendors on static metrics. It does not show that GS beats an expert prompt. |
| CR (capacity ladder, invented benchmark, k = 3) | The scaffolding benefit is capacity-relative | duplication benefit about +14.5 points at the weak rung → about 0 at the frontier, inconclusive at k = 3; behaviour and layer metric uninformative, GS ≤ naive on behaviour at hosted rungs | The duplication and complexity differences point toward “recedes as models strengthen” but are inconclusive at this sample size; nothing is shown on behaviour. |
| ALX | Derivability holds at the formal, machine-checkable tier | a compiler derived from its own specification; 386/386 acceptance tests | The method works even where “correct” means cargo test, not a rubric — a compiler built from its own spec. |
| RX | Independently reproducible | 104 tests regenerated from the committed spec by a third party | Anyone with an API key can press a button and rebuild the result — it’s not the author’s word. |
| BX | The rubric is author-independent | n = 3; rubric rankings congruent with external metrics, on repositories where the check is partly circular | No validity evidence yet: n = 3 and circular for one repository (inconclusive); rubric validity is an open question. |
| MX (single-shot, n = 1) | The effect is model-agnostic | a mid-tier model matched a strong one, 149/149, at ≈6× lower cost | On a memorized task both arms were at the ceiling (the contrast is uninformative) and the tiering result is inconclusive; nothing is inferred about specification versus model size. |
| RND-1 (single-shot, n = 1) | Prescriptive specification suppresses corner-cutting | descriptive 0/3 → prescriptive 3/3 at equal token cost | A prescriptive specification recovered the intent where a descriptive one did not (close to definitional: the text states what the oracle checks). Independent verification found no test-faking to catch (n = 2, floor effect). No claim that the complaint is fixed. |
5.1 Production Projects (Discovery)
The six production projects are the source from which the properties were derived: real systems built or refactored under maturing versions of the discipline, each surfacing a failure mode that became a property (Compendium §7.1 to §7.7). SafetyCorePro (a takeover of an existing system; Defended), Invellum (a brownfield system; Bounded), Conclave (a complex greenfield system; Composable), BRAD (an extension to a legal-intelligence engine; Self-describing), Shattered Stars (a migration of a Unity/C# arcade game to TypeScript and Phaser; Auditable), and a Regulated Multi-Layer Data Platform (specification-derived infrastructure for a public-sector data platform; Executable). A seventh system, ForgeCraft (the methodology’s own tooling), is the self-application case and is not counted among the six.
These are not evidence of effect, and we mark them so. They are observational: author-built, author-evaluated, built under early versions of the discipline, with no comparison condition. Two of them (Conclave and a confidential client system informally referred to as lumen) are client-confidential, so a reader cannot inspect them at all; for the others the reader cannot verify from this paper what the author reports of them. We therefore describe them to explain where the seven properties came from and we draw no conclusion from them about whether the properties work. The confirmatory weight, such as it is, rests on §5.2.
5.2 Controlled Experiments (Testing)
AX: structured specification versus unstructured use, and versus an expert prompt (controlled comparison, exploratory, for the three base conditions; iterated diagnostic, exploratory, for everything after them).
Design. The task is to generate the complete RealWorld “Conduit” backend (JWT authentication, profiles, articles with slugs, comments, tags, favourites, following) in TypeScript, Express and Prisma against a live PostgreSQL 15 container, from the benchmark’s published API specification, in a fixed sequence of prompts. The model is the same in every condition (claude-sonnet-4-5), with no tool use during generation; files are emitted as path-annotated code blocks that a runner materializes, so an emitted block without a path header is a file that does not exist. The three conditions differ only in the specification context supplied. Naive: the specification and a three-line README; six prompts of about four lines. Control (expert prompt): the specification and a detailed README stating the stack, the layering boundary (no direct database-client calls in route files), the error contract, naming and an 80% coverage target; seven prompts of about thirty lines. Treatment (GS v1): the specification and a 17-file cascade (constitution, status file, predefined schema, four ADRs, C4 and sequence diagrams, fourteen use cases with acceptance criteria, test architecture, non-functional requirements, technical specification); six short prompts. The control is deliberately strong: it holds what a senior engineer would put in a prompt, including the layering rule that the layer-violation metric counts, which is why that metric favors both structured conditions over the naive one by construction (§6).
Runs, registration and scoring. The original design (March 2026) generated one run per condition, with the design, the rubric and ten point predictions committed before the runs. Those commit identifiers are recorded in the Supplement (§S1) but are not present in the public repository, whose history begins on 16 March 2026, so that registration is author-attested, not independently timestamped. The three conditions were then re-run as k = 5 independent generations each (data committed in September 2026) and analyzed with exact two-sided Mann-Whitney U tests, Cliff’s delta and Holm correction (Holm, 1979) within each metric’s three pairwise comparisons. We cannot establish from commit history that the replication’s analysis plan preceded its runs, so we call the replication pre-specified in intent and do not call it registered. The metrics are computed by committed scripts: layer-boundary violations (a count of prisma.* calls in route files), files and test files emitted, strict type errors, lint problems, dependency vulnerabilities, generation cost. Mutation score and executed coverage were planned for the replication but were not obtained for its control and treatment runs (the fields are empty in the committed data), so they are not reported for it. A seven-property audit (each property scored 0 to 2, a 14-point total; an instrument since retired as a scorecard, §3) is a secondary instrument. “Blind” has a limited meaning here: two fresh sessions of the same model family, given only the project directory and no knowledge of the study or of GS, scored each project; the artifacts usually reveal the condition (a constitution file, ADRs), and the two auditors are two runs of one prompt, not independent raters. Their agreement is a quadratic-weighted kappa of 0.62 over 105 property-level pairs (15 projects by 7 properties).
Results of the k = 5 re-run, an internal replication of the three base conditions (k = 5 per condition; median [interquartile range]).
| Metric | Naive | Expert prompt | GS v1 | Naive vs GS (Holm p) | Expert vs GS (Holm p) |
|---|---|---|---|---|---|
| Layer-boundary violations (lower better) | 45 [41.5, 46] | 0 [0, 49] | 0 [0, 0] | 0.024 | 0.89 |
| Files emitted | 21 [17.5, 21.5] | 41 [40, 46.5] | 55 [46.5, 58] | 0.024 | 0.095 |
| Test files emitted | 5 [5, 5.5] | 11 [10.5, 14] | 13 [10.5, 15] | 0.024 | 0.57 |
| Blind audit, 0 to 14 (session 1) | 5 [4.5, 7.5] | 10 [9.5, 11] | 11 [6.5, 12] | 0.27 | 0.57 |
| ESLint problems per TS file (lower better) | 2.13 [0.74, 2.23] | 0.45 [0.36, 0.80] | 0.62 [0.49, 0.89] | 0.27 | 0.50 |
| Generation cost, USD per run (lower better) | 0.65 [0.53, 0.70] | 1.34 [1.28, 1.43] | 1.89 [1.67, 1.95] | 0.024 | 0.024 |
Against unstructured use the separation is complete on the structural and completeness metrics (Cliff’s delta = 1.0, exact p = 0.008, Holm 0.024). At five runs against five, 0.008 is the smallest exact p that exists, so this means “no overlap in five draws”, not a tightly estimated magnitude. On the blind audit the naive-versus-GS difference is not significant (Holm p = 0.27; the GS runs scored from 3 to 12), and on vulnerabilities and lint the three conditions do not separate. Against the expert prompt, no difference survives correction on the audit score, files, test files, or median layer violations. The expert prompt breached the layer boundary in 2 of 5 runs (46 and 52 calls) and the full cascade in 0 of 5; with five runs that difference is not statistically supported (Holm p = 0.89), so it is an observation consistent with a reliability effect, not a demonstrated one. Per generation, the cascade costs about 2.9 times the naive run and 1.4 times the expert prompt; the return, if any, is not on these metrics. The honest summary is that the separation is naive-to-disciplined, and a strong expert prompt ties GS on these single-shot metrics.
The original single run and the post-hoc series (iterated diagnostic, exploratory). In the original single run the naive condition scored 3/14 (its test suites did not compile, because several schema models were written in blocks without path headers and so were never emitted), the control 9/14 and the GS v1 treatment 10/14. GS’s only audit advantage was Composable (interface-based injection); the control’s executed line coverage was higher (34% versus 28%), and 6 of the treatment’s 10 suites were blocked by one typing error. Of the ten point predictions registered for that design, three were confirmed; the Supplement attributes four of the misses to ceiling or floor effects (the expert control was stronger than anticipated). Five further conditions (v2, v3, v4, v5, v6) were then run, one run each, each after a gap analysis of its predecessors, and scored 13, 14, 11, 14 and 13 out of 14 (a non-monotonic path). The v3 score of 14 is inferred by the auditor from static artifacts; the v5 score is runner-verified (109 tests passing, 106 on an independent re-run). This series is the source of the “3/14 to 14/14” figure, and it is a diagnostic series, not an effect size: the conditions were designed with full knowledge of the earlier gaps, there is one run per condition, and the specification author, the experimenter and the rubric author are the same person. What it shows is that each observed gap could be named and closed by editing the specification. A ninth condition replaced the hand-authored cascade with one generated by tooling with no hand-tuning and reached comparable objective results in one run (211 tests, 99.08% executed statement coverage, no layer violations, 11 of 11 live use-case probes), which is a construction-invariance demonstration at n = 1.
What AX does and does not support. It supports the claim that authored structure, of either kind, beats unstructured use on structural and completeness metrics for this task and model. It does not support a claim that GS beats a strong expert prompt on median quality, and it does not test the questions listed in §5.4. Evidence: experiments/ax (runner/results.csv, runner/stats.json, per-run JSON, audits, generated harnesses); Supplement §S5, §S6, §S11.
EX — the result is deployable and operable in production. A Conduit backend specified, generated, verified, and deployed to a live cloud runtime (April 2026), the harness driving the full development→staging→production cycle. Level 2: 13/13 behavioral (Hurl) probes carrying 1,013 assertions, derived from use-case acceptance criteria, against the deployed service. Level 3: 3/3 environment-governance probes (configuration, secret hygiene, reachability). Level 4: 6/6 service-level-objective gates under load (aggregate p95 350 ms, p99 720 ms, error rate 0.04%). Fifteen defects were surfaced by failing probes and fixed before the cycle could close. This is the Executable property earned against a running system, not assumed from compilation. What it means: the specification did not just produce code that compiles — it produced a service that shipped, met its latency and error targets under load, and caught fifteen real defects on the way. Evidence: experiments/ex (Hurl probes, slo-ramp-summary.json, deploy logs).
KX — authored structure is cheaper to retrieve from (knowledge-retrieval comparison, exploratory). The CKG benchmark method run on a GS software harness across three conditions, each a fresh agent session per query: a routed navigation tree (CKG analog) used 78.6k tokens/query, against everything-in-context (RAG-dump: 100k) and code-search-at-query-time (no-structure: 233k). Accuracy scores were also computed (macro-F1 0.808, 0.611 and 0.431) but are not offered as evidence, because the answer key for structural queries derives from the same structure the routed condition reads; only tokens and cost are claimed. Two cost figures are reported and they differ. In tokens (input, output, cache-creation and cache-read tokens counted equally) the routed condition used 3.0× fewer than the unstructured condition (233,583 → 78,603) and 1.3× fewer than the in-context dump (100,237 → 78,603). In dollars it was 5.5× cheaper than the dump ($0.10 versus $0.56 per query) and 2.4× cheaper than the unstructured condition ($0.10 versus $0.24). The dollar gap to the dump exceeds the token gap because, on average, about 78k of the dump’s 100k tokens were billed as cache creation against about 7k for the routed condition, which mostly read cached tokens; dollars depend on a provider’s cache pricing and are the less portable figure. The claim is deliberately bounded: explicit structure beats inferred structure on structural queries, not general superiority. What it means: giving the agent an authored map of the system, rather than the whole codebase or a search box, made answering questions about that system cheaper (up to three times fewer tokens on this model) — the absence of structure was the most expensive condition tested. Nothing is claimed about accuracy. Evidence: experiments/kx (per-query token counts, macro-F1 by condition); the full replication of the Yarmoluk–McCreary CKG benchmark on a GS software harness is developed in Compendium §7.8.E.
TX — what disciplined structure contributes to reading and construction (behavior-preserving twin study, single system). One representative undisciplined generation of the Conduit backend (a 489-line route file concentrating article, favourite, and feed logic) was refactored into a behavior-preserving disciplined twin (layered domain/application/infrastructure, repository interfaces, small units, a centralized response builder); behavioral equivalence was fixed by a shared conformance suite passing identically on both. Two findings. First, a boundary: disciplined layering alone, at fixed content, did not lower a stateless reader’s cold-read cost — the disciplined twin read equal or slightly more files, because one concern is spread across several small files — so the read economy belongs to the authored navigation (the sentinel) and the contracts, not to layering as such. (SX, below, varies the other axis, content quality, and finds the complementary lever.) Second, the construction effect is capacity-relative: given a cross-cutting change on a small local model, the undisciplined twin was regenerated truncated (two of eight route handlers retained, most of the API dropped, still compiling, because untyped code carries no contract to violate), while the disciplined twin’s small units regenerated whole and its type contracts turned the same model’s error into a compile failure a human or a loop then corrects; a capable model on the same small system showed no difference. What it means: clean structure by itself is not the payoff — the authored map plus the gates are, and their value is largest exactly where you are weakest (a cheaper or self-hosted model, a larger or more entangled system), which is also the honest boundary of the read-cost claim. Single benchmark, one small and one capable model, one system; the mechanism is demonstrated, the effect size across benchmarks is future work. Evidence: experiments/ax/bridge (RESULTS.md, per-arm data); full treatment in Compendium §7.8.J.
SX — what surface costs, versus navigation (behavior-preserving twin study, surface axis, n=2). Where TX held content fixed and varied organization, SX holds organization roughly fixed and varies content quality: a clean GS-disciplined Conduit backend against a twin degraded to the industry-average state of a real project, calibrated to published norms across eight dimensions (~13% live code duplication, a few God-methods at cyclomatic complexity 20-40, ~17% dead code, ~38% coverage with modules at zero, ~15-20% comment density with drift, mixed architectural patterns and styles, ~1-year-stale dependencies — each recorded with its citation), so the degradation is representative, not adversarial. Both twins pass the shared oracle 13/13, so they differ only in surface. Task: add a computed field to every article response — one edit against the clean twin’s centralized builder, five live duplicated copies to reconcile on the degraded one. Runs are agentic (frontier model) under a three-level sentinel ablation (no map / map on the clean twin only / map on both), cost measured as tokens-to-complete. Two findings. First, the sentinel fixes the search cost, on both twins (localization tokens collapse ~3x with the map) — the KX/authored-structure result again, and the reason query-time code search is superseded. Second, the sentinel does not fix the surface cost: with the map on both twins the degraded twin still costs ~2.4x the tokens and 3.5x the edits (seven versus two), because the change must reach the five duplicated copies — a cost only refactoring removes. What it means: a GS project with its map versus an average project without one is ~6x on the same change; even map-for-map, ordered code costs ~2.4x less and a third the edits — and it holds on a frontier model, so this lever is structural, not capacity-relative. Coherence held (the frontier model pays rather than drops a copy); the coherence failure mode is the weaker-model story TX already shows, left to future work. Single benchmark, one frontier model, n=2 — a mechanism demonstration. Evidence: experiments/sx (RESULTS.md, calibration.json); full treatment in Compendium §7.8.K.
AX2: cross-vendor structural comparison (controlled comparison, exploratory; an internal, conceptual replication of AX’s structural contrast). To test whether the AX separation is a single-model artifact, 45 Conduit backends were generated (three vendors, three conditions, five runs each): recorded as gpt-5.6-sol, gemini-3.8-flash and claude-opus-4.8, each run as a fresh sub-agent inside one agent harness (GitHub Copilot CLI), under the naive, expert-prompt and mature-GS conditions. Only convention-independent static metrics are comparable across heterogeneous projects, so only they are reported: layer-boundary violations, duplication, cyclomatic complexity and test files. In the naive condition the median layer violations were 33 (Claude), 35 (Gemini) and 30 (GPT; two of its five naive runs had none); across the expert and GS conditions together there were none in all 30 runs. Mean duplication fell from 7.9%, 17.1% and 5.2% (naive; Claude, Gemini, GPT) to between 0.4% and 6.3% in the expert and GS conditions, and complexity fell. The expert and GS conditions are saturated against each other, and on some cells the expert prompt is better (Gemini mean duplication 2.6% against 6.3%), so the separation is again naive-to-disciplined and not GS-over-expert. Limits: five runs per cell where the protocol targeted twelve to fifteen; one benchmark; vendor and harness are confounded (one harness for all three); the GS condition supplied the cascade as prompting and did not run an enforced verification loop; and the runtime metrics (coverage, mutation score, a strict behavioural oracle) produced no comparable numbers, because the oracle measured REST-convention conformance (0 of 13 on functional apps) and coverage was dominated by test-infrastructure failures, so those sub-metrics are withdrawn and not reported. Evidence: experiments/ax2, experiments/ax/runner/static_ax2.json.
CR: a capacity ladder on a non-memorized benchmark (controlled comparison, exploratory). To address the memorization threat and to test whether the scaffolding benefit depends on model capacity, CR uses an invented domain, “Pastura” (a rangeland grazing-rotation API with temporal business rules and no public implementation), and a ladder from a small local model (qwen2.5-coder 7B) through a mid model to three frontier models, each under a naive and a GS condition, k = 3 per cell, medians reported. The design and the prediction were committed on 17 September 2026 (commit c4c855e) before any CR run. On the structural-cleanliness axis the prediction held: the duplication benefit (naive minus GS) was +14.5 percentage points at the weak rung and about zero at the mid and frontier rungs (-1.2, -3.5 and 0 for the three frontier models), and the cyclomatic-complexity benefit was +0.63 at the weak rung against +0.07 to +0.16 above it. The predicted gradient did not appear elsewhere: layer violations were zero in both arms at every rung (the metric never fired on this benchmark, unlike Conduit), the behavioural oracle gave no weak-rung signal (neither arm’s apps served) and GS scored equal to or below naive on it at every hosted rung (for example -1 of 6 for the GPT mid model and for two of the three frontier models), and test files moved against the prediction. Limits: k = 3; the GS arm at the weak rung was highly dispersed (one 32-file app, one 5-file app, one empty project); one benchmark; one weak model (a 32B rung was dropped for lack of VRAM); and the contamination canary that the design calls for has no results file in the repository, so non-memorization rests on the invented domain and the unpublished specification and not on a measured recall. The write-up is not yet in the Compendium’s §7.8 series. Evidence: experiments/cr (RESULTS-final.md).
What the capacity studies support together. TX shows, on one system, a small model silently truncating the undisciplined twin while the disciplined twin’s units and type contracts kept it coherent. CR finds, on a second and non-memorized benchmark, duplication and complexity differences that point the same way (about +14.5 points of duplication at the weakest rung, about zero at the frontier) but are inconclusive at k = 3, with behaviour and the layer metric uninformative. AX2 shows that the naive-to-disciplined structural separation is not specific to one vendor, though because the expert prompt ties GS there it speaks to structure against no structure and not to GS against a prompt. Read together they are consistent with, and do not establish, the claim that the mechanical, structural benefit is capacity-relative and recedes as models strengthen. Each has the limits stated above, and none is a powered estimate of how fast it recedes.
ALX — derivability holds at the formal, machine-checkable tier. Loom is the formal-tier specification language of the GS ecosystem — a language precise enough that its own compiler can be derived from its specification; ALX is exactly that compiler, generated from Loom’s spec alone (github.com/jghiringhelli/loom). A complete compiler for the Loom language was derived from its own formal specification alone (cargo check passed on first emission). The contribution is the correction curve from specification gaps to S_realized = 1.0 (0.000 → 0.339 → 0.642 → 0.781 → 0.900 → 1.000 across six phases, terminating at 386/386 acceptance tests). Each correction was a specification improvement, not a code patch — enumerating exactly which classes of detail a formal specification must carry to be machine-derivable. This is spec derivability demonstrated at the machine-checkable layer above natural language, where conformance is cargo test, not a rubric. What it means: the discipline is not a trick of fuzzy natural-language grading — it holds where “correct” is decided by a compiler, all the way to a working compiler built from nothing but its own spec. Evidence: experiments/alx in the public Loom repository (spec, derived source, and correction log committed).
RX — the result is independently reproducible. From a single committed specification, any reader with Docker, Node, and an API key regenerates 104 passing tests across seven suites (recorded run March 2026), with committed evidence (jest-output.json, score.json, build log) under experiments/rx. The result does not rest on the author’s word; it is a button a third party can press. What it means: reproducibility here is literal — you can rebuild the whole result yourself from the spec, without trusting anyone.
BX — the rubric measures something independent of its author (blind cross-validation). Three community implementations never exposed to GS were scored on the rubric; the rankings were congruent with independent external metrics (CVE count, test count, type-health) — a preliminary cross-check (n = 3, circular for one repository). What it means: there is no validity evidence for the rubric yet. Three cases cannot separate the rubric from the author’s preferences, and rubric validity is an open question. Evidence: experiments/bx (per-implementation scores and external metrics).
MX and RND-1 — two June-2026 single-shot experiments (n = 1, complete and reproducible; weighted below the larger set above for their scale, not for being preliminary, and reported as such). RND-1 addresses the most common practitioner objection — that AI agents cut corners. Under explicit speed-and-token pressure, a descriptive specification let the model floor to the literal minimum (0/3 against a held-out acceptance oracle) while a prescriptive one — the same task, the intent made explicit — recovered the full intent (3/3) at equal token cost; separately, a stateless external judge confirmed that genuine reward-hacking (vacuous or improperly-mocked tests) did not survive independent verification — the reward-hacking failure mode now catalogued by ImpossibleBench, EvilGenie (arXiv:2511.21654), and the Reward Hacking Benchmark (arXiv:2605.02964). What it means: a prescriptive specification recovered the intent where a descriptive one did not, which is close to definitional because the text states what the oracle checks; independent verification found nothing to catch (a floor effect, n = 2). We do not claim the complaint is fixed. MX holds the GS specification constant and varies only the model: a mid-tier model matched a strong model at 149/149 on the full Conduit backend for ≈6× lower cost — on a memorized task where both arms were at the ceiling, so the contrast is uninformative, and with the tiering result inconclusive. What it means: nothing is inferred about specification versus model size; whether the effect is a property of the specification rather than of any one model remains untested. Both are committed and reproducible — experiments/rnd-1/ and experiments/mx/.
5.3 Field Corroboration (Observational)
A four-day GS workshop delivered to a paying eight-developer cohort at an insurance brokerage (June 2026) is reported as observational evidence, distinct from the controlled program (no control, no blind scoring, single self-selected cohort). It cannot test a hypothesis; it shows whether the controlled findings recur when GS meets a real team on its own code — and it is the paper’s evidence for practitioner transfer: eight developers who had never seen the discipline applied it, in a single engagement, to code they owned. That leg is observational, not a controlled result. On the greenfield day, every demonstrated project produced a running artifact within a single morning, and residual defects traced to under-specification or a missing asset rather than to the method — one participant diagnosing his own failed build without prompting: “it is absolutely my fault, because I did not specify it correctly.” By the brownfield day every participant had mapped GS onto a production system, and one instituted a process change of his own accord, making an architecture decision record a merge prerequisite. The token objection recurred with a consistent trajectory — caution, an acute mid-workshop episode of exhausted budgets, then qualified willingness to adopt — corroborating the time-not-tokens reconciliation of §4.3. What it means: when the method met a real team on their own code, it behaved the way the controlled results predict — the failures were specification failures the developers could see and own.
5.4 What the expert-prompt tie does and does not test
An expert prompt is GS content delivered through the prompt. The AX control states the stack, the layering rule, the error contract, the naming conventions and a coverage target: the same obligations a GS constitution states, without the persistent substrate (the cascade of files, the sentinel, the gates, the lock, the audit trail). The control is therefore not an independent alternative to GS; it is GS without its substrate. The tie reported in §5.2 says that, for a single-shot, short-horizon generation of a well-specified mid-complexity system by a capable model, it is the content that matters on the measured metrics and the vehicle that carries it makes no measurable difference.
That is all it says. It does not test:
- Who knows what to put in the prompt. The control prompt was written by the method’s author, who knows which obligations matter. Whether a practitioner without that knowledge writes a prompt of the same quality is not tested, and the knowledge of which obligations to state is exactly what the seven properties are meant to teach.
- Whether quality persists across many iterations on a large project. AX is six or seven prompts for a system small enough to hold in context. SlopCodeBench (Orlanski et al., 2026) reports that agent code degrades under iterative extension and that quality guidance reduces verbosity and erosion by up to a third without removing them; whether a substrate arrests it is not tested here.
- Continuity across sessions and across people. A prompt lives in a session. A substrate lives in the repository and is read by whoever, or whatever, arrives next. AX has one session per generation and one author.
- Governance and auditability. A prompt leaves no durable, reviewable, version-tied record of what was required and why. None of the AX metrics measures whether a third party could ratify the result or reconstruct its rationale.
An open hypothesis (H-S), stated so that it can fail. Over a long horizon, a project that carries the persistent substrate shows less structural degradation and better preserved intent than the same project driven by an expert prompt containing the same obligations word for word. A fair test would hold the obligations fixed and vary the increments one at a time: the prompt supplied in-session; the same text persisted as a file; plus enforcing gates; plus the derivation lock and ratification record. It would run many sequential feature iterations on a project too large for the context window, with sessions and contributors rotating, and measure layer violations, duplication, complexity, mutation score on changed code, criteria coverage (Compendium §8.19), regressions per iteration, and whether a newcomer can reconstruct the reasons for earlier decisions. The prediction is no difference at the first iteration (the AX tie) and a divergence that grows with iterations. It is refuted if the prompt arm tracks the substrate arm across the horizon, in which case the substrate adds nothing measurable on these axes and its value is confined to governance and continuity, which would then need their own evidence. H-S has not been run. It is a hypothesis, not a result, and nothing in this paper depends on it being true. The boundary between prompt and substrate is also a continuum (a prompt persisted in a repository file is already a minimal substrate), so the experiment concerns the increments, not a binary.
6. Threats to Validity
The threats are organized after Wohlin et al.’s four categories, with one paragraph each stating the threat and what mitigates it, or that nothing does. The most serious is that the author designed the method, wrote the specifications, the rubric and the audit prompts, ran every experiment and scored the results; there is no independent party in this program.
Construct validity. Each metric proxies a narrower construct than “quality”. The layer-violation metric counts prisma.* calls in route files, which is the rule that the control and treatment prompts state; it is targeted by the treatment and favors both structured conditions over the naive one by construction. The seven-property audit is the author’s rubric applied by two runs of one prompt by a model of the generator’s family; its kappa of 0.62 is run-to-run consistency and not agreement between independent raters, and the artifacts reveal the condition. Mutation score and executed coverage were not obtained for the replication, and the one mutation progression reported (58.6% to 93.1% on one services layer) was produced by model-written tests repaired until the score rose, so it shows that mutation testing detects weak tests and not that GS caused better ones. In AX the emit rule that makes a file exist was imposed in the structured conditions and not in the naive one. KX’s ground truth for structural queries derives from the same structure the routed condition reads, so its claim is bounded: explicit structure beats inferred structure on structural queries, not general superiority.
Internal validity. GS guided the implementations and supplied the rubric (guidance circularity). BX applies the rubric to three implementations that GS never guided and finds the rankings congruent with rubric-independent metrics (CVE count, test count, type health, complexity); at n = 3 that is a feasibility check. The post-hoc AX conditions were designed with knowledge of the earlier gaps and are one run each. The original registration is author-attested (its commits are not in the public repository’s history) and the replication’s analysis plan cannot be shown to precede its runs. The expert-prompt control is GS content delivered without the substrate and was written by the method’s author, so the tie with it bounds the claim to single-shot, short-horizon generation and leaves the substrate question open (§5.4).
External validity. One benchmark: the RealWorld “Conduit” backend, which exists in dozens of public implementations that the models very likely saw in training (the Supplement says so). Memorization is therefore not ruled out for AX, EX, KX, TX, SX or MX. Results are predominantly one model family (Claude); MX and RND-1 are single-shot (n = 1); human-participant evidence is observational only (§5.3).
Conclusion validity. At five runs against five the smallest exact two-sided p is 0.008, so a Cliff’s delta of 1.0 means no overlap in five draws and not a tightly estimated magnitude; Holm correction is applied within each metric’s three comparisons and not across the many metrics; the observed 0/5 against 2/5 architecture failures is not statistically supported (Holm p = 0.89). Single-run results are examples and not rates. The 3/14 to 14/14 series is diagnostic. The inverse-effort relation between specification completeness and correction cost is a directional mental model, not a formal result. The ~70% token-reduction figure circulated in the field is conceded unproven and deliberately not asserted; the binding metric is tokens-per-correct-output, not tokens generated.
Scope of the twin studies and the production projects. TX and SX are single-benchmark mechanism studies (TX one small and one capable model; SX one frontier model at n = 2); they show that the navigation and bounding levers operate and mark the read-cost boundary, and their effect sizes across benchmarks are future work, as is SX’s weak-model coherence-failure arm. The six production projects are observational (§5.1).
7. Implications for Practice
The specification precedes the code. The architectural constitution, structural diagrams, schema definitions, and at least a skeleton decision record must exist before the first agent session. This is not new; it was optional when the cost of skipping it was paid by a human who could compensate with memory. That compensation is unavailable to a stateless executor.
The document cascade. The individual artifacts below are established practice — every mature team writes ADRs, diagrams, and schemas. What GS changes is their role. They are not documentation about the code; they are the specification the code is derived from — authored first, the source of truth from which the implementation is regenerated (the inversion of §4.2). And together they are the read-asymmetry (§4.1) made concrete: the layered structural surface the stateless reader comprehends the system through, instead of reading the implementation. The novelty is the inversion and the read-surface, not the list of artifacts:
| Document | What it specifies / is used for | Authored |
|---|---|---|
Architectural constitution (the sentinel root — CLAUDE.md / AGENTS.md / .cursor/rules) | The grammar: identity, standards, inviolable constraints, tool sequencing, routing. Governs every session. | First — before any code |
| Sentinel navigational tree | The scoped child specs the root routes to, so a session loads only the slice its task needs. | With the constitution |
| Architecture Decision Records (ADRs) | The why — so the agent does not “correct” an intentional decision it lacks the context for. | At each decision; ongoing |
| Structural diagrams (C4) | The system at a glance — context for any agent entering the codebase. | Up front; revised on change |
| Use-case / sequence / state diagrams | Protocols (which calls, in which order), user journeys (which are also the E2E test scripts), and valid states/transitions (which also generate the state-test cases). | Before generating the behavior they describe |
| Schema definitions (DB / API / event) | The vocabulary of the system with its constraints formally stated. | Before implementation |
| Test suite (TDD / contracts) | The behavioral specification and a standing adversarial audit. | With each feature |
| Quality gates & commit hooks | Structural rejection of malformed output — the parser that makes certain mistakes unreachable. | Once; enforced continuously |
| Living (derived) documentation | Regenerated from the specs (OpenAPI, TypeDoc, Storybook) so it never drifts from the code. | Automatic — from the source |
Specification-first, iterative delivery. GS is not a third methodology beside waterfall and agile. The specification layer runs waterfall — the grammar is written first; the delivery layer runs agile — each session produces atomic, tested, deployable commits. Waterfall’s rigid front-loading dissolves because the constitution is a living document revised through commit discipline; agile’s structural drift dissolves because the specification gates every session. Scope may be bounded: a complete specification of a minimum viable slice is still complete.
The industrial threshold. Three constraints historically prevented sustained formal discipline — learning (no career is long enough), maintenance (discipline erodes under deadline), and transfer (knowledge lived in people). A tireless executor that reads the specification before every session makes all three irrelevant. The practitioner’s role shifts from implementation artisan to specification architect. The complexity moved upstream, into the card.
8. Related Work
Generative Specification sits in a lineage of work on specifying software and on instructing models, and reduces to none of it. Each neighboring tradition supplies part of the picture; GS names the obligation they leave implicit, that a stateless reader must be able to derive correct output from the artifacts alone, and makes that obligation measurable. All references below were verified (§References); a short list of items that could not be verified is kept out of the bibliography.
Software specification theory and structural disciplines. The obligation to state intent precisely is old. Hoare (1969) established the axiomatic basis for reasoning about programs; Parnas (1972) established information hiding and module specification, in which a module is defined by what a reader may assume and not by its implementation; Meyer’s design by contract (1992) makes preconditions, postconditions and invariants first-class; Jackson’s Problem Frames (2001) structure the relation between a specification and the world it constrains; Brooks (1987) separated essential from accidental difficulty. SOLID, clean code, test-driven development and domain-driven design (Martin, 2008, 2017; Beck, 2003; Evans, 2003) are the structural disciplines of §2.1, and architecture decision records come from Nygard (2011). GS inherits all of these and adds the reader they did not name: each specifies for a human engineer who can still ask, remember and infer. GS restates the obligation for a stateless executor that can do none of these, and turns “well-specified” from a judgment into a graded rubric (§3).
Architectural erosion and evolution. Perry and Wolf (1992) named architectural drift and erosion, Lehman (1980) stated that complexity grows unless work is done to reduce it, and de Silva and Balasubramaniam (2012) survey erosion control. GS applies this vocabulary to a new mechanism: a reader that completes every gap at generation speed from its prior.
Spec-driven development: tools, practice and research. Amazon’s Kiro (Swaminathan & Singh, 2025) and GitHub’s Spec Kit (Delimarsky, 2025) scaffold a requirements → design → tasks workflow for an agent, and Piskala (2026) describes tiers of specification rigor for AI coding assistants. The closest empirical neighbor is traceSDD (Panda, 2026), a spec-driven framework that requires a per-line requirement citation in generated code and is evaluated across models against Spec Kit and OpenSpec. These supply a place and a workflow for specifications and, in traceSDD’s case, a checkable citation discipline. GS supplies a criterion for what the specification must contain (derivability by a stateless reader), a graded instrument for whether it does, and a measured comparison against both unstructured use and an expert prompt. The idea that the specification comes first is not GS’s; and we make no claim that GS outperforms any of these tools, none of which is a comparator here.
Agent context files, context engineering and harnesses. Instruction files such as AGENTS.md and CLAUDE.md are now the common vehicle for project intent. Chatlatanagulchai et al. (2025) study thousands of them across repositories, Galster et al. (2026) study the configuration mechanisms agentic tools expose, and Gloaguen et al. (2026) evaluate whether repository-level context files help coding agents, reporting no general gain in task success and more than 20% higher inference cost. Context engineering is surveyed by Mei et al. (2025) and described for practitioners by Anthropic (2025). Böckeler (2026) divides an agent’s harness into guides and sensors (§4.3), and we adopt her terms; the verify half of GS is not distinct from harness engineering, and we do not claim it is. What GS adds is a criterion for the content of the guides and a measurement of the result. Two findings here bear on Gloaguen et al.: a strong expert prompt ties the full cascade on single-shot quality (§5.2), and the cascade costs more per generation, both consistent in direction with their finding. Whether a persistent, enforced substrate pays over a long horizon is untested here (§5.4).
Prompt engineering and retrieval. The few-shot and chain-of-thought lineage (Brown et al., 2020; Wei et al., 2022) improves output by shaping the immediate input. GS treats much of it as specification content delivered through a transient channel (§5.4). Retrieval-augmented generation (Lewis et al., 2020) retrieves text at query time; GS is retrieval-augmented and verified generation in which the retrieval structure is authored, not inferred (§4.3). Long contexts are used unevenly (Liu et al., 2024), which is one reason bounded contexts matter. KX replicates the method of the compact-knowledge-graph benchmark of Yarmoluk and McCreary (2026).
Code-generation evaluation and measured degradation. HumanEval (Chen et al., 2021), EvalPlus (Liu et al., 2023), SWE-bench (Jimenez et al., 2024) and SWE-agent (Yang et al., 2024) establish that models and agents resolve real tasks and how to measure it. Orlanski et al.’s SlopCodeBench (2026) has agents extend their own earlier solutions over long iterative tasks; across 15 agents and 36 problems (196 checkpoints) it reports that no agent solves any problem end to end, that structural erosion rises in 77% of trajectories and verbosity in 75.5%, that agent code is 2.3 times more verbose and 2.0 times more eroded than 473 open-source repositories, and that quality guidance reduces verbosity and erosion by up to a third. (These are the figures of the May 2026 revision; an earlier version reported different counts.) SlopCodeBench measures the failure mode that §4.1 builds on and does not test GS. Large-scale studies of AI-generated code report accumulating quality and security issues (Pearce et al., 2022; Liu et al., 2026). From a different angle, Thirolf (2025, KIT) identifies the same failure, implicit context that AI tools cannot access, through traceability gaps in AI-assisted development, and proposes traceability tooling; it is a bachelor’s thesis and is cited as independent problem identification, not as validation.
Benchmark contamination. Contamination and memorization threaten any benchmark in public training data (Magar & Schwartz, 2022; Dong et al., 2024). The RealWorld “Conduit” application used in most experiments here has many public implementations (RealWorld, n.d.), so memorization is not ruled out for those results; CR (§5.2) addresses it partly with an invented domain. Reward hacking in test-graded settings is catalogued by ImpossibleBench (Zhong et al., 2025), EvilGenie (Gabor et al., 2025) and the Reward Hacking Benchmark (Thaman, 2026), which frame RND-1.
Documentation-as-code. Treating documentation as a versioned, reviewed, CI-gated artifact (Gentle, 2017) is a direct ancestor of the cascade; GS sharpens the purpose, so that the cascade is the primary artifact from which the system is regenerated.
The through-line. Every neighbor treats derivability as an unstated background assumption: prompt engineering patches it per session, retrieval infers it at query time, specification theory trusts a human reader to close the gaps, code-generation evaluation measures the executor and not the specification, spec-driven tools supply a workflow, and context-file practice supplies a vehicle. What GS adds is the criterion, the instrument and the measured comparison. What it does not add is a new property of software, a new mechanism for any single practice, or a demonstrated advantage over a prompt that carries the same content.
9. Conclusion
Architectural drift at generation speed is the anomaly that documentation-based convention cannot structurally prevent. The reconstitution is the specification becoming the primary artifact, with code as derived output, governed for a reader that carries no context of its own. The discipline is regenerable from a committed specification in one reported run (RX), and its structural effect against unstructured use is measured at k = 5 (AX) while its advantage over a strong expert prompt is not shown on single-shot metrics; retrieval cost (KX) and a deployment (EX) and a formal-tier derivation (ALX) are mechanism and feasibility demonstrations; observationally, it transfers to practitioners who meet it on their own code, and recurs in the field (§5.3). The specification is the mold. The AI is the foundry. The scarce resource — the one that does not regenerate for free — is the judgment to specify correctly.
The substrate built to make that investment viable (§1) produced, without being designed to, two forms of governance: continuity of what was decided and why, and a knowable state for each project. We suspect, and have not measured, that this lowers the dependence of average quality on individual talent while the exceptional keep feeding the substrate with rules and gates. That is a thesis, not a result.
For the developer who wants to build with agents, the invitation is direct. Learn to specify — to force the structural disciplines, to build the sentinel, to let specification, implementation, and verification collapse into one derivation — and the ceiling on what you can build alone rises to the rate at which you can describe it correctly. The aim is a process that is verifiable, auditable and governable. The evidence reported here tests parts of the mechanism and none of the durability claim.
Terms are defined in prose where they are introduced; the full glossary is maintained in the Compendium.
References
Full bibliography, glossary, the pathology catalogue and further material are in the Compendium. Every entry below was confirmed against a primary or indexing source on 2026-10-01 (log: docs/white-paper/ieee-access/references-verification-log.md); items that could not be confirmed are in docs/white-paper/ieee-access/REFERENCES-TODO.md and are not cited.
- Anthropic (2025). Effective context engineering for AI agents. Anthropic Engineering Blog, Sep. 29, 2025. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- Beck, K. (2003). Test-Driven Development: By Example. Addison-Wesley.
- Böckeler, B. (2026). Harness engineering for coding agent users. martinfowler.com, Apr. 2, 2026. https://martinfowler.com/articles/harness-engineering.html
- Bransford, J. D., & Johnson, M. K. (1972). Contextual prerequisites for understanding: Some investigations of comprehension and recall. J. Verbal Learning and Verbal Behavior, 11(6), 717-726.
- Brooks, F. P. (1987). No silver bullet: Essence and accidents of software engineering. IEEE Computer, 20(4), 10-19.
- Brown, T. B., et al. (2020). Language models are few-shot learners. NeurIPS 33, 1877-1901.
- Chambers, C. D. (2013). Registered reports: A new publishing initiative at Cortex. Cortex, 49(3), 609-610.
- Chatlatanagulchai, W., et al. (2025). Agent READMEs: An empirical study of context files for agentic coding. arXiv:2511.12884.
- Chen, M., et al. (2021). Evaluating large language models trained on code. arXiv:2107.03374.
- de Silva, L., & Balasubramaniam, D. (2012). Controlling software architecture erosion: A survey. J. Systems and Software, 85(1), 132-151.
- Delimarsky, D. (2025). Spec-driven development with AI: Get started with a new open source toolkit. The GitHub Blog, Sep. 2, 2025. https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/ (toolkit: https://github.com/github/spec-kit)
- Dong, Y., et al. (2024). Generalization or memorization: Data contamination and trustworthy evaluation for large language models. Findings of ACL 2024, 12039-12050.
- Evans, E. (2003). Domain-Driven Design. Addison-Wesley.
- Gabor, J., Lynch, J., & Rosenfeld, J. (2025). EvilGenie: A reward hacking benchmark. arXiv:2511.21654.
- Galster, M., et al. (2026). Harness engineering for agentic AI coding tools: An exploratory study. arXiv:2602.14690.
- Gentle, A. (2017). Docs Like Code. Lulu.com, Sep. 2017. https://www.docslikecode.com/
- Gloaguen, T., et al. (2026). Evaluating AGENTS.md: Are repository-level context files helpful for coding agents? arXiv:2602.11988.
- Gordon, C. S. (2024). The linguistics of programming. Onward! 2024, 162-182. https://doi.org/10.1145/3689492.3689806
- Hoare, C. A. R. (1969). An axiomatic basis for computer programming. CACM, 12(10), 576-580.
- Holm, S. (1979). A simple sequentially rejective multiple test procedure. Scandinavian Journal of Statistics, 6(2), 65-70.
- Jackson, M. (2001). Problem Frames. Addison-Wesley.
- Jimenez, C. E., et al. (2024). SWE-bench: Can language models resolve real-world GitHub issues? ICLR. arXiv:2310.06770.
- Lehman, M. M. (1980). Programs, life cycles, and laws of software evolution. Proc. IEEE, 68(9), 1060-1076.
- Lewis, P., et al. (2020). Retrieval-augmented generation for knowledge-intensive NLP tasks. NeurIPS 33, 9459-9474.
- Liu, J., et al. (2023). Is your code generated by ChatGPT really correct? NeurIPS 2023. arXiv:2305.01210.
- Liu, N. F., et al. (2024). Lost in the middle: How language models use long contexts. TACL, 12, 157-173.
- Liu, Y., et al. (2026). Debt behind the AI boom: A large-scale empirical study of AI-generated code in the wild. arXiv:2603.28592.
- Magar, I., & Schwartz, R. (2022). Data contamination: From memorization to exploitation. ACL 2022 (Short Papers), 157-165.
- Martin, R. C. (2008). Clean Code. Prentice Hall. Martin, R. C. (2017). Clean Architecture. Pearson. (Paradigm as removal of freedom: Clean Architecture.)
- Mei, L., et al. (2025). A survey of context engineering for large language models. arXiv:2507.13334.
- Meyer, B. (1992). Applying “design by contract”. IEEE Computer, 25(10), 40-51.
- Morris, C. W. (1938). Foundations of the Theory of Signs. University of Chicago Press.
- Nosek, B. A., Ebersole, C. R., DeHaven, A. C., & Mellor, D. T. (2018). The preregistration revolution. PNAS, 115(11), 2600-2606.
- Nygard, M. (2011). Documenting architecture decisions. Cognitect Blog, Nov. 15, 2011. https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
- Orlanski, G., et al. (2026). SlopCodeBench: Benchmarking how coding agents degrade over long-horizon iterative tasks. arXiv:2603.24755 (rev. May 2026).
- Panda, S. (2026). Citation discipline in spec-driven development: A cross-model empirical study of output determinism and automated hallucination detection in LLM-generated code (traceSDD). arXiv:2606.30689.
- Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. CACM, 15(12), 1053-1058.
- Pearce, H., et al. (2022). Asleep at the keyboard? Assessing the security of GitHub Copilot’s code contributions. IEEE S&P. https://doi.org/10.1109/SP46214.2022.9833571
- Perry, D. E., & Wolf, A. L. (1992). Foundations for the study of software architecture. ACM SIGSOFT SEN, 17(4), 40-52.
- Piskala, D. B. (2026). Spec-driven development: From code to contract in the age of AI coding assistants. arXiv:2602.00180.
- Ralph, P., et al. (2020). Empirical standards for software engineering research. arXiv:2010.03525. ACM SIGSOFT Empirical Standards, https://acmsigsoft.github.io/EmpiricalStandards/
- RealWorld (n.d.). The mother of all demo apps. https://github.com/realworld-apps/realworld
- Swaminathan, N., & Singh, D. (2025). Introducing Kiro. Kiro Blog, Jul. 14, 2025. https://kiro.dev/blog/introducing-kiro/ (docs: https://kiro.dev/docs/specs/)
- Thaman, K. (2026). Reward Hacking Benchmark: Measuring exploits in LLM agents with tool use. arXiv:2605.02964.
- Thirolf, T. (2025). Analysis of Project-Intrinsic Context for Automated Traceability Between Documentation and Code. Bachelor’s thesis, Karlsruhe Institute of Technology (KASTEL). https://mcse.kastel.kit.edu/downloads/theses/ba-thirolf.pdf
- Uber (2026). Running a software factory efficiently at Uber Scale (U. K. Medisetty). Uber Blog, Aug. 27, 2026. https://www.uber.com/us/en/blog/efficient-software-factory/ Cited as industrial corroboration of direction only; figures are Uber’s own.
- Wei, J., et al. (2022). Chain-of-thought prompting elicits reasoning in large language models. NeurIPS 35, 24824-24837.
- Yang, J., et al. (2024). SWE-agent: Agent-computer interfaces enable automated software engineering. Advances in Neural Information Processing Systems 37 (NeurIPS 2024). arXiv:2405.15793.
- Yarmoluk, D., & McCreary, D. (2026). Benchmarking knowledge retrieval architectures: RAG, GraphRAG, and compact knowledge graphs. v0.6.2. https://github.com/Yarmoluk/ckg-benchmark (title and version as reported at check date).
- Zhong, Z., Raghunathan, A., & Carlini, N. (2025). ImpossibleBench: Measuring LLMs’ propensity of exploiting test cases. arXiv:2510.20270.
- NASA (1999). Mars Climate Orbiter Mishap Investigation Board Phase I Report. Nov. 10, 1999 (cited in §1).
- Experiment evidence:
experiments/in the public repository, with committed per-run JSON.
Materials & Evidence
This is the white paper — the focused, publication-length statement of the methodology, intended for Zenodo deposit and journal submission. It is derived from the Compendium, the canonical ~115-page source that carries the full evidence, the failure-mode catalog, a practitioner protocol (under development), the formal-disciplines treatment, and the biological-isomorphism frontier. Every claim and number here is traceable there; where this paper compresses, the Compendium expands, and both are kept consistent.
All materials are public. The Compendium and the experiments AX, BX, EX, KX, RX live in the public repository github.com/jghiringhelli/generative-specification (Compendium at docs/white-paper/GenerativeSpecification_Compendium.md; experiments, with per-run JSON evidence, under experiments/). The two June-2026 single-shot experiments — MX (experiments/mx/) and RND-1 (experiments/rnd-1/) — are committed there with their specs, oracles, and generated outputs, as are the TX twin study (experiments/ax/bridge) and the SX twin study (experiments/sx, with RESULTS.md, calibration.json, and per-cell data). The formal-tier experiment ALX and the Loom language itself live in the public Loom repository at github.com/jghiringhelli/loom (ALX at experiments/alx). The pragmaworks reference project is at github.com/jghiringhelli/pragmaworks.
The IEEE Access derivative of this paper (docs/white-paper/ieee-access/) carries a subset of these contributions and the same AX evidence; where the two differ in scope, this paper is the broader.
Data Availability
All experiment evidence — per-run JSON, audit transcripts, coverage output, SLO summaries, and session logs — is public under github.com/jghiringhelli/generative-specification/tree/main/experiments, with the formal-tier ALX evidence under experiments/alx in the public Loom repository. Step-by-step replication instructions — clone, container setup, runner invocation, and blind-audit procedure — are in the Experiment Supplement §S15.