Flight Recorder¶
Artifact — instantiates Intermittent Failure Capture
Continuously or selectively retains recent operational state so evidence is available when a rare episode occurs.
A Flight Recorder is an always-running, fixed-size buffer that continuously overwrites its oldest contents, so that at any instant it holds the most recent slice of live operational state. Its defining move is that it captures the lead-up retrospectively: because the recent past is already recorded, when an episode finally occurs you can look backward at the moments before the visible symptom without having predicted which moment would matter. It is the machinery of the rolling window — how far back the buffer reaches (capture_window), what state each write holds (state_snapshot), and how big the buffer is allowed to grow before the oldest data is discarded (capture_budget). It keeps a continuous rolling window of live state; it does not freeze one curated package, nor guarantee the record survives a catastrophe.
Example¶
An online multiplayer game studio keeps getting sporadic reports of players "rubber-banding" — teleporting backward for a second — that clears before anyone can look, and never reproduces in the studio. They add a flight recorder to each match server: a rolling 30-second ring buffer holding every player's position, input, and the server's tick timings, overwritten continuously and costing almost nothing. When a player taps a "report lag" button, the current buffer contents are dumped to durable storage. After a dozen dumps, engineers notice the rubber-band always follows a specific pattern of tick-time spikes in the four seconds before the symptom. The whole value of the buffer is that those four seconds were already recorded — no one could have known to start logging then.
How it works¶
- A ring (circular) buffer sized to hold the last N seconds or events of state; writes are cheap and continuous, and old entries are overwritten in place so storage never grows unbounded.
- The buffer inverts the usual "start logging when something looks wrong" — it is always logging the recent past and quietly discarding it if nothing happens.
- On a trigger (or a manual freeze), the current buffer is copied out; often a short post-trigger tail is kept too, so the return-to-normal is captured alongside the lead-up.
Tuning parameters¶
- Buffer depth (window length) — how far back the rolling window reaches. Longer catches slow-developing causes but costs memory and overwrite churn; too short and the root cause is already gone by dump time.
- Sampling fidelity — how much detail per write. Richer state diagnoses more but raises overhead — and enough overhead can perturb the very timing you are trying to observe.
- Pre/post split — how much after-trigger tail to retain beyond the pre-symptom buffer.
- Freeze trigger — manual versus automatic dump. Too eager fills storage with non-episodes; too reluctant and the buffer overwrites the moment before anyone freezes it.
When it helps, and when it misleads¶
Its strength is that it cheaply captures the pre-symptom lead-up you could never have predicted, always-on, for the price of a bounded buffer. Its central failure mode is a mismatch between buffer depth and the cause-to-symptom lag: if the true cause fires further back than the window reaches, it has already been overwritten by the time you dump, and you preserve a tidy record of only the aftermath. The classic misuse is cranking fidelity so high that the instrumentation itself changes timing and the defect moves or vanishes — a Heisenbug.[n1] The guarding discipline is to size the window from the observed cause-to-symptom lag rather than a guess, keep per-write cost low enough that recording does not alter behavior, and confirm that captured dumps actually contain the transition, not just the recovery.
How it implements the components¶
Flight Recorder realizes the retention-window side of the archetype — how much recent state to keep and for how long, not what to do with it after:
capture_window— the ring buffer is the capture window; its depth sets how far before (and, with a tail, after) the symptom is retained.state_snapshot— each write records the live operational state — positions, inputs, resource levels, timings — so the frozen buffer is a slice of what the system was actually doing.capture_budget— the fixed buffer size is a hard budget: oldest data is overwritten so retention cost never grows, which is exactly what makes always-on recording affordable.
It does not harden the record against tampering or loss (evidence_preservation_rule) — that durability is black_box_log's; and it does not bind a dump into one identified, context-linked package (episode_identifier, contextual_trace) — that assembly is incident_snapshot's. Flight Recorder keeps the recent past always; Incident Snapshot assembles a record once.
Related¶
- Instantiates: Intermittent Failure Capture — supplies the pre-event evidence the rest of the capture loop depends on.
- Sibling mechanisms: Trigger-Based Debug Trace · Incident Snapshot · Symptom Diary · Rare Event Monitor · Automatic Diagnostic Capture · Post-Episode Evidence Review · Black Box Log
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: The mechanism continuously or selectively preserves recent operational state so a durable time-ordered history exists when a rare episode must be reconstructed.
Nearest alternative: Monitoring, Sensing & Alerting — State is captured continuously, but the primary value is retained retrospective evidence rather than a current indicator or alert.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Aviation & Aeronautics
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Continuous retention of operational state for rare-event reconstruction originates canonically in aviation flight-data recorders.
Related originating lineages:
- Computer Science & Software Engineering — Software observability adopted rolling logs, traces, and crash recorders for intermittent failures.
- Engineering & Design — Accident investigation and reliability engineering generalized event recording to physical systems.
Review resolution: Both reviewers agree that aviation_aeronautics is primary. I retain engineering_design, computer_science only as formative origin lineage(s), without treating every later application as an origin. convergent is appropriate because the same operational structure arose through materially independent professional lineages. Reach is multi_domain as a separate applicability judgment: it does not widen or narrow the recorded provenance. Encyclopedia synthesis is false because the artifact is already established enough that encyclopedia-specific synthesis is not required. The secondary differences are reconciled with no unresolved primary-provenance ambiguity.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
A flight recorder's power comes from what it is willing to throw away. It records everything recent and keeps almost none of it — the discard is not a limitation but the design. That is what separates it from a mechanism that decides in advance what is worth keeping.
[n1] A Heisenbug is a defect that alters its behavior or disappears when one tries to observe it — for instance, added logging that changes timing enough to hide a race condition. Named by analogy to Heisenberg's uncertainty principle, it is the reason capture fidelity must be weighed against the risk of perturbing the system. ↩