# Partner-readiness release checklist

**Current result: BLOCKED.** This checklist is a gate, not evidence. A
partner-ready claim is prohibited while any item is open or not bound to the
exact release candidate.

## Candidate and technical boundary

- [ ] Exact 40-character source commit, package version, deployment-manifest
  digest, and computed candidate ID recorded.
- [ ] Existing technical package validator passes.
- [ ] Organizational manifest schema/checker passes with `partnerReady: true`.
- [ ] Base chain ID 8453, one-partner maximum, no production claim, V2 default,
  and excluded Solana/cross-chain value flows reconfirmed.
- [ ] Deployment, activation, addresses, caps, routes, audit results, and
  authorization are supported by evidence rather than inferred.

## Organization and agreement

- [ ] Legal entity evidence.
- [ ] Authorized signatory and authority evidence.
- [ ] Actual security/privacy/incident/support/change/commercial contacts.
- [ ] Role assignments, separation/conflicts, coverage, and tested channels.
- [ ] Insurance decision and evidence.
- [ ] Counsel signoff and privacy signoff.
- [ ] Commercial agreement completed and signed.
- [ ] Explicit partner acceptance and signatures.

## Policy acceptance

- [ ] Pilot terms/scope and success/acceptance procedure accepted.
- [ ] Security/vulnerability policy accepted and intake tested.
- [ ] Incident plan accepted and exercised.
- [ ] Support tier/SLA selected and staffed.
- [ ] Maintenance/deprecation terms accepted.
- [ ] Deployment/change RACI accepted.
- [ ] Data map/minimization/retention/consent documentation accepted.
- [ ] Flourishing cannot slash principal.
- [ ] Rewards cannot consume collateral.
- [ ] Surveillance is never required.
- [ ] Consent is explicit.
- [ ] Exits are bounded.

## Evidence rule

Each of the 25 mandatory evidence records must be a distinct, type-specific
strict JSON attestation below
`pr10/partner-package/evidence/organizational/attestations/`; match a unique
SHA-256 digest; use an exact allowlisted approver role and trusted Ed25519
identity; carry canonical UTC issuance, approval, expiry, and signature times;
pass causality/freshness checks; include the exact semantic statement and
required artifact hashes for its claim type; and bind the exact scope and
computed candidate ID. Generic or reused files, symlinks, traversal,
out-of-package evidence, unknown fields, duplicate keys/IDs, and opaque inputs
are rejected. Do not commit private contracts,
identity documents, signatures, personal contact details, or insurance
certificates; retain originals in the approved controlled system and reference
them from a signed redacted attestation.

The technical subset additionally requires blocker-free canonical operations
for the same candidate, an existing clean exact Git commit/tree, exact canonical
operations/open-spec/ledger/deployment hashes, exact-commit tests, one-module
rollout, bounded liabilities, pull payments, fail-closed APIs, immutable
evidence, pause-safe refunds/terminal exits, prohibited surveillance/biometric/
profiling inputs including hashed/derived/transitive forms, and chain-specific
privacy-preserving trust portability without pilot cross-chain value flow.

Run:

```bash
python3 pr10/partner-package/scripts/validate_partner_package.py
python3 pr10/partner-package/scripts/check_organizational_readiness.py
python3 -m unittest discover -s pr10/partner-package/tests -p 'test_*.py' -v
```

The checked-in template is expected to pass structural validation while
reporting `partnerReady: false` and all blockers open. Only a separately
completed, candidate-bound manifest may report readiness.
# Sixth-audit evidence gates

- [ ] The two exact agreement legal names match two distinct legal entities in
  the externally signed trust registry.
- [ ] Each legal entity resolves to a fresh, digest-pinned independent registry
  verification outside the candidate repository, signed by the pinned genuine
  authority.
- [ ] The incident exercise is a tracked, typed, candidate/source/tree/scope
  bound record with required separated participants, exercised channels,
  ordered timestamps, passed objectives, and no unresolved failures.
- [ ] Every required contact function uses an allowed channel type and has a
  unique tracked reachability result bound to its exact role, identity,
  organization, channel, outcome, and test time.
- [ ] Unlinkability evidence uses the approved threat model/methodology,
  statistically meaningful sample and pair counts, confidence and false-link
  bounds, and unique parsed per-test and combined logs.
- [ ] Liability currency and smallest-unit identifier agree; cap arithmetic,
  maximum loss, reserve coverage, remedy maxima, substantive remedies, and
  enumerated residual-liability terms all validate.

All items above remain unchecked. They are evidence requirements, not claims
that an entity, authority, person, partner, exercise, test, acceptance, or
signature exists.

## Seventh-audit evidence gates

- [ ] A legal-registry authority is pinned separately from the human-identity
  authority, with a reviewed external path, root ID, issuer ID, key digest, and
  authority class. Each legal record resolves a distinct externally signed
  registry response whose exact entity fields, status, issuer, issuance,
  observation, expiry, and freshness validate.
- [ ] Unlinkability inputs contain and hash the actual seed opening, corpus, and
  command material; every log resolves a unique candidate-bound transcript.
  Component counts are summed, the combined log equals those sums, observed
  rates are recomputed, and the documented one-sided Hoeffding upper bound is
  recomputed and remains within the configured maximum.
- [ ] Every liability category is capped in the same smallest unit, no uncapped
  category exists, cumulative remedy maxima do not exceed the aggregate cap,
  category allocations do not exceed maximum loss, and reserve coverage is
  adequate.
- [ ] The incident exercise occurs inside the candidate interval and within the
  30-day freshness window. Exact assigned participant identities,
  organizations, contact-matrix channels, and unique objective logs are
  resolved and time ordered.
- [ ] Every reachability result resolves a unique, fresh receipt signed by the
  exact assigned channel controller and bound to the function, role, identity,
  organization, channel, nonce, outcome, and acknowledgment duration.

These items remain unchecked. The separate human and legal authority policies
are deliberately disabled, so positive readiness remains structurally
impossible until genuine reviewed authorities and evidence exist.
