Two suites, one rule
The rule is the same for both: pass the suite before you make the claim. A green result is the claim; there is no review that can stand in for it and no person who can wave it through.
| Suite | Who it applies to | What passing allows |
|---|---|---|
| K1–K7 | Every implementation bound behind a fusion.*/v1 contract in elan1 Run. | To serve calls under the contract, and to be the target of a substitution. |
| C1–C14 | Third-party agents and integrations that write through elan1 Govern. | To say the agent runs on elan1 Govern. Until all fourteen pass, it connects in Mode B and makes no such claim. |
Suite K1–K7: components behind a contract
Seven classes. Five block: a run is blocking-green or it is not. Two report a figure against a tolerance. Which classes block is fixed in the schema, not chosen at run time.
| Class | What it shows | Result |
|---|---|---|
| K1 Surface | Every endpoint, field and outcome in the contract descriptor behaves as written, on every implementation. | Blocks |
| K2 Isolation | No tenant can see another tenant's data or counts. An isolation attack runs nightly. | Blocks |
| K3 Accounting | The meter counts what actually happened: the runtime meter agrees with the component's own counters within 0.5%. | Blocks |
| K4 Semantic | Answers behave as the contract promises, within tolerance on a fixed corpus, when a component changes. | Reports a figure |
| K5 Failure | Each declared failure comes back in the declared shape, including a 409 at the edge, metered at 40% of one governed action. | Blocks |
| K6 Performance | Latency, throughput and cost are measured and published as measured. | Reports a figure |
| K7 Licence | Each component is pinned at an exact commit, with its licence text stored verbatim and its obligations, and checked for change. | Blocks |
Why only five block: answer quality and speed depend on your workload, so K4 and K6 are reported against a tolerance. Surface, isolation, accounting, failure shape and licence are pass or fail.
How K results count
Vectors come from the descriptor.
Test vectors are written from each contract's descriptor, the same source as the SDKs and the API docs.
Red before green.
A green assertion that has never been red is not evidence. Every assertion must be shown to fail before its pass counts.
Nightly, on every implementation.
The suite runs every night against every bound implementation. Results land in the append-only evidence plane.
Red blocks substitution.
A red implementation cannot be the target of a substitution. Conformance alone decides step 5 of every substitution.
Fourteen red nights, off the list.
An implementation red for fourteen nights in a row comes off the price list. There is no override.
Run K1–K7 offline
The suite runs on a machine we have never seen, with no network: yours, or your auditor’s. That is the difference from vendor validation, which runs on the vendor’s machine.
Collect the inputs.
The suite, the test vectors for the contract you are checking, and the implementation pinned at its exact commit, with its licence text from the licence register.
Read the vectors.
It is our suite. Read what the vectors assert before you rely on a green result.
Disconnect and run.
Run the suite against the pinned implementation with no network. Nothing is sent to us.
Read the result.
Blocking-green, or not. For K4 and K6, compare the reported figures with the contract's tolerance.
Compare with ours.
Set your result next to the nightly result for the same implementation and commit. They should agree.
# On a machine with no network. Names in <angle brackets> are placeholders.
$ <conformance-runner> \
--contract fusion.trace/v1 \
--implementation ./components/langfuse@<pinned-commit> \
--vectors ./vectors/fusion.trace.v1/ \
--licence-register ./licence-register/ \
--out ./results/conformance run · fusion.trace/v1 · implementation langfuse @ <pinned-commit>
network none
vectors fusion.trace.v1 · every assertion shown to fail before its pass counts
K1 Surface passed blocks
K2 Isolation passed blocks
K3 Accounting passed blocks
K4 Semantic reported within tolerance
K5 Failure passed blocks
K6 Performance reported figures recorded
K7 Licence passed blocks
result blocking-greenTests C1–C14: third-party agents on Govern
C1–C14 check the governed path an agent’s writes travel, end to end: that nothing bypasses the single writer, that every rung runs, that failures fail closed, and that outcomes, records and the meter agree. They do not grade the agent’s answers.
| Test | What it shows | Protects |
|---|---|---|
| C1 Import graph | No module reachable from rungs 3–8 imports a model client; nothing above P3 imports a kernel type. | Boundary |
| C2 Bypass attempt | Every write path other than the single writer fails against the real target. | Boundary |
| C3 Rung completeness | For 100 intents, every rung runs in order and every gate records a row. | The path |
| C4 Determinism replay | The same intent, versions and as-of time give the same decision on replay. | The path |
| C5 Fail-closed matrix | Every dependency outage produces a platform refusal, never an allow. | The path |
| C6 Missing grant → A0 | Actors without a grant resolve to A0 Observe. | The path |
| C7 Idempotency | Replaying an intent returns the original outcome, sequence and digest, and no second meter event. | Outcomes |
| C8 Refusal shape | A refusal returns a register code, the rung, a zeroed record_id, record_version 0 and a meter quantity of 0.4. | Outcomes |
| C9 Chain integrity | A flipped octet, a reordered pair, a duplicate and a gap are each found. | Outcomes |
| C10 Meter reconciliation | Meter event, proof record and target reconcile both ways. | Outcomes |
| C11 Approval separation | No approval where the approver is the requester, and none by an agent token. | People and change |
| C12 Rollback drill | The reversal plan runs by both paths: native undo and the compensating entry. | People and change |
| C13 Version pinning | “latest” is rejected for production keys; every decision records its versions. | People and change |
| C14 Claim boundary | A string check over rendered L1 copy for claims that belong to L2. | Boundary |
C14 is also the lint that this site’s own copy runs through: L1 copy that claims what only L2 delivers fails the build.
What changes when all fourteen pass
- Before
- The agent connects in Mode B, over MCP or HTTP. Its write intents are evaluated against your rules and recorded. It may not say it runs on elan1 Govern.
- After
- It may say it runs on elan1 Govern. It still connects in Mode B unless elan1 holds the write credential by agreement: passing C1–C14 does not by itself make a write enforced.
- Mode A
- By agreement only, where the write credential can move to elan1. We ask for at least 30 days of Mode B traffic and a bypass test against the real system first.
Running C1–C14
- Some tests need the real target. C2 tries every other write path against the real system of record, and C12 runs the reversal plan both ways. Neither can be shown on a mock.
- Some tests are about records. C7 to C10 compare outcomes, proof records and meter events. C9 uses the same chain walk described in Recompute a chain at L1.
- Keys. Sandbox keys are issued with your workspace. Production keys are issued by elan1 after an onboarding checklist, never self-serve.
- Witnessed runs. How a third party’s run is scheduled, witnessed and published, and the result format, are agreed with each third party under KernelPort v1.
CI boundary checks: two seams only
Layers meet in exactly two places: KernelPort, the only way into elan1 Govern, and fusion.*/v1, the way into elan1 Run. A boundary check in CI fails the build when any other crossing appears, so no layer grows a private door into another. C1 Import graph applies the same idea inside the kernel.
What conformance does not prove
- It does not test whether a business write should happen. That is elan1 Govern’s job, recorded in the proof record.
- K4 and K6 report figures; they do not block.
- A green suite is not a compliance statement, and no regulator has accepted it. It is our suite, so read the vectors before you rely on them.
- Passing C1–C14 does not turn Mode B into enforcement.
Status
| Milestone | What it means | Status |
|---|---|---|
| K1–K7 suite | Runs every night against every implementation bound in elan1 Run; blocking-green decides step 5 of a substitution. | Available |
| Offline runs | You or your auditor run K1–K7 on your own machine, with no network. | Available |
| C1–C14 tests | The third-party test definitions for agents on KernelPort v1. | Available |
| CI boundary checks | The build fails on any crossing other than KernelPort and fusion.*/v1. | Available |
What we share with customers
Runner name, flags and file layout
The offline run above shows the inputs and the result; the exact command is in the customer reference.
Shared with customers
Result format
The ledger above writes every row in words; the machine-readable form is shared with customers.
Shared with customers
Tolerances for K4 and K6
Reported figures are compared with a tolerance per contract and workload.
Shared with customers
How a C1–C14 run is witnessed and published
Who runs it, where, and how a pass is announced.
Agreed per third party