A sales team can approve certain pricing exceptions only at a Tuesday meeting. The delay frustrates account managers, but nobody is sure why that meeting exists. One person remembers a billing limitation. Another believes finance required it after a costly mistake. A training guide describes the meeting as mandatory without identifying the decision that made it so.
The team could remove the meeting, preserve it, or move its approvals into a new tool. Each option assumes something about the problem the meeting is meant to solve. Without examining that assumption, a redesign can either retain unnecessary work or remove protection that still matters.
Decision archaeology is a practical name for reconstructing this history from evidence. It helps establish what was decided, under which conditions, and what remains uncertain. Its purpose is to inform a present decision, not to produce a complete historical account before anyone can change a process.
Start with a specific rule and a current question
Define the object of the investigation. The Tuesday meeting may contain several rules: who can approve a discount, when approvals occur, which evidence is required, and how the result reaches billing. Those rules may have different origins and different present uses.
For the sales team, the immediate question might be whether timing can change while approval authority remains intact. That is narrower than asking why the entire pricing process exists. It also directs the search towards evidence about batching and system updates rather than every discussion of discount policy.
Record what the current process actually does. Follow a few exceptions from request to invoice, including an urgent case and a rejected case. The written procedure may describe one path while staff use another. Knowing that difference prevents the investigation from explaining a rule that no longer governs the work.
Agree who will use the findings. A historical explanation can identify an old constraint, but the current process owner still needs authority to decide whether that constraint remains relevant and what evidence supports a change.
Build a timeline from contemporary records
Look for material created when the rule was introduced or changed: incident records, release notes, meeting decisions, approval messages, configuration changes, and earlier versions of the procedure. A useful record connects an event to a decision, rather than merely mentioning the same topic.
Suppose a change ticket records that the billing platform could import approved discounts only once a week. An accompanying decision permits weekly batching until a replacement interface becomes available. A later release note describes that interface, but the procedure was never revised. Together, these records support an explanation that the meeting’s timing addressed a technical constraint.
They do not necessarily explain every part of the meeting. Finance may also have used it to review unusually large discounts. Keep those claims separate. Discovering a plausible origin for one rule does not establish the full history of the process.
Michael Nygard’s account of architecture decision records describes preserving context, a decision, its status, and consequences. That structure is useful during reconstruction too: identify the choice and the circumstances that made it reasonable, rather than recording only the resulting instruction.
Treat recollection as evidence with limits
People who participated can identify missing records, explain terminology, and reveal alternatives that a final memo omitted. Their recollections can be valuable without being complete or mutually consistent. Ask what they directly observed and which parts they inferred later.
A participant may remember that the meeting followed an incident but not whether the incident caused the timing rule or only the requirement for a second approval. Trace those statements back to dates, actions, and available records where possible. Preserve disagreements that cannot be resolved.
Do not count several retellings as several independent confirmations if they all derive from the same departing manager’s explanation. Similarly, a training guide copied into multiple repositories remains one source of a claim, not a collection of independent decisions.
| Material found | What it may establish | Limit to retain |
|---|---|---|
| Accepted decision record | The recorded choice and rationale | It may omit informal considerations |
| Change or incident ticket | A problem, intervention, or implementation | Implementation does not establish every motive |
| Later procedure | What staff were instructed to do | It may not explain why the instruction began |
| Participant recollection | Context and leads for investigation | Memory can be incomplete or influenced by later events |
| Current system behaviour | Which constraints exist now | It does not establish the original intention |
The resulting account can distinguish documented facts, supported interpretations, and unresolved questions. That distinction matters more than making the history read as one seamless explanation.
Record the limits of the search as well. The earliest procedure found establishes that the rule was documented by that point; it does not necessarily identify when the rule began. Failure to find a decision in one repository does not establish that no decision was made. Note which collections and participants were consulted, which periods are missing, and which records could not be accessed. This helps a later investigator extend the account without mistaking an incomplete search for evidence of a deliberate absence.
Avoid filling gaps with a plausible story
An AI assistant can search a collection, group references, and propose a timeline. Its account should identify the records supporting each material claim. A coherent narrative is not additional evidence that the organisation acted for those reasons.
Ask the assistant to distinguish an explicit statement from an inference. If a document says an interface was unavailable, that does not alone establish that every weekly approval rule existed because of it. A later interview or decision record may support the connection; without one, the gap should remain visible.
Keep the original source and relevant version available for checking. The W3C provenance overview describes information about the entities, activities, and people involved in producing data. Applied here, provenance helps a reviewer trace an account to its sources, while the adequacy of its explanation still requires judgment.
The limits of reconstruction are developed further in information theory and institutional memory. Retrieving a surviving document cannot guarantee recovery of reasoning that was never recorded or preserved elsewhere.
Compare the original conditions with the present ones
Once the evidence supports a historical explanation, test which conditions still apply. The replacement billing interface may remove weekly batching while leaving approval limits, commercial review, or reconciliation requirements unchanged. A current process can combine decisions made at different times.
For the Tuesday meeting, demonstrate that the new interface can apply approved changes with the necessary checks. Identify who receives the result, how failed updates are handled, and whether another process depends on the meeting’s output. Historical obsolescence and operational replaceability are different findings.
Where the origin remains uncertain, assess the current function directly. The team may be able to justify an alternative that provides the required approval and reconciliation without resolving every historical disagreement. Uncertainty about the past should be explicit, but it need not become a permanent prohibition on improvement.
Stop the investigation when it can support the decision
Set a proportionate boundary on the search. A low-consequence timing change may need a few source checks and a controlled trial. Removing a consequential control may require a more extensive review of dependencies and evidence. The investigation should serve the decision’s stakes.
A useful stopping point is an account that identifies the rule, the strongest available explanation, material uncertainties, current dependencies, and the owner of the next decision. Additional history can be retained if found later without requiring the team to wait indefinitely for a perfect archive.
Keep the difference between explanation and justification. A rule may have been reasonable under the conditions of its introduction and be unnecessary now. It may also have a disputed origin while serving a clear current purpose. Processes that outlive their original purpose require that present-function assessment before retirement.
Leave a record that the next team can interpret
Document what the investigation established and the decision made from it. Include the evidence used, what remains uncertain, which assumptions support the new arrangement, and what would trigger another review. A short linked record can preserve more usable understanding than a long report separated from the operating procedure.
AWS’s guidance on decision records recommends preserving accepted or rejected records and using a new record to supersede an earlier decision. This provides one workable pattern for keeping history distinguishable from the current instruction.
Link the current procedure to the new decision, and make the status of the old rule apparent. A future search should not leave two equally authoritative-looking instructions with no explanation of their relationship. Update the relevant workflow, training, and reference points as part of the change.
The successful result is a decision people can explain and revisit. The team understands enough of the inherited rule to assess it, retains uncertainty honestly, and records why the present arrangement is appropriate. The next group should inherit that reasoning along with the instruction it produced.
