Engaging with the programme

This chapter exists so that nobody spends a meeting discovering what the previous sixteen have said. Kasuri is at specification stage, ahead of a reference implementation. There is nothing to procure, deploy, or pilot today, and any conversation that begins there will be short.

Section 01What this is not

• Not a product. There is no compiler, no interpreter, and no released toolchain. No program in this language has ever been executed.
• Not accredited. No security certification, accreditation, clearance or approval is held, in any jurisdiction, and none has been applied for.
• Not deployed anywhere. There is no reference customer, no pilot, and no production system.
• Not seeking to displace your current stack. The controls evaluated in Chapter 3 should stay. The argument is about where the ceiling is, not about replacing what works below it.

Section 02Why engage at this stage at all

Because the properties that matter to regulated, sovereign and defence estates are decided at specification stage, and they are close to impossible to retrofit.

The evidence for that claim is in the industry's own record. Two serious attempts to add per-component authority to established platforms after the fact both failed — one because process-granular permissions cannot express it, the other withdrawn after years of effort. Erasure obligations that reach derived state, releasability enforced inside an application rather than at a domain boundary, a trusted base small enough to review, evidence reproducible by a third party: every one of those is a decision taken before an implementation exists or a compromise made permanently.

A requirement stated now costs a paragraph. The same requirement stated after implementation costs a rewrite, or never happens.

Section 03What the programme is asking for

Sector requirements

The obligations you actually carry, stated preciselyNot a wish list — the specific statutory, regulatory or accreditation properties your software must be able to demonstrate, and the ones your current stack makes hardest to demonstrate.

Adversarial review

Attempts to break the argumentThe most valuable contribution anyone can make is a refutation. The claim in Chapter 12 is the one most worth attacking, and the programme's method already treats a survived objection as more useful than an endorsement.

Threat picture correction

Where Chapters 2 and 3 are wrong about your environmentThose chapters are built from public incident data. If your operational reality differs, that is a finding.

Benchmark realism

Whether the evaluation scenarios resemble your workloadsThe benchmark is what will decide whether this works. A benchmark that tests the wrong thing produces a confident wrong answer, and the sector chapters in Part II are the current best guess at the right thing.

Section 04What is available in return

• Technical due diligence access. The research corpus, the decision records, the specification and its gap register, and the verification instruments are artifacts rather than assertions, and can be examined under appropriate arrangements. Chapter 18 describes what exists.
• Influence on specification while it is still cheap. Requirements raised at this stage are recorded as decision records with their reasoning, in the same register everything else is held to.
• Early sight of measured results. The evaluation described in Chapter 19 produces the first numbers capable of confirming or ending the central claim, and they are published either way.
• A defensible position on machine authorship. Even where Kasuri never becomes something you adopt, the questions at the end of each sector chapter are usable immediately against your existing suppliers.

Section 05Whether this is worth your time

A short and deliberately unflattering filter.

Section 06How the work is produced

Kasuri is built by AI systems working under a human principal. Design decisions, rulings and reviews are made by those systems; the principal is asked for the commitments that bind him personally — money, outward-facing acts, and anything with legal consequence — and holds those absolutely. Review of produced work is performed by adversarial agent fleets briefed to refute it, as a formal part of the method rather than as a courtesy. Chapter 17 sets that out in full.

That arrangement is deliberate and it is relevant to the evaluation: a programme arguing that machines should write software under human direction, held together by machine-checked evidence, would be a poor advertisement for the idea if it were not run that way. It is also how the failure modes get found early enough to design against — several of the disciplines in Chapter 17 exist because something went wrong first.

Section 07Making contact

Enquiries from the sectors in Part II — and refutations from anyone — are welcome. A published contact route accompanies the first measured results; the project's code organisation opens with the first public release and is deliberately unlinked until it does.

github.com/kasuri-lang
Opens with the first public release. Unlinked until it does.