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
Key Takeaway¶
A reliable source of truth is not just a database. It is a governance model that defines what must be trusted, what must be validated, and what must never directly drive production writes.
Continue the Series¶
- Series Index: Production-Grade Network Automation Principles
- Previous: Part 2 - Pre-Flight Checks: Failing Fast Before Making Changes
- Next: Part 4 - Detecting and Handling Configuration Drift Safely
Need help applying this in a live Cisco environment?
This guide is part of the Nautomation Prime Foundation and stays free to read, share, and reuse. If you want the pattern implemented, governed, or adapted for your estate, that is paid engineering work — start a discovery conversation or review how Nautomation Prime delivers engagements. If you are a registered UK charity or CIC, there is a free and low-cost route instead.