Add execution assurance to MNCS and MNCDS test evidence

[epi13]

What changed

• add an experimental shared mncs-execution-assurance companion schema for MNCS and MNCDS test evidence;
• bind the canonical subject identity, candidate, test result, test bundle, execution policy, runner, environment, fresh challenge, explicit assurance properties, and attestation class;
• add fail-closed offline semantic validation that keeps functional test status separate from execution assurance;
• add mncs-test-evidence and mncds-test-evidence commands for standalone companion validation and combined subject/evidence validation;
• reject subject substitution, test-status mismatch, expired or future challenges, contradictory attestations, and authority overclaims;
• prevent local records or signatures from claiming host-root resistance, protected custody, or organizational independence;
• add regression coverage for MNCS measurement records and MNCDS development records;
• add documentation, draft RFC 0008, and a twelve-task Codex implementation queue for real sandbox and attestation backends.

Why

A functional test can report PASS even when the test, runner, policy, or output remains mutable under ambient host permissions. Existing hash-linked evidence can detect later rewriting, but it does not establish that the test used during execution was protected or that hostile host root could not manufacture an accepted result.

This PR applies the same treatment proposed for Forge to MNCS and MNCDS themselves:

subject test PASS + execution assurance UNKNOWN = combined UNKNOWN

The implementation validates evidence supplied by a runner. It does not claim that the current repository has implemented an OS sandbox, TPM attestation, confidential VM, external custody, or independent evaluation.

Compatibility

• MNCS 0.2, MNCS 0.3-rc.1, and MNCDS 0.1-rc.1 record schemas are unchanged.
• Existing release-candidate corpus and Python/Rust agreement are unchanged.
• The companion record is additive and experimental.
• Existing mncs and mncds commands are unchanged; two new dedicated entry points are added.
• Ordinary offline validation still never executes tests, providers, candidates, containers, or privileged helpers.

Status semantics

• FAIL > UNKNOWN > PASS remains authoritative.
• MNCS and MNCDS subject results remain separate.
• A combined PASS requires both the subject result and execution assurance to be PASS.
• Missing or unverified attestation remains UNKNOWN.
• Stale challenges and identity substitution fail.
• Unsupported future companion schema versions remain unsupported rather than guessed.

Intentionally excluded follow-up work

The ordered follow-up queue covers:

1. typed runner receipts;
2. immutable test bundles;
3. Linux namespaces/seccomp/Landlock/cgroup isolation;
4. verity-enforced test integrity;
5. replay tracking;
6. DSSE/Ed25519 execution attestations;
7. TPM measured-platform verification;
8. confidential-VM evaluation;
9. external evaluator custody;
10. case-study integration;
11. independent Rust validation and corpus vectors; and
12. RFC/release integration.

Validation

GitHub Actions has confirmed the implementation against the repository's real toolchain:

• Python 3.11, 3.12, 3.13, and 3.14 test suites passed;
• packaged JSON Schemas, the conformance corpus, MNCDS corpus, and committed examples passed;
• the release-candidate check and pinned independent Rust interoperability passed;
• clean-wheel build and installation passed;
• strict MkDocs passed after correcting one repository-level RFC reference;
• Ruff formatting and lint passed after applying the formatter's exact change; and
• mypy identified three narrow typing issues, which were corrected in the current head.

The current-head workflow rerun is queued to reconfirm the final mypy correction and repeat the already-passing checks.

Review focus

• whether the assurance properties are sufficiently explicit and non-transitive;
• whether each contradiction should be INVALID, FAIL, or UNKNOWN;
• whether local/platform/confidential/external attestation boundaries are conservative enough;
• whether dedicated entry points are the right compatibility surface before any future normative integration; and
• whether RFC 0008 clearly preserves existing frozen record semantics.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.