Begin with a narrow decision statement and a date range. Build a source ledger from the repository, issue tracker, design records, and attributed conversations, then separate what participants knew at the time from what became visible only after implementation.
Define the decision before collecting explanations
Write the choice as a testable sentence: what changed, which component or operating rule it affected, and when the change became real. Use commits, deployments, configuration history, or approved design documents to anchor that date. An undocumented decision often appears as several partial acts, so distinguish the first proposal, practical adoption, and later formal explanation instead of forcing them into one moment.
Collect contemporary alternatives and constraints next. Search issues, pull requests, meeting notes, cost records, incidents, and provider limits from the same period. Record who stated each constraint and whether it was measured, assumed, or imposed. Later recollections are useful evidence, but label them as retrospective so they do not silently replace the information available to the original decision makers.
Link later outcomes without rewriting the past
Add subsequent incidents, scaling changes, customer requirements, staffing changes, and superseding decisions on the same timeline. For each, state whether it confirms an original assumption, contradicts it, or introduces a condition that did not exist. A present-day problem does not prove the original choice was irrational; it may show that the operating environment moved beyond the original boundary.
Finish with an evidence gap list and safe-change questions. Name missing records, disputed attribution, and assumptions that cannot be tested from the archive. The reconstruction should let the buyer ask whether the old constraint still holds, which dependencies now rely on the choice, and what bounded experiment could distinguish reversal from another undocumented guess.
Where the service stops
Reality Contact, LLC reconstructs and organizes the available record, but does not determine legal liability, perform M&A diligence, value a company, resolve personnel disputes, or make the buyer's architecture or management decision. The buyer verifies sensitive facts and source access, chooses which unresolved questions require stakeholder review, and owns any decision to preserve, reverse, or retest the prior choice. This is technical research and document preparation; it does not replace legal, financial, investment, employment, M&A, compliance, or management advice. The dossier reflects the supplied record, labels inference and missing evidence, and does not establish motive, fault, approval, or the correct decision.
Sources: AWS architectural decision record process; GitHub documentation for viewing file history.