Chapter 19 · Part IV — The programme
Stages and gates
Each stage names the evidence that permits it to advance, and what is published if that evidence does not arrive.
A roadmap with dates on it is a forecast, and this class of work is bad at forecasts. What follows attaches a gate to each stage: the evidence that permits it to advance. The sequence is the commitment; the pace is not.
-
Complete
Research and constraint set
Parallel investigative tracks across every question a whole-stack language must answer, distilled into a binding constraint set in which every constraint traces to a finding.
Gate — every track's exit criteria met, findings distilled into constraints that later work is checked against. Passed.
-
Complete
Design and adversarial testing
Complete applications written on paper in a language with no implementation, then attacked by pre-registered adversarial tests with fallbacks named in advance. One test failed and the design changed accordingly.
Gate — the design survives its own tests, with every verdict traceable to a transcript. Passed.
-
Current stage
Specification
Normative sections written against landed decision records, with a generated register of everything they decline to settle, and a human-facing guide alongside.
Gate — the specification covers everything the paper applications use. Measurable rather than judged, and currently standing at 13 of 15 declaration kinds carrying a defined production, whose productions parse 55 of the 100 attested sites.
-
Next
Reference implementation and measurement
An interpreter that executes the language, and a seeded-defect battery producing measured repair rates with ablations — replacing design-stage verdicts with numbers. This is where the diagnostics claim in Chapter 14 is tested on Kasuri's own diagnostics rather than borrowed from another language's.
Gate — measurements confirm the design-stage results, and the kill criteria freeze at benchmark registration. If the diagnostics ablation shows no effect, the central lever of the design is not real and that is published.
-
Then
Compiler slice and familiarity parity
A working compiler for the core language, and a validated corpus that brings models to genuine familiarity with it. The unfamiliarity tax described in Chapter 12 is what this stage exists to pay down, and it is the stage most likely to reveal that the departure ledger was priced wrong.
Gate — a model writing Kasuri performs at parity with the same model writing the strongest incumbent stack, net of familiarity.
-
Then
First production application
A real multi-tenant application, built the way this briefing argues software will be built, operated in production against real users and real failure.
Gate — it runs, it holds under real use, and it would survive being shown to a stranger.
-
Then
Version one and the stability declaration
The point at which the language surface stops moving. From that declaration, change arrives only through explicit editions — which matters for model corpora and, as Chapter 9 argues, matters equally for systems with lifetimes measured in decades.
Gate — a first external production user, and the corpus-stability declaration.
Section 01The test that can end the programme
Across the measurement stage sits a pre-registered benchmark: multiple sealed domains, multiple arms, with the primary measure fixed before any run and the comparison arm being the incumbent stack at its best, including a best-practice library for every task where one exists.
The security result is the one that matters most here, because it is where the claim is strongest and therefore most worth attacking. The incumbent baseline is established: roughly half of functionally correct machine-written backends measure as exploitable.[1] If explicit authority does what Chapter 12 claims, the equivalent rate for Kasuri should approach zero by construction. If it does not, the central claim of this briefing is false — and that is a publishable result rather than a quiet one.
Section 02Per-layer triggers
Beyond programme-level criteria, each component that is built rather than adopted carries its own written trigger and a named fallback. A few, to show the shape:
- The reactive persistence layer — the most expensive owned component — reverts to adopting an existing engine if it cannot support the target application's workload by a stated milestone, or if plumbing defects consume more than half the area's engineering effort for two consecutive periods.
- The formatter carries a canonicality trigger: the first configuration option added is the signal that the zero-configuration claim has failed.
- The standard library widens through versioned, reviewed packages rather than by growing the standard surface — and repeated blocking of application work is the recorded trigger to revisit that.
Every fallback must be executable without any other layer's build having succeeded. That constraint exists because the historical failure mode of unified-stack languages is a set of layers coupled so tightly that no single one can be replaced — and it is the risk this approach most needs to be defended against.
Committed: the ordering, the gates, and publication of the result either way. No stage advances without its evidence, and a failed gate is published rather than reframed. If a gate fails and cannot be repaired within one bounded, pre-scoped attempt, the programme stops there and says so.
Not committed: a calendar. Pace depends on resourcing, and this is deliberately patient work — the properties in Chapter 16 are not achievable on a schedule that rewards shipping over correctness.