The governed write path: an architecture paper

AI agents are starting to change systems of record: ledgers, invoices, claims and customer files. Most deployments govern the call — which model ran, what it cost — and leave the write itself to whatever credential the agent was given. This paper describes the alternative elan1 runs: a single, fixed route that every consequential write takes, owned by one component and ending in one record.

It sets out the reference architecture (planes P0–P8), the Right Path from rung 0b STOP to rung 9 METERED, the two seams where layers meet (KernelPort v1 and fusion.*/v1), the single writer and its 10-minute single-use credential, and the failure rules. It states what each layer does, what it proves and what it does not.

An AI agent that drafts an email and an AI agent that posts a journal entry are doing different kinds of work. The first produces text that a person reads. The second changes a record that the business, its auditors and sometimes its regulators will rely on later. Most of the controls that exist today were built for the first kind of work. They govern the call: which model ran, through which gateway, at what cost, with which prompt filters in front of it.

Those controls matter, and elan1 Run provides them. But they answer a different question from the one a finance controller asks when an agent is about to change the books. That question is not “was the model call within policy?” It is “may this record change?” — and, later, “who said it could, under which rule, and can I show that to someone who does not trust me?”

In most deployments, the answer to the second question is whatever the agent’s credential allows. If the agent has a database user or an API key with write access, the write happens, and the evidence is whatever logs the target system kept. The decision to allow was made implicitly, when someone issued the credential.

Two objects, kept apart

The governed write path rests on separating two objects that are usually fused:

• A write intent is a typed proposal to change a record. It names the write type, the declaration it claims to fall under, the record it would change and a hash of the payload. An agent can produce one. elan1 Decide’s router can produce one. A person in the console can produce one.
• An allow is the decision that the write may happen. Only elan1 Govern produces one, at the end of a climb through rungs 0b to 6.

Why the allow lives outside the model

The answer to “may this record change?” has to be reproducible. Given the same intent, the same declaration version and the same policy version, the result must be the same today, next quarter and in front of an auditor. That is why every proof record carries F07 declaration_version and F08 policy_version: so the decision can be replayed against the rules that were in force.

A model cannot make that promise, however capable it is. Its output depends on weights, sampling and context that are not part of the record and cannot be replayed in the same sense. So evaluate() runs versioned rules with no model in it. Earned autonomy — how much an agent may do alone — uses a deterministic score. A guard verdict from elan1 Run, such as a personal-data or prompt-injection check, is an input to the decision, never the allow.

The rule is kept true by construction rather than by policy. Conformance test C1 checks the import graph on every build: no module reachable from rungs 3 to 8 imports a model client, and nothing above P3 imports a kernel type.

The reference architecture divides the system into nine planes, from residency at the bottom to packs at the top (Figure 1). Four layers act across them — elan1 Work, elan1 Decide, elan1 Govern and elan1 Run — and an assurance rail (L1, L2, L3) runs alongside. Each plane has one owner. Where a layer has no role in a plane, the architecture says so, and that absence is as important as any presence.

Why the kernel is shut

P3 is the only plane where an allow can be produced, so it is the plane where extension would be most dangerous. A plugin model — where products add their own checks inside the kernel — would make every product a potential author of allows. Instead, the kernel is shut: elan1 Work, elan1 Decide and elan1 Run add nothing at P3. They reach it through KernelPort, like any third party.

Customisation happens one plane up, at P4. A declaration is a process’s rules as data, in seven versioned blocks: identity, shape, permissions, write types, gates, proof binding and channels. Every proof record names the declaration and version it was checked against. elan1 Decide’s Decision Packs compile to the same seven blocks, so a decision model and a hand-written rule set are checked by the same kernel in the same way.

Residency at the bottom

P0 sits under everything because residency is not a feature that can be added later. Each residency domain has its own database and, from L2, its own signing key. India is the first domain: AWS ap-south-1, Mumbai. Pre-gate G2 checks that a record’s domain matches the tenant’s on every write.

Every consequential change takes the same path, wherever it starts. Five plain steps — ask, check, approve, act, record — map onto ten rungs, from 0b STOP to 9 METERED (Figure 2). The rungs run in a fixed order. Any rung can refuse, and a refusal at any rung still produces a record.

