Prompt — Trust Wall Refresh

Update the public Trust Wall to reflect current evidence. Update only claims whose evidence changed. Preserve stable evidence IDs. Downgrade where support has weakened.

Inputs

• Repository changes since intransic.config.yaml → known_state.assessed_commit
• intransic/internal/evidence-ledger.yaml, trust/, intransic/config/publication-policy.yaml

Instructions

Step 1 — Scope the refresh

Identify changes since the last validation. A claim needs revisiting only if a change touched its supporting evidence — implementation, test, configuration or schema. Do not rewrite claims whose evidence is untouched. Churn destroys the traceability the ledger exists to provide.

Step 2 — Re-verify affected claims

For each affected claim:

1. Does the cited implementation still exist and behave as described?
2. Does the cited test still exist and still pass?
3. Does the cited configuration still hold the cited value?
4. Has anything appeared that contradicts it?

Re-verify by execution and inspection — not by reading the previous assessment.

Step 3 — Apply status changes

Downgrade rules:

• A previously verified claim whose test now fails is not still verified.
• A claim whose only remaining support is that the code still exists is implemented_unverified, not verified — deleting a test downgrades the claim it carried.
• A control removed by a later change is not still verified — even if a commit message says it was implemented. Verify current code, never history.
• When in doubt, downgrade. Under-claiming is recoverable; over-claiming is not.

Step 4 — Preserve identifiers

Never renumber an evidence ID. External readers may reference them. If a claim is withdrawn, retire its ID — do not reuse it. If a claim is split, keep the original ID for the primary claim and allocate a new one for the remainder.

Step 5 — Check for newly publishable claims

Has anything previously withheld become publishable? Check especially claims deferred pending another fix (publication_deferred_until in the ledger). If the blocking condition has cleared and been re-verified, restore the public wording.

Step 6 — Disclose material new limitations

If the refresh reveals a new gap, add it to trust/limitations.md. Do not quietly drop a claim — a reader who saw it before deserves to know it was withdrawn. If a claim was withdrawn because of an unremediated security finding, follow publication policy P-04: withhold the specifics, but ensure limitations.md still discloses that a withheld category exists.

Step 7 — Regenerate and validate

Regenerate trust/claims.json from the ledger — never hand-edit it, and never hand-edit claim wording in trust/*.md (rule T-04 will fail). Then:

python3 intransic/validation/validate_evidence.py
python3 intransic/validation/validate_foundation.py
python3 intransic/validation/validate_trust_wall.py

Update last_validated across trust/ and known_state.assessed_commit in the config.

Output format

TRUST WALL REFRESH
Commit range: <from>..<to>        Date: <date>

CLAIMS REVIEWED:   <n>       UNCHANGED: <n>

UPGRADED
  <ID>: <old> → <new> — <new evidence>

DOWNGRADED
  <ID>: <old> → <new> — <what weakened>

WITHDRAWN
  <ID>: <reason> — <disclosed in limitations? yes/no>

NEWLY PUBLISHED
  <ID>: <status> — <evidence that unblocked it>

NEW LIMITATIONS DISCLOSED
  <items added to limitations.md>

VALIDATION
  <results; deviations from expected failures>

NET: <n> published (was <n>)

Rules

1. Verify current code, never commit history. A fix present in history may have been reverted — this occurred on 2026-07-25, and publishing from history would have produced a false public claim.
2. Removal requires disclosure. Silently dropping a claim is a form of misrepresentation.
3. Never publish to fill a gap. A shorter, fully-supported wall beats a comprehensive one with a weak claim in it.
4. Preserve wording discipline. Public wording lives in the ledger; pages are generated from it.