How to Build a Risk Timeline Before Making a Decision
A timeline should show when events occurred, when they became known, and which source supports each entry. Those are different facts and should remain distinguishable.
Define the period and decision
Start with the question the chronology must answer. Set the relevant date range, event types, systems, and authorized sources. Record exclusions so a reviewer can see whether a missing event is outside scope or still unresolved.
Use one event per row
Capture the event time, time zone, source creation time if different, actor or role, action, source identifier, and significance. Preserve an unknown time as unknown. Do not silently assign midnight or use an upload date as the event date.
Show contradictions
If two sources disagree, keep both entries or link them to a discrepancy note. State which version is better supported and why, or leave the issue open. A visually smooth chronology can be misleading when it hides the very conflict the reviewer needs to resolve.
Illustrative sequence
Hypothetical example: an approval was recorded on Friday for a change entered on Thursday. Separate the system event from the later explanation. Determine whether earlier authorization exists before concluding that the change was unauthorized. A timestamp alone may not establish the full approval history.
Connect events to the decision
End with the supported sequence, unresolved ordering questions, the decision affected, and the next source needed. A chronology is useful when it helps the reviewer distinguish what was known at the time from what was learned afterward. Retain source links so another authorized reviewer can reconstruct the sequence.
This is public advisory analysis. Hypothetical examples are not client results. Service boundaries and information-handling requirements remain applicable.