Truth Layer Operating Model

File-backed wiki page. Edit the content here; keep Business Truth separate and use the wiki for practical, reusable memory.

View Page

Title

Summary

Status

Validation

Tags

Sources

Body

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.

File: truth-layer-operating-model.md • Updated 2026-05-05 16:41