Ask: rungs 0b to 2

The stop switch is read before anything else, so a tenant can be halted — by its owner, by revocation or by a regulator’s directive — without depending on any later check. Identity follows. The kernel, not the caller, sets actor_kind, so an agent cannot present itself as a person. The write door then requires that the write type exist at an explicit version in the declaration. There is no generic “update record” call; a write that is not declared does not have a door.

Check: rung 3, the nine pre-gates

Pre-gates are pure functions of the context, the declaration version, the record state and an explicit as-of time. No gate reads a clock, which is what makes a decision replayable. Gates run in declared order. The first failure sets the refusal code, but the remaining gates still run and record, so an operator sees every problem at once instead of fixing them one refusal at a time.

Six gates can never be switched off: consent, residency, retention, dual control, counterparty and precondition. The other three — rate, budget and schedule — can be declared off for a write type, and only with a decision record, which is itself a governed write.

Check: rungs 4 and 5

evaluate() applies the declaration’s versioned rules and returns one of three typed results: allow, refuse or escalate. It never returns a score. The guardrail then measures the blast radius against the declared limit for the write type. A request described as “update one invoice” must arrive as one invoice; an unbounded filter is refused before anything is written.

Approve: rung 6

Autonomy belongs to the actor, not the tenant, and runs from A0 Observe to A5 Act broad. There is no A6. A missing grant resolves to A0, never to a tenant default, and raising a level is itself a governed write approved by two people. Above the actor’s ceiling, a named person who is not the asker decides. They see the difference, the gate results and the policy version before they answer. The approval wait is held durably on elan1 Run’s fusion.run/v1 contract, so it survives a restart, and expiry means refusal.

Rungs 7 to 9 turn an allow into a change, a record and a meter event. Each has exactly one owner, and that is the point.

Rung 7: the single writer

Only one component writes to the system of record: the kernel’s single writer. For each allowed write it holds a single-use credential that lasts 10 minutes. It takes a snapshot, applies the change in a shadow sandbox, runs the gates again against the sandbox result, and only then sends identical bytes to the live system. If the second gate run disagrees with the first, the write is refused.

A single writer turns “who can change the books?” from a question about every credential in the estate into a question about one component. Conformance test C2 makes that claim testable: every write path other than the single writer is attempted against the real target, and each attempt must fail. Before a write type moves to Mode A, a bypass test against the real system is part of onboarding.

Every write type declares a reversal plan — a native undo or a compensating entry — or is marked irreversible: true. Test C12 runs the reversal plan by both paths.

Rung 8: the proof record

The record is written synchronously, before the caller gets its answer. It has sixteen fields under Seal v6 — no optional fields and no seventeenth field — and its SHA-256 digest is carried in F03 prev_digest of the next record in the tenant’s chain. The payload itself is never stored in the record; F14 holds a hash of it, so personal data stays out of evidence. Evidence rows cannot be updated or deleted.

A refusal is sealed like a commit, with a zeroed record_id and record_version 0. The outcome, the approver’s name and the refusal code are rendered beside the record, never inside it. The companion brief, Evidence for auditors, explains how an auditor reads these records.

Rung 9: the meter

Exactly one meter event is emitted per decision. A refusal is metered at 0.4 of a governed action, less than an allowed write, so a stricter rule set never makes a write intent cost more. Test C10 reconciles meter events, proof records and the target both ways, and replaying an intent (test C7) returns the original outcome, sequence and digest without a second meter event.

assert(write_intent)
  write_id          wr_specimen_7c2
  write_type        journal_entry.post
  declaration_id    decl_month_end_close
  record_id         je_specimen_5531
  payload_hash      sha256:e1eb0d8f…1a32ab6a

→ outcome          committed | refused | escalated
  seq              1042
  digest           sha256:f2423aa3…5aca2c18
  refusal          (register code and rung, when refused)

Four layers could easily become a web of private calls. The architecture allows exactly two crossings, and continuous integration fails the build anywhere else (Figure 1).

KernelPort v1: the only way into Govern

KernelPort has six calls. elan1 Work and elan1 Decide reach the kernel through it. Third-party agents reach it over an MCP server (34 tools) or an HTTP API. No caller has a side entrance that skips a gate.

