<!-- Rendered from intransic-skills/skills/intransic/prompts/trust-wall-refresh.md at v0.2.2 (50e2c2f38f69cc1bf592760723fccbe04da611ba).
     Source of truth: https://github.com/intransic-ai/intransic-skill.git -->

# 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

| Situation | Action |
|---|---|
| Evidence unchanged | Leave the claim alone; update `last_validated` only if genuinely re-checked |
| Evidence strengthened (test added, observation made) | Upgrade, e.g. `implemented_unverified` → `verified` — only once `behavioural` evidence or better exists (`E-11`) |
| Evidence weakened (test now failing, control removed) | **Downgrade immediately** |
| Evidence contradicted | Set `contradicted`, `public_safe: false`, **remove from the Trust Wall**, log in the contradiction register |
| Capability removed | Mark `deprecated` or delete; remove the public claim |

**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:

```bash
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.
