A customer asks whether a particular service arrangement is supported. Sales has a presentation saying yes. Operations has a checklist saying no. Engineering knows that the arrangement works only for accounts migrated after a recent release. Each group can point to a document that accurately reflects part of its experience.
The conflict is not necessarily a failure to store information. Relevant knowledge exists, but it is distributed across people, records, and systems without a dependable way to assemble the answer for this customer. A new knowledge portal might make all three documents searchable and still leave the disagreement unresolved.
Distributed systems provide a useful lens for the problem: copies become stale, changes travel at different speeds, and a shared timestamp does not explain every relationship between events. People and organisations are not software replicas, however. Their disagreement can concern interpretation, authority, and competing objectives as well as different versions of a fact.
Begin with the decision that needs a complete enough picture
No organisation needs everyone to know everything. Specialisation distributes knowledge for practical reasons, and some information appropriately has restricted access. The design problem is how relevant knowledge reaches a decision when it is needed.
For the customer question, identify what a dependable answer requires: technical eligibility, the account’s migration state, the support commitment, and the authority to offer that arrangement. Those elements may have different owners. A single document cannot become authoritative for all of them merely by appearing at the top of search results.
Walsh and Ungson’s account of organisational memory considers retention across different parts of an organisation, rather than locating memory solely in an archive. That conceptual view helps explain why improving document search is only one part of the task.
Define a narrow route for composing the answer. Engineering can establish the supported technical condition, operations the service commitment, and an account system the customer’s state. Someone then needs responsibility for resolving the request, including what happens if those sources disagree.
Distinguish an outdated copy from a substantive disagreement
The sales presentation might predate the limitation, in which case replacing its claim with a link to the current eligibility rule can help. Alternatively, sales and operations might understand a recently approved exception differently. That requires a decision about the exception, not merely synchronising files.
Ask what each statement refers to. Record its applicable population, effective period, status, and source. A checklist for unmigrated accounts can remain correct while a newer engineering note describes migrated accounts. Combining them into one undifferentiated answer would erase the condition that resolves the apparent contradiction.
| Difference between accounts | Question to resolve |
|---|---|
| Different versions | Which decision superseded the earlier one? |
| Different scope | Which accounts or situations does each statement cover? |
| Different effective dates | When did the rule begin to apply? |
| Different authority | Who can decide the disputed point? |
| Different interpretations | What evidence or clarification could settle the meaning? |
Retain genuine disagreement until someone with the relevant authority resolves it. Marking every conflict as a documentation defect can hide an unsettled business choice behind an editorial task. Equally, escalating a simple version mismatch as a strategic disagreement can create unnecessary delay.
Preserve causal relationships as well as timestamps
A newer upload is not necessarily a newer decision. Someone may copy an old presentation into a new folder after the engineering note was approved. Sorting by file modification time can make the stale claim look current.
In Lamport’s work on event ordering in distributed systems, causal relationships play a central role in describing which events precede others. The organisational application is a comparison: records should expose relevant relationships, such as which decision authorises a procedure or which change supersedes a previous rule. A date alone cannot supply those relationships.
For the service arrangement, connect the eligibility decision to the release that enabled it and the operating instruction that implements it. Also distinguish when the decision was accepted, when the release was deployed, and when particular customers became eligible. These may be different events.
A short shared identifier can connect the records without requiring every team to copy the full explanation. The operational checklist can reference the decision and the account condition, while retaining its own task-specific instructions. Readers then have a route to the rationale and the source of current eligibility.
The state used for a particular answer also needs an appropriate level of freshness. A slide listing migrated accounts may have been correct when prepared, while the account system now records additional migrations. Decide which source establishes the customer’s current state and how that state is linked to the policy’s conditions. Preserve enough of the check to explain the answer later, including the account reference and when the relevant state was observed. Updating a policy document alone cannot keep every changing customer fact current.
Design how changes reach the people who act on them
Publishing a revised rule does not establish that the relevant teams received it or changed their work. Identify which actions depend on the rule and where those actions are initiated: sales templates, support scripts, automated checks, onboarding forms, and internal training may all contain a local representation.
Choose an update method suited to the consequence. A shared link may be enough for reference material. A change affecting a consequential customer promise may need explicit acknowledgement, a template update, or an automated eligibility check. The control should address the actual route through which an outdated claim could become an action.
Keep one maintained location for the rule where feasible, while allowing local procedures to explain how it applies. Copying the entire policy into every team document increases the number of places that need coordinated revision. Removing all local explanation can also make the rule difficult to use. Test whether staff can complete the task through the resulting references.
AWS’s decision record process provides a pattern for distinguishing a superseded decision from the one that replaces it. The additional organisational work is ensuring that this relationship reaches the documents and systems where people still encounter the old instruction.
Let AI expose conflicts without inventing authority
An assistant retrieving across departments can help find relevant accounts, compare their scope, and identify missing evidence. It should not quietly combine an unconditional yes from sales and a conditional no from operations into an unsupported compromise.
Require the answer to retain the conditions that matter. If the available records do not establish whether the customer has migrated, the system should identify that gap and point to the appropriate check. A fluent answer that omits the condition can be less useful than a clearly bounded incomplete answer.
Access control remains part of the arrangement. The assistant may be able to indicate that an authorised owner must confirm eligibility without exposing restricted account details to everyone. Centralising the search interface does not require centralising every disclosure or decision right.
Evaluate the assistant with conflicting, superseded, and scope-dependent records. Ask whether it identifies the disagreement, retrieves the relevant authority, and preserves uncertainty. These questions extend the evidence-focused approach in RAG and legacy systems, rather than treating document retrieval as proof of organisational agreement.
Test the handoff through a real decision path
Choose a request that crosses the relevant teams and follow it through the proposed arrangement. Can staff locate the current rule, establish the customer’s state, obtain clarification, and give a supported answer within the required time? A complete catalogue of documents is insufficient evidence for that workflow.
Include a case in which an owner is unavailable or a source cannot be reached. Define whether the request is held, escalated, or answered within a narrower scope. The person handling the request should not have to invent an authoritative answer to clear the queue.
New staff provide another useful test of the arrangement. Ask them to locate the right owners and assemble the answer using the references available in ordinary work. If success still depends on knowing whom to message informally, the organisation has identified a connection worth preserving. A maintained directory of responsibilities can support that connection without trying to copy every specialist’s knowledge into one manual.
Review failures at the level where they occurred. A missing source, an unowned policy dispute, and an outdated sales template need different corrections. Recording all three as knowledge-management problems would make it harder to assign effective work.
The related issue in the monoculture problem of expertise is whether the organisation has other useful routes into a question when its usual sources or specialists fail. Distribution can provide breadth, but only if the connections make that breadth usable.
A workable institutional memory does not require one person to hold the complete picture. It requires a dependable way to assemble the relevant picture, identify which claims apply, and resolve uncertainty with the right owners. Preserve the source knowledge where it can be maintained well, and make its relationships clear enough for decisions to cross organisational boundaries.
