Progress

This page is deliberately long. It is the closest thing the programme has to an audit trail written for a reader rather than for an instrument, and an audit trail that summarises itself into three bullet points is not one.

Every claim below is derived from the repository rather than remembered. Where a figure appears it comes from a tool that recomputes it, and where something failed it is recorded as having failed — several of the entries here are withdrawals, refutations and dead ends, because a progress record that only lists successes is a marketing document.

How to read the identifiers

Work is grouped by the phase that produced it, and each item has a stable identifier. C is the charter. R is research, and the fourteen research identifiers are the programme's own track numbers rather than a scheme invented for this page. D is design, S is specification, I is implementation, V is the verification apparatus, and P is the platform the public material runs on.

The phases overlap in time and the identifiers do not imply that one finished before the next began. They imply dependency: nothing in S is sound if the D item it cites was withdrawn, and nothing in I means anything unless the V item that checks it actually runs.

Effort attributed to date

These are counts, not estimates, and each is produced by counting the artefacts themselves. They understate the work in one specific way worth naming: withdrawn work leaves a record but not a line count, and a great deal of the effort below went into decisions that were taken and then reversed.

Research

61 documents, of which 55 are track findingsFourteen tracks, run as agent fleets across three waves, at approximately 6.7 million tokens.

Design records

914 working documentsThe visible output of a process that withdraws as often as it lands.

Decisions

32 landed, 20 disposed ofThe disposal count is the informative half.

Specification

22 sections, 17,271 linesPrecise enough that an implementation could be built from it alone — the standard it is held to, and now partly tested against a real one.

Guide

14 pagesWritten for the reviewer rather than the author.

Gap register

230 triggers, 210 distinct gapsGenerated from the sections themselves. The handoff list for implementation.

Implementation

13,286 lines across 84 modulesLexer, recogniser, syntax tree, tree parser, loader, evaluator, and the probes that grade them.

Verification

168 tools

Gates

220 gatesRun as one suite. Every instrument must be shown able to fail before it is trusted.

Measurements

275 artefact filesIncluding the ablation runs, their manifests and their voided tasks.

Public briefing

21 chaptersEvery figure checked against the instrument that produces it.

The figure that best describes the shape of the effort is the ratio between the verification rows and the implementation one: 168 verification instruments and 220 automated gates against 13,286 lines of implementation. The programme has spent more on checking than on building, and that is the intended allocation rather than an accident of sequencing. The argument for it is in the method chapter; the evidence that it was necessary is scattered through the entries below, most of which record a defect that only a mechanical check could have found.

C — The charter

C1. The charter itself. A statement of what the language is for, seven principles, and a six-phase roadmap with a gate between each phase. The principles that have actually constrained later work are the third and the sixth: one program spanning the whole stack with the compiler deciding placement, and a deterministic surface with one canonical formatting and no dialects. Both have been expensive to hold and neither has been relaxed.

C2. The adoption doctrine. An amendment establishing that the adoption target is AI agents and the model corpora they are trained on, not a human developer community. This is the single decision that most changes what counts as good design here. It makes model familiarity a budget to be spent rather than a preference, and it is why the strangeness ledger in D1 exists at all. Human legibility remains a principle, but for the people who direct and review the code rather than for the people who might adopt it.

R — Research

Fourteen tracks were run as agent fleets across three waves, and every claim in the distillation is traceable to a findings file. The research phase is complete and gated. What follows is one paragraph per track, in the programme's own numbering.

R1. The audit of the incumbents. Twelve mainstream languages examined for what they get right and what they get wrong, on the hypothesis that the wrongs are mostly retrofit failures rather than necessary trade-offs. The hypothesis survived: most of the cons in the audit are sequencing accidents, things that could not be added later without breaking what already existed. A smaller set of genuine forced trade-offs was enumerated and carried forward to be resolved explicitly. The second finding was less comfortable and more useful: language properties beat corpus size as a predictor of whether a model writes correct code in that language.

R2. Requirements and the benchmark. Fifteen ranked requirements for AI authorship, and — more importantly — a pre-registered benchmark design capable of killing the central hypothesis, with four named kill criteria. This is the track that made the programme falsifiable rather than merely argued. It also produced the design razor that governs every later decision: a feature that helps because the model is weak is a liability within a few years, while a feature that helps because the model is untrusted appreciates with every capability increase.