The frozen identifiers are kernelport/v1, elan1.proof.seal.v6 and action-receipt/1. KernelPort v1 and the record shape are frozen: the six call names do not change, and a breaking change ships as a new version alongside v1.

fusion.*/v1: the only way into Run

elan1 Run puts each part of the open-source AI stack behind a versioned contract: chat, gateway, inference, retrieval, vectors, trace, tools, run, memory and guard. A caller names the contract in the X-Fusion-Contract header, never a vendor. Each contract has two licence-clean implementations and a conformance suite, K1 to K7, so a component can be replaced without changing the integration. elan1 Govern uses five of the ten: gateway, trace, tools, run and guard.

The dependency runs one way

Run never depends on Govern. Infrastructure gets swapped; the write path must not. Where the two meet, the rules are fixed:

• A guard verdict is an input, never the allow.
• The approval wait is held on the run contract, and expiry means refusal.
• Trace spans bind to the proof record.
• Substitution step 7.3 calls a Govern gate check — through KernelPort, like everyone else.
• Erasure is itself a governed write.
• Restore drills are verified with elan1-verify.

The same kernel can sit in two positions relative to the write, and the difference decides what may truthfully be claimed. The mode follows the credential (Figure 3).

Mode A, Enforced. elan1 Govern runs in-process through the SDK and holds the write credential through the single writer. No write reaches the system of record without a gate decision and a proof record. Only here do we use the word “enforced”. elan1 Work on hosted ERPNext runs in Mode A, and third-party agents can run in Mode A by agreement once conformance tests C1–C14 pass.

Mode B, Attested advisory. elan1 Govern is reached over MCP or HTTP and does not hold the credential. Every write intent is evaluated against your rules and recorded, and the caller receives a typed answer. The caller then makes the write with its own credential. We do not say a Mode B write was blocked, because elan1 Govern does not hold the key that makes it.

Modes do not change with the assurance level. From L2, a Mode B record can be signed, but signing does not make it enforced, and the record keeps the mark that the caller made the write in every export. Mode B is still worth having: it gives an agent vendor a typed, rule-based answer before the write and leaves a record of every attempt. What it cannot give is a guarantee about writes that never asked.

Every system fails eventually. The useful design question is which way. The governed write path has one rule: when anything is unclear or unavailable, stop and ask a person. A change that waits costs time. A wrong change committed to the books costs a correction, an explanation to an auditor and sometimes a restatement. Because the costs are not symmetrical, the failure direction is not either.

Conformance test C5, the fail-closed matrix, makes each dependency unavailable in turn and requires a platform refusal, never an allow. Test C6 checks that an actor without a grant resolves to A0 Observe. Test C11 checks that no approval is accepted from the requester or from an agent token.

An architecture paper that only lists capabilities invites readers to assume the rest. These are the limits, stated as plainly as the capabilities.

Nor is elan1 Govern an ERP, a CRM or a UI shell. It does not store your business data — the record holds hashes, not payloads — and it does not charge per seat. A refusal costs 40% of one governed action, never the full rate.

Reference architecture v1.0 is available in all four platforms. The following are set per deployment or set out in the reference customers receive. Changes are logged in public, on the architecture page and the disclosures page.

1. Who performs rung 7 for elan1 Work for small firms — the kernel or the promoter. Rung 7 is the single writer; for the small-firm edition, it is agreed with each firm at onboarding.
2. Where the proof record physically lives. The record shape is fixed; its physical home follows the deployment: hosted in your residency domain, or in your own VPC or on premises.
3. Key custody for L2 signing: signing keys are held per residency domain; custody details are in the customer reference.
4. DPDP erasure alongside an append-only chain. Payloads are hashed rather than stored, and erasure is itself a governed write. The library note sets out elan1’s role under the Act and the question that remains.
5. Pack gate names against the kernel register, listed per pack, described in section 3.
6. The refusal-code register, part of KernelPort v1 and shared with customers. Codes shown in this paper are illustrative.

Everything else in this paper describes the platform as it runs. Where a precise mechanism is fixed — SHA-256 over a length-prefixed preimage, a 10-minute single-use credential, six un-skippable gates — we have said so.