Owner, Classification, Expiry

The end state to avoid

An organization several years into this has four hundred data products. Two hundred and fifty have no identifiable owner. Nobody can turn any of them off, because nobody can prove nothing depends on them. Each costs money, each is a potential source of a wrong number, and collectively they are why the next platform migration takes two years.

Nobody decided this. It is what happens by default when every product is created and none is retired.

You have already built most of the defense: a named consumer, an owned definition, an acceptance test, retirement conditions from Lesson 1.4. This lesson makes it survive you.

Prompt first: write the record that outlives you

Draft the stewardship record for this data product [paste definition,
consumers, acceptance test, and my notes from profiling].

Include: owner as a ROLE with current holder separate, technical
maintainer, classification with any grain-specific rulings, consumers
of record, upstream dependencies, review cadence, expiry date, and
retire-if conditions.

For KNOWN QUIRKS, pull every data defect and surprise from my
profiling notes - the misleading names, unusable periods, and
identifier anomalies. Do not summarize them; whoever inherits this
needs the specifics.

“Do not summarize them” matters. An agent will compress a quirks list into something tidy like “some data quality issues exist in historical periods,” which is worthless to the person who inherits it. The value is entirely in the specifics: which column, which months, how many extra identifiers.

The stewardship record

One block per data product, versioned alongside the definition:

STEWARDSHIP - circuit_monthly

OWNER            Distribution Planning Supervisor (role, not person)
CURRENT HOLDER   [name], since 2026-08
TECHNICAL        Grid Analytics team
CLASSIFICATION   internal; segment-grain variants restricted -
                 see the ruling of 2026-09-08
CONSUMERS        crew-assignment report (primary), rate analysis
                 workbook, exec reliability tile
DEPENDS ON       circuit_faults, circuit_master (curated)
REVIEW           annually, each August
EXPIRES          2027-08-01 unless renewed
RETIRE IF        Monday crew-assignment meeting stops using it; or
                 the outage system is replaced (planned 2028)
KNOWN QUIRKS     fault_duration source column is SECONDS despite its
                 name; 2021-03..05 unusable (source migration);
                 257 decommissioned circuits present in history

Two lines deserve attention.

OWNER is a role, with the holder recorded separately. People move. A record naming a person is stale the day they change jobs, and a record naming a role survives with a one-line update.

KNOWN QUIRKS is where Module 2’s findings finally live. The misleading column name, the unusable period, the extra identifiers — everything you found that was not yours to fix. That list is the single highest-value paragraph for whoever inherits this, and it exists nowhere else. Without it they will rediscover each quirk the expensive way.

Expiry is the mechanism that works

Review dates get skipped. Expiry dates force a decision, because something stops.

The pattern: every product carries an expiry, typically a year out. Ninety days before, the owner is asked one question — is this still used for the decision it was built for? Renewing is a two-minute confirmation. Not answering means it retires.

Keep, hand back, or retire

At review, three options:

Keep it. Still used, still yours to run. Confirm the owner, refresh the quirks list, set the next expiry.

Hand it back to the platform team. The right move when a product has become infrastructure — several teams depend on it, it needs the same reliability as the platform’s own tables, and the domain judgment that made it hard is now settled and written down. Handing back means transferring the definition, the acceptance test, the stewardship record, and the quirks list. Handing back a table with none of those is not a transfer; it is abandonment with extra steps.

Retire it. The decision it served is no longer made, or the consumer moved on, or Lesson 6.2’s cost comparison came out badly.

Retirement that finds the unknown consumer

Never delete. Run the same play as a breaking change in Lesson 5.2, because the risk is identical — a consumer you cannot name:

1. Announce to consumers of record, with a date.
2. Stop refreshing, leaving the last data in place with a clear stale marker. Anyone still reading it sees stale data and complains — and that complaint is the point. It is how you find the consumer who was never on your list.
3. Wait through at least one full decision cycle, and a quarter if the product feeds anything periodic.
4. Archive the final state, the definition, and the stewardship record.
5. Then remove it.

Step 2 does the work. A product switched off without that step produces its complaint three months later, from someone whose quarterly report just broke, and by then the context is gone.

Key takeaway

Write the stewardship record so the product survives everyone who built it: owner as a role with the holder tracked separately, consumers of record, dependencies, and — most valuable of all — the known quirks that Module 2 found and nobody else will ever rediscover cheaply. Use expiry rather than review dates, because expiry forces a decision while a review date gets skipped, and default to retire rather than renew. At review, keep it, hand it back to the platform team with its definition and quirks list, or retire it. And retire by stopping the refresh with a visible stale marker rather than deleting — the complaint that follows is how you find the consumer nobody knew about.

LEADERSHIP DECISION   require an owner role, a classification, and an
                      expiry on every data product, and back the review
                      that actually retires things
PRACTITIONER ACTION   record owner-as-role, consumers, dependencies, and
                      specific known quirks; retire by stopping refresh
                      with a stale marker, never by deleting
SUCCESS MEASURE       zero data products without a named owner role and
                      an expiry; every retirement completed without an
                      unknown consumer discovered after removal