This article is divided into three parts. Be sure to read the first and second parts in a separate article.
I also recommend reading this in your browser, as some email services like Gmail may clip it due to its length.
7. Designing atomic deployments and rollbacks for state consistency
So far, we’ve mostly talked about detecting inconsistent states.
But a huge amount of inconsistency is created by the way we apply change in the first place. If your deployment model is “spray some CLI here and there and hope for the best”, you’re basically manufacturing drift as a service.
The antidote is to treat network changes the way serious software systems treat database transactions:
Either the change happens as a coherent unit, or it doesn’t happen at all.
No half-applied policies. No “I’ll come back to that other POP later”. No mystery boxes stuck in-between.
That’s what atomic deployments and rollbacks are about.
7.1. Why piecemeal changes are a drift factory
Traditional network operations grew up on the CLI:
You SSH into one router and paste a few lines.
Then to another, paste a slightly different variant.
Someone else does the same in a different time zone.
In total, you “rolled out the change.”
It’s easy to see how this goes wrong:
You forget one device in scope.
You mistype a policy name on a single box.
You run out of maintenance window halfway through and stop at 70% coverage.
A connection dies mid-paste; half the stanza is applied, while the other half is not.
From the network’s perspective, you’ve created multiple versions of reality:
Some devices have the new policy.
Some have the old one.
Some have a hybrid of both.
At a small scale, you can sometimes get away with this because traffic doesn’t always hit the “weird” devices. At hyperscale:
There is always traffic hitting the weird devices.
There is always a change in-flight somewhere.
The chance of “some nodes are partially updated” is essentially 1.
If you design deployments as a series of ad-hoc, per-device edits, inconsistent state isn’t an edge case. It’s an inevitable outcome.
7.2. Atomic deployment principle #1: changes are units of intent
The first shift is conceptual: instead of thinking in terms of “lines of config”, you think in terms of units of intent:
“Add this customer with these prefixes and these policies to all relevant PEs.”
“Change the export policy for Transit X globally from v12 to v13.”
“Move this fabric from hashing on L3-only to L3+L4.”
Each of these becomes:
A versioned object in your source-of-truth (“policy v12”, “policy v13”).
A renderable configuration block (or set of blocks) for all affected devices.
A scoped rollout plan (which devices, in what order, with what gates).
You don’t sprinkle bits of policy around. You:
Compute the complete before/after diff for every device in scope.
Treat “apply v13” as a single logical operation, even if it touches hundreds of nodes.
This is the foundation for atomicity: you change concepts, not random config fragments.
7.3. Atomic deployment principle #2: full candidates, transactional commits
Once you have a unit of intent, the next step is to render full candidate configurations and commit them as a whole wherever possible.
On platforms with transactional semantics (Junos, IOS XR, modern NOSes), you can:
Build a candidate configuration that includes all relevant changes for that device.
Run validation checks (syntax, referential integrity, sometimes even policy sanity) on the candidate.
Commit the entire thing in one shot, with the ability to rollback to the previous commit if something breaks.
The key is what you don’t do:
You don’t send a sequence of imperative commands and hope that midway errors don’t leave you in a weird state.
You don’t rely on human memory to ensure all dependencies are applied in the proper order.
Instead, for each device:
You construct a complete view of the desired config for this change (intent + existing state).
You send that as a candidate.
You commit or reject it as a single operation.
If the commit fails, the device stays at version N. If it succeeds, the device moves to version N+1. There is no “N-and-a-half”.
At the fleet level, you then layer this with controlled rollout:
Batch devices by POP, region, or role.
Commit candidates per batch.
Combine with the consistency checks we discussed earlier (canaries, validation gates).
7.4. When the platform doesn’t support transactions: simulating atomicity
Of course, not every platform is as friendly as we’d like:
Some NOSes don’t have a true candidate/commit model.
Some only support partial rollback, or rollback with side effects.
Some older devices barely have an API; you’re still pushing CLI under the hood.
In those environments, your deployment architecture has to simulate atomicity:
Pre-stage configs:
Generate the full target config or config block for the device.
Upload it out-of-band (e.g., as a file or staged snippet) without activating it yet.
Guarded apply:
Apply the new config in a way that is as single-shot as the platform allows (e.g.,
configure replace, import a profile, apply a saved config).Validate immediately after apply:
Check that all expected lines are present.
Check that key sessions (BGP/IGP) are up.
Check that RIB/FIB state matches expectations for a small set of prefixes.
Auto-rollback on mismatch:
If any of the post-apply validations fail, revert to the staged “last known good” config.
If automatic revert isn’t supported, programmatically undo the changes using a precomputed diff.
Cordon devices on failure:
If you cannot safely roll back, mark the device as “cordoned” (aka “Andon Cord"):
Remove it from pools or load-balancing sets where possible.
Prevent further automated changes.
Raise a high-priority alert for human intervention.
The goal is not perfection; it’s bounded inconsistency:
The device is either clearly at version N or clearly at N+1.
If it’s neither (post-checks fail), it gets isolated and treated as unhealthy.
That’s still vastly better than silently leaving devices in partially updated states.
7.5. Rollbacks: a workflow, not a panic button
Most teams treat rollback as the red “oh no” button slammed during incidents, barely tested, often more dangerous than the original change.
In a world of state consistency, rollback needs to be just another well-defined workflow:
For any change unit (e.g., policy v13), you define a corresponding rollback intent (back to v12).
You test that rollback path before you ever roll v13 into production:
Can we cleanly reapply v12 config to all device types?
Do control plane and data plane states converge back without surprises?
Do rollback pipelines honor the same guardrails and validations as forward deploys?
You also accept that rollback is not always safe or desirable:
Stateful middleboxes may drop or reset sessions when policies revert.
Long-lived flows may be more disturbed by an abrupt topology flip back to the old state than by a targeted forward fix.
Some changes (e.g., data migrations, address renumbering) are fundamentally one-way; “rollback” means a new, carefully designed change, not just “undo”.
So you categorize:
Safe rollbacks: stateless config changes (e.g., BGP policies, routing preferences) where reverting to the previous version is low-risk.
Conditional rollbacks: rollbacks that are safe only within a short time window or under certain traffic conditions.
No-rollbacks: changes where the “rollback” is a separate forward plan.
Your tooling then reflects this:
Safe rollbacks are automated and can be triggered as part of confidence gates.
Conditional rollbacks require additional checks before execution.
No-rollbacks instead prompt a repair workflow (“deploy fix v14”) rather than a naive revert.
The point is to make rollback predictable, not magical.
7.6. Atomicity and state: making inconsistency visible and short-lived
Atomic deployments and structured rollbacks matter for consistency in two significant ways.
First, they shorten the time the network spends in a partial state:
Devices move from “old world” to “new world” in discrete steps.
Failed transitions are caught and reverted quickly.
You don’t have policies half-applied for days because someone forgot the last POP.
Second, they clarify what version each device is supposed to be on, which makes drift detection dramatically easier:
Either a device is at version N or at version N-1.
If the state comparison engine sees something else, it’s clearly a drift.
If a device claims to be at N but the source of truth says it should be at N-1, you know you have an unplanned change.
This is the difference between:
Staring at a sea of subtle differences and trying to guess which ones matter.
Asking a simple question: “For this change, who’s on which version, and is that what we expect?”
Atomicity doesn’t eliminate inconsistent states; the world is too messy for that. But it does something just as powerful:
It makes inconsistency rare, short-lived, and sharply defined, rather than constant, fuzzy, and invisible.
With that in place, you can finally close the loop: when (not if) inconsistency does slip through, reconciliation loops have a clean, well-versioned system to act on, restoring alignment without turning every correction into another state explosion.
8. Consistency-aware observability: seeing state, not just signals
Most observability stacks answer questions like:
“Is latency up?”
“Did packet loss spike?”
“Are errors above SLO?”
Those are necessary, but they’re late signals. By the time they move, inconsistency has already existed for a while.
If you care about state consistency, you need observability that doesn’t just show symptoms, but actively tracks whether the network is telling the same story everywhere.
That means elevating a new class of signals:
State-aware metrics: numbers that describe how aligned (or misaligned) intent, control-plane, data-plane, and observations are.
8.1. State-aware metrics: not “is it fast?”, but “is it consistent?”
Let’s make this concrete. Instead of just graphing “latency per region”, you start to graph things like:
Prefix propagation time per region or POP
For a given tag set (e.g., customer:C, service:auth-api):
Measure how long it takes from the moment a route enters the network (or changes) until:
All targeted RRs see it.
All targeted edge routers see it.
All targeted POPs or regions advertise it externally.
Now you can track:
“In Region EU, customer C prefixes propagate to all edges in 7–9 seconds.”
“In Region APAC, the same prefixes oscillate between 20 and 60 seconds.”
You’ve just turned a vague sense of “sometimes convergence feels slow” into a consistency SLO: propagation time for specific, high-value routes.
FIB vs intended route-set drift
For a given shard of the network (e.g., “internet-edge”, “fabric-pod-A”), compute:
The set of prefixes + next-hops that should be present in FIB, based on intent and control plane.
The set that is actually present in FIB on each node.
From there, derive a metric like:
%_fib_alignment{shard="internet-edge"} = 98.7
Meaning: 98.7% of nodes have a FIB that exactly matches the intended route set for this shard; 1.3% do not.
You can drill down later to see which nodes are out of line, but as a top-level signal, this tells you if the data plane is globally obeying the contract.
Staleness detection for key control-plane structures
Certain tables going stale is a classic source of inconsistent behavior:
BGP adj-RIB-in / adj-RIB-out for specific peers or prefix sets.
EVPN ARP/ND suppression tables.
MAC/IP learning caches for ToR fabrics.
LDP/SR label binding databases.
You can track metrics like:
max_entry_age_seconds{table="evpn_arp_suppress", vni="5001", pod="dc1-podA"}max_prefix_age_seconds{table="bgp_rr_customerC", region="eu-west"}
If those numbers grow beyond expected thresholds, you don’t just know “something is old”; you know where the state is no longer being refreshed, which is precisely where inconsistencies pop up first.
Asymmetry indices for critical flows
Asymmetry is not always bad, but a sudden change is often a hint that reality drifted:
For a set of well-known endpoints or flows (e.g., region→region, AZ→AZ), you record the forward path and return path and compute:
“How often does forward≠return?”
“Has this ratio changed recently?”
You can express this as:
flow_asymmetry_index{src_region="eu-west", dst_region="us-east"} = 0.12
Meaning: 12% of probes show asymmetric paths.
If that number jumps from 0.12 to 0.65 after a change, you have a state-consistency smell, even if the raw latency is still within the SLO—for now.
8.2. Tagging telemetry with change IDs and versions
State-aware metrics are powerful on their own, but they become game-changing when you can tie them directly to what changed.
That’s where change IDs and versions come in.
Every deployment or policy update should have:
A unique change ID (
change_id="net-2025-0214-bgp-edge-v49").A semantic policy or intent version (
policy_version="bgp-edge:v49").
You then propagate these tags into:
Logs from your deployment pipelines (“applied v49 to devices X,Y,Z”).
Metrics from your state comparison engine (“device D reports policy_version=v48 but intent says v49”).
Telemetry from devices (“this node is currently running config hash H for policy P”).
Now you can ask observability questions that sound like:
“For routing policy v49, when did Region US-east become fully consistent?”
“During the rollout window for v49, what was the FIB alignment percentage per region?”
“Did prefix propagation time degrade between v48 and v49 for customer C?”
On an incident bridge, this stops the usual finger-pointing:
Instead of “did this deploy break it?”, you can say:
“Customer C’s propagation SLO was stable at 8 seconds under v48.
Under v49 in Region APAC, it spiked to 40 seconds. The RR FIB alignment dropped at the same time.”
You’re not guessing correlation; your observability fabric knows which version was active and where.
8.3. Surfacing consistency in dashboards: heatmaps, not haystacks
Once you have state-aware metrics and version tagging, you need to present them in a way that makes drift obvious at a glance.
A pattern that works well is a consistency heatmap:
Rows: components of the network
Regions, POPs, fabrics, clusters, or even specific device roles (RRs, PEs, spines, ToRs).
Columns: state dimensions
intent_alignment(config vs Git)control_alignment(BGP/IGP consistency)data_alignment(FIB vs expected)probe_alignment(synthetic tests vs intent paths)policy_alignment(attributes/tags vs policy spec)
Each cell is computed from underlying checks and metrics:
Green: aligned within thresholds.
Yellow: in-flight change or minor drift known/accepted.
Red: divergence with no associated change or known exception.
So instead of a generic “network health” view, you get something like:
Region EU-west:
Intent ✅, Control ✅, Data ✅, Probes ✅, Policy ✅
Region APAC:
Intent ✅, Control ⚠️ (RR best-path mismatch for customer C),
Data ❌ (FIB misalignment 10% of nodes), Probes ❌ (increased loss on APAC↔EU flows)
Now your eye is drawn directly to where the story diverges and at which layer.
A red cell doesn’t just mean “something is wrong”:
It might say “LSDB hash mismatch in region X” (control-plane drift).
Or “BGP table inconsistent for prefix set P on 2/5 RRs” (policy/control inconsistency).
Or “FIB vs intended route set mismatch >2% for shard S” (data-plane misalignment).
You’ve converted vague “noise” into structured, layer-aware signals.
8.4. Alerts that talk about consistency, not just pain
Finally, alerts.
If you stop at “ping to site Z failed” or “latency from region A to B is high”, you’re still in the old world: symptoms without hypotheses.
In a consistency-aware world, alerts are framed like this:
Data-plane + control-plane divergence
“Data-plane probe failed from POP X to prefix 198.51.100.0/24, and BGP RIB views diverge between RR R1 and RR R3 for this prefix set in region EU-west.”
Policy enforcement inconsistency
“Policy attribute community 65000:123 missing on exports to Transit X from 2/10 edge routers in region APAC; intent requires this for tag
customer:C.”
Stale control-plane state
“Max EVPN ARP-suppression entry age exceeded threshold (300s) for VNI 5001 in dc1-podA; probes show intermittent reachability to MAC/IP set S.”
Propagation SLO violation
“Prefix propagation time for
service:checkout-apiexceeded 30s in region SA for change net-2025-0214-bgp-edge-v49; expected <10s based on prior versions.”
These alerts do a few critical things:
They anchor the pain (failed probes, SLOs) to specific layers (control-plane, data-plane, policy).
They come pre-packaged with where to look (RRs, edges, specific VNIs, specific shards).
They tie directly into change context (which version, which rollout).
So instead of an on-call engineer starting from “something is slow,” they start from:
“APAC edges running v49 are out of policy alignment for customer C, and probes from APAC↔EU for those prefixes are failing.”
That’s hours of blind debugging collapsed into a single sentence.
Consistency-aware observability doesn’t replace traditional metrics; it sits on top of them.
You still care about latency, loss, utilization, and errors. But you also care about:
How fast does the state converge?
How aligned the different layers are.
Where and when invariants about your network stop being true.
Once your dashboards and alerts speak that language, you’ve turned “the network is lying to us” from a vague feeling into something you can see, measure, and act on, often before users ever notice.
9. Corrective reconciliation loops: closing the gap automatically
By this point, we’ve:
Named the kinds of inconsistent states that appear in real networks.
Built machinery to detect them (state comparison engines, multi-layer validation).
Wired observability so we can see misalignment as a first-class signal.
Now comes the hard part:
What do you actually do once you know the network is lying?
You can’t page a human for every tiny inconsistency in a hyperscale system. At the same time, you absolutely should not let automation “freestyle” its way through arbitrary repairs.
The middle ground is a set of corrective reconciliation loops: autonomous or semi-autonomous processes that continuously:
Consume diffs from the comparison engine.
Apply safety and policy checks.
Decide whether to auto-correct, isolate, or escalate.
Think of them as the network’s immune system:
Constantly watching for cells that don’t match the blueprint and taking proportionate action.
9.1. What a reconciliation loop actually is
A reconciliation loop is not a single script. It’s a pattern:
Input: a structured description of inconsistency
“Device R7 is on policy v12; intent says v13.”
“FIB on line card 3 of P2 is missing 5% of the expected routes for shard
internet-edge.”“BGP best-path for prefix set S differs between RR R1 and R2 with no in-flight change.”
Policy evaluation: rules that decide what’s allowed to happen automatically
“Is this within a known rollout window?”
“Is this a low-risk config fragment (QoS remarking, community tagging) or something dangerous (default route, ACL)?”
“Is this a one-off or part of a wider pattern?”
Action: one of a few carefully defined behaviors
Auto-correct the drift.
Propose a reconciliation change for humans to review.
Quarantine the suspicious part of the network.
Nudge convergence in a constrained way.
Or simply escalate to on-call with all the context.
The key is that none of these actions is “wing it with root access”. They’re bound, versioned, and logged.
9.2. Auto-correction: fixing the easy stuff, safely
Some kinds of drift are both:
Very common, and
Very safe to fix automatically.
For example:
A QoS policy that is correctly configured on 999/1000 edges but is missing on one.
A static route for an infrastructure prefix that dropped off a single box.
A known-good BGP export-policy that failed to apply during a deployment, leaving one device at the old version.
In these cases, a reconciliation loop can:
Confirm that intent is unambiguous:
Git says device D must have policy P@v13.
All other peers in the same role have P@v13.
There is no open change ticket targeting D that would justify a deviation.
Apply a known-safe correction:
Re-render the config for D and reapply the missing block.
Reattach the expected route-map to the relevant neighbor.
Re-add the static route.
Re-run targeted validation:
Confirm that the config now matches the intent.
Confirm that control plane and data plane behavior for the relevant prefixes is back in line.
If everything passes, the loop logs the fix and moves on.
If anything fails, it downgrades to isolation or escalation (more on that below).
This is auto-remediation with scope and context, not “if ping fails, reboot the router”.
9.3. Reconciliation PRs: turning hotfixes into new truth
Not all drift is “bad”. Sometimes the network diverges because a human fixed something faster than the system could:
An on-call engineer hot-patches a policy on a single edge to stop a live incident.
A regional owner tweaks a local preference to avoid a flapping upstream.
A ToR MAC/ARP timeout is adjusted to mitigate a specific workload pattern.
From the state engine’s point of view, these are violations: the box no longer matches intent. But if probes and SLOs show that the new state is actually better, then the blueprint is what’s wrong.
In these cases, reconciliation loops don’t auto-correct the device back to “wrong”. Instead, they:
Detect that the deviation is stable and apparently beneficial:
Drift has persisted beyond the usual remediation window.
No associated alerts or SLO breaches are tied to the new behavior.
Similar changes don’t exist elsewhere yet.
Generate a reconciliation change in the source of truth:
Open a PR that updates the policy model to match the observed “good” state.
Include diffs from the device, validation results, and context (“hotfix by on-call X at time T”).
Assign it to the relevant owners for review:
Network architects, regional leads, or service owners sign off.
Once merged, automation rolls the updated policy out to the rest of the fleet.
You’ve effectively turned a local, informal fix into a new global intent, with traceability.
Instead of punishing deviations, the system learns from them, but only via an explicit human-in-the-loop process.
9.4. Isolation: when the safest fix is to get out of the way
Sometimes the drift indicates something more serious:
A device’s FIB is corrupted in ways that don’t match any known pattern.
EVPN state in one POD is wildly inconsistent, with conflicting MAC/IP bindings.
The control plane on a node flaps between contradictory views every few seconds.
Auto-correcting in these conditions may be more dangerous than doing nothing. You don’t want your automation arguing with a sick box.
So the reconciliation loop chooses a different path: isolation.
Typical actions include:
Traffic draining:
Remove the device from load-balancing pools.
Adjust IGP/BGP metrics to steer traffic away (aka “Traffic Shift”).
Mark the node as “do not originate new sessions” at higher layers.
Change (Andon) cordon:
Block further automated config pushes to the device.
Require explicit override for any manual change.
Explicit alert with rich context:
Page on-call with a summary:
“Device R9 removed from edge role for shard
internet-edge.
Reason: FIB alignment 83% vs peers at 100%.
Detected anomalies: missing ECMP members, inconsistent MPLS label programming.”
This doesn’t fix the problem, but it sharply reduces the blast radius and makes it very clear where the problem is.
The most important part: the loop does not keep banging its head against a clearly unstable target. It switches from “repair” to “containment”.
9.5. Nudge convergence: gentle prods to distributed protocols
Some inconsistencies are not about static drift but about protocols getting stuck:
BGP sessions that remain established but stop exchanging certain updates due to vendor bugs.
EVPN routes that linger past their lifetime in one place but not others.
IGP areas that converge for most nodes but leave a few LSAs in limbo.
In these cases, a reconciliation loop can take small, constrained actions to “shake the system loose”:
Clearing a single BGP session or a subset of address-families for a specific neighbor.
Triggering a targeted EVPN resync for a VNI on a pair of ToRs.
Restarting a protocol process on one box after draining traffic and under strict throttling.
The guardrails matter more than the actions:
Only touch nodes that are known-good candidates for nudging (healthy CPU, no active incident, no concurrent change).
Only apply a nudge if the inconsistency matches a known pattern with proven remediation steps.
Never chain multiple nudges automatically without human review; one poke per event.
Done right, this helps you avoid a full-blown “turn it off and on again” mentality at fleet scale. You deploy a scalpel, not a hammer.
9.6. Safeguards: keeping your immune system from causing autoimmune disease
Any automation that can touch live networks needs rigid boundaries. Reconciliation loops are no exception.
Key safeguards usually include:
Rate limits
Cap the number of auto-corrections per unit time per:
Device, region, fabric, or policy.
If too many inconsistencies appear at once, assume something systemic is wrong and stop auto-fixing; escalate instead.
Backoff strategies
If a particular inconsistency recurs after correction (e.g., config keeps drifting back within minutes), stop trying to fix it in a loop.
Back off and treat it as a higher-severity signal:
Maybe a human keeps hotfixing your changes away.
Maybe a flapping link or faulty line card is causing repeated state corruption.
Maybe another automation system is fighting you.
Scoped permissions
Reconciliation loops don’t get to do everything.
They’re explicitly allowed to:
Reapply whitelisted config blocks.
Drain or undrain traffic using vetted mechanisms.
Initiate a narrow set of protocol nudges.
They are not allowed to:
Touch core security policies.
Modify underlay addressing, core routing defaults, or global BGP sessions.
Perform arbitrary config edits outside their known patterns.
Audit trails and observability
Every action must be recorded as if a human had done it:
What inconsistency triggered the action?
What was the intended fix?
What exactly changed (before/after diffs)?
What were the results of post-change validation?
Who (or what) approved it (e.g., “auto-policy: low-risk QoS reconciliation”)?
These logs feed back into:
Incident analysis (“did automation help or hurt here?”).
Policy refinement (“we should stop auto-fixing this class of drift”).
Training and documentation for new engineers.
9.7. Reconciliation is not a magic band-aid
It’s tempting to imagine reconciliation loops as a cure-all: “if anything drifts, the robots will fix it.”
That mindset is dangerous.
Reconciliation is powerful precisely because it is constrained:
It handles the boring, repetitive, low-risk repairs that humans shouldn’t waste their time on.
It codifies known patterns and responses, so you get the same measured behavior at 3 p.m. and 3 a.m.
It shrinks the window during which inconsistency lives in the wild.
But it does not:
Replace the need for good design and clean intent models.
Eliminate the necessity of deep human debugging for novel, complex failures.
Give you an excuse to tolerate sloppy change processes.
The right mental model is:
Detection + validation tells you where the network is lying.
Reconciliation loops correct the lies they’ve been explicitly trained to handle.
Everything else still needs engineers.
When used this way, reconciliation becomes the closing piece of the consistency story:
You model what the network should be.
You continuously check what it is.
You observe how it behaves.
And when those disagree, you have a principled, safe way to pull reality back towards intent automatically, where it’s safe, with humans where it’s not.
At hyperscale, the question is never “is my network consistent?” but instead it’s “how inconsistent is it right now, and how quickly can I bring it back in line with intent?”
We started by admitting an uncomfortable fact: you can have correct-looking configs and healthy-looking protocols and still end up with the wrong network. State lives in layers, including intent, configuration, control plane, data plane, and what you actually observe in the wild. Inconsistent behavior is what happens in the gaps when those layers drift apart.
The path forward isn’t relying on hero engineers or prettier dashboards. It’s building a system that continuously interrogates reality. A state comparison engine to diff intent vs live state. Multi-layer validation that ties control-plane views to real packet outcomes.
Atomic deployments and structured rollbacks that shrink the time your network spends in partial, undefined states. Consistency-aware observability that measures alignment, not just latency. And finally, reconciliation loops that can safely correct the classes of drift you understand, and escalate the ones you don’t.
You won’t eliminate inconsistency. But you can change its shape. Instead of long-lived, invisible pockets of bad state that only show up as customer pain, you get short-lived, well-bounded deviations that your systems can see, explain, and often fix before anyone notices.
That’s what a mature “intent vs reality” practice really buys you: not perfection, but a network that is constantly pulled back toward the truth you intended, even as it changes under load.
Leonardo Furtado