Claim-ladder gate: verify against the live source before you encode it

Verify before encodeFreshModel-agnosticverified 2026-06-21sha 100edf9b2ae8

Born in: the post where it earned its place →

A vendor “double-check your work” prompt asks the model to re-read its own reasoning; this one bans encoding on doc/memory authority entirely and forces a cited live run as the gate, born from a real case where trusting a tool’s own README would have shipped a guardrail that clipped test output and hid failures.

You are about to encode this load-bearing claim into {{target_file}}:

  {{claim_to_encode}}

A load-bearing claim is anything that, if wrong, silently breaks behavior or misleads a future reader: a config value, a guardrail/threshold, a hook or cron timing, an API/library behavior, a CLI flag's effect, an "X is safe / X is fenced off" assertion.

Treat every input as a claim on a trust ladder, cheapest and least trusted first:
  1. your memory or a guess
  2. docs, README, changelog, a blog, a code comment
  3. the source RUN LIVE against the real artifact -- the ONLY rung that counts as evidence.

Hard rules:
- You MAY consult rungs 1 and 2 to form a hypothesis. You may NOT encode anything into {{target_file}} on the strength of rungs 1 or 2 alone.
- Docs are a claim too, and they are routinely stale or wrong. "The README says so" is not evidence. If a doc and a live run disagree, the live run wins and the doc is now suspect.
- Before you write the claim, drop to rung 3: read the actual source at the exact file:line that governs the behavior, OR run a NON-MUTATING command / minimal script in the environment where the claim matters, and capture the raw output plus the relevant runtime / version / config / timezone.
- Never type a value you predicted. Capture it live and paste the captured value. If you catch yourself about to write a number, path, flag, SHA, or behavior "from memory," STOP and go verify it.

Scale the rigor to the blast radius: a throwaway script, a quick read is fine; a guardrail that decides whether a real failure reaches a human, never skip the live run.

Output, in this order:
1. CLAIM: the one sentence you intend to encode.
2. EVIDENCE: the exact `path/to/file:line` you read, or the exact command you ran, plus the raw captured output (verbatim, not paraphrased).
3. VERDICT: CONFIRMED (evidence matches the claim -> eligible to encode; edit {{target_file}} only if the caller asked for writes), CORRECTED (evidence differs -> show the corrected claim and what the doc/memory got wrong), or UNVERIFIABLE (you could not reach rung 3 -> do NOT edit; say exactly what live access you are missing).

If VERDICT is anything other than CONFIRMED, do not modify {{target_file}}. Refuse to encode an unverified claim even if it "looks obviously right."

Fill in: claim_to_encode target_file

Shared as is, for reference. Read it and decide what it will do before you run it; using it is your responsibility, under the terms.