R3. Semantics. The type system and effect system. The conclusion was a TypeScript-shaped surface over an ML-shaped core: mandatory signatures at module boundaries, restrained local inference, nominal unions, exact records, no null, mandatory exhaustive matching. The effects work produced the decision the whole design now rests on — effects as capabilities, in the capability-parameter form, with no user-visible handlers. Memory management produced a law rather than a mechanism: reclamation must be unobservable, so no finalizers, ever.

R4. User interface. Compiler-owned signals with statically derived dependency graphs, effect-checked render purity, and a retained language-owned DOM. Canvas rendering was eliminated on accessibility grounds with a documented field record behind the decision. The accessibility work went further than expected and became a design constraint rather than a library concern: the six error classes that account for the overwhelming majority of detected accessibility failures become compile-time obligations.

R5. Persistence and reactivity. The moat, if there is one. Read-set-tracked whole-query recomputation over optimistic concurrency, with a single-timeline snapshot contract — serializable transactions, all client subscriptions at one timestamp, and therefore no stale windows. The interesting property is that it is an absence of anomalies rather than a feature. The migration work in the same track produced typed expand-and-contract schema programs with mandatory acknowledgement of anything discarded.

R6. Tier splitting. Function-granularity boundaries whose tier is determined by their capability signature, a closed endpoint set, and a compiler-owned wire schema. Closure capture across the tier boundary is a compile error, and the indictment for that decision is the published CVE record of frameworks that allowed it. Tenancy is handled by minting a tenant-scoped database capability at authentication, which makes cross-tenant access unrepresentable rather than merely forbidden.

R7. Targets. One code generation path to WebAssembly with garbage collection, for browser, edge and server, with a semantically identical JavaScript backend held at parity permanently because it is the fallback, the DOM driver and the observability-mature tier. Native ahead-of-time compilation was demoted to a later escape hatch behind a performance gate. The track also produced a fifteen-item constraint cage that binds the semantics work in R3.

R8. Toolchain and packaging. A single tool with a coarse-grained incremental engine, on the argument that because the language mandates locality, the cheap compiler is the correct compiler. Packaging adopts minimal version selection and a transparency log wholesale, and adds computed version bumps derived from typed API diffs, which turns a version number into a theorem rather than a promise. One rule from this track became a permanent precommitment: the toolchain never executes package-provided code during resolution or build.

R9. Intent artifacts and oversight. A three-layer intent stack, each layer with a mechanical freshness check, designed specifically to close the rot vector that kills specification-driven development. The oversight half produced a review pipeline built on compiler-emitted behavioural deltas — including an effect and capability delta that no existing review process has and that falls out of the effects design for free.

R10. Trust and the threat model. A trusted computing base of five enumerable items, and a threat model of seven classes each with an assigned mitigation. The organising assumption is that the agent writing the code is fully injected and prompt injection has no clean fix, so the design bounds the blast radius rather than trying to prevent the compromise. The conclusion worth repeating is that the security model and the productivity model turned out to be the same three mechanisms — one budget, two payoffs.

R11. Corpus and durable execution. An evidence-derived boundary between the standard library and blessed packages, and the decision to own durable execution rather than rent it, staged, with four pre-committed conditions that mechanically downgrade the decision from own to bless if any of them fires. Writing the downgrade conditions before building anything is the part of this track that has since proved most useful.

R12. Build versus rent. A per-layer matrix with kill criteria and executable fallbacks at every layer, checked row by row against an invariant that every fallback must be executable without any other layer's build succeeding. This track produced the strangeness budget that D1 then formalised.

R13. Operations and compliance. Compiler-emitted telemetry from effect sites, typed structured logging with classification-driven redaction, and one classification vocabulary feeding five separate consumers. The finding that shaped later design: the operational burden concentrates precisely on what the language owns, which is a consequence of owning persistence and durability rather than a defect in the plan.

R14. Identity. The working codename was retired on evidence — an actively monitored trademark, a large collision count, and a namespace closing at roughly one collision a month. Twenty-six candidates were screened for trademark risk and the name Kasuri was selected as the cleanest path, with the identity story that the pattern is dyed into the threads before the cloth is woven, which is what the language claims about its guarantees.

