Declared Process vs. Actual Process in Field Operations

A process document describes what is supposed to happen on a job site, in a warehouse, or on a plant floor. The work that actually happens there diverges from that document almost as a matter of course. That divergence, not any single bad decision or any one careless worker, is where operational risk compounds over time, quietly, until a schedule slips or a shipment misses its window and nobody can say why. The distinction starts at the level of definition: a process describes what needs to happen and why, while a procedure tells a worker how to execute one step inside it. BOC Group's 2025 BPM study found that only around 15% of organizations have reached a more advanced level of BPM maturity, so most have documented processes that exist on paper without governing how work actually runs on the floor. The structural cause sits in governance, not documentation: policies are rarely translated into assigned tasks, measurable controls, and verifiable evidence at the point of execution, and until they are, the gap between declared and actual process has nowhere to close.

How the gap forms and stays hidden

The gap does not open overnight. Structural failures built into how most organizations check their own work allow it to accumulate, and it appears in well-run operations as readily as in poorly run ones. Standard audits compare the declared process against outcomes: did the shipment arrive, did the budget close, did the inspection pass. That comparison skips the middle layer entirely, the one that shows what actually happened between the start of the process and its end, and that middle layer is where the real failures live. A complete audit requires three layers: the designed process, the actual process, and the data trail connecting them, and each of these three can fail independently of the other two.

Shadow data is one of the most reliable signals that a declared process has already been bypassed. When approvers manage exceptions through email threads and hallway conversations instead of through the documented workflow, it means the documented workflow does not account for how the work really gets done. Workers and managers find the shortest path to getting something approved or released, and the formal process gets hollowed out from the inside while the org chart and the flowchart stay exactly as they were drawn.

The anatomy of that hollowing-out tends to look similar across industries. Process mining pulls event logs out of the systems that already record transactions and timestamps, reconstructs what the process actually looked like in execution, and measures the divergence from the model that was supposed to govern it. The space between the intended model and the reconstructed one is where the real optimization opportunities sit, because it is the only place that shows what the organization is actually doing instead of what it believes it is doing.

The cost of an unexamined gap in construction and logistics

In asset-heavy, schedule-driven operations, this gap does not stay abstract. It turns into schedule overruns, procurement failures, and coordination breakdowns that cost far more to repair after the fact than they would have cost to prevent. The KPMG Global Construction Survey consistently shows that fewer than thirty percent of major projects deliver on time and on budget, a figure that reflects how routinely the declared schedule and the field reality part ways. Manual scheduling tools cannot hold the combinatorial complexity of a large project, so the plan that gets published is really an approximation, and the field starts working around it before the first task even begins.

The data center buildout sector shows what happens when this same gap scales up into infrastructure with national consequences. Regulatory attention to this problem has followed: the fact that grid operators have had to respond formally signals that the gap between declared commissioning readiness and actual grid coordination status has become a systemic risk rather than a project-level inconvenience. When a facility's energization timeline depends on dozens of interlocking actual processes, none of which match their declared versions exactly, the consequences stop being contained to one job site and start touching regional power reliability.

The structural remedy for construction and logistics alike is operational redesign grounded in field evidence, built from an understanding of how crews actually mobilize, how procurement actually releases materials, and how inspections actually sequence, with the process rebuilt around that reality instead of around an idealized schedule drawn up before anyone broke ground.

Why automating before surfacing the gap makes things worse

Automating a process before understanding how it actually runs does not close the gap between declared and actual work. It locks that gap in place and speeds up its effects. When a single task gets automated without a view of the broader process around it, that task completes faster while every downstream step stays designed around the old manual pace, and the system as a whole does not get better, it just relocates its bottlenecks to wherever the automation now exposes them.

At the AI layer, this risk compounds. Teams frequently move from intention to implementation without ever establishing a stable, measurable baseline for the process they intend to automate, and whatever assumptions were baked into that process get locked into code. An error in the process model becomes an error in the agent's behavior, repeated at whatever speed and scale the automation runs. A procure-to-pay deployment at Habitat for Humanity shows this precisely: automation was introduced to shorten a long approval cycle, but mapping the actual process revealed that procurement was pulling vendor data from an external spreadsheet that had never been connected to the approval system. The "approved vendor" rule inside the workflow never fired correctly as a result, because staff were maintaining two separate data sources by hand, and the automation did not resolve that split, it simply hid it behind a faster-looking interface.

A CapEx approval process at BIC tells a related story. None of that appeared in the declared process. The audit made it visible, and the fixes that followed reduced the approval cycle and nearly eliminated the rework that the shadow spreadsheet had been generating all along.

