What a contract is
A capability with one implementation is a dependency, not a contract. A fusion.*/v1 contract is a written promise about a capability, such as serving a model, storing vectors or running a durable workflow, that at least two independent, licence-clean implementations keep. The promises belong to the contract, not the component.
- Name form
fusion.<name>/v<major>, for examplefusion.gateway/v1- Where it lives
- elan1 Run. The contracts are one of the two seams between layers; the other is KernelPort. Any other crossing fails the build.
- Who calls it
- elan1 Work, elan1 Decide and elan1 Govern all run on these contracts, and none gets a private door. So do your own applications.
- Dependency rule
- elan1 Run never depends on elan1 Govern. Infrastructure gets swapped; the write path must not. elan1 Run governs the call; elan1 Govern governs the write.
- Status
- Available in elan1 Run
The descriptor
Each contract has a written descriptor in five parts. Everything a caller or a tester relies on is generated from it, so the documentation, the SDKs and the tests cannot drift apart.
| Part | What it fixes | Checked by |
|---|---|---|
| surface | Every operation, field and outcome a caller may use. | K1 Surface |
| promises | What the contract promises whichever implementation is bound, including the declared shape of each failure. | K4 Semantic · K5 Failure |
| state | What the capability keeps between calls: stateless, indexed, registered or in-flight. | Declared, and shown on every contract |
| meters | What is counted for each call, and how. | K3 Accounting |
| test vectors | Inputs and expected outcomes that every implementation must reproduce. | The whole K1–K7 suite |
Generated from the descriptor: the SDKs (Python, TypeScript and Go), the routing table, the conformance assertions and the API docs.
The ten contracts
| Contract | What it carries | State | Example implementations | Govern’s work |
|---|---|---|---|---|
| fusion.chat/v1 | Chat interface, conversations, single sign-on and per-user quota. | Stateless | One candidate today; the second implementation is still open | — |
| fusion.gateway/v1 | Model gateway: aliases, routing, failover, budgets that stop before the first token, and attribution. | Stateless | LiteLLM · Bifrost · Portkey | Yes |
| fusion.inference/v1 | Serving open-weight models in your region. | Stateless | vLLM · SGLang · LocalAI | — |
| fusion.retrieval/v1 | Document ingestion and permission-aware retrieval, with per-document provenance. | Indexed | RAGFlow · Onyx | — |
| fusion.vectors/v1 | Vector storage and search. | Indexed | pgvector · Qdrant | — |
| fusion.trace/v1 | Spans for every call: who made it, what it cost, which component served it, bound to the proof record. | Indexed | Langfuse · Opik · MLflow | Yes |
| fusion.tools/v1 | Tool and MCP server registry, pinned by hash, with scopes and autonomy ceilings. | Registered | ContextForge · agentgateway · ToolHive | Yes |
| fusion.run/v1 | Durable workflows: long runs, retries and approval waits that survive a restart. Expiry means refusal. | In-flight | Temporal · Prefect · Dagster | Yes |
| fusion.memory/v1 | Agent memory across sessions. | Indexed | Mem0 · Cognee | — |
| fusion.guard/v1 | Checks for personal data, provenance and prompt injection. A guard verdict is an input, never the allow. | Stateless | Presidio · NeMo Guardrails · elan1 Run's own engine | Yes |
Open-source projects named for reference. No endorsement by them is implied. Which implementation is bound in a given deployment is set in that deployment’s stack spec.
Calling a contract
Five things happen to every call, whichever layer makes it. The example is a model call through fusion.gateway/v1.
Call the contract.
Your application calls
fusion.<name>/v1, never a component’s own API.Name contracts in the spec.
Your stack spec names contracts, not products. Changing a component is a one-line diff in the spec.
Pass the edge.
Every call passes the edge, where tenancy, budget and attribution are stamped once.
Route and label.
The contract proxy routes to the bound implementation and labels the call with an X-Fusion-Contract header.
Count it.
The call is metered against the contract's declared meters. A call refused at the edge sends no token, and it costs 40% of one governed action: ₹0.64 at the L1 rate.
POST https://<your-edge>/<path> # path per contract descriptor
Authorization: Bearer <tenant token>
X-Fusion-Contract: fusion.gateway/v1
Idempotency-Key: 4bf92f35-77b3-4da6-a3ce-929d0e0e4736
Content-Type: application/json
{
"model": "alias:finance-default",
"messages": [{ "role": "user", "content": "Summarise open purchase orders for Kolam Components*" }]
}HTTP/1.1 200 OK
X-Fusion-Contract: fusion.gateway/v1; impl=litellm
200 served under contract
409 refused at the edge (budget, guard) · no token sent · 40% of one governed action
4xx your request did not meet the contract
5xx our failure, never billed*Kolam Components is a fictional company; all data is illustrative.
A component change is a one-line diff
contracts:
fusion.gateway/v1: { impl: litellm }
fusion.trace/v1: { impl: langfuse }
- fusion.vectors/v1: { impl: pgvector }
+ fusion.vectors/v1: { impl: qdrant }
fusion.run/v1: { impl: temporal }The diff is small; the process around it is not. A change of component runs as a nine-step substitution with two human gates, H1 and H2, and is never autonomous. Conformance alone decides step 5, and at step 7.3 elan1 Run asks elan1 Govern for a gate check and honours the answer. If elan1 is unreachable, the plan is held, undecided. See elan1 Run Substitution.
The X-Fusion-Contract header
Every call carries the contract it was made under. The caller names the contract; the proxy labels the call with the contract and the implementation that served it. The label is what lets a trace, a meter line or a conformance result say exactly which contract version and which component handled a call.
- Names
- The contract and its major version, for example fusion.gateway/v1.
- Labels
- The bound implementation that served the call, added by the proxy.
- Used by
- Tracing, the meter, conformance results and substitution, so each can tell contracts and implementations apart.
- Full grammar
- How a minor revision or a pinned commit is written is in the customer reference.
Two licence-clean implementations
A contract is only a contract when two independent implementations keep it. That is what lets a component be archived, relicensed or acquired without your integration being rebuilt.
- Licence-clean means registered. Each component is entered in the licence register, pinned at an exact commit, with its licence text stored verbatim and its obligations recorded. K7 Licence checks it nightly. A component with a blocked licence cannot be registered.
- Both must pass. Every implementation behind a contract runs the K1–K7 suite every night. A red implementation cannot be the target of a substitution, and one that is red fourteen nights in a row comes off the price list. There is no override.
- One is not enough.
fusion.chat/v1has one candidate implementation today. With one implementation it is a dependency, so it is not served under contract until a second passes the suite. - Adding a component. Only through the licence register and the conformance suite.
Versioning and direct access
| Rule | What it means | Why |
|---|---|---|
| Breaking change | A new major version: fusion.<name>/v2. | A caller on v1 never has its promises changed under it. |
| Overlap | Both majors are served for at least two quarters. | Time to migrate without a cut-over night. |
| Notice | A quarter's notice before a major version is retired. | Planning, not surprise. |
| Direct access | Calling a component directly is allowed, but the contract's promises do not cover those calls. | The promises belong to the contract. |
| The 15% rule | If more than 15% of traffic goes direct, the contract needs a new version. | Direct traffic that large means the contract is missing something. |
The five contracts that carry Govern's work
elan1 Govern’s work runs on five contracts: gateway, trace, tools, run and guard. They carry the work; they never make the decision. Allow, refuse, approve, seal and prove stay with elan1 Govern, behind KernelPort.
| Contract | What it carries for Govern | What it never does |
|---|---|---|
| fusion.gateway/v1 | Routing, a budget hard stop before the first token, and attribution in front of every model call. | Decide whether a business write may happen. |
| fusion.trace/v1 | Spans for every call, bound to the proof record of the write that followed. | Stand in for the proof record. The record is written by Govern at rung 8. |
| fusion.tools/v1 | Tool authorisation, pinned by hash, with an autonomy ceiling. | Raise an actor above the autonomy its grant allows. |
| fusion.run/v1 | Long-running work, including approval waits. Expiry means refusal. | Approve on a person's behalf when a wait runs out. |
| fusion.guard/v1 | Checks for personal data, provenance and prompt injection. | Allow. A guard verdict is an input, never the allow. |
Status
| Contracts | What is served | Status |
|---|---|---|
| Govern's five | Gateway, trace, tools, run and guard, with elan1 Run as the real runtime. | Available |
| The other four | Inference, retrieval, vectors and memory, each with two licence-clean implementations. | Available |
| Chat | Served under contract once a second licence-clean implementation passes the suite. | Waits for a second implementation |
What the contracts do not do
- They do not resell inference or own GPUs.
- They do not decide whether a business write may happen. That is elan1 Govern’s job.
- They do not extend a contract’s promises to calls made straight to a component.
- A green conformance result is not a compliance statement. Read the test vectors before you rely on them.
What the customer reference covers
Paths and request bodies per contract
The examples above show the shape of a call; each contract's descriptor gives its exact path and body.
In the customer reference
X-Fusion-Contract grammar
How the implementation label, a minor revision or a pinned commit are written in the header.
In the customer reference
Stack spec format
The file that binds each contract to an implementation in a deployment.
In the customer reference
Descriptor schema
The five parts are fixed; the machine-readable schema that holds them is shared with customers.
In the customer reference
Second implementation for chat
Chat is not served under contract until it has one.
Waits for a second implementation