# Four-stage candidate freeze, random selection, execution evidence, and attestation

## Truthful current state

The checked-in external-authority policy is intentionally disabled because no
independently established human identity authority has been supplied. The
blocked organizational manifest validates. Every `partnerReady: true` manifest
fails before scope, candidate, or evidence review. A later reviewed commit must
pin the exact external trust-root path, identifier, and digest before a positive
path can exist. An environment variable may identify the input location; it
cannot replace or override the tracked authority.

## Phase 0 — freeze upstream inputs

Record an existing Git commit containing the canonical supported-module
specification, generated route inventory, and deployment manifest. Derive the
closed pilot scope registry from those exact tracked blobs. The registry records
their exact digests and its upstream source commit. The selected module,
generated route, read-only action, required deployment contract, and rollout
stage must form one exact relationship.

## Phase 1 — compute the candidate ID

Compute `candidateId` as the domain-separated SHA-256 hash of immutable external
artifact digests, organizations, package version, and exact selected scope. The
preimage excludes `candidateId`, `envelopeId`, source/evidence commits and
trees, timestamps, evidence, signatures, and every artifact that embeds the
candidate ID. This makes candidate creation deterministic and acyclic.

Domain: `vaultfire-partner-candidate-freeze-v1`.

No Phase 1 input may contain or depend on the resulting candidate ID.

## Phase 2 — freeze externally authorized randomness and deterministic selection

After the source commit exists, obtain randomness only through the separately
pinned randomness-authority root, its root-signed beacon credential, and the
exact public-beacon response. The checked-in policy has no genuine pinned root,
so this stage is deliberately unavailable and positive readiness is
structurally impossible.

The selection commit is the single direct child of the source commit. It may
contain only the signed beacon material, the globally deduplicated corpus
universe, the exact command/context, and the deterministic selection. The
beacon seed ranks every content-derived pair with the domain-separated
selection function, selects exactly 400 pairs for each mandatory privacy test,
then deterministically orders the 1,200 selected pairs. Duplicate or reversed
pairs anywhere in the universe fail before filtering.

No selection-stage artifact contains the selection commit or tree. Those values
do not exist while the selection commit preimage is constructed.

## Phase 3 — execute exact-candidate behavior and commit evidence

Run the exact source-commit privacy-portability adapter in the canonical isolated
runner using the selected corpus, byte-for-byte argv, pinned toolchain and
environment, network prohibition, and fail-closed exit/output rules. Preserve
the actual candidate input/output bytes, privacy predicates, raw JSONL output,
stdout/stderr digests, timings, and exact candidate/module/route bindings.

Add those results plus the remaining candidate-bound organizational evidence
and externally attested identity registry in one evidence commit that is the
single direct child of the selection commit. Every claim and typed artifact
references the Phase 1 candidate ID. The artifact manifest lists each evidence
blob and digest but does not list itself. No evidence-stage blob contains the
evidence commit, evidence tree, artifact-manifest digest, or attestation commit.
Those values do not exist while the evidence commit preimage is constructed.

## Phase 4 — attest the completed evidence commit

After the evidence commit exists, compute `envelopeId` from the candidate ID,
source commit/tree, selection commit/tree, evidence commit/tree, and
artifact-manifest digest.

Domain: `vaultfire-partner-candidate-envelope-v1`.

The exact four required authorities sign the post-commit payload over that
envelope. Add only the manifest/envelope containing those signatures in one
direct-child attestation commit. The envelope does not contain the attestation
commit or tree. The validator requires exact single-parent history:
`source -> selection -> evidence -> attestation (HEAD)`, exact per-stage
path sets, and a clean worktree. Evidence must be unique, tracked, unignored,
exact at the evidence commit, digest-matched, typed, semantically parsed,
correctly ordered in UTC, fresh, and signed by the exact externally attested
identity assigned to the corresponding manifest role.

## Human gates

This procedure is technical release control, not legal advice. It does not
establish an entity, identity, authority, partner acceptance, signature,
insurance, counsel approval, privacy approval, audit, deployment, or rollout.
Those remain external human blockers until objective candidate-bound evidence
exists.
