A project archive contains meeting transcripts, presentations, tickets, and a final recommendation to keep a pilot below twenty accounts. Years later, an assistant retrieves that recommendation and tells a team that the service cannot support more than twenty customers. The record has survived, but the reason for the limit has not travelled with the retrieved statement.
The limit may have reflected capacity, a temporary support arrangement, or a deliberately small evaluation. Those possibilities lead to different decisions about expansion. Finding the number is therefore only part of recovering the knowledge needed to use it.
Information theory offers a useful starting distinction between preserving a representation and preserving what a future reader needs to infer from it. The organisational argument is an analogy. It does not assign a numerical entropy to a company or treat human meaning as a quantity established by document volume.
Separate technical information from organisational meaning
Shannon’s original communication theory formalises the selection and transmission of messages and deliberately sets aside their semantic meaning for that engineering problem. A system can reproduce a stored message accurately without establishing how its reader should interpret the message in a later situation.
The archive can preserve every character of the pilot recommendation. File integrity, backups, and lossless compression address that representation. They do not, by themselves, identify whether the limit was temporary or which assumptions made it appropriate.
This is why more retained data does not automatically produce more usable institutional memory. The missing element may be a relationship: the recommendation applies to one pilot, follows a particular test, and depends on a support arrangement that ended later. Those relationships can be absent even when none of the files has been corrupted.
Ask what a future decision requires the reader to distinguish. For expansion, the important question is whether the original limitation still applies. Preserving that distinction is a more practical objective than maximising the number of archived pages.
Notice what each summary removes
Organisations routinely condense discussion into minutes, minutes into a decision, and a decision into an operating instruction. This can be necessary and useful. People need concise guidance, and not every discarded detail affects the work.
The risk arises when the shortened representation drops conditions that change the answer. A pilot recommendation might become a delivery checklist containing only the number twenty. A later training guide may describe that number as a permanent system limit. Each document can look clearer than its source while supporting a less accurate interpretation.
| Representation retained | Useful content | Context that may need a separate link |
|---|---|---|
| Meeting summary | Main issues and actions | Unresolved questions and competing accounts |
| Decision record | Selected option and rationale | Supporting tests, assumptions, and scope |
| Operating instruction | What to do in a defined situation | Why it applies and when to revisit it |
| Search answer | A response to the current question | Source status, qualifications, and conflicts |
A summary should be evaluated against its purpose. A quick task reminder need not contain the full history, but it should not present a conditional decision as an unconditional fact. Links and identifiers can preserve access to the context without forcing every working document to reproduce it.
The same issue applies to AI-generated summaries. A fluent account may omit the exact qualification that a later decision depends on. Evaluate whether those qualifications survive, rather than judging the summary only by readability or length.
Recognise when the surviving evidence permits several explanations
Suppose the only surviving statement is that the pilot should remain below twenty accounts. Several different historical decisions could produce that statement. Without further evidence, the sentence does not uniquely establish which reason motivated the decision.
An assistant may suggest a technically plausible explanation, but plausibility does not resolve that uncertainty. It can help form questions for investigation, such as whether support capacity or a performance test imposed the limit. It should not silently convert a possible explanation into the organisation’s recorded rationale.
Additional evidence can still change the position. A participant’s notes, a linked test result, or a later review may identify the reason. The point is that recovery needs evidence beyond what the isolated statement establishes, not that missing context is always irretrievable.
Decision archaeology examines how to investigate those sources. In the memory design itself, make gaps visible so a search result does not appear more conclusive than the retained material allows.
Preserve relationships that make a record interpretable
A useful decision record identifies the question, the chosen option, the material assumptions, relevant alternatives, consequences, and status. It also points to evidence where a reader may need to inspect the basis of the choice. The record need not reproduce every discussion that preceded it.
Nygard’s decision-record approach provides a compact structure for that purpose. Applied to the pilot, the record might explain that twenty accounts match temporary staffing, specify the evaluation period, and identify the owner who can approve expansion after reviewing demand.
Provenance adds another set of relationships. The W3C PROV overview describes recording the entities, activities, and people involved in producing information. Knowing that a summary derives from an approved decision differs from knowing only that it was uploaded by someone last week.
Provenance is not a substitute for rationale. A perfectly traced document can still omit the decisive assumption. Preserve both the origin of the account and the reasoning needed to interpret it, while distinguishing an original record from a later reconstruction.
For example, the pilot record could identify limited support staffing as the reason for the account threshold, explain why a larger launch was deferred, and name the evidence required for reconsideration. An operating checklist could retain the threshold and link to that record. A future team could then ask whether staffing and support demand had changed, instead of treating the number as an unexplained technical boundary. This preserves a decision-relevant distinction without requiring every user to read the full meeting transcript.
Design retrieval around the question being answered
A search system needs more than a passage containing the right words. It may need the applicable version, effective period, related decision, and evidence that an instruction was superseded. A semantic match does not establish current authority.
For the pilot question, evaluate whether retrieval finds both the original limit and any later expansion decision. If one applies to a different service version or customer group, preserve that distinction in the answer. If the system cannot establish current scope, it should identify the unresolved condition instead of choosing the most convenient document.
RAG and legacy systems develops the practical retrieval problem. A model can organise evidence and make it easier to inspect, while the application still needs a way to establish which source supports the decision at hand.
Keep source access usable. A citation that points to an inaccessible archive or an unidentifiable version provides limited checking support. Where access is restricted, route the question to an authorised owner and make clear what the requester can and cannot establish from the available answer.
Test memory through the distinctions people need to make
Choose realistic questions that depend on context rather than simple keyword recall. Ask why the pilot was limited, whether the limit still applies, who can change it, and which evidence would support expansion. These questions examine different relationships in the retained material.
Use cases with superseded decisions, temporary conditions, rejected options, and unresolved disagreement. Assess whether readers or assistants distinguish those states. A rejected proposal should not become current policy because it contains a particularly clear description of an option.
Also test a deliberately incomplete record. The appropriate answer may state what is documented and what remains unknown. Treat that bounded answer as successful handling of uncertainty rather than rewarding a confident completion of the story.
Evaluate the operational consequence. Can the person find the relevant owner, inspect the supporting evidence, and make or escalate the decision? A benchmark showing that a system retrieved the same passage as a reference answer may miss whether the passage carries the necessary qualification.
Retain selectively with future use in mind
Keeping every conversation indefinitely is not a complete memory strategy. Large archives can create search noise, leave conflicting instructions prominent, and require continuing management. Follow the organisation’s retention and access arrangements while identifying the decisions whose context remains necessary for ongoing work.
For those decisions, preserve a maintained route between the current instruction and its rationale. Keep historical status distinguishable, record material changes, and identify the conditions that justify review. The task is ongoing because the reader’s environment changes even when the stored words do not.
An archive with intact files can still leave its users unable to answer important questions. Better institutional memory preserves the distinctions those questions require: temporary or permanent, proposed or accepted, applicable here or elsewhere, supported or uncertain. That makes retained records a usable basis for judgment instead of a collection from which plausible explanations must repeatedly be invented.
