Begin with a fact type, not a tool
A CRM can own opportunity stage while the signed agreement owns notice terms and the billing system owns the approved rate. Declaring the CRM the single source of truth would be accurate for one field and dangerous for the other two.
Write a real question such as, “Can this customer receive the old rate next month?” Then list the facts the answer requires: contract version, current rate, effective date, approved exception, and account identity. Assign authority to each fact rather than to the whole application.
This method also exposes missing ownership. If no role can decide which exception record governs, the knowledge project has found a process problem that retrieval cannot solve.
Build a source-authority register the system can use
The register should be small enough for business owners to review and specific enough for retrieval to enforce. Conditions may include client, country, contract type, business unit, date, workflow status, or record version. Keep those conditions with the retrieved evidence.
Freshness is part of authority. A policy page can be the approved source and still be unsafe after its review deadline. A live operational field may be current but lack authority to change a contractual term.
| Register field | Question it answers | Example |
|---|---|---|
| Fact type | What exact claim is governed? | Approved bill rate |
| Primary source | Which record owns it? | Executed rate schedule |
| Owner | Who resolves ambiguity? | Commercial operations lead |
| Scope | When does this source govern? | Client, country, and effective period |
| Freshness | When must it be reviewed or replaced? | On amendment or contract renewal |
| Fallback | What happens when evidence is missing? | Stop the quote and request owner review |
Make source conflict visible work
When approved records disagree, relevance scoring is not a policy. The newest document may be a draft. The signed document may have been superseded by a later amendment. The system should show the competing claims, their status, and the named owner rather than average them into one answer.
Pause any action whose safety depends on the disputed fact. The owner can confirm which record governs, correct the source, and state whether the decision applies only to this case or changes the general rule. Keep the resolution beside the conflict event.
NIST's AI Risk Management Framework places governance and context before measurement and management. A source register is one practical way to make that context operable for retrieval and review.
Keep authority aligned with the live process
Assign a review trigger to the register itself. New products, contract templates, markets, workflow states, and system migrations can change which record should govern. A quarterly calendar review may help, but process events usually reveal the change sooner.
Track conflicts, missing owners, stale sources, and questions that repeatedly need manual interpretation. Those events show where the map is weak. They also prevent the team from treating a quiet index as evidence that company knowledge is healthy.
Use the separate knowledge-base freshness guide to connect source edits, deletions, permission changes, and verification to this authority map.
Sources and verification
Primary product, architecture, risk, and security sources checked on 29 August 2026. Product behavior can change, so verify current plan and admin documentation before implementation.