Truth Layer Operating Model

The right shape is not one giant wiki and not a pretend full copy of Monolith. It is a layered overlay designed for fast routing, controlled drill-down, and explicit freshness boundaries.

Fractal structure

• Level 1: Business Truth for compact cross-cutting rules, principles, and guardrails.
• Level 2A: Index pages in the Business Wiki that say what exists, where it lives, who owns it, and what its caveats are.
• Level 2B: Topic pages under those indexes for practical interpretation, recurring caveats, relationship notes, and operational patterns.
• Level 2C: Dated operational truth packs for recent contextual subsets such as customers, suppliers, contacts, and metrics.
• Level 3: Live deeper work against the system when the question needs current state, full coverage, or transaction-level certainty.

Design rules

• Keep the overlay above Monolith. Do not mirror Monolith tables or try to make the wiki into a hidden second database.
• Each layer should declare what it is for, how fresh it is, and what it excludes.
• Index pages should be clear-cut and sparse. Topic pages can be more organic, but they should still sit under an obvious parent topic.
• Dated packs should be intentionally subsetted to business-relevant records, not treated as complete population dumps by default.
• Instant mode should usually hit the smallest layer that can answer safely, then stop.

Contact profile model

• Build contact understanding as a composed profile, not a single canonical record pretending to be perfect.
• Separate stable identity facts from recent activity context.
• Prefer explicit evidence strands:
• identity and directory context
• linked customer or supplier context
• recent operational activity
• known caveats or ambiguity
• If different strands disagree, surface the disagreement rather than flattening it away.

Freshness and discrepancy rules

• A mismatch between the overlay and the live system can mean either:
• the overlay is out of date
• the overlay intentionally carries only the most relevant subset
• both are true
• Every dated pack should say when it was generated, what window it covers, and what inclusion rule it used.
• Wiki pages should state whether they are stable guidance, human-reviewed interpretation, or a working draft.
• If a question depends on omitted records, latest live state, or full financial/operational coverage, it should escalate to deeper system work.

Update process

• Business Truth changes should be deliberate and rare.
• Wiki updates should be additive, ordered, and attached to clear page ownership or at least a clear topic parent.
• Dated packs should be regenerated on schedule with a manifest that records generation time, source scope, and row counts.
• Instant-review learnings can sharpen prompts and routing rules, but should not silently rewrite the canonical truth layers.
• Avoid orphaned notes by either linking a new page from an index page or not creating it at all.

What good looks like

• A user can start from a short answer and then drill down one layer at a time.
• Instant mode can say what evidence tier it used.
• The business can see why a result may differ from full Monolith data.
• Useful subsets stay fast and readable.
• The system does not accumulate unordered memory sludge.