Evidence is useful when it is attributable, bounded, internally consistent, and independently verifiable. This playbook builds that record from the first decision rather than attempting to reconstruct it after an incident.
Define the evidence boundary
List the decisions, approvals, aircraft and crew state, operational intent, constraints, telemetry, alerts, communications, media, and external notices that the final record must explain. Assign a system or person responsible for capturing each class.
Mark sensitive fields and access purposes before collection. More data is not automatically stronger evidence; unexplained or unlawfully retained data creates a different risk.
Attribute every state change
Record actor, tenant, role, source, event time, receive time, correlation identifier, prior version, new version, and reason for every material mutation. Automated actors need stable identities and code/configuration versions just as people need user identities.
When a manual step occurs outside the platform, create a contemporaneous record and attach the external reference. “Operator called authority” without who, when, channel, and outcome is an unresolved gap.
Build and verify the hash chain
Canonicalize the protected event representation and link each entry to the previous hash within the defined chain. Sign checkpoints or export manifests using a governed key. Keep the algorithm and canonicalization version with the evidence.
Regularly verify the chain from a read-only copy. A chain proves later modification is detectable; it does not prove the original statement was true, so attribution and source evidence remain essential.
Correlate decisions to flight behavior
Tie the approved assessment and intent revision to activation, telemetry, conformance events, interventions, and closure using stable identifiers. Preserve source timestamps and clock-health evidence so a reviewer can reason about ordering.
Keep raw or source-grade artifacts where policy requires them and derive display summaries reproducibly. A graph screenshot is not a substitute for the underlying observations and rendering parameters.
Apply retention and legal hold
Set retention by evidence class, jurisdiction, contract, and operational need. Apply legal hold without moving records outside tenant and authorization controls. Log hold creation, scope changes, access, and release.
Test retention against restored data as well as live data. Backup expiry and private-asset deletion must follow the same governed outcome.
Export a defensible package
Export an immutable manifest, human-readable report, structured events, geometry, telemetry, referenced artifacts, verification instructions, and hashes. Use open formats where possible and identify any file requiring proprietary software.
Scope the export to the authorized tenant, project, operation, and classification. Run an IDOR and over-broad export check before release, then record who generated and received the package.
Verify offline
On a separate machine, verify the signed manifest and every file hash, reconstruct the event order, open the human-readable report, and sample structured records back to their references. Perform the exercise with a reviewer who did not create the export.
Record tool versions, verification result, unexplained gaps, and the disposition of every finding. Store the verification receipt separately from the package it validates.
Common failure review
- A manual approval or phone call was never recorded.
- Clocks differed enough to make event order ambiguous.
- A mutable report was regenerated after issue.
- An export omitted private runtime assets or external attachments.
- Tenant scope was assumed rather than tested.
- A hash chain was present but no independent verification was performed.