D — Design

D1. The strangeness ledger. A budget for how far the language may depart from what a model already knows, with a counting doctrine, one major unit at 0.85 and 0.15 of headroom remaining. It is binding: it may be tightened at any time and loosened only at a phase gate, in writing. Several later design decisions were shaped by having to state their ledger line, and at least one was narrowed specifically because the budget would not cover it.

D2. The decision register. Thirty-two landed decision records against twenty disposed of. The disposal count is the honest half of that figure and the more informative one: fourteen of the twenty deaths are in the declaration layer alone, against a pre-registered expectation of five, and that overrun is itself a recorded finding rather than a silent adjustment.

D3. The diagnostic scheme. A merged, append-only registry of diagnostic codes, where a new code may only be added by appending a row in the commit of the decision that owns it. No code may be minted in a specification section. The append-only rule has been enforced mechanically since shortly after it was written, and the instrument that enforces it caught several attempts to fold one code into another.

D4. The paper applications. Two complete applications written on paper in a language that did not exist, before any implementation work began. This is the cheapest possible way to find design flaws, because aspirational code costs nothing to rewrite, and it worked: the paper programs are the corpus that every later coverage figure is measured against, and they refuted several decisions that read well in isolation.

D5. The leak tests. Four pre-registered tests of whether a design choice leaks into code the author has to think about. One failed as pre-registered — capture checking — and the design shipped the blunter alternative that the ledger had already priced as the fallback. Recording a pre-registered failure and taking the pre-priced consequence, rather than arguing the result away, is the practice these tests existed to establish.

D6. The proof-of-concept ladder. A cost-gated sequence of stages, each with an exit criterion set before it began. Stages zero and zero-point-five are complete and stage one has landed: a front end and a checker capable of running a micro-task battery.

D7. The micro-task battery. A battery of tasks, each a program with a seeded defect that must fire exactly one diagnostic code, paired with a repaired program that must be clean. It grew to thirty-nine tasks covering thirty-four codes, and was then measured to be at the checker's ceiling: every code the checker can fire is covered, and extending the battery means extending the checker.

D8. The diagnostics ablation. The thesis test, and the most important measurement the programme has produced. The same author, the same program, the same instruction, with the diagnostic's code, line and detail withheld in one arm. Pooled over twenty tasks the repair rate was seventy-five per cent with diagnostics and twenty per cent without. A second independent series over seventeen further tasks agreed in direction and magnitude at eighty-two and twenty-nine per cent, and is reported beside the first rather than pooled with it.

D9. What the ablation's failures looked like. The separation in failure mode is starker than the separation in rate, and it is the part that persuades. Across every slice run, the arm without diagnostics produced not one over-repair: every single failure was a defect left uncleared. The arm with diagnostics failed differently, by over-repairing. Without the diagnostic the author does not find the defect; with it, the author sometimes finds too much.

D10. The contamination finding. Partway through the ablation the authors themselves reported that the repository's own instruction file was being injected into their context. The affected tasks were voided, the leak was bounded mechanically, and then a second probe found that the bound had been drawn around the wrong surface — a separate block was injecting recent commit subjects, one of which carried a diagnostic code. The corrected bound is published with the result, and the rates are explicitly conditioned on it. The instrument was not moved to make the measurement look clean.

D11. The premise change. A decision that the programme is agent-decided: design, rulings, kill calls, what lands and what is withdrawn are all decided within the programme, and all review is performed by adversarial agent fleets, which is the formal review step. The human principal is asked for exactly three things — real money, outward-facing acts, and anything with legal consequence — because those bind him personally. One consequence was recorded at the time rather than glossed: two of the intent artifact's planned metrics measure human minutes, and under this premise they are not merely unmeasured but unmeasurable, so the phase was closed by explicit decision rather than left open forever.

S — Specification

S1. The specification. Twenty-two numbered sections totalling 17,271 lines, covering lexical structure, editions, types, declarations, schema and labels, migrations, functions and capabilities, queries, mutations, views, routes, durable execution, platform wiring, testing, intent, standard partials, the diagnostic scheme and contract, a grammar summary and the strangeness ledger. It was drafted by a fifteen-agent fleet and has been under continuous adversarial revision since.

