All four platforms available

Architecture · Field note

A model may produce a write intent, never an allow

In elan1, a model may produce a write intent, a typed proposal to change a record, but never an allow. The allow comes only from elan1 Govern, after identity, gates, versioned rules, a guardrail, the autonomy check and, where required, a named person. Keeping models off the allow path means no model can approve its own change.

One sentence carries most of the architecture. Here is what it rules in, what it rules out, and why the allow path has no model on it.

If you keep one sentence from elan1, keep this one: a model may produce a write intent. It may never produce an allow. Most of the architecture follows from it.

Two different objects

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: stop, identity, write door, the nine pre-gates, evaluate(), the guardrail and the autonomy check.

Illustrative specimen — the shape of a write intent. Not customer data. Exact field names are in the KernelPort v1 reference.
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:51b0…7d9a
  proposed_by       agt_specimen_ap01   (agent)

Why no model sits on the allow path

The question Govern answers is "May this record change?" The answer 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 good it is. So evaluate() runs versioned rules with no model in it. Earned autonomy — how much an agent may do alone — uses a deterministic score, with no model involved. A guard verdict from elan1 Run is an input, never the allow.

What models are for

This is not a position against models. They are good at the work that comes before the question: reading a document, drafting the journal entry, proposing which ledger a line belongs to. elan1 Decide gives a typed answer with a stated confidence and routes it by risk; below the threshold, a person decides.

Decide decides what the answer probably is. Govern decides whether any record changes. If they disagree, Govern wins.

How we keep the rule true

  • Layers meet in two places only — KernelPort and fusion.*/v1 — and CI fails the build anywhere else.
  • No product other than Govern builds a gate, an approval store, a seal, a meter or a verifier.
  • Where elan1 Work or elan1 Decide uses a model to draft, the product page names it in full.
  • An agent never approves its own change. Where a person must approve, the approver is named and is not the asker.
Status. elan1 Govern is available, with L1 Guarded and L2 Attested.

Corrections

  • 10 Oct 2026Status updated at launch: elan1 Govern, Work, Decide and Run are available, with L1 Guarded and L2 Attested. Technical content unchanged.

// SEE IT

See it on one governed write.

The walkthrough follows one write from intent to proof record, step by step, with a refusal branch.