A team can write down everything and still lose what it knows. Meeting notes multiply. Folders fill with screenshots. Three versions of a policy sit side by side. A new employee finds an answer but cannot tell whether it is current. An AI assistant searches the same pile and repeats the most confidently worded obsolete instruction.
The purpose of evidence capture is not to preserve every scrap forever. Keep the smallest reliable record that lets someone understand, check, and improve a decision. That record needs context: who observed or supplied it, when it applied, what it supports, and who is responsible for reviewing it. This article shows how to build such a record and how to retire clutter before it becomes a misleading source.
The previous article, Choose the Decisions Your Knowledge System Must Improve, starts with the choice a team wants to make better. That choice is the filter for what evidence deserves to be collected.
Collect for a decision, not for a hypothetical future
Suppose a local service business wants to improve estimates. Staff members keep asking the owner why a job was priced a certain way. The owner could upload years of invoices and messages into a new system. That would be expensive to review, may expose private customer details, and still might not reveal the reasoning behind past prices.
Start with the decision: “What should we quote for this type of job, given scope, materials, travel, and current capacity?” Useful evidence might include a recent cost sheet, labor assumptions, a handful of completed jobs with actual time and material use, and an explanation of exceptions. The customer phone number in an old invoice may be irrelevant. So may a pile of marketing drafts.
Ask three questions of each proposed source:
- Which decision could this record help us make or audit?
- Is there a person who can explain and maintain it?
- Can we keep the needed information without copying unnecessary private material?
If nobody can answer the first question, do not import the record into the working knowledge set merely because it is available. It may belong in an archive under its normal retention rules, or it may have no continuing purpose. Keeping less can make the right evidence easier to see.
Separate observations, decisions, and policies
A common failure is to store unlike statements as if they carried equal authority. “A supplier says a part should arrive Tuesday,” “The technician saw the part arrive,” and “We may promise a completion date once the part is here” are different records. The first is an estimate, the second an observation, and the third a rule. If search returns them as interchangeable snippets, a person or AI system can make a false promise.
Use a small set of record types:
| Type | Example | What a reader must know |
|---|---|---|
| Observation | A product failed a dated functional test | Who tested it, what was tested, and what was not |
| External source | A supplier’s delivery estimate | Source, retrieval date, and whether it is confirmed |
| Decision | A manager approved an exception | Who approved it, for which case, and why |
| Policy | The current return or quoting rule | Owner, effective date, version, and next review |
| Outcome | A refund, repair, or customer response | What happened and whether the earlier decision held |
The types are an editorial design suggestion, not a formal standard. Their purpose is to prevent a past exception from becoming a general policy or a secondhand estimate from becoming a verified fact.
Give every working record a minimum identity
A sophisticated database can enforce metadata, but a simple document header can do the job for a small team. Add these fields when a record enters the working set:
- Plain-language title: what someone will look for, such as “Current appliance testing checklist.”
- Type and purpose: observation, policy, source, decision, or outcome; name the decision it supports.
- Origin: the person, system, publication, or event the information came from.
- Relevant date: when the information was observed, published, or effective. A file creation date alone may not answer this.
- Owner: the person or role that can resolve questions and approve changes.
- Status: draft, current, disputed, superseded, or archived.
- Review trigger: a calendar date or event such as a supplier change, regulation update, or repeated error.
- Access level: who may see it and whether it may be shared with an outside tool.
Not every field has to appear on a public page. Some are internal controls. The point is to make the status and provenance visible enough for a user to judge whether the record fits the present question.
The UK Government Data Quality Framework distinguishes completeness, uniqueness, consistency, timeliness, validity, and accuracy. These dimensions help explain why a record with all fields populated may still mislead. A complete price sheet can contain a wrong number. Two individually accurate documents can conflict because they apply to different periods. Metadata makes such problems more likely to be noticed; it does not remove the need to check the underlying claim.
Preserve the reason, not only the final answer
Organizations often record a final price, approval, or publication while losing why it was chosen. Later, nobody knows whether the decision was a normal application of policy or a one-time exception. That missing reasoning makes old records dangerous examples for a new worker or an AI system.
For consequential choices, add a short decision note:
Question: Should this used camera be listed as fully functional? Evidence: Dated test notes cover shutter, screen, storage, and controls; video mode was not tested. Decision: Do not describe the whole camera as fully functional. List tested functions and disclose the untested mode. Owner: Seller. Review: Update if video mode is tested before publication.
The note is brief, but it connects evidence to wording. If a buyer later asks about video, the seller can answer honestly. If the camera is retested, the note explains exactly which fact changed. This is more valuable than saving a polished draft listing with no test record behind it.
Do not turn every trivial choice into a meeting document. Record reasoning where future readers might otherwise misinterpret a result, repeat a mistake, or be unable to defend a claim. A good working record is long enough to make the choice auditable and short enough that people will actually maintain it.
Handle disagreement instead of hiding it
Two records may disagree because one is wrong, one is old, they describe different cases, or their words mean different things. Quietly picking the newer-looking file can hide a serious issue. Give disputed claims an explicit status and name the person who can resolve them.
For example, a catalog says an item includes an accessory, but the receiving photo does not show it. The system should not merge those into “Accessory included.” It should say “Accessory status unconfirmed” until the physical item is checked. If the item has already been listed, the team may need to correct the listing or contact a buyer. A disputed status is useful information, not a failure to appear confident.
For numerical data, distinguish missing from zero. An empty repair-cost field means the cost was not recorded; it does not mean the repair was free. A default value entered automatically can make a dashboard look complete while reducing its accuracy. The UK framework’s distinction between completeness and accuracy is particularly important here.
Keep a current path and an archive path
A reader doing today’s work should encounter the current rule first. A person investigating what happened last year may need the older version. Both needs can be met without displaying every version as equally valid.
Give a current policy one canonical location. Link it to a version history if the history matters. Mark a replaced page superseded and point to the current page. Keep effective dates so the team can interpret an old transaction under the rule that applied then. For working search and AI retrieval, filter or rank by status and date, and make old material visibly historical rather than deleting context silently.
Retention also deserves a deliberate rule. Different records may have legal, contractual, privacy, or operational requirements that this article cannot settle for every organization. Identify those requirements before deletion, restrict access where appropriate, and avoid copying sensitive information into a second tool merely to make search convenient. The site’s AI data privacy guide offers a task-level sharing check; it does not replace advice for a regulated record system.
The ISO knowledge management systems standard’s public abstract describes an ongoing system of establishment, maintenance, review, and improvement. A knowledge library needs the same attention. It is not finished when the documents are uploaded.
A worked capture: a recurring repair delay
Consider a fictional repair business that has missed three promised dates in a month. The owner wants to understand whether the cause is parts, scheduling, diagnosis, or communication. A useful capture set could look like this:
- A case record for each delayed job: the promised date, actual completion date, scope, part status, and customer updates. Customer identifiers remain in the authorized service system rather than a broadly shared analysis copy.
- A source record for each part estimate: supplier, estimate date, status, and later confirmed arrival. The system does not overwrite an estimate with the final date without preserving which one informed the original promise.
- A decision note: who made the promise and which evidence was used. The point is process improvement, not a blame ledger.
- An outcome note: the actual delay and its known cause, with “unknown” where evidence is insufficient.
- A revised rule if justified: for example, an unconfirmed supplier estimate may support a progress update but not a firm completion date.
Now the business can ask a specific question: “How many missed promises involved an estimated, rather than confirmed, part arrival?” It can inspect the cases, understand exceptions, and improve the rule. A stack of generic “delay” tags would not support that diagnosis.
The numbers in this example are illustrative. A team should not infer a cause from three cases without examining the underlying records. A small sample is useful for discovering a failure mode and designing a test, not for claiming a stable rate.
A weekly maintenance routine
The working set will become a graveyard unless someone maintains it. A small team can reserve a short weekly review for three questions:
- What changed? Update current prices, policies, source links, contacts, or procedures when a known trigger occurs.
- What failed? Review decisions that needed correction, including cases where a record was hard to find or easy to misread.
- What can leave the working set? Supersede duplicates, archive completed projects, and remove material that no longer supports a current decision, subject to retention requirements.
Assign the review to named owners, not to “the team.” Record the next review date on each current rule. Where changes are frequent, use an event trigger as well: a marketplace policy change, a new product version, or a supplier term update can require review before the calendar date arrives.
The measure of success is not the number of records captured. It is whether a person can find the applicable evidence, understand its limits, and make a better decision. The next article will examine how to make trusted knowledge findable to both people and AI. Begin that work with a modest, well-labeled collection; search cannot repair a source whose meaning has been lost.