S2. The conventions that bind every section. The normative source is the landed decision record and never a summary of it; every normative statement carries a citation; nothing may be invented to fill a hole, and a hole must be written down as a hole. The rule with the most teeth is the last one, because a section that reads complete because its gaps are unwritten is worse than a short one.

S3. The gap register. Generated from the sections themselves and checked in, currently 230 triggers resolving to 210 distinct gaps. It is the handoff list for the implementation phase — the set of things a reference implementation must not guess at. The register has twice reported its own ownership figure wrongly and both corrections are recorded in it, including the one where the pass that fixed the first error introduced the second.

S4. The declaration heads. Fifteen kinds of declaration are used by the paper applications, and thirteen now have a defined grammar production resting on a landed decision record rather than a draft. The distinction between those two conditions is load-bearing and was got wrong for weeks: an earlier instrument counted a production as settled when only its fence existed, and the published figure read higher than the truth until a tool was written to tell the two apart.

S5. The grammar. Productions for the landed heads, with the remaining holes recorded as holes rather than filled by invention. The grammar does not yet close end to end, and the specification's own grammar summary says so as its headline rather than burying it.

S6. The withdrawals. Twenty decision records have been disposed of, and several were withdrawn after being drafted, reviewed and nearly landed. At least one was killed by its own author on measurement rather than by a reviewer: a rule was drafted, the corpus was measured to check its premise, the premise turned out to be false, and the rule was withdrawn before it was written up. That is the intended failure mode and it is cheaper than every alternative.

S7. The guide. Fourteen pages written for the person who directs and reviews AI-written code rather than the person who writes it by hand. Its most useful page ranks where to spend review attention, derived from the checker's own enforcement ledger; its most honest states what the guide does not cover and measures that boundary rather than asserting it. Both of the guide's own published coverage figures were found wrong and corrected, by a gate built after the pages were written.

I — Implementation

I1. The lexer. The first executable component, and the first place where the specification met something that could disagree with it. It is checked against the corpus rather than against hand-written examples.

I2. The recogniser. A backtracking parser that answers whether a form parses, and nothing else. Every coverage figure the programme publishes rests on its yes-or-no verdict, which is why it is the component most heavily controlled. It was for a long time the entire implementation, and a finding recorded at the time is worth repeating: a specification that has never been executed is a hypothesis.

I3. The syntax tree. Node kinds derived from the loaded grammar at call time rather than hand-written from reading the specification. Nodes exist only for heads that have landed, because a node for a draft head would be inventing a form — the exact defect that killed two earlier decision records.

I4. The tree parser. The recogniser made to yield structure instead of discarding it. It mirrors the recogniser rather than replacing it — same node kinds, same backtracking, same guards — because a second parser that disagreed with the first would be a second grammar. Making it fast enough to run the whole corpus took several rounds of work on its memo key, each one recorded with the argument for why the narrowing was sound rather than merely faster.

I5. The round trip. A corpus sweep that parses each declaration to a tree, renders the tree back to text, and re-parses the result. The renderer is deliberately unintelligent, because a clever renderer that repaired its own input would hide the defect the test exists to find. It was the first honest answer the programme had to whether the specification is buildable.

I6. The loader. Whole files, not single declarations. 265 of 269 corpus declarations load, and three of the four that do not are not declarations at all. All four belay source files load completely — forty declarations, zero failures. That is the point at which the corpus stopped being a set of lines and became programs.

I7. The evaluator. Kasuri code runs. Eighty-five of eighty-seven function bodies execute, and a whole corpus file runs end to end: given a page size of 150 it returns 100, given 20 it returns 20, and it maps role values to their labels. Precedence is not implemented in the evaluator at all — it comes from the shape of the grammar's own productions, so the evaluator cannot hold a private opinion about it.

I8. Queries, and an oracle to check them. Queries run: eight of ten in the standing bar. The more important half of that work was noticing that the bar scored the wrong thing. It measured liveness — did the query reach a body and return something that was not empty — which cannot distinguish a correct answer from a count that always returns zero or a filter that is never evaluated. It was replaced by a test that scores agreement with an answer computed independently in Python from the same seeded rows, and that test passes four of four. A bar that cannot fail in the interesting direction is not a bar.

