# Owner-controlled verification

## Authority is separate from contributed content

Use the tooling and policy from a trusted owner checkout, never from a pull request's
branch. Protect policy, scripts, review prompts, canonical attestations and deployment
credentials with owner-only merge/deploy control. Do not use a contributor-controlled
CI workflow to validate itself or release the site. These repository/platform protections
are deployment prerequisites; this local prototype does not configure them remotely.

The default key registry is empty and fails closed. No production signing key is
generated, no Astra session is fabricated, and historical reviews are not silently
converted into attestations. Private keys must stay outside the repository and outside
the untrusted execution environment. The CLI refuses an in-repository signing key.

## Three distinct approvals for a claim

1. **Verifier approval.** The owner's Astra session inspects the exact claim, assumptions,
   all bundle files, controls, and logical implication. It uses the pinned claim-review
   prompt. The owner records the transcript digest and actual model/run provenance.
2. **Owner rerun.** Execute only that approved bundle, without network, with read-only
   inputs, bounded resources and no secrets. Preserve output and environment hashes.
   A trusted runner signs the receipt, bound to the approval's digest.
3. **Final Astra review.** The owner's Astra session reads the result and controls and
   recommends acceptance or another disposition. A signed owner decision references the
   exact approval and rerun. The build derives status; it never trusts submitted badges.

All attestations bind `policy_sha256` and the complete `subject_sha256` bundle digest.
Review attestations additionally bind the exact model, prompt, transcript, and owner
run ID. Keys have separate reviewer, runner and curator roles. Later owner decisions
can revoke or supersede acceptance. Conflicting decisions at the same sequence fail
closed. Policy changes require explicit re-attestation/migration, not implicit reuse.

**What signatures prove:** an authorized owner key attested to these fields. They do not
prove a model really ran or that mathematics is correct. Actual Astra invocation and
prompt capture must happen in the owner's controlled runtime; a contributor's
`model: gpt-6-astra` field is not evidence. That runtime integration remains on the roadmap.
Do not sign a claim merely because external logs say it passed.

## Task curation

Task proposals are not automatically open tasks. The owner's Astra curator uses the
separate task-review prompt and signs accept/duplicate/revise/defer/reject decisions.
Exact bundle matches can be flagged mechanically; semantic deduplication remains an
owner decision. Replication and competing hypotheses should not be collapsed as duplicates.

## Commands

```sh
node src/cli.mjs fingerprint ledger/contributions/example
node src/cli.mjs review-pack ledger/contributions/example .local/example-review
node src/cli.mjs evaluate ledger/contributions/example --policy policy.json --attestations ledger/attestations
node src/cli.mjs sign .local/decision.json --policy policy.json --key /external/owner.pem --key-id owner --out ledger/attestations/new-decision.json --owner-reviewed
```

Signing is a maintainer operation. Keep signing capability out of both the contributor's
agent and the verifier process. Signing does not itself run Astra or execute a verifier.
The example filenames are placeholders; no trusted key is enrolled by default.