When Your Process Model Predicts One Thing but Your Flow Audit Shows Another: Which Map to Redraw

You stare at two versions of the same approach. The model, built over months of workshops and swimlane diagrams, promises a 3-day cycle time. The flow audit, pulled from system logs and stopwatch timings, shows 10 days. Someone is wrong—or both are. This tension isn't rare; it's the norm for any operation that's been running longer than a quarter. The question isn't which data set to trust blindly, but which map to redraw first.

Who Needs This and What Goes Wrong Without It

The ops manager who sees churn but can't explain it

You have a approach model that says a customer service ticket should close within four hours. The model shows a clean handoff from tier one to tier two, a knowledge base lookup, and one approval gate. Your dashboard says tickets close in four hours. But your customers keep leaving. The churn data is clear—something is breaking, yet every metric that matches the model looks fine. That's the gap. The model predicts efficiency. The audit shows escalations, duplicated work, and a hidden loop where agents bypass the knowledge base entirely because it's outdated. The damage is invisible until you lose a high-value account. I have watched crews spend three months optimizing a sequence that existed only on paper. Their flow audit revealed a completely different reality—one where the bottleneck was not speed but trust in the documented steps. The ops manager kept pointing at the model; the audit kept pointing at the floor. They were both right, and that was the problem.

The method architect whose model is ignored on the floor

You designed the workflow. You mapped every decision node, every approval, every SLA boundary. Then you walk the floor—or the Slack channels—and people are doing something else. They built a spreadsheet. They created a manual handoff that your model never captured. The architect's instinct is to enforce compliance. Wrong move. The real question is: why did the floor adapt? Usually because the model missed a constraint—a data field that was never available at that phase, a regulatory check that only a specific person can run, a system that crashes every Wednesday at 2 p.m. The odd part is—the model was technically correct. It was just correct for a world that didn't exist. That hurts. The method architect's credibility erodes fast when the audit exposes gaps nobody admitted. I have seen a Six Sigma Black Belt lose her entire improvement budget because the steering committee decided the model was "fantasy." She was not wrong; she was uninformed by reality. The audit fixed that, but not before three months of resistance.

We kept optimizing a approach that had already been abandoned by the people who actually did the work.

— approach improvement lead, logistics company

The Lean Six Sigma belt facing resistance from both sides

The catch is that the belt sits in the middle. On one side, the operational team says the model is irrelevant. On the other, the executive sponsor insists the model is the standard. The belt runs a flow audit and finds a 40 percent deviation—transactions that follow a path the model never documented. The immediate reaction is to update the model. That's a trap. Updating the model without understanding why the deviation exists just codifies bad behavior. Maybe the deviation is smart—workarounds that actually improve throughput. Maybe it's dangerous—regulatory shortcuts that will get someone fired. The belt needs to decide which map to redraw: the audit trace or the method model. Neither is automatically right. The trade-off is speed versus control. Redraw the model to match reality, and you gain buy-in but lose the ability to enforce standards. Redraw the audit to match the model, and you gain compliance but lose visibility into what actually works. Most crews default to one or the other. That's where the damage compounds.

What usually breaks first is trust. Not trust in the tool—trust in the people who claim to know how work gets done. The startup scaling too fast feels this acutely. They hire five new engineers in a month. Nobody updates the onboarding method model. The audit shows that new hires take fourteen days instead of the promised three. The model is redrawn. A month later, the audit shows nine days. Improvement? Yes. But the model still predicts three. The gap remains, and the operations team stops believing any number in any document. That's the real cost: not just wasted effort or misaligned improvements—but a culture where approach work is dismissed as theoretical. Fixing that requires more than a better model. It requires deciding which map to trust when they disagree. This chapter is about making that call before the churn spreads.

Prerequisites You Should Settle First

Agree on a Common Definition of 'the method' Boundaries

Before you run a single comparison, the modelers and the auditors must draw the same box around the same work. I have sat through two-hour meetings where one side counted "order received → shipped" and the other counted "quote sent → invoice paid." Both were right, on their own terms. But that kind of mismatch turns reconciliation into noise. Nail down the explicit start event and the explicit terminal event. Write them on a whiteboard. If someone says "we usually start when the ticket pops up," push back — does that mean when the email arrives, when someone clicks "accept," or when the system logs a status change? The gap between those three moments can swallow a whole day of lead time. The catch is that modelers often think in logical gates and abstractions, while auditors think in timestamps and screen recordings. You need a single, written boundary statement before either party touches their tools.

