A Flight Recorder is OpsProof’s human-readable view of a sealed Proof Bundle: a read-only record of a real run that you can review, share, and defend. It’s designed so you can answer the questions that matter in operational work—what happened, what evidence supports it, and who signed—without having to trust a system-of-record summary or dig through raw logs.
The key idea is simple: policy comes first. Every Flight Recorder is evaluated under a specific policy profile. That profile defines what must be true for a run to be certifiable: which requirements must be met, which evidence must be attached (and where), which approvals are required for closure, and which violations are hard stops. When you see an outcome, you are seeing that policy profile applied to the recorded timeline, attached evidence, and recorded decisions—not a narrative someone typed after the fact.
Read a Flight Recorder in this order:
- Quick Read: Start here. It shows the outcome and the reason, then links you to the exact steps, evidence, and sign-offs that support it.
- Steps: This is the timeline. It shows what happened, in order, and where decisions, deviations, and checkpoints occurred.
- Evidence: Evidence is attached to steps. Use it to confirm the claims the run is making—documents, reports, logs, snapshots, photos, and other artifacts tied to specific moments in the procedure.
- Sign-offs: Sign-offs record decisions: who acted, what they decided, and when they recorded it. Some sign-offs are approvals—the specific decisions that satisfy the policy profile’s closure requirements for FINAL. Others exist to document awareness or response (especially after a FAIL) and do not convert a failure into an approval.
- Record details: This is where integrity, provenance, and verification context live—what was sealed, what was checked, and which policy profile was applied.
What the outcomes mean
- FINAL: The proof is complete under the policy profile. Required evidence is present, and required closure approvals are present.
- PROVISIONAL: The proof is intact, but closure isn’t complete under the policy profile. Integrity and gates have passed, but one or more required approvals (for example, a quorum threshold) are still missing.
- FAIL: A hard policy rule was violated. The record is preserved for investigation and response, but closure approvals are blocked until the underlying issue is remediated and the work is re-run under policy.
Hardcore audit details
Most readers should stay in the Flight Recorder UI—this is the whole point. But when you need maximum defensibility (external audit, incident review, dispute resolution), the bundle also includes machine-verifiable artifacts and deeper audit structures that let tooling validate the record independently:
- Offline verification artifacts (canonical files that tooling can validate without trusting the UI): the recorded timeline, the verifier’s report, and the bundle’s sealed manifest + signature metadata.
- Claim DAG: a requirements graph that shows exactly which requirements were satisfied, what evidence supports each claim, and what sign-offs close which requirements—useful when you need a precise “why” behind FINAL, PROVISIONAL, or FAIL.
- Verification context: policy profile identifiers, verifier versioning, ordering/time confidence signals, and trust material identifiers—so you can see *what was checked* and *under what trust assumptions*.
These details exist so the record can be verified and exchanged as a portable, tamper-evident artifact—while the Flight Recorder remains the document a human can actually read.
