# Prompt — Release Validation Produce a release assurance report before a release. **Refuse to mark unsupported claims as verified.** --- ## Inputs - Current repository state and the diff since the last validated commit (`intransic.config.yaml` → `known_state.assessed_commit`) - Foundation, evidence ledger, Trust Wall - Test execution results (run them; do not read them) --- ## Instructions ### Step 1 — Establish the delta Identify the commit range since last validation. Summarise what changed by subsystem. Flag any commit touching: authentication, authorisation, identity resolution, consent, clinical entities, rate limiting, configuration providers, or secrets handling. **Merge commits deserve particular scrutiny** — check whether any merge reverted a previously verified control. Compare the current state of security-relevant files against their state at the last validated commit. A merge that reverts a fix is indistinguishable from a feature commit in a shortlog. ### Step 2 — Re-run evidence checks For every ledger entry with status `verified`: - Does the cited implementation still exist at the cited location? - Does the cited test still exist and **still pass**? - Does the cited configuration key still hold the cited value? **Any entry whose evidence no longer holds must be downgraded immediately.** Do not carry a claim forward on the strength of a previous verification. Run: ```bash python3 intransic/validation/validate_evidence.py python3 intransic/validation/validate_foundation.py python3 intransic/validation/validate_trust_wall.py ``` Compare failures against `known_state.expected_validator_failures`. **A previously expected failure that now passes must be confirmed as genuinely fixed rather than silently suppressed by a weakened check.** ### Step 3 — Execute the test suite Run it. Record: total, passed, failed, and the failure count **compared to the recorded baseline**. - Failure count **increased** → identify which are new. New failures block release until triaged. - Any test covering a `verified` claim now failing → **downgrade that claim before release**. - Do not accept "known failures" without checking the baseline. A baseline nobody re-reads is how a regression hides: in the repository this process was built on, the standing failure count drifted from ~75 to 103 without anyone noticing. ### Step 4 — Identify untested critical paths For each critical path — authentication, authorisation, consent, clinical data access, payment, data retention — state whether an automated test covers it and whether that test passes. List every critical path with **no passing coverage**. These are release risks even when nothing is failing. ### Step 5 — Compare implementation with the Foundation - Are all invariants still upheld? Any moving to `contradicted` is a **release blocker** if it concerns security or privacy. - Have new endpoints appeared without `[Authorize]`? - Have new external integrations appeared without a Foundation entry? - Have new personal or health data fields appeared without a privacy review? Run the `pii_coverage` rule if one is declared — an unexplained hit means a field shipped without a Foundation update. - Have new outbound data flows appeared with no matching `privacy.processors` entry? ### Step 6 — Gating defects Check each entry in `known_state.gating_defects`. For each: still open, or remediated and re-verified? **An open gating defect blocks a production release** regardless of what else is green. ### Step 7 — Trust Wall accuracy Would every published claim survive scrutiny today? Downgrade or remove any that would not, regenerate `trust/claims.json` from the ledger, and update `limitations.md` with material new limitations. --- ## Output format ``` RELEASE ASSURANCE REPORT Commit range: .. Date: Recommendation: RELEASE | RELEASE WITH CONDITIONS | DO NOT RELEASE DELTA SUMMARY REVERTED CONTROLS TEST RESULTS Total / passed / failed: / / Baseline failures: Change: <+n | -n> New failures: EVIDENCE REVALIDATION Verified claims re-checked: Downgraded: Still verified: VALIDATOR RESULTS UNTESTED CRITICAL PATHS FOUNDATION DRIFT GATING DEFECTS BLOCKERS CONDITIONS ``` --- ## Rules 1. **Never upgrade a claim to `verified` without executing its evidence.** A test that exists is not a test that passes, and `E-11` only checks that behavioural evidence was cited — not that it was green. Executing it is your job. 2. **Never mark a gating defect closed on assertion.** Re-verify directly. 3. **A green validator run is not an assurance result.** It establishes claim/evidence consistency only. 4. **Recommend DO NOT RELEASE** when a security or privacy invariant is contradicted, a gating defect is open, or new test failures are untriaged — regardless of schedule pressure. 5. **Report honestly.** If the suite cannot gate the release, say so plainly rather than presenting a subset as if it were the whole.