Responsibility effectiveness
Every critical asset in your catalog has an owner, a steward and an approver. The names are filled in. The workflows still route to them. The question this page is about is the one the catalog cannot answer: if that asset needs a decision today, can the person named on it actually act?
What effective means
Assignment is a record. Effectiveness is a state, and it has three conditions — all of them true at the same time, today:
01
Active
02
Authorised
03
Able to act
Miss any one and nothing breaks visibly. The asset still shows an owner. The workflow still routes. The failure surfaces weeks later, as a review that timed out and a decision nobody made.
Which is why, in our model, a responsibility is never simply present or absent:
Being assigned is the second of those four, not the last. A catalog field records the second step and implies the fourth.
Today · invisible
AdventureWorks2025 — HumanResources data product, in use across HR operations, payroll and workforce planning. Four roles answer for it. Every one of them is filled in, and the catalog shows no problem.
Owner · and approver
Hedda M Halvorsen
departed · both roles left with her
Steward
Mindy C Martin
mandate not revalidated since May 2024
Subject matter expert
Lakshmi A Venkatesan
on leave · no cover
Subject matter expert
Ashok X Joshi
assigned · never informed
Four different failures, and not one of them is missing data. Every name was correct when it was written. Nothing is blocked, and that is the problem — the asset is routed to someone who left, to someone whose mandate expired, to someone who is away, and to someone who was never told. Any decision that needs one of these four has nowhere to land, and nothing anywhere says so.
Notice what one departure did. Hedda held two of the four roles — which is normal, because the person who owns an asset is usually the one who approves changes to it. When she left, half the governance of this product left with her — and the asset still names her in both roles, so anything needing either one still routes to someone who is gone.
The second expert is the one worth pausing on. Ashok is employed, authorised, and holds the access. Nothing in any system is out of date. He simply was never informed that this asset routes to him when the other expert is away — and no report anywhere is capable of showing that.
This is what governance decay looks like from the inside: not an empty field, but a full one that stopped being true.
Why the catalog can't see it
In a catalog · an attribute
Text on an asset, pointing at a person the asset knows nothing about. Their employment, their area, their entitlements live in three other systems, and the field has no way to ask them anything.
A field cannot be wrong, because a field cannot be checked.
In Nodwise · a typed relationship
Between two nodes that both exist in the same model — the asset and the person. And it is not configured per asset: every node type carries its own responsibility matrix, so a node is born knowing which roles answer for it, and who currently fills them resolves through the graph.
That matrix declares, per role, what is expected of whoever holds it and what qualifies someone to hold it. So "data owner" is not a job title borrowed from a policy document — it is a defined set of expectations and a defined bar, written once and inherited by every node of that type.
Which means the three conditions stop being an audit exercise and become a traversal:
Department
Human Resources
Person
Hedda M Halvorsen
Person
Mindy C Martin
Person
Ashok X Joshi
Enterprise Role
Human Resources Manager
Enterprise Role
Benefits Specialist
Enterprise Role
Recruiter
Data Product
HumanResources data product
Three questions the catalog can only ask a human, answered by walking the model.
The loop
Once responsibility is a relationship, an ineffective one is a condition an agent can watch for. What follows is not a report you have to read.
01
Detected
02
Routed to someone who can decide
03
Decided by a person
04
Recorded
And the same loop runs before the gap opens — by default, not as something you configure. A responsibility has a status of its own, so it can be stood down without being erased: when someone changes area, goes on leave or resigns from a duty, the responsibilities they carry leave the effective state and the question reaches them while they still have the context to answer it, rather than reaching their former team six months later.
Which also gives the honest version of the question this page opens with. Not "is there an owner" but when was this last confirmed to be true — a date, per responsibility, that either exists or does not.
The agent watches and escalates. It never decides. Autonomy of attention, not of authority.
What this normally costs
Done as a project, cleaning up ineffective responsibilities in a mature catalog runs in eight phases: identify the inactive holders, associate each case with a manager, group them into one view per leader, notify with context and a deadline, run a traceable replacement workflow, onboard the new holders, certify the ones whose area changed, and finally find the flows that depend on a single person.
It is competent work, and it is the reason this problem is usually postponed: it takes months, it needs three source systems reconciled by hand, and the result is accurate on the day it is delivered.
Each of those phases is a query or a workflow against a model that already holds the answer. Not because the work is trivial, but because the reconciliation the programme spends most of its time on is what the model is.
Ask the harder question
The demo tenant has the asset, the four roles, the broken conditions and the query that flags them — in a model you can open now.