Trust Boundaries Around Your Source of Truth
Why Trust Boundaries Matter¶
A source of truth is powerful, but dangerous when treated as infallible.
Production reality:
- Inventory can lag real changes
- Device metadata can be incomplete
- Field operations may introduce temporary deviations
Blindly trusting stale intent can create outages faster than manual operations.
Three Trust Modes¶
Define trust mode per data field, not globally.
- Authoritative: must match exactly (for example serial, role)
- Advisory: used for defaults but validated against live state
- Observational: tracked for reporting only, never used to drive writes directly
Example policy:
- Serial: authoritative
- Site code: authoritative
- Interface descriptions: advisory
- Optional tags: observational
Reconciliation Pattern¶
Use explicit merge logic between intent and live state:
- Load source-of-truth intent
- Collect live state
- Classify differences by trust mode
- Block, warn, or annotate based on policy
- Generate plan only from reconciled state
Governance Controls¶
Minimum controls for trusted inventory use:
- Versioned inventory changes
- Peer review for critical metadata edits
- Change provenance (who, when, why)
- Drift dashboards for stale records
- SLA for metadata correction after incidents
Production Checklist¶
- Trust mode is defined per key field
- Authoritative fields block execution on mismatch
- Advisory fields require live confirmation before writes
- Reconciliation output is stored per run
- Inventory update workflow exists and is auditable
Anti-Patterns¶
- Treating all YAML fields as equally trusted
- Auto-patching inventory from live state during emergency runs
- Ignoring unknown fields or null values silently
- Allowing write workflows when critical metadata is missing