What about sub-processes inside that box? Set a rule: anything shorter than ten minutes and involving only one person gets folded into the parent move. Otherwise your model becomes a spiderweb of micro-steps and your audit log shows nothing but noise. Flat boundaries — this is where it starts, this is where it ends, everything inside is a stage — save you from the endless "but technically" arguments.

Decide Which Flow Metric Matters Most: Lead Time, Handoffs, or Rework

You can't reconcile three metrics at once and keep your sanity. Pick one. Lead time is the usual suspect — it's visible, it's tangible, and it's the first thing a stakeholder questions when the model says "two hours" and the audit says "two days." But lead time hides handoff delays. Handoffs, in turn, hide rework loops. The trick: choose the metric that surfaces the problem your approach actually has. If your team is chronically waiting between steps, lead time is your anchor. If people keep dropping the baton between departments, count handoffs. If the same task reappears in three consecutive weeks, track rework percentage. I have seen groups waste a week trying to reconcile all three, only to discover that their model was built for throughput while their audit was built for cycle time. Wrong order. Pick one metric, write it on the boundary whiteboard, and ignore the other two until this pass is done.

That said, the metric you choose must be measurable in both sources the same way. If your model calculates lead time as calendar hours but your audit logs only capture business hours, one of you will look catastrophically wrong — and neither is. Align the unit of measurement before you compare a single number.

Secure Access to at Least Two Independent Data Sources (Logs + Observation)

One source is a story. Two sources are evidence. The model is a hypothesis; the audit is the test. But if your audit pulls the same system logs that your model was built from, you're just running the same bug twice. You need at least one independent stream — ideally, time-stamped system logs on one side and direct observation (screen recordings, walk-throughs, shadowing) on the other. System logs lie in silent ways: they record button clicks, not the five-minute pause after a click while someone reads a sticky note. Observation catches that pause. Observation, however, misses the automated handoffs that happen at 3 a.m. Logs catch those. The combination is what keeps you honest. Without it, you're not reconciling — you're guessing which artifact to trust.

Not every water checklist earns its ink.

Not every water checklist earns its ink.

'The model is a map; the audit is the ground. You can't redraw the map until you have stood on the ground and seen where the rivers actually run.'

— process engineer, after a three-month audit that disproved their own model

Get Buy-In from Both the Modelers and the Auditors Before You Start

A reconciliation effort that surprises one side halfway through will stall. Hard. The modelers need to accept that their map might be wrong — not an easy conversation when they have defended that model in quarterly reviews for two years. The auditors need to accept that their data might show noise, not truth — also hard when they have been logging every keystroke as "critical." I once watched a six-week project collapse because the modeler refused to believe that the audit showed a seven-hour gap, and the auditor refused to re-check the timestamp zone offset. No one had agreed, upfront, that both artifacts were fallible. So set the ground rule: we're looking for the gap, not for the blame. Schedule a 30-minute kickoff meeting where both parties verbally commit to the boundary, the metric, and the two data sources. If someone hesitates, don't proceed. That hesitation will cost you weeks down the line.

Last thing: get it in writing. A quick email recap of that kickoff — "We agreed the process starts at X, ends at Y, we're measuring lead time in business hours, and both sides accept that the model or the audit may need redrawing" — eliminates the "I thought we were measuring something else" surprise three meetings later. It's boring. It's necessary. Do it.

Core Workflow: Steps to Reconcile Model and Audit

move 1: Map your model's explicit assumptions — not just the steps

Every process model is a lie. A useful lie, sure — but it hides decisions about time, capacity, and sequence that nobody wrote down. I have seen groups print a beautiful BPMN diagram, hang it on a wall, and then wonder why the actual flow never matches. The fix is brutal: list every assumption baked into the model before you touch audit data. Things like “we assume handoffs take less than 30 minutes” or “this stage uses one person at a time.” Write them out. Most units skip this — they jump straight to comparing counts. Wrong order. You need the assumptions because they're the first things that break when the audit contradicts the model. That said, you also need to note which assumptions are implicit — the model might show a single box for “approval,” but your team knows approval actually means three people emailing each other over two days. Write that down too.

Glacier moraines, scree fields, crevasse bridges, serac falls, and alpine hut logs rewrite courage as paperwork.

