All four platforms available

Builders · Field note

Two crossings: why the layers meet in only two places

elan1's four layers meet in only two places. Above, every write intent enters through KernelPort; below, elan1 Run reaches the open-source AI stack only through fusion.*/v1 contracts. With two crossings, there are only two places to audit, and components on either side can change without opening a new path to the system of record.

Four layers, two seams. KernelPort is the way into Govern, fusion.*/v1 the way into Run, and the build fails if anything else crosses.

elan1 is one write path in four layers: elan1 Work, elan1 Decide, elan1 Govern and elan1 Run. Four layers could easily become a web of private calls between them. We decided early that they would meet in exactly two places, and that the build would fail anywhere else.

Crossing one: KernelPort

KernelPort v1 is the only door into Govern's kernel. It has six calls: define, assert, seal, verify, scope and refuse. Work reaches Govern through it. Decide reaches Govern through it. Third-party agents reach it over an MCP server (34 tools) or an HTTP API.

Having one door means having one place to check. Every write intent from every layer climbs the same Right Path and ends in the same 16-field record. Nobody has a side entrance that skips a gate.

Crossing two: fusion.*/v1

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 call names its contract in the X-Fusion-Contract header. Each contract has two licence-clean implementations and a conformance suite, K1–K7.

The dependency runs one way. Run never depends on Govern. Infrastructure gets swapped; the write path must not. When Run substitutes a component, it asks Govern for a gate check at substitution step 7.3 and honours the answer — through the same door as everyone else.

Modes follow the credential

How each consumer connects
ConsumerModeWhat we may say
elan1 Work hosted (ERPNext)A · SDK in-processNo write reaches the system of record without a gate decision and a proof record.
elan1 Work Attach (your ERPNext)B · MCP/HTTPEvaluated against your rules and recorded.
elan1 DecideB · MCP/HTTPWrites go to Govern as intents.
elan1 Run toolingB · MCP/HTTPIf elan1 is unreachable, the gate check fails closed.
Third-party agentsB (A by agreement)No claim to run on Govern until conformance tests C1–C14 pass.

The word "enforced" belongs to Mode A only, where Govern holds the write credential. Over MCP or HTTP, elan1 evaluates and records. We do not say it blocks, because it does not hold the key that makes the write.

What builders get from the constraint

  • One integration surface to learn, with six calls whose names do not change: KernelPort v1 is frozen.
  • Typed refusals: when a write is turned down, your agent receives a code it can act on, not a string to parse.
  • Components you can replace without rebuilding the integration, with conformance you can run offline.
Status. KernelPort v1 and the record shape are frozen. elan1 Run is available.

Corrections

  • 10 Oct 2026Status updated at launch: elan1 Govern, Work, Decide and Run are available, with L1 Guarded and L2 Attested. Technical content unchanged.
  • 6 Oct 2026Product names updated to elan1 Work and elan1 Run, following the v1.1 brand register. No technical content changed.

// 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.