Decision record: when master system is no longer trustworthy
Master systems are expected to act as sources of truth. When their behavior becomes inconsistent or ungoverned, the risk is not only local — it propagates through every integration point.
Symptoms of erosion
- Data contracts break without warning, e.g. mutated primary keys
- Sensitive fields appear without governance or notice
- Downstream systems apply compensations for upstream anomalies
- Production exposes invalid assumptions about identity or consistency
Why trust matters
Trust in master systems depends on a few core invariants:
- Identities remain stable
- Keys are immutable unless versioned
- Data semantics are consistent across consumers
When these break, silent faults spread across systems. The damage is architectural, not just operational.
Decision summary
- Master system is now treated as a semi-trusted input
- Validation boundaries are introduced at first point of integration
- Responsibility for divergence risk is formally assigned to the master system team
- Downstream systems are authorized to enforce safeguards, including record quarantine
Consequences
- All integrations must apply validation explicitly
- Operational cost rises, but resilience improves
- Divergence risk becomes visible in incident reporting
- Shift in team posture: trust must be earned, even by official systems
Defensive patterns
- Contract versioning: integrations declare and enforce the version they support
- Trust window compression: reduce cache time from master systems
- Anomaly fencing: isolate records that fail validation instead of passing them silently