A source becomes authoritative only when the system reliably routes writers, readers, indexes, and agents to it. Naming one file “canonical” does not stop stale copies, outdated links, generated summaries, or cached instructions from winning in practice. Source-of-truth design therefore needs ownership, discovery, precedence, freshness, and repair—not just a document with a confident title.
Why does canonical content still drift?
Most teams do not have a single-context problem. They have a context graph:
- a governing decision;
- product documentation;
- implementation comments;
- API schemas;
- generated indexes;
- agent instruction files;
- marketing pages;
- old branches and copied plans.
Even when one node is declared authoritative, another node may be easier to find or loaded earlier. The stale copy then becomes operational truth while the canonical source remains technically correct and practically ignored.
For AI agents, this is especially dangerous. A mandatory stale instruction is repeated with confidence because the agent is behaving correctly relative to the context it received.
What must a routing contract answer?
A working source-of-truth system answers five questions:
- Ownership: Which source is allowed to define this claim or contract?
- Discovery: How does a human or agent find that source from the task at hand?
- Precedence: What happens when two sources disagree?
- Freshness: How can a reader tell whether the source still matches current state?
- Propagation: Which dependent surfaces must be regenerated or reviewed after a change?
Without those answers, “single source of truth” usually means “one more source in the pile.”
Why is duplication not always the real defect?
Duplication can be useful. A quickstart, SDK example, integration guide, and API schema may need different presentations of the same contract. The defect appears when those copies can change independently without a route back to authority.
Healthy derived content has lineage:
- the owner is named;
- the derived surface links back to it;
- generation or review is repeatable;
- contradictory wording fails a gate or creates a visible review task;
- superseded copies stop presenting themselves as current.
The goal is not zero repetition. It is governed repetition.
How should authority travel with context?
Content is more useful when it carries evidence about where it came from and when it applied. A retrieved sentence without lineage forces the receiving agent to guess whether it is policy, preference, historical fact, or an unreviewed draft.
The Northsun (formerly Mnemix) repository includes an evidence_refs substrate for provenance, lineage, source priority, hashes, and temporal metadata. That substrate is not a direct public REST resource, and its existence does not mean every current caller-memory response exposes evidence references. It does illustrate a durable principle: retrieval and authority are different concerns.
A content hash can show that referenced material changed. It cannot prove the material was true. A source priority can inform a precedence decision. It cannot resolve every conflict without an explicit policy.
What is a practical routing pattern for agent instructions?
Start with the task, not the file tree:
- Classify the request by product and subsystem.
- Route to the governing decision or contract for that class.
- Load the current implementation or deployed evidence needed to verify it.
- Treat summaries and generated indexes as discovery aids, not automatic authority.
- When a conflict appears, repair the owner and every route that selected the stale source.
- Record which authority and version produced the result.
This prevents a common partial fix: correcting one sentence while leaving startup instructions, indexes, or links pointed at its stale predecessor.
How do you test a source-of-truth claim?
Use a routing falsifier. Introduce a controlled contradiction in a non-authoritative fixture and ask whether the system still selects the canonical value. Then move or rename the authoritative source and verify that discovery fails visibly rather than falling back to an old copy.
Useful checks include:
- broken-link detection for mandatory sources;
- stale-reference scans after renames;
- generated-index freshness checks;
- precedence tests with conflicting fixtures;
- exact-version receipts for reviews and releases;
- searches for retired claim language across public surfaces.
The system should fail loudly when authority cannot be found. Silent fallback is how old truth becomes new behavior.
How does this relate to Northsun?
Northsun is the memory and enrichment layer for AI agents. Governed context intelligence is the differentiator: the system should help applications distinguish available information from context that is eligible, current, and appropriate to serve.
Today, the frozen caller REST API defines a callable workflow. The hosted MCP endpoint and source-defined tools also exist, while a complete authenticated production MCP lifecycle still requires fresh release proof. The richer provenance and policy pages describe a mixture of current contracts, repository substrate, and governed design. Each page labels that boundary; none should be read as evidence for a public endpoint absent from the API reference.
A source-first repair checklist
When you find contradictory context:
- identify the authority for the claim class;
- verify it against current code or deployed evidence where state can drift;
- update the owner before editing derivatives;
- mark old material as superseded or remove its routing role;
- refresh indexes, navigation, prompts, and generated surfaces;
- search again for the retired wording;
- bind the repair to a version and a falsifier.
This turns “we have one source of truth” into a behavior the system can demonstrate.
What should you read next?
Read Evidence references for the repository's provenance substrate and its public boundary. Continue with Bi-temporal validity to separate when information was true from when the system learned or corrected it.