Integrity Monitor¶
Detective monitor — instantiates Invariant Guarding
Watches live state for violations, near misses, and bypasses and records them, surfacing invariant breaks that slipped past the guards so they can be governed.
An Integrity Monitor watches live state for signs the invariant has been broken — outright violations, near misses, bypasses, and slow drift — and records them, so breaks that slipped past the preventive guards become visible and governable. Its defining move is that it detects and reports rather than prevents: it sits after the transition, not in its path, and its whole value is turning invisible erosion into a signal someone can act on. On its own it blocks nothing, repairs nothing, and rolls nothing back — the archetype counts it as guarding only because its signal feeds a response owned elsewhere.
Example¶
A hospital's electronic health record must never hold a medication order detached from a patient identity, and an active allergy list must never contradict an active order. Preventive checks exist, but interface feeds, race conditions, and manual edits still leak. An Integrity Monitor runs continuously and in a nightly batch, scanning for orders with null or dangling patient links, allergy-versus-order contradictions, and incorrectly merged medical record numbers. One morning it finds a cluster of orders whose patient links broke during a botched interface upgrade, and raises them on an integrity dashboard with a record of when each anomaly first appeared. The monitor changes nothing itself — but the silent corruption is now surfaced, with the evidence and timeline the data-integrity team needs to repair it before a nurse acts on a mislinked order.
How it works¶
- Scan live state. Continuous streaming checks and/or scheduled batch scans look across the data for invariant breaks.
- Detect the full spectrum. It flags outright violations, near misses, deliberate bypasses, and slow drift — not just hard failures.
- Record with evidence and timing. Each finding is logged with what broke and when it first appeared, building the trail that distinguishes a one-off from erosion.
- Feed, don't act. The monitor routes findings to review, repair, or governance; it never modifies the data itself.
Tuning parameters¶
- Scan frequency — real-time stream vs. nightly batch. Real-time catches breaks fast but loads the system; batch is cheap but lags reality.
- Detection sensitivity — how tight the anomaly thresholds are. Tighter thresholds catch more but flood the queue with false positives.
- Severity triage — how findings are ranked and routed. Good triage is what keeps the high-severity signal from drowning in noise.
- Retention window — how long integrity history is kept, which sets how much trend and drift analysis is possible.
When it helps, and when it misleads¶
Its strength is that it is the only mechanism here whose job is to see what the guards missed: a detective control that catches violations from bugs, races, manual edits, and adversarial bypass that no single preventive check anticipated, and it supplies the drift evidence needed to fix stale guards.[n1]
Its central failure mode is monitoring mistaken for guarding — a dashboard that displays errors nobody acts on. If findings do not connect to blocking, repair, or accountable review, the monitor merely documents the erosion while it continues, and alert fatigue buries the signals that matter. The classic misuse is standing up an integrity dashboard and treating its very existence as the control, while violations scroll past unremediated. The guarding discipline is to wire every high-severity finding to an owned response path and to prune the noise so the real signal gets acted on.
How it implements the components¶
monitoring_signal— its core function: tracking violations, near misses, bypasses, and drift in live state.audit_trace— it records each finding with evidence and timing, distinguishing a legitimate exception from quiet erosion.drift_review_cadence— its accumulated findings drive periodic review of whether the invariants and guards still match reality.
It detects but never acts; it does not translate the invariant into a blocking check (guard_condition, violation_response_path) the way a Database Constraint does, nor restore a valid state via rollback_or_repair_policy (that's Rollback Transaction).
Related¶
- Instantiates: Invariant Guarding — the Integrity Monitor is the detective, see-what-slipped-past realization of the archetype.
- Sibling mechanisms: Database Constraint · Safety Interlock · Invariant Test Suite · Contract Check · Policy Guardrail · Rollback Transaction · Two-Person Rule
Editorial Notes¶
Form Classification¶
Form family: Monitoring, Sensing & Alerting
Rationale: Integrity Monitor operates as an ongoing sensing arrangement that repeatedly observes actual state and surfaces changes or alerts because it watches live state for violations, near misses, and bypasses and records them, surfacing invariant breaks that slipped past the guards so they can be governed
Independent corroboration: The frozen evidence defines Integrity Monitor as 'Watches live state for violations, near misses, and bypasses and records them, surfacing invariant breaks that slipped past the guards so they can be governed', so its operative form is Monitoring, Sensing & Alerting.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: The mechanism watches live technical state for invariant violations and bypasses, which is runtime security and systems monitoring. Audit detective controls and intelligence monitoring are independent institutional lineages for after-the-fact integrity evidence.
Related originating lineages:
- Accounting & Auditing — Detective-control doctrine contributes logging, exception ownership, and required response.
- Security Studies & Intelligence Analysis — Security monitoring materially contributes near-miss, bypass, incident, and response-channel practice.
Review resolution: The mechanism watches live technical state for invariant violations and bypasses, which is runtime security and systems monitoring. Audit detective controls and intelligence monitoring are independent institutional lineages for after-the-fact integrity evidence. The retained alternate domains identify documented formative or independently established origins, not downstream applicability alone. domain_reach=multi_domain because the operating pattern has established use in several fields. The entry generalizes an established mechanism without inventing a new cross-domain composite.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
- https://learn.microsoft.com/en-us/azure/well-architected/security/monitor-threats — Microsoft architecture guidance on continuous security monitoring and detection of anomalous or integrity-threatening activity.
Notes¶
Its nearest twin is the Database Constraint, since both concern data-level integrity. The one-sentence separation: an Integrity Monitor detects and reports invariant breaks after they occur, while a Database Constraint prevents the breaking write from committing in the first place.
[n1] Detective control — in audit and security practice, a control that identifies and reports an incident after it has occurred, as opposed to a preventive control that stops it beforehand; a detective control is only useful when paired with a response. ↩