Re-validate a standing gate's PREMISE against fresh signals (premise can go stale even when preference holds)

Banked 2026-06-13 (auto-continue fresh-signal scan).

The lesson

A standing operator gate has two parts: the PREFERENCE ("don't hunt X") and the stated PREMISE/reason ("because Y"). The preference is the operator's to hold; the premise is a FACT that can go stale. When a fresh signal makes the premise factually false, that is a surfaced DECISION POINT - not an auto-action and not something to bury.

Concrete instance

• Standing gate: "dreUSD stays gated - NO PAT exists." Premise = no ACCESS to the private Immunefi code.
• Fresh signal (DB scan): dreUSD is now ALSO a LIVE PUBLIC Sherlock audit contest (1259, $48k/$60k, public code, window 06-08 -> 06-17).
• A public contest ships the code publicly -> the "no-PAT/no-access" premise is moot for the contest form.
• Correct handling: do NOT silently hunt it (the operator's PREFERENCE may still hold for other reasons - KYC, contest-competition choice, EV), and do NOT silently bury the changed fact. Append a one-paragraph decision point to operator-queue.md and let the operator re-decide with current facts.

Transferable rule

On each fresh-signal scan, for every standing gate, ask: "is the stated reason still TRUE?" If a new signal falsifies the premise, surface it as a decision (1 paragraph, both options framed), then proceed to other work. Do not treat a stale-premise gate as either (a) auto-liftable or (b) permanently closed. The operator owns the preference; you own keeping the premise honest.

Cross-links

• Pattern 09 (autonomous-loop cost governor): the fresh-signal scan that surfaced this is the same governor step - check the board cheaply, act on what is actionable, surface decisions, then hold rather than grind.
• META-collateral-oracle-seam-hunting-playbook: would apply to dreUSD IF the operator lifts the gate (it is a CDP/stable - dreUSD).