Continuous Stewardship Accountability

Continuous stewardship makes data-quality accountability durable: it separates responsibility types, turns recurring defects into evidence, and closes the learning loop.

In this lesson, you will learn to:

• Distinguish ownership, stewardship, custodianship, governance, platform enablement, and consumer responsibility
• Diagnose recurring defects as signals of unclear expectations, semantic conflict, misaligned incentives, or weak feedback loops
• Synthesize semantic, connected-context, operating-model, and quality evidence into a bounded stewardship agreement

Ask a room who owns data quality and someone will say “the business.” That answer has never fixed anything. The more useful question is narrower and more uncomfortable: when this figure is wrong next quarter, whose name is on it, who noticed, who fixed it, and who changed the expectation so it stops happening? Most organizations can answer only the third.

Treating all six as ownership is where stewardship agreements quietly fail. They work together, but they are not interchangeable:

One team can hold more than one of these at once. Platform enablement means providing the capabilities that make quality achievable across many assets; custodianship means operating and safeguarding one specific asset on an owner's behalf. The platform team often does both, which is exactly why the two still have to be named separately.

Notice what happens when one is vacant. The custodian, often the platform team, can absorb the gap because they are the only party technically able to act. They apply the correction, so they inherit the blame, without holding the authority to change the definition that caused it.

Marcus challenges the platform team’s role; Victoria uses the repeated correction to distinguish custodianship from ownership.

> **Marcus:** The platform team fixed the same discrepancy again last night. Third time. So platform owns this now, right? > > **Victoria:** They applied the correction. Did they decide what the number should have been? > > **Marcus:** No, they asked the service domain and got an answer. > > **Victoria:** Then they're custodians, not owners. Ownership sits with whoever can change the definition and answer for the figure. Right now nobody has been named, so the correction keeps landing on the only team who will pick it up. > > **Marcus:** And nobody's incentives change, so it happens again in six weeks.

The exchange makes the point: naming the responsibility type does the argumentative work that “we need better data quality” never does.

An identically recurring defect is more than a quality problem: its recurrence is a diagnostic signal that points to one of four underlying causes.

1. Unclear expectations: no tolerance, condition, or accountable party was agreed, so “fixed” means only “the number looks right today.”
2. Semantic conflict: two domains publish the same term under different meanings, so reconciliation cannot succeed.
3. Misaligned incentives: nothing in any domain’s objectives rewards reliability for someone else’s report.
4. Weak feedback loop: a fix is applied but never recorded, so the learning evaporates.

That last cause is best understood through the Continuous Stewardship Loop, in order:

1. Define expectations
2. Observe evidence
3. Assess impact
4. Assign accountable action
5. Communicate status
6. Capture learning
7. Refine expectations and responsibilities

Most teams run the first five steps competently and stop. Skipping capture and refine is precisely what converts a one-off defect into a permanent feature. When you see the same defect twice, ask which step the organization is not performing rather than which engineer was careless.

A bounded stewardship agreement is where this path converges. It carries four threads at once:

• Semantic thread: which meaning the domains converge on and what the term deliberately excludes
• Connected-context thread: the dependencies the figure sits inside, expressed as typed claims with a source, a currentness check, and residual uncertainty
• Operating-model thread: who owns, stewards, safeguards, governs, enables, and consumes
• Quality thread: the relevant dimension, expected condition, tolerance, and evidence that will show whether it is being met

A typed claim states a dependency as subject → predicate → object — for example, regulatory return → reports → service-domain active-customer count — and then records where the claim comes from (its source), when it was last confirmed to still hold (its currentness), and what remains unknown about it (its residual uncertainty).

Be honest about status. What you write is proposed until the named approvers sign it, so state your assumptions and name them. Build in a review trigger, because an agreement without a condition that forces re-examination is a snapshot, not a loop. A repeated identical discrepancy is an obvious trigger.

The takeaway is this: trust is not the absence of defects. It is the presence of a named party, an agreed meaning, and a loop that closes. Two quick checks come first to test whether the six responsibilities and recurrence patterns hold in your head, then a capstone writing task where you draft the bounded stewardship agreement itself. Before you start, ask yourself: if you cannot name who is allowed to change the definition, what exactly is anyone agreeing to?