In practice
To test whether any of this holds, we built a small world: a managed-services provider, a starting model of seven entity types, and seventeen observations drawn from the messy places real organizations keep their truth — a signed contract, support tickets, an invoice, a line in a chat channel.
The prototype was given one objective sentence and the contracts — no domain rulebook. For every observation it asks the same thing: can this new reality already be represented coherently by what we understand?
Observation 1 · identity
“Meridian Sàrl” from the CRM, “MERIDIAN” from ticketing, “Meridian S.a.r.l.” from the invoice — all resolved to a single Client, each source still attached. The ticket's requester email resolved to a Person already in the model, Camille Roth, rather than a second copy of her.
Observations 2–12 · reuse before novelty
Most of the stream introduced things the model could already hold. A firewall became an Asset; the contract's SLA became a ServiceContract; the new supplier Novatek became a Vendor. No entity was minted just because a source system had a table for it.
Two observations genuinely needed the model to grow. Apollo — a budgeted, multi-phase engagement — earned a proposed new Project entity, with its own lifecycle. Recurring maintenance windows earned a MaintenanceWindow. Growth happened where reality demanded it, and only there.
Observation 13 · consistency
The signed contract guaranteed a four-hour response on critical incidents. The ticketing system was configured for eight. Ontheia kept both — a contradiction with both provenances, never flattened into one answer — and then did something a field-by-field diff can't: it followed the relationships out to what the gap actually costs.
Observations 14–17 · the loop closes
Given the intent “resolve Meridian's SLA breach risk,” the prototype composed a surface for exactly that moment: the contradiction, the breach-exposure facts each carrying its source, and a single authorized action. The action ran under capability control against the service-management system. Its result came back as a new observation, reconciled — and the open contradiction closed.
The full history stays reconstructible: every candidate, every source, and the resolving action are retained. The loop from the mechanism page ran end to end, on this evidence.
The honest part
Across a golden set of nine paired reconciliations — cases with a known better and worse answer — this run scored eight. Publishing the ninth is the same discipline the system practices on evidence: don't quietly flatten the thing that disagrees with the story you'd rather tell.
On the single thin line “Apollo should be paused until Q4”, the prototype proposed creating the Project entity right away, instead of waiting for the corroborating email a step later. On this evidence, restraint was the more coherent move — and the model even hedged in its own note, flagging the proposal for confirmation. This points straight at an open question: how much evidence should novelty require before the model grows?
A new supplier, Novatek, arrived twice inside two minutes — an email at 10:00, an invoice at 10:02 — before governance had applied the first proposal. With the pending-proposal overlay off, the invoice couldn't see the not-yet-applied Novatek and proposed a second one. With it on, the invoice attached to the pending proposal instead.
This is a proof-of-concept run on a constructed evidence stream — eight of nine golden reconciliations, with the failures shown above — not a production deployment. What it demonstrates is that a small model and minimal instruction are enough to reconcile heterogeneous evidence into a coherent, living picture, and act on it. The gaps it surfaces are the next questions, not surprises.
Where it stands
The prototype, the seed model, and this evidence stream are on GitHub, where the ideas get tested against cases like this one. Read how the loop works, or what coherence means and why the ninth case matters.
Read the prototype on GitHub