What Termin is

Termin is a compiler and a reference runtime. You write an application description in constrained English in a .termin file. The compiler produces a .termin.pkg archive containing a compiled intermediate representation (IR — a JSON artifact the runtime consumes) and supporting artifacts. A conforming runtime reads the archive and serves a complete web application: a server-side-rendered web UI, a REST API for every declared content type, a WebSocket endpoint for real-time subscriptions, a managed database, access control enforced on every call, and a complete audit log of every modification.

The .termin file declares:

A single .termin file expresses all of these. The compiler enforces consistency across them.

What Termin is not

A longer example

A fragment from the warehouse example that ships with the reference runtime:

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"

As a warehouse operator, I want to review inventory so that I can plan restocks:
  Show a page called "Inventory"
  Display a table of products with columns: SKU, name, category, state
  Allow filtering by category, state
  Allow searching by SKU, name
  For each product, show actions:
    "Activate" transitions to "active" if available, hide otherwise
    "Discontinue" transitions to "discontinued" if available, hide otherwise

The full file is roughly 120 lines. It produces a working application with create, read, update, and delete operations (CRUD), access control, state transitions, a filterable and searchable inventory page, and the corresponding WebSocket subscription endpoints.

Is Termin a fit for what you want to build?

Termin is a good fit if your application is predominantly CRUD over structured records with declared roles, state transitions, and permissioned operations. Internal tools, line-of-business applications, and back-office systems match this shape. Applications that fit this shape cover most of what internal tools, line-of-business applications, and back-office systems do.

Termin is a poor fit for:

Integration with external systems is expressed through Channels (typed interfaces) and Computes (pluggable providers). These extend what an application can do, but the provider itself is outside the Tier 1 guarantee boundary — see /guarantees.

How it differs from adjacent tools

If your application fits what Termin can express, you get structural guarantees no general-purpose framework can provide. If it does not, Termin is the wrong tool. The fit diagnostic above exists so you can decide without installing.

For the full conceptual model — the primitives, how they compose, and why applications built from them are easier to reason about than applications written in a general-purpose language — see the Termin model.

Where the name comes from

The name layers four references, in rough order of weight:

Named after the inventor of a musical instrument that sounds the way secure-by-construction software tries to feel — unambiguous, precise, a little otherworldly — with the software-engineering overtones riding alongside.

Next