Core concepts

The one rule

A model may produce a write intent. It may never produce an allow.

A write intent is a typed proposal to change one record in a system of record: post this journal entry, change this credit limit. Agents, the elan1 Decide Router and people in the console can all produce one.

An allow is elan1 Govern’s decision that the write may happen. It is the end of a climb, not a single check, and only Govern produces one. No model sits on the allow path: a model may draft the change, Decide may propose the answer, and a runtime guard verdict may be an input, but none of them is the allow. If Decide and Govern disagree, Govern wins.

A refusal is a typed “no” from any rung. It is recorded like any other outcome and costs 40% of one governed action, because it still runs every check and writes a proof record. Refusals are information: they show how often agents propose writes your rules do not allow, and which rule said no.

Four layers, one write path

elan1 is one write path with four layers. Two propose, two assure, and only one allows.

Verbs belong to their owner. Only Govern allows, refuses, approves a write, seals or proves. Work never says a change was “approved by the agent”; Decide never approves a write and is never a second kernel; Run is never the subject of allow, refuse, gate, proof or seal. Wherever another surface shows a Govern decision, it carries one line: “Checked and recorded by elan1 Govern.”

Two seams. Nowhere else.

Layers meet in exactly two places, and CI fails the build if a third crossing appears. Neither seam is a convention; each is the only path that exists.

The separation has a practical consequence. Infrastructure underneath can be swapped — a model gateway, a vector store, a tracing backend — without touching the write path, because nothing above the seam knows which implementation is in service.

Write intents and outcomes

A write intent names the write type, the declaration it claims to fall under, the actor, the record it would change and its expected version, and the payload. Its identifier, write_id, becomes field F04 on the proof record whatever the outcome, and doubles as the idempotency key: replaying the same write_id returns the original outcome, never a second write.

write intent            proposed by an agent, the Decide Router or a person
  │
  ▼  KernelPort · assert
Right Path              0b STOP → 1 IDENTITY → 2 WRITE DOOR → 3 PRE-GATES
                        → 4 evaluate() → 5 GUARDRAIL → 6 AUTONOMY
  │
  ├─ refused            typed code · proof record · meter 0.4 governed action
  ├─ escalated          obligation to a named approver · proof record
  │     └─ approved → continues at rung 7 · refused or expired → refusal
  ▼
7 ACT                   single writer · sandbox first · single-use credential, 10 minutes
8 PROOF                 16 fields · Seal v6 · chained by prev_digest
9 METERED               exactly one meter event: one governed action

There are three outcomes — committed, refused and escalated (waiting on a named person) — and every one of them writes a proof record. A platform failure is a fourth case that is ours, not a rule, and is never billed. Handling the outcomes shows each response.

An undo changes the books too, so it is a write intent of its own: it takes the same path and leaves its own record. Nothing in elan1 edits history in place.

Declarations: rules as data

A declaration is a process’s rules in seven versioned blocks: what may change, under which gates, and who approves. The blocks are identity, shape, permissions, write_types, gates, proof_binding and channels. Declarations are written in Declaration Studio in elan1 Govern, or registered through define.

Every proof record names the declaration it was checked against (F06) and the version in force at the time (F07). Change the rules and the version moves; old records still point at the rules that applied to them. Registering or changing a declaration is itself a governed write under dual control. elan1 Decide’s Decision Packs compile to the same seven blocks, so there is one rule format across the layers.

A pack — ledger1 for MCA, invoice1 for GST, collect1 for RBI — is configuration of Govern for a rule set: declarations and gate parameters, never code and never a brand. Declarations reference.

The Right Path

The Right Path is the fixed route every consequential write takes, from rung 0b STOP to rung 9 METERED. Five plain steps map onto ten rungs, and any rung can refuse.

1. Ask — 0b STOP, 1 IDENTITY, 2 WRITE DOOR. Writes are not stopped; the asker is identified; the write type exists at an explicit version.
2. Check — 3 PRE-GATES, 4 evaluate(), 5 GUARDRAIL. Nine pre-gates run against your own data, six never skippable; versioned rules decide with no model; the blast radius is measured.
3. Approve — 6 AUTONOMY. Above the actor’s autonomy ceiling, a named person who is not the asker decides.
4. Act — 7 ACT. In Mode A, a single writer makes the change with a single-use credential that lasts 10 minutes, sandbox first. In Mode B, your system writes.
5. Record — 8 PROOF, 9 METERED. A 16-field record, chained to the one before it, and exactly one meter event.

Rungs 3 to 8 cannot reach a model client; conformance test C1 checks the import graph on every build. The Right Path, rung by rung.

Approvals and autonomy

Every actor holds an autonomy level from A0 (observe) to A5 (act broad); there is no A6. A missing grant resolves to A0, never to a tenant default. At rung 6, the level the actor holds now is compared with what the write type needs. Below the ceiling the write continues; above it, Govern raises an obligation for a named approver.

Approvals are named and step-up. The approver is never the asker, and sees the change, the gate results and the policy version before deciding. If nobody answers before the approval expires, expiry is a refusal. Raising an actor’s autonomy level is itself a governed write, approved by two people. Earned autonomy uses a deterministic score, with no model involved. The level a write actually ran at is sealed into its record as F11.

The proof record

Every outcome — committed, refused or escalated — writes a proof record of exactly 16 fields under Seal v6. “No seventeenth field, ever.” The record is hashed with SHA-256 over a length-prefixed preimage, and the digest becomes the next record’s prev_digest (F03). Chains are per tenant and never cross tenants.

The record keeps a hash of the payload (F14), not the payload, so personal data stays out of evidence; and a hash of the vocabulary the write was expressed in (F15), so meanings cannot drift unnoticed. Evidence rows cannot be updated or deleted.

At L1 the chain is tamper-evident: change a past record and its digest no longer matches the one its successor carries. It is evident to you; it is not signed. All 16 fields and the recompute.

Modes and assurance levels

Two separate questions decide what elan1 may claim about a write.

Levels are levels of a claim, not product tiers. Modes and assurance levels sets out what each combination lets you say.

Tenancy and residency

A tenant is the unit of isolation: every token, declaration and chain belongs to exactly one, and field F01 names it on every record. scope sets and reads what a caller may do: tenant, residency domain, write types and autonomy ceiling.

A residency domain is a region with its own database and, from L2, its own signing key. Today there is one: in, on AWS ap-south-1 (Mumbai) across three zones. A cross-domain query is not slow; it is impossible. New regions open only on a signed contract, never a forecast.

The meter

Each layer charges for one unit, never per seat and never per outcome: elan1 Work meters credits, elan1 Decide meters decisions, elan1 Govern meters governed actions and elan1 Run meters node-years. A credit in Work is a rendering of governed actions, never a separate count, so one change is never paid for twice.

A governed action is one consequential write that passed the Right Path and was committed. It produces exactly one meter event at rung 9. A refusal produces a meter event of 0.4 of a governed action, and a database check holds it there. A platform failure is never billed. Prices are on the pricing page, exclusive of GST.

Failure behaviour: fail toward a human

When anything is unclear or unavailable, elan1 stops and asks a person. Stopping allows is the safe direction: a delayed change costs time, while a wrong change committed to the books costs far more.

• If elan1 Govern is unreachable, allows stop and changes wait for a person. elan1 Run tooling fails closed.
• If the runtime fails, writes stop.
• If nobody answers an approval before it expires, expiry is a refusal.
• If a gate cannot reach the data it needs, it does not guess; the write is refused or held.

Concept map

Where each concept appears in the API and on the record.

Every term on this page is defined in one sentence in the docs glossary.