Baseline Data Requirements Before Starting an AI Process Redesign

Most AI process redesigns fail for a structural reason that has nothing to do with the model, the budget, or the strategy document that launched them. Data sits scattered across ERPs, cloud warehouses, SaaS tools, and legacy systems with no unified way to reach it, most data domains have no clear owner, and quality checks vary from team to team and file to file. Strategy documents describe the process a company wants to run, not the data conditions underneath it, so none of this is visible when a project gets approved.

The gap doesn't produce a slow start. It produces a stall that looks like progress until it doesn't. An agent handed incomplete, inconsistent, or stale data doesn't pause and raise a flag the way a human analyst might. The agent does what it was built to do, acting on inputs nobody checked first.

The move to agentic AI raises the cost of every one of these gaps, because agents aren't reading data so much as acting on it. An agent built on bad data takes a wrong action, and that action can touch a customer record, a purchase order, or a shipment before anyone notices. The rest of this piece sets out what to check before that happens.

Baseline Data for a Process Redesign

A baseline data assessment for a process redesign asks a narrower, sharper question than an enterprise data maturity audit does. It is a process-specific inventory: the exact inputs, quality conditions, ownership structures, and system links one target workflow needs before an agent can act on it reliably. It is not a survey of how mature a company's data estate is overall.

The distinction matters because most organizations already have some data initiative running somewhere in the background, often for years, often without a clear end date. What they need instead is a clear answer about what their specific process requires, not a status update on a company-wide platform migration.

Five conditions have to hold at once for any system an AI workload touches, and they give a useful lens for this kind of check. When any one of these five is missing for a system the process touches, that system becomes a blind spot for every AI workload that needs to reach it.

The pre-redesign question is which of these five conditions fail for the specific process under redesign, and which of those failures would stop an agent from acting safely. Terminal Use's approach to process redesign starts with a scoped inventory of the inputs, quality conditions, ownership structures, and system links one target workflow requires. That distinction is what makes a first deployment possible in weeks instead of quarters, because teams resolve the conditions blocking one process and build outward from there, rather than waiting on infrastructure maturity across the whole organization.

The four concrete data conditions to audit before redesigning any process

Every process redesign needs a check across four concrete conditions before an agent touches anything: what data the process actually consumes, whether that data clears a quality bar an agent can act on, who owns each data domain involved, and how the process connects to the systems upstream and downstream of it.

The first condition is inputs, meaning what the process actually consumes day to day, as distinct from what the documentation says it consumes. A useful audit step is sitting the official process map next to the field workarounds, the things a warehouse manager or a dispatcher actually does when the documented path is blocked, and reconciling the two. The output should be a full list of every input the process touches, structured and unstructured alike, with a confirmed answer on which of those an agent can actually consume: not just searchable, but versioned, placed in context, and linked back to the structured records that give it meaning.

The second condition is quality, meaning whether the data clears the bar an agent needs to act on it, not the lower bar a human analyst has learned to work around. BASF's AlphaEvolve supply chain digital twin, built with Google Cloud, needed three years of historical data on inventory levels, market demand, and production outputs before the model could be trained on it at all, a reminder that quality and depth of historical data are preconditions for a working system, not details to patch in after launch.

The third condition is ownership: whether each data domain touched by the process has a named owner and a governed way to grant access. A near-universal finding at this stage is that most data domains have no clear owner, and that data contracts, where they exist, are informal or missing. Governance bolted on after an agent is already live doesn't catch up. It accumulates as debt that compounds with every new use case built on top of it.

The fourth condition is process linkages, meaning how the target process connects to the systems feeding it and the systems it feeds, and where those connections are likely to break once an agent is operating them rather than a person. Brittle pipelines that break when a source schema drifts are one of two hurdles that occur in nearly every enterprise AI transformation, and the audit has to name every upstream system the process reads from and every downstream system it writes to, confirming that pipeline monitoring and contract-style schemas sit at the point of ingestion, and that they account for what happens when a source schema changes, a feed goes stale, or an upstream system throws an error back instead of data. In processes that cross multiple departments, this linkage check has to extend across every handoff between agents, because a procurement agent feeding a scheduling agent feeding a logistics agent creates a new point of cascading risk at each boundary.

The baseline audit by industry: construction, logistics, manufacturing, and retail

The four conditions above apply to any process redesign, but in asset-heavy, operations-intensive industries, each sector tends to produce one dominant failure mode that the audit needs to be built to catch.

In construction, the sharpest baseline failure occurs around energization and procurement readiness. Long-lead equipment status has to be treated as an explicit, live input to the baseline, not a line item buried in procurement paperwork. Large power transformers currently take an average of 30 to 36 months to arrive after an order is placed, roughly 130 to 156 weeks, and generator step-up units run past 160 weeks. P6 schedules describe intent, not what is actually achievable on site, so the baseline audit needs to confirm that procurement, coordination, and commissioning data, not just the schedule itself, is accessible to the agent, because that is where the real risk to the timeline sits.

