Intent Drift

Intent drift is the divergence between declared intent and actual network state. It occurs when the operational configuration, performance metrics, or resource allocations no longer satisfy the service-level objectives (SLOs) specified in the original intent. Unlike hard failures, drift is often gradual and insidious—a slow degradation of latency, throughput, or security posture that accumulates until a threshold is breached. The assurance function detects this delta by continuously comparing streaming telemetry against the intent's desired state model.

Drift originates from multiple sources across the network stack:

• Configuration decay: Manual overrides or ad-hoc changes by operators that bypass the intent engine
• Resource exhaustion: Gradual memory leaks, CPU saturation, or buffer bloat that degrade performance without triggering hard alarms
• Environmental shifts: Changes in traffic patterns, user mobility, or interference that invalidate the assumptions under which the intent was originally fulfilled
• Software entropy: Firmware upgrades, patch installations, or vendor-specific optimizations that alter device behavior
• Policy conflicts: The activation of a competing intent whose resource demands silently degrade another intent's SLOs

The assurance function employs multiple techniques to identify drift:

• Threshold-based monitoring: Comparing real-time telemetry against hard SLO boundaries—e.g., latency exceeding 10ms triggers a violation event
• Predictive anomaly detection: Machine learning models trained on historical telemetry that forecast drift before it breaches thresholds, using time-series forecasting and statistical process control
• Configuration reconciliation: Periodic audits that compare the running configuration of every device against the golden configuration synthesized by the intent engine
• Semantic validation: Checking that the meaning of the network state—not just its syntax—aligns with the business intent, often using formal verification methods

These terms represent distinct concepts in the assurance taxonomy:

• Drift: A deviation from intent that may not yet breach an SLO—a warning state indicating the network is trending away from the desired state
• Violation: A confirmed breach of a specific SLO—the network has crossed a defined threshold and is no longer compliant
• Failure: A hard outage or complete loss of service—the intent cannot be fulfilled at all Drift is the leading indicator; effective closed-loop systems remediate at the drift stage before violations or failures occur.

Upon detecting drift, the closed-loop system executes a remediation workflow:

• Root cause analysis: Correlating telemetry anomalies with recent configuration changes, resource utilization spikes, or external events to identify the drift source
• Corrective synthesis: The intent engine recalculates the necessary configuration changes to restore compliance—this may involve re-optimizing resource allocations, rerouting traffic, or rolling back unauthorized changes
• Safe actuation: Applying corrections through staged rollouts with pre- and post-validation checks to prevent remediation from causing cascading instability
• Verification loop: After actuation, the assurance function re-validates telemetry to confirm the drift has been resolved and the intent is once again fulfilled

Not all drift requires immediate remediation. IBN systems define a drift budget—the acceptable margin of deviation before corrective action is triggered. This prevents remediation thrashing where minor, transient fluctuations cause constant reconfiguration. The drift budget is typically expressed as:

• Percentage deviation: e.g., latency may drift up to 15% above the SLO before triggering remediation
• Time-weighted threshold: e.g., drift must persist for 30 seconds before being classified as a violation
• Business-impact weighting: Drift affecting critical slices or premium tenants triggers faster remediation than drift in best-effort segments