Kasuri

Chapter 17 · Part IV — The programme

How the work is held to account

Pre-registered criteria capable of ending the programme, adversarial review by parties briefed to refute, and independent human scrutiny of everything produced.

Audience
Technical due diligence, internal audit, evaluation
Chapter
17 of 21

Language design has a rigour problem: claims are made in manifestos and settled by adoption, and adoption measures marketing at least as well as merit. That is a poor way to establish anything, and a particularly poor way to establish a security property. This programme is run as an experiment instead.

Section 01How the work is produced

Kasuri is built by a small team working in close collaboration with AI systems. Direction, judgement and every decision that binds are held by people; a great deal of the execution — research, drafting, measurement, instrument building — is done in collaboration with machines under that direction.

Two features of that arrangement matter to an evaluator:

  • Adversarial review is a formal part of the method, not a courtesy. Work is examined by review fleets briefed to refute it, which did not produce it and have no stake in it landing, and their findings feed directly into design direction. Those reviewers are AI agents run in independent passes rather than people: the programme is agent-decided by design, and stating otherwise would misdescribe who does the work. It is the mechanism by which machine-produced work is prevented from accumulating unexamined, and its discipline is that a finding becomes a mechanical check or it did not happen.
  • Decisions are reserved by category, in writing. A defined class of judgement — anything that changes the departure budget, anything that touches a signed constraint, anything outward-facing, and every decision to stop — is reserved to people and recorded with its reasoning. Everything else is delegated. The boundary is stated as categories rather than case by case, deliberately, because a case-by-case line is one an eager collaborator can argue past.

This is the thesis in miniature, which is the point. The programme is building a language premised on machines writing code under human direction with machine-checked evidence holding it together. It would be a poor advertisement for that premise if it were not run that way — and running it that way is how the failure modes get found early enough to design against.

Section 02Criteria that can end it, fixed in advance

Before building the benchmark that will test this language, the results that would kill it were written down. They are specific, numeric, and frozen at registration — locked before any test runs and never adjusted afterwards. The comparison arm is the incumbent stack at its best, with current tooling and a best-practice library for every task, never a strawman. The numbers are published either way.

The reason to fix criteria in advance is that any team will otherwise rationalise. That is not hypothetical; it is a documented pattern in this programme's own records, which is why the rule has the shape it has.

If Kasuri does not measurably improve the software machines write, that result is published and the programme stops.

Section 03Adversarial testing before implementation

The design's central claims were attacked before any implementation existed. Two complete applications were written on paper — in a language with no compiler — and then subjected to pre-registered tests whose only purpose was to break the claims those programs relied on. Aspirational code is the cheapest possible place to find a design flaw.

One test failed, and the design changed as a result: the pre-registered fallback shipped in place of the preferred rule (Chapter 12). The fallback was written down before the test ran, precisely to remove the temptation to argue with an unfavourable result.

One standing rule came out of that stage and is worth quoting because it generalises: a test may never pass on the strength of an instrument the tester invented for the occasion.

Section 04Three lenses, briefed to refute

Design rulings face adversarial review from independent perspectives whose brief is to refute rather than to improve, and a ruling that survives is recorded together with the objections that failed against it.

This is the most expensive part of the method and the one that has paid best. The largest single decision in the programme took nine consecutive review passes, every one of which returned a blocking verdict, before it was allowed to land. The instructive part is the pattern: across all nine, the rulings survived largely intact, and what failed every single time was the evidence — a measurement that reproduced at no scope anyone could name, a checking tool whose grammar was wider than the document it certified, a rule stated without the diagnostic that made it affordable, a citation to a section that did not contain what was attributed to it.

Several proposed pieces of work have been killed outright by their own review. In each case the fatal objection was a sentence that already existed in the programme's records before the work began. That produced a standing rule: read the governing record before writing the proposal, not after.

Section 05Derive, do not retype

The most repeated defect in work of this kind is a figure that was correct when written and wrong when read. The answer here is mechanical: any figure that can be computed is computed by a command, and the commands run automatically.

There are 220 automated gates and 168 verification instruments in the programme's repository, checking the things that otherwise rot — that a claimed amendment matches what was actually applied, that a register of open questions is regenerated alongside the section that changed it, that a published figure still reproduces, that a document does not cite a source which fails to say what it is quoted as saying.

Two disciplines make those gates worth having, and both were adopted after being caught out:

  • A gate must be proved able to fail. Before a check is trusted it is run against a deliberately broken input and must go red. This was adopted after finding a gate that could never have failed, because an earlier step in the same run rewrote the file it was checking.
  • An instrument must not share a pattern with the edit it certifies. A check built from the same assumption as the change it verifies will approve that change by being wrong in the same way.

Section 06The author is kept away from the scoring

Because threat class 6 names the author as an adversary of its own evaluation, the benchmark harness separates them: distinct write domains for code and for the tests that grade it, hidden suites injected at verification time, and a requirement that a null or tampering agent scores zero. Where an artifact must be authored blind, it is authored by parties who cannot see what will grade them.

That discipline has already caught a mistake of the programme's own: a benchmark component described as independently authored turned out, on inspection of the records, to have been mechanically generated — so the independence claimed for it was not a property it had. The correction is in the record with its reasoning, because a benchmark's credibility is made of exactly that kind of disclosure.

Section 07Results that do not help are reported anyway

Two examples from the record.

A structured-specification trial largely failed. The hypothesis was that a formal intent artifact would make an agent catch divergences it would otherwise miss. Two of three arms beat the plain-prompting control — but by a single case, and the one case the control missed was already known to discriminate. Remove it and every arm ties. Nine of ten seeded divergences were caught by plain prompting. The honest reading is that the design intent largely failed, and the headline verdict flatters it.

A departure survived its drop test. One item in the departure ledger carried a registered trigger: remove it if measurement showed no effect. Measured, it showed a 55.8-point gap against a pre-committed 10-point threshold, consistent across four of four families. The trigger did not fire and the item stays.

Both are reported the same way, because a method that only publishes its wins is not a method.

Section 08One bounded repair, scoped before it starts

When a test fails the rule is: one repair attempt, scoped in writing before it begins, with the pre-repair number recorded first, and the outcome reported either way. The risk this guards against is specific — that a bounded attempt quietly becomes an exercise in explaining away an unfavourable result — and it was flagged by the party it constrains.

What this method does not fix

It is slow and expensive in expert review. It cannot catch a wrong assumption shared by every reviewer. And it produces long, uncomfortable internal records that are difficult to read — which is a real weakness for anyone who has to trust a summary. This briefing is an attempt to make the substance legible without softening it.