In logistics, the dominant failure mode is a structural gap between what a company has declared about its digital transformation and what its data actually supports day to day. A useful check reconciles official routing and freight documentation against the workarounds dispatchers actually use on the ground, because an agent will operate inside the real workflow, not the one written down in a policy manual. The condition that makes this possible is clean, timestamped invoice and contract data available in near-real time, and that condition needs confirming before deployment, not assuming.

In manufacturing, the gap tends to open between a successful pilot and a system that actually runs in production. GE Appliances deployed AI agents across its manufacturing, logistics, and supply chain operations, and the prerequisite for doing so was unified operational data running through a single platform that tracks production performance, part genealogy, and workforce activity across lines, shifts, and plants. IoT telemetry, ERP maintenance records, and supply chain data all need to be reachable across on-premises and cloud systems at the same time, and the audit's job is to confirm that linkage for the one process at hand, not for the company as a whole.

In retail, the common mistake is assuming that a central AI rollout plan means every department underneath it is actually ready. The audit has to go down to the level of the individual process, not stop once IT has confirmed a system is technically live. For a retail process redesign, that means confirming the specific inputs the process depends on, SKU-level inventory, supplier lead times, fulfillment status, are reachable in real time by an agent, not just visible later in a reporting dashboard. Fortnum & Mason ran six AI pilots in three months during 2026 through a single implementation partner, Rio, using AI to help staff navigate and surface information across a large catalogue of SKUs. What enabled that pace wasn't a comprehensive data platform built in advance. Product and operational information was already organized and accessible enough to support a bounded deployment, and identifying that minimum organized condition is what a baseline audit is for.

The objection that waiting for clean data is itself a failure mode

There's a real argument made against everything above, and it deserves to be taken seriously. For the right kind of bounded deployment, that argument holds. Waiting indefinitely for a perfect data estate before taking any action is its own failure mode, and companies that treat data readiness as a precondition for starting anything often never start.

The argument breaks down when it treats "just start" as a substitute for checking the four conditions, rather than as a reason to check them quickly and move. All three are preventable with a targeted baseline audit. None of them are preventable by skipping that audit in the name of speed. It generates errors at scale and then has to be unwound, which costs more time than the audit would have.

The resolution isn't a compromise between the two positions so much as a correction to what each one is arguing against. The pre-redesign baseline audit was never a demand for enterprise-wide data maturity before a single agent could run. It's a demand for knowing, specifically, whether the data conditions for one target process are actually met. Where they are, deployment should follow quickly. Where they aren't, the minimum blocking conditions get fixed first, and only those conditions: the audit stays scoped to one process, the fixes stay targeted to what that process needs, and the deployment follows from evidence rather than from a schedule somebody wrote down in advance, so a first AI-first process goes live in weeks instead of a transformation program running for quarters without ever producing a live process.

How to run a process-scoped baseline audit in practice

A process-scoped baseline audit starts by watching the process run as it actually runs today, not as it appears in whatever documentation describes it, and then checks each of the four conditions above against what that observation turns up.

The first step comes before any data system gets opened. Ask the team running the process to walk through how it works today and where it causes pain: the workarounds, the exceptions, the manual fixes that never made it into the SOP. Centralizing process knowledge does help AI systems understand a workflow more accurately, but that only works once someone has actually uncovered what the workflow is, since relying on how it was designed to work leaves the real gaps hidden.

The second step maps every real data input the process touches, built from what the first step surfaced. Any input that fails one or more of these gets classified by how much it matters: blocking means the agent can't act at all without it, degrading means the agent can act but with less reliability, and acceptable means the gap doesn't touch the specific process under redesign.

The third step narrows the list down to the conditions that actually block deployment and fixes those first. The two hurdles that turn up almost every time are fragmented data ownership with no central lineage, fixed by naming clear owners and building quality scoring for the specific domains the process touches, and brittle pipelines that break when a source schema drifts, fixed by adding pipeline monitoring and contract-style schemas at the point of ingestion for those specific pipelines. The output of this step should be a ranked list of blocking gaps with a sequence for fixing them, scoped to the one process being redesigned, not a data transformation roadmap for the whole company.

The fourth step confirms a governance minimum before the agent goes live. The audit needs to confirm that access controls, handling of personally identifiable information, and audit trails are in place at the data layer before the agent starts touching any of it, not as an enterprise governance initiative, but as confirmation that the specific data this agent will use is governed and that its actions will be auditable from day one.

Terminal Use's process audit is built for exactly this scope. Clients show how a process runs today and where it hurts, and that field evidence, rather than a declared project schedule or a data maturity score, determines what gets rebuilt first and whether the data conditions are in place to do it in weeks. An operations team working through these four conditions is running the diagnostic that keeps a redesign from stalling: confirming what data the process actually consumes, whether quality thresholds exist and hold up, who owns each domain involved, and how the systems upstream and downstream connect to the workflow in question. That ground-level inventory is the only foundation solid enough to support an agent handling real operational work from the day it goes live.