Ember nexus clamps seize overnight.

stage 2: Run a flow audit that captures timing and handoffs — not just counts

A flow audit that only logs “how many times stage A happened” is useless. What breaks is the timing. A model might show a 10-minute task, but the audit reveals it takes 90 minutes because the person who does it also handles phone support. So capture two things: wall-clock time per node and the handoff latency between nodes. The handoff — that gap where work sits in someone’s inbox — is where models lie most. The catch is that audit tools often log timestamps only at gateways, not inside the swimlanes. You need to instrument at the granularity of “person receives task” and “person sends output.” If your tool can't do that, you will reconcile wrong data. I once watched a team spend two weeks reconciling counts that were off by 3%, then discover the real gap was a 4-hour handoff delay the model never considered.

stage 3: Overlay both views node by node — mark deviations

Take the model and the audit — side by side. For each node, ask three questions: Does the sequence match? Does the duration match within 20%? Does the handoff pattern match (who passes to whom)? Mark every deviation with a flag: model wrong, audit incomplete, or both need fixing. The tricky bit is that a deviation in sequence often masks a deviation in timing — for example, the model shows phase B after move A, but the audit shows stage B sometimes runs in parallel. Don't smooth over those conflicts. That hurts. Instead, create a third column: “observed reality.” This column may contain fragments — “B starts before A finishes” — and that's fine. You're not polishing a diagram; you're finding where trust breaks.

“We found a node where the model predicted 15 minutes, but the audit logged 47. The model assumed single-threaded work. The auditor had ignored the waiting time.”

— actual note from a manufacturing flow audit, 2023

phase 4: Decide which nodes to trust from each source — and merge

Now you have a marked-up overlay. The decision rule is simple but not easy: trust the model for nodes where the process logic is deterministic and well-documented — think compliance gates or regulatory steps. Trust the audit for nodes where timing, handoff, or human judgment dominates — approval queues, rework loops, escalation paths. Then merge them into a hybrid map. This means the final diagram may have model-based sequence arrows but audit-based duration labels. It may show a handoff delay that the model never drew. The real test? Show the merged map to the person who does the work. If they say “yes, that's how it actually runs,” you're done. If they laugh, you missed something. Take the laugh seriously — it's cheaper than running the audit again.

Tools, Setup, and Environment Realities

Celonis vs. Prom: when to use enterprise vs. academic tools

The gap between a polished platform and a research prototype isn't just price—it's how much truth you can tolerate. Celonis gives you beautiful dashboards, automated conformance checking, and a team of sales engineers who will hold your hand. It also costs more per month than a junior developer's salary, and its black-box algorithms can hide the very discrepancies you're chasing. Prom, by contrast, is free. It forces you to choose the right miner, tweak parameters manually, and stare at spaghetti logs until your eyes cross. But that raw exposure—no slick UI buffering the output—often reveals why your model predicted one thing but your audit found another. The trade-off: Celonis gets you adoption from executives who want traffic-light reports; Prom gets you actual understanding from analysts who can read a Petri net. I have seen units burn six weeks trying to force a Celonis export into a format Prom could read, only to realize the handoff they needed to see had been filtered out by the enterprise tool's default preprocessing.

The spreadsheet-only approach for small groups or sensitive data

Sometimes the tool you have is Excel—or, worse, Google Sheets with a 100-request-per-minute API limit. That sounds like a limitation until you realize your process model predicted a 48-hour approval cycle, but your flow audit shows nobody clicked "approve" because they did it offline via email. No enterprise process mining tool captures that. A spreadsheet can. The trick is mapping each column to a real event: timestamp, actor, action, artifact ID. One column per handoff. Then pivot tables become your conformance checker. The catch: manual data entry rots fast. You need one strict gatekeeper—someone who updates the sheet before coffee, not after lunch. For sensitive data (patient referrals, payroll approvals, vendor payments), this approach also keeps logs off third-party servers. Is it elegant? No. Does it catch the gap between what people say they do and what the spreadsheet cells prove? Yes. That alone can fix the map.

“We built our entire audit in Google Sheets because the client refused to let any tool touch their PII. The model said 94% compliance. The sheet revealed 42%.”

— Process analyst at a mid-market healthcare firm, off the record

Whiteboard and sticky notes: surprisingly effective for trust-building

