The Drift Monitor

The Drift Monitor treats truth as temporal: an approved claim can stop being true (a source number changes) or stop being sayable (legal flips a hold). When that happens it re-verifies only the affected claims and pauses any variant that depends on a claim that just went red (pipeline/drift/monitor.py).

Two triggers

• Legal-hold flip — flipping a hold changes the active rule set, which changes rules_version, which changes the verdict-cache key and forces a re-Gate of the held claim (pipeline/gate/rules.py).
• Source change — editing a source's text changes its content hash (source_version); the monitor walks the claim-to-source dependency edges to find exactly the claims that depend on it.

Surgical re-verification

Because verdicts are cached on (claim_id, source_version, rules_version), only the claims whose key actually changed are recomputed; every other claim is a cache hit. The monitor counts the Gate's recompute calls before and after the change to prove which claims were re-Gated — no under-invalidation and no over-invalidation. This is attributable to a single dimension: the legal-hold demo flips only rules_version, with the same claim text and same source_version.

Action-pool mutation

After re-verifying, the monitor mutates every action pool: if an affected claim went red, every variant that asserts it is paused (removed from the arms the bandit may pull); if a claim recovered from red, its variants are unblocked (pipeline/common/store.py). So the optimizer keeps sending every variant that is still clean and stops only the ones that just became unsafe.