The three conditions
A reliable fact needs more than a populated field.
Ownership answers who repairs the record. Decay answers how the team expects the record to become stale. Contract discipline answers what another system may assume about it and what happens when that assumption fails.
These are connected. A contract without an owner leaves failure unresolved. An owner without a decay signal only discovers the problem when someone complains.
Name the fact the team needs to trust.
Name the role accountable for correction.
Name the signal that the fact may have changed.
Name what downstream work must do when the fact is absent or invalid.
Apply it
Turn a vague data complaint into an operating rule.
01
Choose one decision
Start with a field that changes a real action, not a generic request to clean the database.
02
Trace the source
Identify where the fact entered, who can correct it, and which system publishes it onward.
03
Design for change
Set the event, review, or expiry signal that tells the team the record may no longer be current.
04
Write the dependency
Specify what another system can rely on and how it should handle a missing, duplicate, or stale value.
Bring the report or field that everyone checks before they trust it.
We can trace its source, ownership, decay signal, and downstream dependency.
Bring the page, report, or workflow as it is now.
We reply with the clearest next step, or an honest no.
