A defensible incident reconstruction orders independently recorded events around one stable request or run identity, distinguishes observation from inference, and leaves missing evidence visible instead of forcing a clean causal story.
Define the incident boundary before collecting logs and traces
Start with the customer-visible symptom, the first known time, the affected request or account, and the service versions that could have handled it. Define an observation window wide enough to include the triggering deploy and final recovery. This boundary prevents a broad log export from replacing the actual question: which execution path produced the reported behavior, and what changed before the service returned to an accepted state.
Collect records from sources that keep their own clocks: edge requests, application logs, queue events, state transitions, model and tool calls, downstream APIs, deploy history, alerts, support messages, and operator commands. Preserve the original timestamp and source identifier for every event. Normalize time only in a separate field so the reconstruction can expose clock skew instead of silently rewriting it.
Join events and label the strength of each link
OpenTelemetry describes traces as a request path assembled from spans that share a trace identifier and parent relationships. Use that path where it exists, then bridge missing segments with request IDs, run IDs, session IDs, queue message IDs, idempotency keys, deployment versions, and downstream response identifiers. A temporal sequence alone does not prove causation, so label a link as direct, correlated, inferred, or unresolved.
Build the timeline from the narrowest verified events outward. A span says a tool call started, the provider record says an operation arrived, and the application state says a result was committed. If the provider identifier is missing, the timeline should say that the effect cannot be joined rather than assume the absence of an effect. Record conflicting evidence next to the claim it challenges.
End with recovery evidence and instrumentation changes
The reconstruction should identify impact bounds, confirmed causes, contributing conditions, causal uncertainty, mitigation, recovery verification, and the signals that were unavailable. Google's SRE postmortem example starts from a timeline and supplements it with incident evidence, which keeps later analysis tied to the record. Each corrective item should name the missing field, span, alert, test, or recovery action and the owner who can verify it.
Incident Recovery Record is operated through Reality Contact, LLC. The buyer reviews every causal statement, controls production access, and decides which repairs to deploy. The reconstruction is a technical incident record from the supplied evidence; it is not a forensic opinion, compliance report, or assurance that all affected requests and causes were found.
Where the service stops
Reality Contact, LLC installs bounded telemetry and recovery controls but does not provide forensic determinations, certify security or compliance, decide lawful retention, approve production access, or supply continuing incident response. The buyer approves the telemetry fields, redaction and retention rules, alert owners, recovery authority, scenarios, production credentials, and final deployment. This is technical implementation and incident-record preparation; it does not replace the buyer's legal, privacy, security, compliance, or forensic review. We do not promise complete telemetry, a single root cause, error-free recovery, continuous availability, or visibility into systems that do not expose records.
Sources: OpenTelemetry explanation of traces and context propagation; Google SRE example incident postmortem.