Termin

Termin is an open-source application platform that compiles constrained English specifications into running software whose security properties are enforced by the structure of the language itself.

Termin is three things at once.

A language for describing applications. You write what the application does — its content, its roles, its workflows, its pages — and the compiler produces a running web application with structural security properties.

An ecosystem of conforming implementations. The specification is open, the conformance suite is public, and applications run on any conforming runtime. Presentation, storage, identity, and compute providers let the same application target different operational environments without code changes.

A substrate designed for AI agents. The language is small enough that an LLM can fully master it. Agents can author Termin applications that are safe by construction, not by review. Agents can also participate in applications through declared scopes, typed channels, and complete audit logs — as real participants in workflows, not external consumers with API keys.

The sections below start with the first layer. The vision page explains what is true today and what is on the path. The roadmap shows the development timeline.

A .termin file describes content, roles, scopes, state machines, and operations. The compiler produces a .termin.pkg archive (a package containing the compiled specification). A conforming runtime serves it over HTTP. SQL injection, command injection, and broken access control are not achievable through Termin application code, because the language provides no construct for expressing them.

Every structural claim is backed by a test in the conformance suite.

# What a .termin file looks like

Content called "products":
  Each product has a SKU which is unique text, required
  Each product has a name which is text, required
  Each product has a category which is one of: "raw material", "finished good", "packaging"
  Anyone with "inventory.read" can view products
  Anyone with "inventory.write" can update products
  Anyone with "inventory.admin" can create or delete products

State for products called "lifecycle":
  A product starts as "draft"
  A product can also be "active" or "discontinued"
  A draft product can become active if the user has "inventory.write"
  An active product can become discontinued if the user has "inventory.admin"

The full warehouse example is roughly 120 lines and implements content management, access control, state machines, event-driven computations, and a role-appropriate presentation layer.

# What you get when you run it

When the compiler processes a .termin file, it produces a .termin.pkg archive. A conforming runtime reads that archive and serves a complete web application:

• A web UI rendered server-side, with pages, forms, tables, and role-appropriate content. The presentation layer is declarative and covers the interactions common to internal tools and back-office workflows — list and detail views, create and edit forms, filtering, searching, pagination, and action buttons gated by permission. Rich client-side interactivity beyond this surface is not part of Termin's scope.
• A REST API for every content type declared in the source. Create, read, update, and delete records — all parameterized, all scope-checked, all audit-logged. The API is generated from the specification, not hand-written.
• A WebSocket endpoint for real-time subscriptions. When a record changes, every client subscribed to that content type receives the update. Live dashboards, collaborative editing, and real-time alerts are declarative features, not bolt-ons.
• A database managed by the runtime. The reference runtime uses SQLite; alternative runtimes can use PostgreSQL, MySQL, or other storage backends through the storage provider interface.
• Access control enforced on every call. Declared scopes are checked on every record operation, every state transition, every Compute invocation, every Channel send, and every page render. There is no code path that bypasses the access-control layer.
• A complete audit log. Every modification is recorded with the caller's identity, the operation, the affected record, and a timestamp.

This is what you get from the 120-line warehouse example: a working inventory application with role-based access, state transitions, filterable tables, real-time updates, and a complete audit trail. No separate framework to learn. No plumbing to write. No access-control layer to audit.

# Where to go next

• Try it — install the reference runtime, compile the warehouse example, run it locally.
• The vision — the full three-layer thesis, what is shipping today, and what is on the path.
• What Termin is — the longer explainer, including fit diagnostic and comparisons to Rails, Django, Hasura, Supabase, and Retool.
• See the guarantees — the three-tier model, with a link to the conformance test backing each structural claim.

# About the project

Termin is authored by Jamie-Leigh Blake and released under Apache 2.0. There is no paid tier, no hosted offering, no enterprise edition, and no commercial services contract. The project has no monetization plan. Source is on GitHub. The conformance suite and IR (intermediate representation) schema are in a separate repository.

Termin is pre-v1.0. The IR format is versioned and breaking changes between minor versions are still permitted. See the roadmap for the path to v1.0.