Staying true

Every model you have seen was right once.

The CMDB was accurate the week it went live. The architecture diagram was correct at review. The data catalog was complete at handover. Then the organisation moved, and nothing in any of them noticed. If you are wondering whether this ends the same way, that is the right question to be asking.

The CMDB

accurate the week it went live

The architecture diagram

correct at review

The data catalog

complete at handover

The failure mode

Born obsolete, and it only looks fine for a while.

Everyone selling intelligence offers you a single source of truth. The only source of truth is reality. Every model, catalog and register — ours included — is a copy of it, and a copy with no mechanism for following reality as it moves is not going to go stale eventually, it is born obsolete, and only looks fine because the gap takes a while to show.

A model nobody can change calcifies; a model anybody can change decays.

nobody can change it

calcifies

Lock it down behind a governance board and it becomes a document about the organisation as it was in March.

anybody can change it

decays

Open it to everyone and it becomes a wiki with types — the same contradictions as before, now with a schema.

~1 year

The trap is that both failures look like success for about a year. Calcification looks like stability. Decay looks like adoption.

Which points at what the problem actually is. Decay is not a data problem. It is an accountability-routing problem.

The organisation always knew the thing had changed — somebody knew. Nothing carried that knowledge to the model, and nobody was asked.

Half the model

What is read from a system cannot drift from that system.

A large part of your model is not authored at all. It is read — from the catalog you already curated, from the HR system, from the identity provider, from the schemas themselves. Those nodes do not go stale, because nobody is maintaining a second copy that could fall behind. They are the current state of the source, typed.

And when something disappears from the source, that is not silence. The node moves to Missing from Source — a status in the Inactive family. It is not merely flagged: it is demoted, and every traversal that runs through it now says so.

This is the cheap half of the answer, and it is worth being clear that it is the cheap half. It covers systems, datasets, people and access. It does not cover what only a person knows.

The other half

The rest has an owner. And the owner gets asked.

Every node type carries its own responsibility matrix — who owns it, who stewards it, who approves a change, who is the expert. Not a convention some team follows. Part of the type, so a node of that type cannot exist without the question of who answers for it having been settled.

On top of that sit use cases with their own workflows: what "review this", "hand this over" or "approve this change" actually means for that kind of thing. Reviewing a supplier agreement is not the same act as reviewing a technical skill, and the model knows the difference.

So when something moves, the people who answer for it are engaged — by the workflow that fits, not by a notification. Four things start that:

A source changed

The system of record no longer says what the model says.

reaction

Somebody proposed a change

A governed proposal, with an audit trail — not an edit.

reaction

A lifecycle state moved

A node entering Under Review or Deactivation in Progress pulls its dependents in with it.

reaction

A periodic check came due

Nothing moved, and that is the point: silence is not evidence.

the model asking

The fourth one is the one that separates this from every catalog you have used. The others are reactions. That one is the model asking whether it is still true, of the only party who can answer.

Something moves, or a check comes due

The responsibility matrix says who answers

The use case's workflow puts the right question to them

The answer becomes a state change, with its trail

Metamodel

Data Product

Responsibility Types

Assign Responsibility Type

Owner

Is Owned By

The party with ultimate accountability for the node and full authority over every decision about it. Answers for its existence, correctness, and fate end-to-end.

Steward

Is Stewarded By

The party accountable for curating the node’s business meaning and data quality on a day-to-day basis. Maintains its definition, accuracy, and fitness for use, but holds no ultimate decision authority over it.

Approver

Is Approved By

The party holding the authority to formally sign off the node, or changes to it, so that it becomes valid or released. Accountable for the gating decision itself, distinct from ongoing assessment or end-to-end accountability.

Subject Matter Expert

Expertise Is Provided By

The person designated to provide clarification on the subject the node represents, relied upon for deep, first-hand knowledge of it. Supplies the context and insight that the node’s records and documentation do not capture — an advisory authority on the subject itself, not on how the node is maintained.

the responsibility matrix on a node type — owner, steward, approver, expert

None of that is the agent changing your organisation. It identifies, reports, monitors and escalates — autonomy of attention, not of authority. A person still decides. What changed is that the decision reaches them while it is still cheap.

Absence, made visible

Missing is a state you can see, not an empty field.

Models rot quietly because absence looks like nothing. A blank owner, an unwritten boundary, a node whose source vanished — none of them raise their hand. The same principle runs through three places here, and it is the same principle each time.

Assigned · not yet Informed

A responsibility that was handed out and never communicated. Not a blank field — a rung on a ladder the model can see you standing on.

Missing from Source

A status in the Inactive family. The node is demoted, not annotated.

Certified Bronze · Silver · Gold

In the Active family. Verification is a way of being current — and its absence is equally legible.

Which makes the health of the model a traversal like any other. Not a maturity report somebody assembles once a quarter: a question you ask the same graph, with the same syntax you use for everything else.

What this does not fix

Nothing here models what was never modelled.

the loop's boundary

If an ability, an obligation or a dependency was never typed, no amount of routing will surface it. The loop keeps true what is in the model. It does not discover what is outside it.

the read half's boundary

A node read from a system stays true to that system. If the system is wrong, the model is faithfully wrong. What the model adds is that the disagreement between two systems becomes visible, because both are typed into the same graph.

Which is why coverage grows by decision, not by ambition. You extend the model where being wrong would cost you something — and everything you extended stays true by the same mechanism as everything before it.

Check it yourself

Everything above is checkable without talking to us.

The lifecycle families, the responsibility matrix on a type, a responsibility sitting at Assigned that nobody was ever told about — they are in a demo tenant with Adventure Works fully modelled. The same organisation you have been reading about.

without us

Go and check it.

Open the demo

with us

Or model your own.

The Design Partner Program is for organisations that want their own model built alongside our team, before general availability.

Design Partner Program →

One of those takes two minutes and does not involve us. Start there.