<!-- normative -->

# Validation and Acceptance

Validation evidence may be produced by deterministic tools, reasoning components, external authorities, or people. Only
deterministic governance applies evidence policy and authorises state changes.

## Risk-sensitive and independent evidence

Acceptance criteria and acceptance oracles must exist before the execution attempt whose output they evaluate.

For repository experiments, the project owner prepares and versions:

- visible build and test commands available to executors;
- a hidden acceptance suite unavailable to executors;
- a hidden-suite manifest hash;
- an oracle runner version;
- a fixed execution environment;
- a mapping from hidden tests to root acceptance criteria.

Models may add tests, but model-generated tests are development artefacts and never constitute the independent grading
oracle for the same run.

Initial evidence policy:

```text
LOW:
    Pre-existing objective structural checks or deterministic validators

MEDIUM:
    Pre-existing objective checks plus separate semantic review where needed

HIGH:
    Pre-existing independent evidence source or method-diverse validation

CRITICAL:
    Formal, authoritative, or explicitly human-approved evidence
```

A generator's self-report, generated test, or generated evaluator is never sufficient evidence for acceptance of that
generator's output.

The hidden suite is an experiment-grading oracle, not an authoritative acceptance validator within the measured run.

The controller evaluates root acceptance using only the predeclared visible validation procedures and evidence policy
available to every experimental arm. When the controller authorises root acceptance, it makes an authoritative
acceptance claim under those visible bindings.

After the run terminates and the final candidate has been frozen, the experiment harness executes the hidden suite
exactly once to grade that claim. The hidden result does not retroactively change the run's authoritative node state. It
classifies the run as one of the [trial classifications](glossary.md#trial-classifications):
`CORRECT_ACCEPTANCE`, `FALSE_SUCCESS`, `CORRECTLY_UNRESOLVED`, `MISSED_SUCCESS`, or `INDETERMINATE`.

## Acceptance binding

Acceptance must be bound to:

- node-contract version;
- input versions;
- output artefact versions and hashes;
- integration result;
- validator versions;
- test versions;
- evidence-policy version;
- control-policy version;
- relevant environment version;
- acceptance authority.

Root acceptance binds to the visible validators and evidence available during the measured run. Hidden-oracle versions
and outcomes are grading metadata and are not part of the controller's acceptance binding.

## Distinct lifecycle concepts

Do not conflate:

- execution returned
- artefact produced
- validation passed
- node accepted
- artefact published
- result superseded

Only an `ACCEPTED` node result with freshness `CURRENT` or `COMPATIBLE`, or an explicitly `PUBLISHED` artefact version
satisfying the dependency contract, may satisfy dependant obligations.

## Parent acceptance

A parent is accepted only when:

- every mandatory child obligation is accepted;
- selected alternative obligations are satisfied;
- compatible outputs are integrated;
- blocking conflicts are resolved;
- inherited invariants remain valid;
- parent-level acceptance criteria pass;
- required provenance exists;
- acceptance authority approves the transition under policy.

Child success alone never proves parent success.

## Independent evaluation

Independent evaluation is an evidence strategy, not an executor level. Independence should be
risk-sensitive and preferably method-diverse. Possible sources:

- compiler;
- type checker;
- tests;
- theorem prover;
- schema validator;
- independent model family;
- external authority;
- human review;
- benchmark or simulator.

A second call to the same model with similar context provides weak independence.

The [model profile](deferred.md#model-profile) schema defines a post-MVP extension. Its enum values
follow the global uppercase convention, but the MVP is not required to implement this schema unless
the experiment manifest enables the extension.