Executive overview

Kasuri is a whole-stack programming language designed for a world in which most new code is written by machines and answered for by organisations. It is built on a single principle: the classes of failure that matter most should be impossible to express, not merely possible to detect.

Section 01The problem, in three measurements

The shift to machine-authored software is not in question. What is less widely understood is that its failure modes have not improved as models have become more capable.

• ~halfOf AI-generated backend programs that were functionally correct in a benchmark with executable end-to-end exploits, roughly half were exploitable.^[1]
• 45%Rate at which models chose the insecure implementation where a secure one existed, across 80 tasks and 100+ models. A later re-run found no improvement.^[2]
• ~1 in 20Package references pointing at software that does not exist. The rate improved elevenfold and then stopped; attackers register the invented names.^[3]

These are properties of authorship without verification rather than properties of any particular model, which is why they have proved durable. Meanwhile the shared substrate that this code is assembled from is under automated attack aimed specifically at the development toolchain: self-replicating package worms, malicious tool servers, and campaigns that turn installed AI coding assistants into credential harvesters.^[6][7]

Section 02Why this lands hardest on you

For a consumer software business, this is a quality problem. For a government department, a defence supplier, a bank, or an operator of critical infrastructure, it is an accountability problem — and the difference is structural.

Your organisation already works in the language of assurance: stated properties, evidence that the properties hold, and a named party who answers if they do not. Those processes were sized for human-paced change and for a supply chain that a person chose. Adopt machine authorship at scale without changing anything else and you have made review the bottleneck for your entire delivery capability — while the evidence says that monitors good enough to catch most problems produce false-positive rates no organisation can operate.^[10]

The question stops being "is the model good enough to write this?" and becomes "what can this code reach, and who decided?"

The first question has no stable answer and gets a different one every few months. The second has an answer a compiler can produce, and the answer does not change when the model does.

Section 03What Kasuri does differently

Five commitments, each argued from evidence and each described in Part III.

• Authority is explicit and unforgeable. Every ability to affect the world — reaching data, sending a request, holding a credential — is a value that code must be handed. Code never given the database cannot query it, whatever the model was persuaded to attempt. Whole vulnerability classes stop being detectable-in-principle and start being unwritable.
• Boundaries are derived, not maintained. Interface, logic and data are one program; the compiler decides what runs where and checks every boundary it draws. The seam where most real breaches occur is computed rather than hand-wired.
• The compiler is the reviewer of first resort. Diagnostics are a versioned protocol carrying stable codes, exact locations, observed values, admissible alternatives, and machine-applicable fixes — the format measured to move a frontier model from 22 of 56 to 54 of 56 on unfamiliar work.^[12]
• The supply chain is a language problem. Names resolve at build time against a verified log; the toolchain executes nothing a package supplied; a dependency's authority requirements are part of its checked signature rather than a promise in a readme.
• Evidence is generated, not asserted. Reproducible builds, provenance per definition, an enumerable trusted base, and a second independent checker running differentially — so the artifact that says a property holds does not depend on trusting us.

Section 04Where it applies first

Part II works through five sectors in the same structure and closes with the cost model; Chapter 11 then compares Kasuri directly against the stacks you run. Each sector chapter gives the typical workloads, the threat picture against them, the controls in common use today, where those controls run out, and what changes.

Agencies & retail

Client platforms, marketplace and channel operations, commerce, internal toolingThe general commercial case: several clients' data in one platform, third-party credentials with real spending power, and a security questionnaire standing between you and the next contract.

Government

Citizen services, case management, cross-department data sharingStatutory duties that are architectural rather than procedural; accreditation regimes designed for point-in-time assessment meeting continuous machine-authored change.

Defence

Mission support, logistics, coalition data handlingSupply chain compromise as a state-level technique; provenance and sovereignty of the toolchain; releasability enforced by construction rather than by process.

Financial services

Payments, ledgers, regulated reporting, customer platformsSegregation of duties and authorisation correctness as type-level properties; operational resilience obligations against accelerating change.

Critical infrastructure

Asset and outage management, regulated industrial workloadsDecades-long system lifetimes against a dependency ecosystem that churns weekly.

The cost case

Where the money actually goesA model rather than a claim: six cost lines, the published evidence on each, and a stated position on which figures are measured and which are targets.

How Kasuri compares

Against TypeScript, Python, Java/C#, Go and RustSixteen structural properties, like for like — including the three rows where Kasuri loses outright, and what each incumbent does better.

Section 05Where the programme stands

Kasuri is at specification stage, ahead of a reference implementation. The research is complete and distilled into a binding constraint set; the design phase has closed against its own gate; the specification is written against landed decision records with a generated register of everything it does not yet settle.

There is no production system to buy today, and this briefing does not pretend otherwise. What exists is a programme with published criteria capable of ending it, an evidence base that is checkable rather than asserted, and a roadmap in which every stage advances only when its evidence passes. Chapter 19 sets out the stages; Chapter 20 describes what engaging early involves and what it does not.