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:

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: <from>..<to>        Date: <date>
Recommendation: RELEASE | RELEASE WITH CONDITIONS | DO NOT RELEASE

DELTA SUMMARY
  <changes by subsystem; security-relevant commits flagged>

REVERTED CONTROLS
  <any previously verified control no longer present, or "none detected">

TEST RESULTS
  Total / passed / failed:  <n> / <n> / <n>
  Baseline failures:        <n>      Change: <+n | -n>
  New failures:             <list>

EVIDENCE REVALIDATION
  Verified claims re-checked: <n>
  Downgraded:                 <id: old → new, reason>
  Still verified:             <n>

VALIDATOR RESULTS
  <per-script errors/warnings; deviations from expected failures>

UNTESTED CRITICAL PATHS
  <path — coverage status>

FOUNDATION DRIFT
  <invariants or constraints no longer holding>

GATING DEFECTS
  <id — open | remediated and re-verified>

BLOCKERS
  <must be resolved before release>

CONDITIONS
  <must be resolved shortly after release>

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.