Worked guide · Governed data change

Work a source change from detection to an accepted data product.

Follow one unexpected source change from detection to an accepted data product: an agent prepares the evidence, a business owner decides the meaning, and an independent path accepts the change.

Synthetic reference example. Every record, name and identifier here is invented. It shows the method applied end to end; it is not a client deployment or a measured result.

How this guide works

Ten parts, one workflow, the same identifiers throughout.

Each part answers one question a business owner, technical lead or control owner has to settle before the next commitment. Read it straight through, or jump to the part that matches the decision in front of you.

Part 1 of 10 · Decision and audience

Decide what a new claim status means, and whether consumers may rely on it.

Claims business ownerDecides what the new status means. Only this person can approve the meaning.
Data product ownerAnswers for the claim status product and its consumers.
Data engineerPrepares the versioned change and its tests.
Stewardship agentDetects, investigates and drafts. It cannot approve meaning or release.
Consumer ownersConfirm their reports, models and assistants recover.

Output of this guide: an accepted change package and a consumer recovery record.

Part 2 of 10 · Business baseline

Know how long changes take today, and who does the work.

Time from detection to accepted changeRecent source changes, from first alert to release[your baseline]
Total human effortOwner, steward, engineer and reviewer hours per change[your baseline]
Consumers affected and recoveredProducts and reports that consumed the field[your baseline]
Silent errorsChanges found by a consumer before the data team[your baseline]

Lines of generated code and closed tickets are activity counts. The outcome is consumers relying on the result again.

Part 3 of 10 · Scope and exclusions

One source, one field, one product.

In scope

  • The claims system’s status field and the claim status product built on it.
  • Direct consumers: the claims assistant, the operations dashboard and the reserve report.

Excluded

  • Changing the source system itself.
  • Consumers that cannot be identified from lineage. They are listed as a known gap, not assumed safe.

Part 4 of 10 · Prerequisites

What must exist for an agent to help safely.

A product contract listing the approved status codesAn unrecognized code can be detected instead of mapped by default.
Lineage from the field to its consumersImpact analysis is only as complete as the lineage behind it.
Expected results kept outside the generating pathGenerated code and generated tests can share the same mistake.
A named business owner for meaningThe agent can propose; it cannot decide.

Part 5 of 10 · Completed example

The status RO appears on a Tuesday.

An invented example. The claims system starts sending RO for reopened claims. The field is still two characters long, so the pipeline accepts every record.

Tuesday 08:10Validation flags RO as outside the contract; affected records are marked degraded, not mapped to closed.
Tuesday 08:40The stewardship agent assembles evidence: sample records, the source release note, lineage and the consumers affected.
Tuesday 11:00The agent drafts a proposed meaning and mapping, labeled as a proposal.
Wednesday 10:00The claims business owner approves: RO means reopened, open for reserve and preparation purposes.
Wednesday 15:00The engineer’s versioned change passes independent tests; the product owner releases version 3.1.
Thursday 09:00Consumer owners confirm recovery. The degraded flag is cleared for affected records.

Part 6 of 10 · Implementation path

From detection to release, with authority at each step.

  1. Detect. Contract validation finds the unknown code and restricts affected records.
  2. Investigate. The agent gathers evidence and impact. It has read access to metadata and samples, not to change anything.
  3. Propose. The agent drafts meaning, mapping and tests as a proposal tied to the evidence.
  4. Decide. The business owner approves or changes the meaning. The approval is recorded with the evidence it relied on.
  5. Implement and test. The engineer prepares the versioned change; independent expected results decide acceptance.
  6. Release and verify. The product owner releases; consumer owners confirm their results.

Part 7 of 10 · Failure cases

Where the process should stop.

The agent proposes RO means closedThe owner rejects it; nothing is released without an approved meaning.
Generated tests agree with a wrong mappingIndependent expected results fail the change.
Lineage misses a consumerThe consumer finds degraded records, not wrong ones; the gap is recorded.
The agent tries to edit its own success thresholdDenied; thresholds are owned outside the generating path.

Part 8 of 10 · Acceptance evidence

The evidence that accepts the change.

  • No unsupported status silently became a business fact.
  • The meaning approval names the owner and the evidence relied on.
  • Independent tests pass on reopened, closed and open claims, including a late event and a correction.
  • Critical consumer checks pass, and each consumer owner confirms recovery.
  • The change can be restricted and rolled back.

Part 9 of 10 · Operate and recover

What the stewardship agent does next time.

Operate

The agent’s scorecard tracks how often its proposals are accepted, changed or rejected. Rising rejection says its evidence or rules need attention.

Recover

Degraded records stay degraded until the accepted version is released. Consumers never receive a guessed value.

Part 10 of 10 · Economics and next commitment

Count all of the work, then decide whether to automate more.

Compare total elapsed time and total human effort, owner, steward, engineer and reviewer together, with the baseline from part 2. Faster preparation that adds review effort is not a saving.

Next commitment: extend the same pattern to a second source, or keep the agent at proposal-only authority if acceptance evidence is thin. A proposal-only agent can stay that way indefinitely.

Read next:

Next step

Bring the source change that keeps breaking your reports.

A free sixty-minute session with Richard to examine one workflow, what is blocking it and whether there is a useful next step.

Request a working sessionSee the data foundation offer