Termin

Why Termin

Termin is not a better framework. It is a different answer to a different question. The mechanism on the what-is-Termin page only makes sense once the question is clear. This page states the questions.

Why is audit the bottleneck, not authorship?

AI can generate application code faster than any human can audit it.

Inside large organizations, every new or substantially updated web application goes through multiple mandatory reviews — security review, accessibility review, design review, architecture review — before it can ship. Review is human, review is slow, and review is now the bottleneck on enterprise software delivery. Code can be generated in minutes. It still takes months to be confirmed safe to deploy.

Termin attacks the bottleneck by shrinking the audit surface. Instead of reviewing every application from scratch, a Termin application is composed of pre-audited primitives that are part of the language and the runtime. The behaviors that traditionally require security review are enforced structurally. A Termin application still needs behavioral testing and business-logic testing. It does not need the same security, accessibility, or architecture review, because those properties belong to the platform, not to the individual application.

Translated to practical terms: an organization audits a conforming Termin runtime once. Every application built on that runtime inherits the audit. The review queue shrinks to the part of the application that is actually unique — the business logic.

Why does AI-integrated software need a structural boundary?

Applications that incorporate AI agents need a clear architectural boundary between their deterministic zone — logic, access control, state machines, audit trails — and their nondeterministic zone — the LLM calls that produce suggestions, summaries, classifications, or decisions.

Today that boundary is a convention. Developers bolt LLM calls onto applications through API keys and prompt engineering, and hope the agent stays inside the envelope it was intended to occupy. Applications written in general-purpose languages have no way to enforce that envelope; there is no typed interface, no declared scope, no audit trail that the agent cannot bypass by being prompted differently.

Termin makes the boundary a structural property of the language. An agent is a typed primitive with declared scopes, typed channels, and a complete audit log. The Termin runtime enforces what the agent can see and do. An agent cannot access data outside its declared scope, cannot take actions it was not granted, and cannot operate without an audit trail — regardless of how it was prompted. See the guarantees for the specific structural properties.

This matters because AI-integrated software is going to be most of software, and the substrate it runs on matters. Termin is designed from the language up to make that substrate trustworthy.

How are Termin specifications meant to be written?

The expected working model for Termin is not that humans learn the syntax and hand-author applications.

The expected working model is:

The language is small enough to fit entirely in an LLM's context window. The specification is readable enough that a non-programmer can audit it. The guarantees are enforced whether the author is human, AI, or a team of both.

A Termin specification is the artifact a human reads. What the compiler produces from that specification — the running application — does not need a separate audit, because the structural properties are properties of the language and the runtime, not properties of the generated output.

Is Termin just a better framework?

If you accept that audit is the bottleneck on enterprise software delivery, Termin is a path to the speed that AI code generation promises but cannot deliver today. Shrinking the audit surface to pre-reviewed primitives is how generated code gets into production in weeks instead of months.

If you do not accept that framing — if audit is not the bottleneck in your context, or if you believe the current review process is appropriate to keep — Termin is extra homework. Learning its primitives, constraining your expressiveness to fit its language, adopting a new runtime. Not worth the cost.

This is not a better Django. It is a different answer to a different question. The answer only makes sense if you have asked the question.

What does this mean for different readers?

For enterprise engineering organizations. The review queue gets shorter for Termin applications because the platform enforces what the review process would otherwise have to confirm on a per-application basis. Adoption makes sense when the cost of maintaining the review process outweighs the cost of constraining application expressiveness to Termin's primitives. The trade-off is real in both directions; Termin is not trying to hide it.

For teams building AI-integrated products. The boundary between deterministic logic and nondeterministic agent output is enforced by the Termin runtime, not by convention or careful prompting. An agent's blast radius is bounded by what you declared in the specification, not by what the model was told to stay inside. When the model behaves unexpectedly — and it will — the damage is bounded by the declared scope, and the audit log records what happened.

For individual developers. Termin is a tool for describing applications that are safe by construction. The interesting work is moving up the stack — specifying what the application should do — rather than writing the plumbing a framework used to require. The work that remains is the work that was always the hard part: getting the requirements right.

Next