You're running a flow audit, the stakeholders are skeptical, and your fancy tool keeps showing a 23% conformance score they yell is wrong. Put down the laptop. Walk to the whiteboard. Draw the process model as they describe it—not as the data says. Then ask them to place sticky notes where they think the actual handoffs happen. What usually breaks first is the honest admission: "Oh, we skip that approval step when the manager is on vacation." No tool will ever surface that exception unless someone captures it in a comment field or a weird timestamp gap. The whiteboard forces the gap into the open. The downside: no traceability, no timestamps, no export to CSV. You fix the model on the board, then you go back to your tool and adjust the audit parameters. This works because trust is the prerequisite for action; tool accuracy comes second.

Reality check: name the conservation owner or stop.

Reality check: name the conservation owner or stop.

What to do when your audit tool can't capture a key handoff

This happens more than vendors admit. Your process model has a "quality review" step, but the actual data source—say, a CRM log—only records when a ticket enters and exits the review queue. The review itself? Invisible. Most units try to infer the handoff through time thresholds: if a ticket sits for 4 hours, they assume review happened. That assumption breaks your conformance check from the start. Fix it by injecting a manual annotation layer: a simple bot that pings the reviewer: "Did you approve or reject ticket #X?" Capture that answer as an audit event. Yes, it's an extra click. Yes, it's imperfect. But it plugs the hole without replacing your entire toolset. The alternative—pretending the handoff doesn't exist—means your model stays wrong, and your audit stays blind. Redraw the map to include that annotation step; then the numbers will finally align.

Variations for Different Constraints

Tight timeline: skip full model rebuild, patch the top 3 deviation nodes

When a client calls on Tuesday and needs reconciled numbers by Friday, you don't rebuild the entire process model. I have seen teams waste two weeks redrawing swimlanes that were 70% accurate. Instead, pull the audit trail and identify the three nodes where model prediction and measured reality diverge the most — typically handoffs, decision gates, or approval loops. Patch those. Literally overlay a sticky-note revision on the original diagram or add a comment layer in your modeling tool. Fix the variance that eats 80% of your throughput, leave the rest as-is, and document the known gaps. The catch is that patched models accumulate technical debt — schedule a 90-minute cleanup session within two weeks or the patches become permanent scaffolding.

No system log data: use manual time studies and interviews

Your ERP went dark, the audit trail vanished, and now you're flying blind. Most teams freeze here — they wait for IT to restore logs that never come. Wrong move. Grab a stopwatch and a clipboard. Walk the floor for three 45-minute observation blocks across different shifts. Record cycle times manually, note queue lengths, and ask the people doing the work: “Where do you wait?” and “What step do you redo most often?” Their answers are often more honest than system timestamps because logs can't tell you about the side-conversation that bypasses the formal approval gate. The trade-off is sample size — you get maybe 30 data points instead of 3,000 — but biased data you understand beats pristine data you can’t explain. One caveat: interviews introduce social-desirability bias. Cross-check with direct observation for the three most sensitive nodes.

Siloed teams: create a shared one-page model before any audit

Operations has one version of the flow, compliance has another, and engineering swears the process died in 2022. Running an audit inside a silo war is pointless — each team will reject the findings. Here is the fix: gather one representative from each silo for a single 90-minute meeting. Hand them a whiteboard and a marker. Build a one-page process map that everyone agrees is approximately true — no detail deeper than 5 boxes. Then run your flow audit against that skeleton. The odd part is that teams who fight over granular detail will often agree on the high-level flow. Use that agreement as the anchor. When the audit reveals deviations, each silo owns part of the gap. That hurts, but it also prevents finger-pointing.

“We spent three months building a perfect model. Then the audit showed we skipped the step that actually adds value.”

— process analyst reflecting on why a shared one-pager beats a cathedral nobody believes in

High staff turnover: anchor on audit data, treat model as historical reference

If your team has turned over 40% in the past year, the process model is fiction — it describes how people used to work, not how the current crew operates. Don't waste time updating the model first. Run the flow audit immediately; let the data show you what is actually happening on the floor. The model becomes a reference artifact: “This is how we designed it, here is how reality differs, now decide which one to institutionalize.” The risk is that old-timers fight to preserve the original model because it represents how things should be. Push back gently: a process that nobody follows is not a process — it’s a wish. Document the delta and schedule a 30-day re-audit after the new hires stabilize. That's your real moment of truth.

