# Eve SOTA evidence-manifest admission contract — 2026-09
**Initiative:** `eve-sota-gap-closure-2026-09-01`
**Schema version:**
`eve-sota-evidence-manifest.v2`
**Originating task:**
`EVE_SOTA_GAP_CLOSURE` 0.5
**Closure policy revised:** operator decision
2026-09-05
**Machine schema:**
[`eve-sota-evidence-manifest.schema.json`](eve-sota-evidence-manifest.schema.json)
**Required verifier:**
[`../../tools/eve-everywhere/verify-evidence-manifest.mjs`](../../tools/eve-everywhere/verify-evidence-manifest.mjs)
This contract defines what a later Eve phase must record before its evidence can
participate in closure. It does not close Phase 0, certify a provider, or turn a
recorded assertion into proof of the world by itself. Structural JSON Schema
validation and semantic admission are deliberately separate, and both are
required.
## Admission command
```bash
node tools/eve-everywhere/verify-evidence-manifest.mjs \
--manifest=
```
The verifier reads the checked-in schema rather than a duplicated required-field
list. The shared schema interpreter refuses unsupported JSON Schema keywords
instead of silently ignoring them. The CLI also reads the initiative ledger so
phase task and gap-owner references must name real task IDs.
## Evidence record model
| Record | Required facts | Admission responsibility |
| ------------------ | ----------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| Manifest | initiative ID, source commit, phase, record time, limitations | Binds the record to this initiative and a source revision that the CLI confirms exists. |
| Claim | statement, proof class, operating boundary, positive execution refs, artifact refs, provenance refs, exact limitation | Keeps a statement no broader than its named evidence boundary. |
| Execution | structured command, working directory, environment-variable names, start/end, integer exit code, expected and observed result | Makes “the test passed” replayable and distinguishes expected red from green. |
| Negative control | affected claims, distinct red execution, later green regression, introduced fault, expected and observed failure | Proves the harness can reject the failure it is credited with detecting. |
| Artifact | locator, media type, SHA-256, bytes, retention state, producing execution | Gives retained output an immutable identity and a producer. |
| Runtime provenance | runtime kind/name/version, execution mode, locator, observation time, live verification execution, receipt | Prevents a source or unit check from standing in for a browser, database, DCC, engine, channel, provider, or remote-service observation. |
| Model provenance | provider, resolved model and endpoint, quantization, prompt hash, registry decision, dated price snapshot, runtime, receipt | Binds model evidence to the route that actually ran rather than a floating model label. |
| Gap | G1–G18 identity, status, external classification, owner task, decision owner, exact unblock condition, evidence claims | Keeps unresolved work visible and prevents closure until it is resolved. |
Commands are structured as an executable plus argument array. Environment
entries contain names only; the format has no field in which to store a secret
value.
## Structural rules
The Draft 2020-12 schema rejects, before semantic evaluation:
- a missing command object or integer exit code;
- empty claim execution lists;
- an absent or empty negative-control collection;
- omitted runtime/model provenance collections, even when correctly empty for a
source-only phase;
- undeclared fields on every object;
- malformed source commits, hashes, task IDs, G1–G18 IDs, timestamps, and
environment-variable names;
- missing limitation language; and
- incomplete runtime, model, price, artifact, gap, or closure records.
An empty provenance array is valid only for a manifest whose claims do not cross
that boundary. Conditional truth is enforced by the semantic verifier.
## Semantic rules
### Executions and receipts
- `observed: pass` requires exit code `0`; `observed: fail` requires a non-zero
exit code.
- Only `negative-control` executions may expect failure.
- A claim can cite only green positive executions. A red run is evidence that a
control bites, not evidence that the capability works.
- Execution start must precede completion, and completion cannot post-date the
manifest.
- IDs and reference arrays are unique. Every reference must resolve to exactly
one record.
- A committed artifact locator must be normalized and workspace-relative. The
CLI reads its bytes and recomputes both size and SHA-256.
- The source commit must resolve to a commit object in the local repository.
- A retained external artifact must use an explicit external URI, name its
producing execution, and be named by that execution.
### Live and model claims
A claim is live-boundary evidence when its proof class is `real-provider`,
`engine`, or `live`, or when its boundary is database, browser, desktop, DCC,
engine, channel, remote service, or model provider. Such a claim is refused
unless it has all of the following:
1. a successful execution recorded in `live` mode;
2. at least one retained, content-addressed receipt;
3. runtime provenance bound to that same execution; and
4. limitation language stating what the observation does not prove.
A model-provider claim additionally requires a resolved provider, model ID,
endpoint, quantization, prompt SHA-256, registry-decision locator, dated USD
price snapshot, runtime reference, and retained receipt. The same live execution
must bind the model ID and receipt. Values such as `unknown`, `latest`, `TBD`,
or `N/A` are refused as provenance.
Top-level and per-claim limitation entries must state a reason; `none`, `N/A`,
and “no limitations” are not limitation evidence.
This prevents prose, source inspection, and unit tests from being promoted to a
live claim. It does not prove that an inaccessible external receipt still
exists; that correspondence must be retained and checked by the execution
environment.
### Negative controls
Every manifest has at least one negative control, and every claim admitted for
phase closure is covered by one. A control is admitted only when:
- the failure and regression executions are different commands;
- the fault execution is classified as a negative control, expected to fail,
observed to fail, and has a non-zero exit code;
- the green regression expects and observes pass with exit code `0`; and
- the red execution completed before the green regression began.
Merely naming a test file or describing an intended mutation does not satisfy
the contract.
### Phase closure and gaps
An open phase must have no closure instant, closure owner, or closure claims.
The only completion state is `closed`, which requires a decision owner, a
closure instant, admitted closure claims, and zero unresolved gaps.
`closed-with-named-external-gaps` is forbidden. An `open`, `blocked`, or
`accepted` gap prevents closure even if it has an owner, a measured rationale,
an exact unblock condition, or an external classification. Unresolved work
remains in an open phase with:
- a real owner task from the initiative ledger;
- a decision owner;
- an exact unblock condition when blocked; and
- measured rationale evidence when accepted.
This implements the operator's 2026-09-05 decision: no task, phase, initiative,
or charter claim closes with unresolved blockers. Human or infrastructure
dependencies remain open work; naming or accepting them cannot close it. The
[charter-completeness contract](EVE_SOTA_CHARTER_COMPLETENESS_2026-09.md) and
task 12.8 extend this rule across workflow, runtime, scorecard, and dependency
evidence. This manifest validator alone cannot establish complete product scope.
## Proof boundary
The contract provides three different checks and does not collapse them:
1. **Internal validity:** the object conforms to the schema and all references,
outcomes, and closure rules agree.
2. **Retained correspondence:** committed artifact bytes still match the record;
external receipts carry immutable identities and explicit retention
locations.
3. **Re-execution:** repeating the command against a live dependency is a new
run, not something a manifest validator can infer from an old receipt.
Consequently, a valid historical manifest proves that a well-formed evidence
record was admitted. Freshness requirements, replay cadence, and phase-specific
sample sizes remain the responsibility of the tasks that produce each manifest.
## Executed contract tests
`node --test tools/eve-everywhere/verify-evidence-manifest.test.mjs` exercises a
complete model/live conformance object, the real CLI process, and the following
adversarial mutations:
| Mutation | Required rejection |
| ------------------------------------------------------------ | ----------------------------------------------------------------------------------- |
| Delete `command` through the real CLI | Process returns non-zero and reports the schema field. |
| Delete `command` and `exitCode` | Schema reports both missing fields. |
| Remove a live claim's run, artifact, runtime, and model refs | Verifier reports no live execution, retained receipt, runtime, or model provenance. |
| Remove all negative controls | Schema rejects the empty collection and closure claim coverage fails. |
| Turn the intended red run green and the regression red | Both observed-control invariants fail. |
| Remove model and runtime records | Model and runtime provenance failures are explicit. |
| Replace limitations and a runtime version with sentinel text | Empty limitations and unobserved versions fail. |
| Close with an unowned gap | Task ownership and decision ownership both fail. |
| Use plain closure with an owned unresolved gap | Plain closure still fails. |
| Change retained committed bytes | Recomputed byte count and SHA-256 both fail. |
| Name a source commit absent from the repository | CLI correspondence hook refuses the source binding. |
| Duplicate an ID and point at an absent execution | Duplicate and dangling joins both fail. |
| Close with an owned external blocker and exact condition | Both v2 closure and the former named-gap state are rejected. |
| Relabel an unresolved gap accepted, internal, or external | Closure still fails; the open phase can retain the gap honestly. |
| Supply the historical v1 schema to authorize closure | Semantic admission rejects closure independently of schema selection. |
| Resolve every gap with evidence in a v2 decision | Closure passes; removing resolution evidence fails. |
The tests construct the conformance object in memory. It is not retained as a
historical provider record, so no invented execution receipt enters the audit
corpus.
## Versioning and use by later phases
**Migration decision, 2026-09-05:** new writers emit
`eve-sota-evidence-manifest.v2`. The canonical schema now rejects the former
named-gap closure status. The original v1 schema is preserved byte-for-byte at
[`eve-sota-evidence-manifest.v1.schema.json`](eve-sota-evidence-manifest.v1.schema.json).
Existing v1 receipts are not rewritten or given new observation dates. The CLI
selects their historical schema for structural inspection and admits only open
v1 phase records as historical evidence. No v1 closure, including a formerly
permitted named-gap closure, can authorize completion under the current policy.
Any new closure needs a v2 decision and current complete evidence; changing the
version string alone does not supply missing proof.
The semantic no-blocker policy applies even when `--schema` explicitly selects
v1, so schema selection cannot restore the old exception. Future breaking field
or admission-rule changes require another version and migration decision.
Task 0.6 may join task/evidence ownership into this format, and later phases may
store actual manifests beside their retained evidence. Neither this schema nor
its tests authorize a later checkbox: each phase still needs its own executed
commands, receipts, negative controls, provenance, gap ownership, and direct
verification.