I read this as an advisory security-architecture review - I’ll trace the plan’s full evidence lifecycle and threat-model clauses, compare internal and independently rooted evidence models, then give one release-gate verdict with exact acceptance criteria.


I read this as a request to resume the interrupted advisory review - I’ll continue from the unread Task26 amendment and trust-boundary artifacts, then finish the architectural verdict without edits.


I read this as an architectural trust-boundary decision - I recommend retaining the internal owner-rooted model and stating its limits explicitly.

## Verdict

**The owner-level attacker is outside the plan’s explicit threat model. External signing is recommended defense-in-depth, not a REQUIRED Task26 release blocker.**

The plan addresses candidate substitution, source/build/install drift, stale or revoked candidates, ordinary evidence mutation, workflow shortcuts, role abuse, provider ambiguity, and cleanup failure. It does **not** claim resistance to compromise or malice of the owner account or host administrator.

### Plan basis

- Candidate identity is explicitly content-based, not externally authenticated: “content digest over the manifest and listed file bytes” (`dualcoach-production-readiness.md:320`).
- Release evidence must come from the “exact immutable candidate” (`:152`), with digest-bound command results (`:725`).
- The amendment requires a hash-linked evidence graph and independent edge verification (`:1149`) plus an independent verifier (`:1162`).
- “Verifier-enforced immutable retention” (`:74`) does not specify WORM storage, a separate principal, an external timestamp, or a signing key.
- Independent reviewers are required (`:873`), but no clause requires privilege-separated execution or custody.
- The owner/operator is deliberately the sole v1 business authority (`:154`). The only explicit external approval requirement concerns authentication and Telegram actions (`:215`), not release-evidence attestation.
- Residual risks must be disclosed (`:910`).

The current evidence follows that model: candidate `78ecb799…789538`, wheels and installed bytes are hash-bound, rehydration passes, qualification/revocation heads are sealed, and files/directories are `0400`/`0500`; all remain owned by `cube`. Those controls prove consistency and reproducibility **assuming that account and host are trusted**. They cannot prove historical authenticity against that same owner coherently rewriting the evidence, verifier, and ledger.

This matches standard internal release-evidence practice: hashes and reproducible builds establish integrity inside a trusted release-administration domain. SLSA/in-toto-style signatures add an independent trust root only when the signer or build identity is inaccessible to the submitting owner; self-signing from the same account adds no material protection.

## Viable designs

1. **Owner-rooted internal evidence — recommended**
   - No migration or service dependency.
   - Fully reproducible and locally testable.
   - Detects accidental drift and inconsistent substitution.
   - Failure mode: owner/host compromise can fabricate a coherent history.

2. **Privilege-separated notary**
   - A second principal signs the final seal digest using a key unavailable to `cube`, with the public key and signed record retained outside owner-writable storage.
   - Protects external authenticity and non-repudiation.
   - Adds identity/key lifecycle, availability, recovery, and release-process coupling.
   - A signature alone still would not stop a compromised owner deploying different runtime bytes; that stronger threat model would also need an independently enforced deployment gate.

## Required trust-boundary wording

> Task26 evidence establishes content integrity, exact source-wheel-installed-runtime parity, reproducibility, and qualification/revocation consistency within the trusted `cube` owner and host-administration boundary. SHA-256 seals, hash-linked ledgers, independent verifier implementations, and `0500`/`0400` permissions provide workflow immutability and tamper detection; they do not provide WORM retention, external timestamping, signer identity, non-repudiation, or authenticity against compromise or malice of that owner or host administrator. “Independent” denotes procedural and implementation independence within the same trust domain, not privilege separation.

## Acceptance criteria

- Security and provenance reviews adopt that boundary and classify owner/host compromise as a disclosed residual risk; they must still return PASS because the plan requires every reviewer to pass (`:892-894`).
- The final review re-verifies candidate `78ecb799…789538`, wheel/install parity, frozen modes, reproducible rehydration, and authority heads `3dbfc6e0…09d30` / `8a1d29a1…c80e`.
- No release report uses “externally authentic,” “non-repudiable,” “WORM,” or “owner-tamper-proof.”
- If external authenticity or owner-compromise resistance becomes a requirement, Design 2 becomes a new release gate. Until then, this finding alone should not block Task26; all other unchecked Task26/Task27 criteria still keep the plan **NO-GO**.