V — The verification apparatus

V1. The gates. 220 automated gates built from 168 verification instruments, run as one suite. The governing rule is that a finding worth having becomes a mechanical check or it did not happen, and the apparatus exists because this programme's own record is that self-review does not converge: six adversarial passes over a single specification section returned thirteen, twelve, twenty-five and twenty-six findings without settling.

V2. Controls, and what a control has to do. Every instrument carries a control suite that must be shown able to fail before the instrument is trusted. Three rules were learned expensively and now apply everywhere. A control must call the function it certifies, because a control that asserts a regular expression matches a string literal certifies nothing. A check that can only fail one way is a print. And a known-bad plant proves nothing unless the plant is asserted to have applied — a case was nearly filed as a blind spot when the real fault was that the planted defect had never been inserted.

V3. The failure pattern. Measured across five consecutive pieces of work: each one correctly named a defect, correctly stated the rule that would prevent it, and then committed the same defect one level up. A widening that did not sweep its own quotation elsewhere; a fix for a vacuous control that was itself vacuous; a gate for an ungated figure that did not hold its own figure; a replacement for a stale list that was stale by one item. The rule is never wrong; the object it is applied to is. Two mechanical questions catch all of it, and both are now asked routinely.

V4. Pre-registered bars. Later work is run as a sequence of numbered ticks, each one naming the number it expects before the run and recording the result as met, missed or exceeded. The record contains a great many misses, and they are more useful than the hits: a bar missed at eight of ten with both remaining rows diagnosed says something a bar quietly lowered to eight does not.

V5. Stopping conditions. The ladder that drove the implementation work carried a written stopping condition — a rule for when to stop climbing and go and look at what is under the ladder. It was invoked rather than ignored, which is what the next section is about.

P — The platform

P1. The public briefing. Twenty-one chapters, statically generated, with no client-side JavaScript. Every figure it publishes is checked against the instrument that produces it, so a number that drifts turns a gate red rather than going quietly wrong on a public page. That check was added after four published figures were found stale simultaneously.

P2. Its own infrastructure. The site moved off a shared host onto a dedicated instance defined entirely in infrastructure-as-code, with its own network, registry, roles and logs, sharing nothing with any other product. The sizing was measured rather than argued, and a smaller instance was rejected on the measurement rather than taken for the saving.

P3. Mail and transport hardening. Strict alignment and an outright reject policy from the start rather than a monitoring phase, on the reasoning that the usual advice exists to discover unknown existing mail flows and this domain had none. Transport security policy is published and authenticated by the web certificate chain rather than by DNS.

P4. Two network moves, and what they cost. The site gave up its own network range so another product could use it, becoming a temporary tenant elsewhere, and later moved back to a fresh range of its own. Both moves were free of any DNS change because the public address is region-scoped and follows the instance. The second move exposed a defect that had been live since the first: a pinned attribute that the cloud provider reports back from a value something else controls, which meant every future plan proposed destroying and rebuilding the production machine.

What is not done, and what blocks it

The implementation loads the corpus, runs function bodies, runs a whole file end to end, and answers queries correctly against an independent oracle. Every one of those rungs is now at its ceiling, and the same thing is underneath all of them.

There is no standard library. The file loader reports sixteen unresolved imported names, and every one comes from a module path with no file anywhere in the repository — a database module, a time module, and the example application's own schema. The same absence shows up twice more in a different shape: most of the evaluator's missing execution rules name a receiver whose type could not be resolved, which is what an unresolvable import becomes, and the last two failing function bodies want a duration expressed on an integer. These are not seventeen missing rules. They are one missing library, seen seventeen times.

That is worth stating plainly because it is the kind of blocker a ladder hides. Each rung looked like a separate problem with a separate fix, and each fix would have been real work that moved the number a little. Counting what was actually under them was cheaper than climbing.

Beyond it, the honest summary is unchanged: there is no runtime, no reactive engine and no deployed database layer, and most of what the guide describes about runtime behaviour is ruled rather than observed. The benchmark that could kill the central hypothesis is designed, pre-registered and unfunded. It remains the single most useful thing anyone could pay for, and it is described on the sponsorship page.

Back to the contents · How the work is held to account · The roadmap