Pitfalls, Debugging, and What to Check When It Fails

Confirmation bias: you favor the model because you built it

You drew that swimlane diagram. You argued for the decision gate. You defended it in three meetings. So when the flow audit shows a different path, the reflex is to blame the data — bad timestamps, wrong tool, user error. I have watched teams spend two weeks re-auditing logs that were perfectly clean, simply because the model felt more correct. The fix is brutal and cheap: hand the audit report to someone who has never seen your process. Let them interpret the divergence cold. Their first reaction is usually the honest one. If they say “huh, that step doesn’t match anything,” believe them before you believe your own slides.

Audit myopia: recent data gets overweighted, ignoring seasonality

The frantic quarter-end push. The shadow IT workaround that appeared last Tuesday. A single data dump that skews the thirty-day window. Audit myopia hits when your reconciliation window is too narrow — you compare last week’s logs against a model built from last month’s assumptions. The result: you redraw a process that was never broken, chasing a spike. The check? Pull a twelve-month slice, not four weeks. Mark the seasonal bands. If the divergence only appears in the latest 10% of data, hold your edits. Wait one more cycle. Most teams skip this, then wonder why the “fixed” model breaks again in January.

The false consensus trap: everyone thinks they know the real process

Three people in the room. Three different mental maps. The product manager insists orders route through approval first; the ops lead swears they skip it for small clients; the engineer just stares at a dashboard that contradicts both. False consensus makes you reconcile the model against an imaginary average — a process that nobody actually runs but everyone agrees “should” exist. The avoidance tactic is inductive, not deductive: trace one real order end-to-end from the audit log, aloud, before discussing any model changes. That single thread often reveals the hidden seam.

“We argued for an hour about the approval gate. Then we traced one invoice. It had never touched the approval queue — the audit was right all along.”

— operations lead after a wasted sprint

Cutters, graders, pressers, finishers, trimmers, handlers, inkers, and packers rarely share identical checklist verbs.

Letterpress quoins reward slow hands.

When both are wrong: the hidden step neither captured

Model says A. Audit says B. So you pick one and redraw the other. The trap is that both could miss step C — the undocumented handoff that happens in Slack, the manual CSV export that bypasses the system entirely. I fixed a reconciliation failure once by finding a sticky note taped to a monitor: “If system times out, call Bob, Bob enters override code.” Neither the model nor the audit logs captured Bob. The concrete check: audit the exceptions, not just the happy path. Pull the records that failed validation, the ones that sat in limbo for days. Those orphans usually point to the step you never mapped. That hurts. Redraw from there.

FAQ and Checklist: Quick Fixes for Common Sticking Points

How often should I recalibrate model vs. audit?

The short answer: whenever the drift hurts. I have seen teams set a quarterly cadence and then wonder why their August model still thinks the process runs in 4 hours when the audit clock says 12. That gap widens fast. Every time a step gets reordered, a person leaves, or a tool changes — that's a recalibration trigger. But don't recalibrate blindly. If the model and audit disagree by less than 5% on duration and the sequence holds, let it ride. Over-calibrating burns time. Under-calibrating burns trust. The catch is — most teams do the latter until something breaks, then they panic-fix. Instead, set a monthly quick-check: compare five random flow paths from the last week against your model. If three of five mismatch, recalibrate. If zero mismatch, skip the meeting. Practical, not procedural.

What if the model and audit agree on timing but disagree on sequence?

That's a handshake problem — the clock says 10 minutes per step, but step C keeps happening before step B. The model thinks the process is linear. The audit shows a skip-back or a parallel fork you never documented. Wrong order. Don't just update the model to match the audit sequence — that hides the real issue. Ask: did someone deliberately reorder steps to work around a bottleneck? Or is this a one-off exception from a tired operator? We fixed this once by watching the actual floor for two hours. The audit was right about the sequence: workers had found a faster path through compliance checks. The model was wrong. So we redrew the model, then told compliance. Sequence disagreements usually mean your process has evolved faster than your documentation — treat it as a signal, not a bug. One rhetorical question worth asking: "Would fixing the model first make the process easier to automate, or just easier to misunderstand?"

Flag this for water: shortcuts cost a day.

Flag this for water: shortcuts cost a day.

