The depth of the work

An argument is worth what its foundations are worth. This chapter sets out what exists behind the preceding thirteen, so that anyone evaluating the programme can judge the depth rather than take the confidence at face value.

Section 01The research base

The design rests on a research phase executed as parallel investigative tracks across the questions a whole-stack language has to answer: an audit of twelve mainstream languages, the measured failure modes of machine authorship, type-system and effect-system design, persistence and reactivity, migration, tier splitting, compilation targets, toolchain and packaging, intent artifacts, provenance and threat modelling, durable execution, day-two operations and compliance, and build-versus-rent economics.

It produced 55 findings documents, with every externally sourced claim carrying its citation inline and vendor-run studies labelled as such. The threat model in Chapter 2 is one output. The evaluation of current controls in Chapter 3 is another.

Those findings were distilled into a single binding constraint set in which every constraint traces back to a finding. It is binding in a specific sense: it may be tightened at any time in writing, and loosened only by a recorded decision at a phase gate. Every design decision downstream is checked against it.

Section 02The decision record

Twenty-two decision records have landed, each stating the alternatives that lost, the reasoning, and its line in the departure ledger. They cover the diagnostic scheme, capture rules, types, schema and labels, migrations, the mutation surface, queries, views and templates, routing, durable execution and scheduling, platform wiring, the test harness, the intent toolchain, the lexical frame, editions, standard partials, and the grammar.

Landing is not a formality. Records are held against adversarial review and several have been substantially rewritten, or killed outright, by it.

Around them sit 205 further working documents: measurements, scoped proposals, critic reports, and the record of proposals that did not survive. The proportion of that corpus devoted to things that failed is deliberate.

Section 03Two applications, written before the language existed

The design was stress-tested by writing complete applications in it on paper: a retail discount feature, and a full slice of a multi-tenant business application including a revenue dashboard, a schema migration threaded through mid-flight, and the compliance path for a data subject's right to erasure.

Those programs are the reason several design defects were found at a stage where changing them cost nothing. They are also the benchmark against which the specification's completeness is now measured — the charter's own exit criterion for this stage is that the specification covers everything the paper applications use, which is measurable rather than a matter of judgement.

Section 04The specification

Sections

22 numbered sections, 14,910 lines15,498 across the directory once the generated gap register and the conventions are counted.

Normative content

27 normative markers · 70 MUST / MUST NOT obligations

Diagnostic registry

101 rows, append-only, of which 63 carry a fully worked renderCodes are never reused: a code that changed meaning between versions would poison every corpus that learned it.

Open gaps

215, generated and gatedEvery place a section declined to settle something because no landed decision covered it.

Current coverage

13 of 15 declaration kinds used by the paper applications have a defined grammar production, and those productions parse 55 of the 100 attested sitesDerived from the corpus and cross-checked independently from the specification's own side. Stated as a floor: a construct without a production cannot be covered whatever prose surrounds it. Both figures were corrected on 2026-08-10, in opposite directions, by two separate defects in the same instrument: the head count downward from 11, when it was found to test that a production name was not referenced-and-undefined — which a name defined nowhere also satisfies — and then upward to 8, when it was found to be asking for three productions the specification deliberately does not write. The parse figure fell from 33 of 45 in that second correction, because the three heads it added are landed as heads and their statement bodies are not.

The gap register is the part worth pointing at first. A specification that reads complete because its gaps are unwritten is worse than a short one, so the register is machine-generated precisely so that nobody can quietly improve the number. It is also the handover document for implementation: the list of things a reference implementation must not guess at.

Section 05The instruments

Claims about the programme's own state are produced by commands rather than remembered. 168 verification instruments and 220 automated gates derive the figures, check the internal consistency of the records, and fail the build when something drifts.

A representative sample of what they check, because the list is more informative than the count: that a claimed amendment matches what was applied; that the gap register is regenerated in the same change as the section that moved it; that no diagnostic code is minted outside the single append-only registry; that a quotation is not truncated in a way that reverses its meaning; that a published figure still reproduces; that a rule priced as free actually has the diagnostic that makes it free.

Each gate must be proved able to fail before it is trusted. That requirement exists because a gate was once found that could not have failed — an earlier step in the same run rewrote the file it was checking.

Section 06The benchmark groundwork

A first evaluation scenario has been built end to end: a frozen task specification, a reference implementation on the incumbent stack, and a sealed oracle of hidden tests authored by parties who could not see what would grade them.

Four integrity properties were then measured rather than asserted: that the hidden tests pass through a vocabulary-obscured build; that the obscuring is exactly reversible; that no distinctive incumbent identifiers leak to the agent, including through provoked compiler output; and that the obscured build's development cycle is not slower than the original. All four passed.

An adversarial layer followed — eighteen exploit probes across four families, validated by seeding fifteen deliberate vulnerabilities and requiring that the probe aimed at each one is the probe that fires. It caught fourteen of fifteen on the first run, and the survivor was the most useful result: that probe could never have fired, because an unrelated rule already blocked the request it was making. A probe standing behind another guard is testing that guard.

Section 07How to inspect this

Everything above is recorded rather than summarised. The research corpus, the decision records, the specification and its gap register, and the instruments are all artifacts rather than assertions, and they are available for technical due diligence under the arrangements in Chapter 20.

They are not currently public. The research corpus publishes alongside the first measured results, together with the benchmark corpus list and method; until then the external sources in Chapter 21 are the part anyone can check independently, and we would rather point at those than at ourselves.