Incident review needs a record of what was known at the time.

Incident response is part of ongoing risk management.

Incident review is often treated as work that begins once something has gone wrong. The evidence available at that point, however, depends on choices made much earlier: which systems were connected, which decisions were recorded, and whether changes preserved their history. Investigation quality is partly a property of everyday record keeping.

NIST’s April 2025 revision of its incident-response guidance places cybersecurity incident response within broader risk-management activities. Its stated aims include preparation and more effective detection, response, and recovery. That publication concerns cybersecurity. We see a useful parallel for operational incidents involving commitments, decisions, and agent actions: the record needs to be useful before an investigator asks for it.

As agents participate in more workflows, the explanation may span a human request, an automated proposal, a policy check, an external operation, and information learned afterward. A list of timestamps helps, but it does not automatically preserve what each participant could know at the relevant moment.

Sources: [1]

The date of a change is not always the date it became known.

Suppose a supplier revises a delivery commitment on Monday, but the account team receives and records the update on Wednesday. A staffing decision made on Tuesday can be evaluated against two different records. One reflects the delivery position that was effective on Tuesday. The other reflects the information available to the team when it made the decision.

Those views are both useful. The first helps explain what happened in the business. The second helps explain the basis of the decision. If a system overwrites the old delivery date and exposes only the latest value, a later reviewer can mistakenly assume the team had information it had not yet received.

Martin Fowler’s account of bitemporal history describes the distinction between actual history and record history. It is an established data-modeling idea with practical consequences for AI-assisted reconstruction. An agent summarizing the latest record needs access to the earlier knowledge state if it is going to explain an earlier decision fairly.

Sources: [2]

A sequence of events does not establish a cause.

A timeline can show that an approval preceded an action, or that a warning arrived before a deadline. It does not establish that the warning caused the decision, that the approval covered the action, or that the responsible person saw the relevant information. Those are substantive claims that require supporting evidence.

The same caution applies to agent records. A permitted attempt may have failed during execution. An imported event may show that a tool was used without showing a prior policy check. A missing record may indicate a coverage gap rather than an absence of activity. Combining these into a fluent narrative can make uncertainty disappear without resolving it.

A useful reconstruction keeps the distinction between established facts, supported connections, and unresolved explanations visible. It should let a reviewer follow the source of a material statement and understand the period and systems covered. The goal is an inspectable explanation, not the most seamless story.

We preserve the record as the organization learns.

Our approach keeps effective time and the time information entered the record separate. New evidence can change the organization’s understanding while preserving the earlier state. That supports questions about what happened and about what could be established from the available record at a chosen point in time.

Reconstruction connects available actors, decisions, policies, source evidence, receipts, and outcomes. It preserves the distinction between in-path governance and observed activity, and between a verdict and confirmed execution. Those distinctions prevent the integrity of one part of the record from being mistaken for broader coverage.

Where Attest is available, authorized users can assemble a conformance packet for a defined organization or agent scope and time window. The packet organizes evidence and verification information for review. It does not establish root cause by itself, certify compliance, or fill in source material that was never captured.

This is a product choice about the shape of the record. We want new knowledge to improve an investigation without erasing the conditions under which the earlier work took place.

Test a late-arriving fact before the real incident.

A practical evaluation can be small. Record a commitment, make a decision based on it, and then introduce a correction that was effective before the decision but learned afterward. Ask for both the current account and the account supported by the earlier knowledge state.

Next, remove access to one source or leave an external action outside the integrated path. The reconstruction should identify the resulting limit. A system that produces the same certainty regardless of coverage is giving the reviewer less information than its polished narrative suggests.

This exercise tests more than a timeline component. It tests whether the organization can preserve its changing understanding and use that history responsibly. For work shared by people and agents, that is a necessary foundation for learning from an incident without judging every earlier choice as though the future were already known.

• Record both effective time and the time information was learned.
• Keep later corrections available without overwriting earlier knowledge.
• Separate chronology from claims about cause, intent, or authorization.
• Make source coverage and unresolved explanations part of the review.