Data, logic, action and security — in one place.

Unabstracted primitives for agents.

An agent sees exactly four things: typed data (objects and links), rules and workflows, permissions, and actions served as MCP tools. There is no hidden glue between them, so what the agent can do is what the model says it can do.

{
  "name": "procurement.supplier_invoice.pay_invoice",
  "description": "Pay a matched, approved supplier invoice.",
  "inputSchema": {
    "type": "object",
    "properties": { "invoice": { "type": "string" } },
    "required": ["invoice"]
  },
  "annotations": {
    "requires": "procurement.SupplierInvoice in [approved]",
    "emits": ["transitioned", "refused"]
  }
}

{
  "isError": true,
  "structuredContent": {
    "accepted": false,
    "refusal": {
      "code": "rules.three_way_match.quantity_mismatch",
      "message": "the action was refused; nothing was committed",
      "explanation": "INV-2291 bills 500 × carton; GR-0042 received 400; payment only leaves [\"approved\"]",
      "routed_to": "task/finance-review/INV-2291"
    }
  }
}

States and events are first-class.

Lifecycles are declared state machines: only a declared transition can move a state, and it is enforced at commit. Every commit appends events to a hash-chained ledger: created, transitioned, observed, deleted, timer, refused. Rules trigger on those events.

export const SupplierInvoice = Norn.type({
  name: "procurement.SupplierInvoice",
  properties: Schema.Struct({
    number: Schema.String,
    purchase_order: Schema.NullOr(Schema.String),
    quantity: Norn.decimal(0),
    total: Norn.decimal(2),
    status: Schema.Literals(["received", "matched", "approved", "paid", "disputed"]),
  }),
  identity: [{ name: "primary", properties: ["number"] }],
  lifecycles: [{
    property: "status",
    initial: ["received"],
    terminal: ["paid"],
    transitions: [
      { id: "match",   from: ["received"], to: "matched",  by: "rules.three_way_match" },
      { id: "dispute", from: ["received", "matched"], to: "disputed" },
      { id: "approve", from: ["matched"],  to: "approved", gate: "human:finance" },
      { id: "pay",     from: ["approved"], to: "paid" },
    ],
  }],
})

{ "kind": "transitioned", "object": "procurement.SupplierInvoice/INV-2291",
  "transition": "match", "from": "received", "to": "matched",
  "by": "rules.three_way_match", "cause": ["GR-0042", "PO-0117"],
  "prev": "sha256:(elided)", "hash": "sha256:(elided)" }

{ "kind": "refused", "actor": "ap_agent",
  "action": "procurement.supplier_invoice.pay_invoice",
  "object": "procurement.SupplierInvoice/INV-2291",
  "code": "rules.three_way_match.quantity_mismatch",
  "prev": "sha256:(elided)", "hash": "sha256:(elided)" }

A constrained, pure-functional core.

Definitions are pure data. Rules are pure functions over a slice of state and an event, with budgeted expressions: no IO, no clock, no randomness. Side effects leave only as explicit commands, and their results come back as observations that are re-checked before they count.

const now = Date.now()     // NORN-FLOW-AMBIENT  9:17
const coin = Math.random() // NORN-FLOW-AMBIENT 10:18

A very lean stack.

A pure Rust core, a sans-IO kernel compiled to native and to wasm, and one Durable Object per tenant holding that tenant’s data in its own SQLite file. There is no database cluster, queue cluster or fleet of microservices to run, because the cell is its tenant’s database, workflow engine and policy point in one process.

Agents never touch prod. Norn works like git.

An agent works on a fork of the business, a branch of the ledger, never on prod. Its changes merge back only through the same checks; conflicts are explicit, because every write is version-checked, and the agent has to resolve them. A bad merge is reverted by replaying the ledger.

Hash-chained ledger Today

Every commit appends; the head is verified on read. Export and verified restore rebuild a cell from a content-addressed export.

Every write version-checked Today

Compare-and-set, so a stale write is refused, not merged. Backtesting a rule change on history runs on sample data.

Per-agent forks and merges Next

The agent never holds a write to prod.

Point-in-time rollback Next

An agent deletes every customer record; you roll back in one step.

Simulation Next

Run a proposed rule or workflow against the fork, or against history, before it ships.

Leaner agents on a thinner substrate.

When the structure lives in the substrate, the model has less to get right. Typed objects, declared states, rules, permissions, and refusals that say exactly what is wrong: the substrate catches what a smaller model would miss, so smaller and cheaper models can do work that otherwise needs the smartest one.

The model proposes; the rules decide. An agent drafts a match or a payment, and whether it goes through is the decision table’s call. A refusal is a cheap retry: “invoiced 500, received 400, payment only leaves approved” is the whole correction.

MCP as the universal tool surface.

Point an agent at /mcp. It gets your actions, not your database. Calls go through the same authorization, lifecycle checks and ledger as a person’s, and a refusal is a structured tool error that commits nothing.

{
  "mcpServers": {
    "norn": {
      "type": "http",
      "url": "http://127.0.0.1:8787/mcp",
      "headers": {
        "x-norn-org-id": "org_demo",
        "x-norn-environment-id": "dev",
        "x-norn-actor": "ap_agent"
      }
    }
  }
}

Early product. Here is exactly where it is.