The approach in brief

This chapter states the mechanism in one page. Part III works through each consequence in detail. Nothing here describes syntax: the language surface is not yet frozen, and the argument is about what is guaranteed rather than how it is spelled.

Section 01The mechanism

In every mainstream language, the ability to reach the outside world is ambient. Any code in a running process can, in principle, open a connection, read a file, or query a database, because those abilities belong to the process rather than to the code. Nothing is granted; everything is simply available.

Kasuri removes that. Every ability to affect the world — reaching data, sending a request, reading a clock, holding a credential — is an explicit, unforgeable value that must be passed to code before it can act. There is no ambient path and nothing to reach for.

Code that was never given the database cannot query it. Not "should not". Cannot — the program that does is not a program.

This is a well-studied idea that mainstream languages declined to adopt, and the reason they declined is instructive: the bookkeeping was judged too tedious for a human author. That judgement was probably correct. It is the wrong judgement for a machine author that never tires of writing things down — which is why the arrival of machine authorship makes an old idea newly practical rather than merely newly fashionable.

Section 02What falls out of it

The reason to spend a design budget on one mechanism is that a single mechanism pays several times.

Injection stops escalating

An author under someone else's influence still has to obtain the authority to act. A component built without data access does not acquire it because a prompt said so.Contains threat class 2, which has no clean fix at the point of injection.

Segregation becomes structural

Where an authority is scoped at the moment it is issued — to one tenant, one classification, one customer — code holding it cannot name anything outside that scope.The cross-boundary leak stops being a defect a test might catch.

Credentials stop being strings

A secret that is an authority rather than a value cannot be printed, serialised or logged by code that was not given it.Contains threat class 4; the documented exfiltrations all needed something readable.

Placement becomes derivable

If what code can do is written into what it must be handed, then where it may run — browser, server, store — has a mechanical answer.The tier boundary is computed and checked rather than maintained by hand.

Dependencies gain a checked permission surface

A component's authority requirements become part of its signature: a static property the checker enforces and a reviewer can read.Answers the SBOM gap in Chapter 3 — not what is present, but what it may do.

Audit questions get real answers

"What can this reach?" becomes a query with a complete answer rather than an inference from imports and configuration.

Section 03Where the trade goes

One consequence of the mechanism deserves stating on its own, because it is counter-intuitive: speed and assurance stop being a trade. That needs justifying, because in every stack you operate today they plainly are one.

The trade exists because assurance is currently added: scanning, review, testing and accreditation are all work performed on top of a system that was written without regard to them. More assurance means more of that work, and the work is serial with delivery. That is a real trade and no amount of tooling removes it.

The claim here is that the trade is a property of the method, not of the goal. When the guarantee is carried by the language:

• The check is the build. The property is established when the code compiles, not in a subsequent phase that has to be scheduled, resourced, and waited for.
• The reviewer is the compiler. A machine author iterating against a machine reviewer converges quickly. The measured lever is large — 22 of 56 unaided against 54 of 56 with compiler-guided repair, in a language the model barely knew.^[12]
• The assembly disappears. One description generating every derived artifact removes the category of work — and the category of dependency — that exists to keep three programs agreeing with each other.

So the assurance work does not get faster. It gets moved, from a phase after writing into the act of writing, where a machine performs it at machine speed. That is the different way of thinking this design asks for, and it is a claim the programme's benchmark is designed to test rather than assert.

Section 04What it costs, and the budget we keep

Every departure from what models already know is a tax: a model writing an unfamiliar construct performs worse than the same model writing a familiar one, and that penalty is paid on every build, forever.

So the programme keeps a binding ledger of every departure, each one priced, with a hard cap. The rules are deliberately awkward for us. A restriction — a rule that makes fewer programs writable — prices nothing, because a model that never saw the forbidden form loses nothing by its absence; but only if the toolchain can report the violation with a real diagnostic. A restriction the compiler cannot explain is not a restriction, it is a trap, and it forfeits the discount. Reusing a construct the major training languages already have also prices nothing, but the comparison set is named and fixed, and searching outside it does not count.

The ledger currently sits at its cap with no headroom. A new departure cannot be added without removing an existing one. We publish this because it is the discipline most likely to be quietly abandoned, and a budget that only ever grows is not a budget.

Section 05The claim under test