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
Required verifier: ../../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#

node tools/eve-everywhere/verify-evidence-manifest.mjs \
  --manifest=<workspace-relative-manifest.json>

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#

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 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:

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