AI agent deployment extends this same pattern at a larger scale. Roughly five percent of enterprise AI agents reach production, and the rest stall out in prototype, usually because the organization never standardized the process the agent was supposed to run. A new category of risk has started to take shape around this failure mode in 2026, involving AI agents that produce incorrect, outdated, or harmful outputs affecting real operational and compliance decisions, often without the audit logging needed to catch the error before it compounds. Val Marchevsky, CTO of Uber Freight, put the underlying choice directly: "The biggest opportunities won't come from layering AI onto broken processes, but from using it to redesign processes for efficiency, eliminate waste, streamline execution, and help teams move faster and smarter." The risk Marchevsky describes compounds because most AI deployment efforts attempt to automate the declared process rather than rebuild the actual one, a mistake that Terminal Use's process-first approach is built to prevent by refusing to move into redesign until the real workflow has been made visible. Firms that start with a process audit before any redesign tend to see faster, more stable outcomes, because the audit surfaces what needs to change before the first agent goes live, instead of after the automation has already amplified whatever gaps the audit would have caught.

Surfacing what is running before touching anything else

Closing the gap requires a structured effort to find out how work actually moves today: where it stalls, where it loops back on itself, and who really owns each decision point, before any redesign gets decided. Documentation of what actually happens, rather than what the procedure manual describes, has to be the starting point, and it has to come from the frontline workers doing the task every day, because they know where the problems sit in a way that formal process owners, sitting one or two levels removed from the work, usually do not.

Gap analysis gives this effort a diagnostic structure. The current state captures how the process actually runs, including its workarounds, its shadow data sources, and its informal escalation paths. The desired state gets defined by operational outcomes rather than by what the procedure manual says should happen. The gap itself covers not only what is missing but what is actively wrong: steps built around a single resource, approval loops that break the moment that person is unavailable, data that lives outside the system of record. Gap analysis delivers the most value in project management when it happens before scope gets locked in, not after a project is already underway and its constraints have already hardened into commitments.

Process mining serves as the forensic tool for this work. It extracts event logs from the systems already running, reconstructs the actual flow of a process, and makes the divergence from the declared model visible and measurable, turning what was an invisible gap into an auditable one. Terminal Use, an AI-first operations rebuilder working across construction, logistics, and manufacturing, treats this kind of diagnostic audit as the foundation of every engagement, using it to find where the declared process has already been hollowed out and where the real work has relocated instead.

The three-layer audit, designed process, actual process, and data trail, remains the most complete framework available for this kind of work. Most audits skip the middle layer and jump straight to compliance checking, which is a large part of why the same gaps keep reappearing after every audit cycle instead of closing for good. A process audit therefore has to include data provenance alongside workflow steps, since a tool built to reveal the gap can only do so where the underlying data is trustworthy enough to reveal anything.

Failure patterns a process audit should look for in field operations

A process audit in field operations is a search for specific failure patterns that reliably mark where the declared process has already broken down in practice.

Single-resource dependencies are one of the most common. Any approval, release, or decision that halts the moment one specific person is unavailable is a structural fragility wearing the disguise of a normal workflow step, and these dependencies are almost never visible anywhere in the declared process documentation.

Siloed data sources are another. When staff maintain parallel records, a spreadsheet running alongside the formal system, or an external vendor list sitting outside the approved-vendor database, the formal process is already operating on stale or incorrect inputs without anyone flagging it as a defect. The Habitat for Humanity case shows this exactly: the automation failed because vendor data lived outside the approval system entirely, and the audit is what revealed that parallel data source, since the declared process had never acknowledged it existed.

Informal escalation chains mark a third pattern. When frontline staff lack the authority to resolve a problem at the moment it occurs, the work moves through conversations and emails instead of through the system meant to track it, and these chains stay invisible to any tool that only reads system logs, because the real resolution never touched the system.

In construction specifically, auditors should look for schedule logic disconnected from procurement release dates and inspection sequencing, task dependencies drawn on paper that do not reflect what the field can actually deliver. In logistics, the pattern to watch is the handoff point: a place where the declared process assumes a clean, instantaneous data transfer, but the actual transfer is manual, partial, or timed to a different system's refresh cycle entirely, introducing a lag or an error that the process diagram never shows.

Resolving the objection that process cleanup becomes an indefinite delay

The strongest objection to auditing before automating is not wrong on its face: waiting for a perfectly clean process before moving forward is a real and common failure mode of its own. Gartner predicted that more than forty percent of agentic AI projects will be canceled by the end of 2027, and over-governance, not just under-preparation, is cited as one of the contributing causes. The objection carries real force, because declaring that the process must be cleaned up before any automation begins often turns into an indefinite deferral, one that risk-averse teams can use to avoid committing to anything.

The resolution sits in scope. An audit does not need to cover every process in the organization before the first one gets rebuilt. It needs to be specific to the one process chosen to go first. The workable sequence is to identify the most painful, most bounded process in the operation, audit that single process across all three layers, rebuild it with AI at the center of the new design, and only then move to the next one. This is a targeted intervention meant to produce a live result in weeks rather than quarters, not a platform strategy or a sweeping transformation roadmap, and a long timeline attached to the audit phase itself is usually a sign that the scope was drawn too wide, not that the team was being insufficiently rigorous. Organizations that get durable value from automation tend to be the ones that go in with a clear, field-tested understanding of how their existing processes actually run and realistic expectations about what a first redesign can accomplish.