Deviation Event Log¶
Recordkeeping artifact — instantiates Reference-Baseline Deviation Flagging
Stores each flagged departure as a durable fact stamped with baseline version, unit, context, status, and review history.
A Deviation Event Log is the archetype's durable memory for the observation side: an append-only store in which each departure becomes a first-class fact — observed value, unit, baseline identifier and version, comparison result, direction, magnitude, uncertainty, timestamp, and current status — that can later be counted, searched, trended, and audited. Its defining idea is preservation: it does not compute the comparison and it does not decide what happens next; it keeps the departure so that months later the fact of it, and the exact reference it was measured against, survive intact even after tools, teams, and baselines have moved on. Without the log, a deviation is a fleeting number on a screen; with it, the deviation is a record with a history.
Example¶
A site-reliability team runs a payments API. When error rate for a service crosses its expected band, the alerting layer emits a flag — but the flag alone is ephemeral. The Deviation Event Log captures it as a row: service checkout-api, observed 2.4% errors, baseline expected_v7 (0.5%), +1.9 points, ▲, sampled over the 5-minute window, uncertainty note "low traffic — wide interval," status open, timestamped. Two engineers annotate it, link the incident, and mark it resolved — deploy rollback. Six weeks later, a reliability review queries the log for every checkout-api deviation of the quarter, sees they cluster on Friday deploys, and — crucially — each old fact still names the baseline version live at the time, so a since-changed expectation does not silently rewrite what counted as a deviation back then.[n1]
How it works¶
The log is strictly append-only. A deviation fact is written once; its status can advance (open → reviewed → resolved → suppressed) through appended state transitions rather than in-place edits, so the full review history is legible. Each fact stamps the baseline version pointer at write time, which is what makes a departure reconstructable against the reference that was actually in force — not whatever the baseline later became. The unit and scope are recorded so facts can be filtered and aggregated without smearing incomparable observations together. The log computes nothing: it receives already-formed comparison results and preserves them.
Tuning parameters¶
- Fact granularity — one row per raw departure versus a rolled-up event spanning a burst. Fine granularity supports precise audits but floods the store; rollups are searchable but blur onset and recovery timing.
- Retention and archival — how long facts stay hot-queryable before cold storage. Longer retention enables long-horizon trend analysis at storage and query cost.
- Status vocabulary — how rich the lifecycle is (open/closed versus a full workflow). Richer states capture more review history but demand discipline to keep current.
- Immutability strength — soft-delete versus true write-once. Stricter immutability is audit-proof but unforgiving of genuine data-entry errors, which must then be corrected by compensating appends.
- Context payload — how much surrounding metadata each fact carries; more context aids later diagnosis but bloats every record.
When it helps, and when it misleads¶
Its strength is auditability: it turns "we noticed something odd once" into a queryable, trendable, version-anchored corpus, and it is the only sibling that guarantees a departure remains reconstructable long after the moment. It is what lets an organization count deviations and study their patterns rather than re-litigate each from memory.
Its failure mode is that a log records faithfully whatever it is fed — including noise. A store flooded with un-triaged, immaterial facts becomes a haystack in which the material departures are as lost as if never recorded, and a fact whose baseline pointer was never populated is unreconstructable no matter how immutable the row. The classic misuse is treating the presence of a logged deviation as proof of a problem, when the log's job is only to record the departure, not to judge it. The guarding discipline is to log at the right granularity, never accept a fact without its baseline-version stamp, and keep detection (what gets logged) tuned upstream so the log stays a signal store, not a noise archive.
How it implements the components¶
deviation_fact_record— its raison d'être: each departure is preserved as a complete, durable, first-class fact with all the fields that keep it meaningful.baseline_version_control— every fact carries the baseline-version pointer that was live at write time, so it can be re-read against the correct reference forever.observation_unit_and_scope— each fact records the unit and scope it belongs to, so facts filter and aggregate cleanly without pooling incomparable observations.
It does NOT implement comparison_metric_rule — the log stores results but does not compute them, which is the Baseline Delta Table's arithmetic — nor deviation_routing_policy, deciding what happens to a logged fact, which belongs to the Deviation Review Queue.
Related¶
- Instantiates: Reference-Baseline Deviation Flagging — the log is the archetype's promise that a departure becomes a durable, auditable fact.
- Consumes: Exception Flag Rules Engine supplies the flagged departures the log persists; Baseline Version Register supplies the versions each fact points to.
- Sibling mechanisms: Baseline Delta Table · Baseline Version Register · Control Chart or Run Chart · Deviation Review Queue · Exception Flag Rules Engine · Null-Model Residual Report · Reference Range Flag · Rolling Baseline Comparison · Standardized Residual Score
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Deviation Event Log operates as a durable record, ledger, register, or trace whose value depends on preserving actual state or history because it stores each flagged departure as a durable fact stamped with baseline version, unit, context, status, and review history.
Independent corroboration: The frozen evidence defines Deviation Event Log as 'Stores each flagged departure as a durable fact stamped with baseline version, unit, context, status, and review history', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Event-sourced software systems cohered append-only records whose status changes preserve rather than overwrite the full event history.
Related originating lineages:
- Accounting & Auditing — Audit trails supplied baseline versioning, review history, and tamper-evident accountability.
Review resolution: Event-sourced software systems cohered append-only records whose status changes preserve rather than overwrite the full event history. The retained alternate lineages materially shaped the mechanism's form.
Attribution caveat: The mechanism applies event sourcing specifically to statistical or operational deviations.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Event sourcing — a design pattern in which state is stored as an immutable, append-only sequence of events rather than as a mutable current snapshot. Applied to deviations, it means status changes are recorded as new appended events, so the full history of a fact (and the baseline it was measured against) is never overwritten. ↩