The tricky bit is — timing alignment can lull you into false safety. I have seen teams celebrate that their model duration matched the audit perfectly, then ship a product that failed because step order caused a data dependency error downstream. Sequence matters more than speed when the output quality depends on preconditions. If you must prioritize, fix the sequence first. Let the timing float while you verify the logic.

Should I update the model or change the process first?

The model is a map. The process is the road. If the road has a pothole, painting a new map doesn't fix the tire. Most teams jump to updating the model because it feels productive — they can close a ticket. But if the audit reveals a broken step (wrong approval gate, missing handoff, redundant check), change the process first. Then update the model to reflect the fix. I have seen the reverse play out: a team redrew their BPMN diagram to match a chaotic audit, effectively codifying bad habits. That hurts. Update the model only after you have decided whether the audit shows a flaw or a better way. The exception: when the audit shows a faster path that doesn't violate policy. Then redraw the model first, test it for a week, and lock the process change after validation.

"You can't fix a process by fixing the diagram. The diagram shows where the process broke — your job is to decide which tool to pick up."

— senior ops lead, after watching a team redraw the same loop three times

Checklist: five things to verify before declaring reconciliation done

• Timing delta ≤10% — average of 20 audit samples vs. model prediction. If larger, flag the outliers before calling it done.
• Sequence matches in at least 90% of runs — exceptions must be documented as variants, not errors.
• Approval gates present in both — missing a sign-off in the model or audit means the control is phantom. Fix that.
• No unmapped error paths — if the audit shows a retry loop or manual override the model ignores, you have a blind spot. Add it.
• One person owns the reconciliation record — no shared docs floating around. Assign an owner who can explain every mismatch decision next month.

Run this checklist before any stakeholder review. It catches the three things that usually fail: hidden exceptions, timing rationalization, and ownership gaps. Don't skip the owner step — I have seen five people claim they "fixed" a mismatch, but nobody knew why the fix was chosen. That's not reconciliation. That's deferred confusion.

What to Do Next (Specific Actions)

Schedule a cross-functional review within two weeks

Your model and your audit disagree—now what? You book a room. Pull in the process owner, the data engineer who built the audit query, and one operator who actually touches the workflow daily. I have seen teams spend three months polishing a model nobody challenged. Two weeks is tight enough to force decisions, loose enough to get calendars aligned. The goal here is not consensus—it's a single agreed list of the top three discrepancies. Keep the meeting to ninety minutes. Anything longer breeds excuses, not fixes.

Before that meeting, send each attendee one page: the model diagram, the audit output for the same period, and three highlighted mismatches. No slide deck. No appendix. The odd part is—most teams skip this prep and then wonder why the review devolves into finger-pointing. Let them arrive knowing what hurts. You lose a day if you waste time explaining basics in the room.

Pick one node with the largest deviation and update its model

You can't fix everything at once. Choose the single process step where the model says “3 hours” but the audit logs show “6.5 hours”—or the handoff that the model treats as automatic but the audit reveals requires manual approval. That node is your lever. Update its parameters, its sequence, or its decision logic in the model. One change. Then resist the urge to tweak three other nodes because they also look off. That's how you break what still works.

‘We changed one approval gate and our forecast error dropped from 34% to 12% in two weeks.’

— Process analyst, mid-size logistics firm, 2024

The catch is: a single-node fix often exposes a second hidden problem downstream. That's fine. You now know the real chain. Document that discovery but don't chase it yet—stay focused on verifying this one change first.

Run a mini-audit after the change to verify improvement

Set a seven-day window. Same audit script, same data source, same period length as before. Compare the new audit output against the updated model. Did the deviation shrink? If yes, you have a replicable method. If no—and this happens often—the model may have been wrong about the root cause, not just the numbers. The mini-audit doesn't lie. It tells you whether your redraw was cosmetic or structural. Most teams skip validation entirely and assume the fix stuck. That assumption burns.

Set a calendar reminder to compare model vs. audit quarterly

Processes drift. New tools get adopted, old steps get skipped, staffing changes shift actual cycle times. A single reconciliation is a snapshot, not a system. Block two hours on the first Monday of every quarter. Re-run the audit. Compare it to the current model. If the gap exceeds 10% on any critical node, trigger a quick review—not a full fire drill, just a thirty-minute check-in. Wrong order? Letting eighteen months pass without a comparison is how your model becomes a fiction that everyone nods at but nobody trusts.