Field instruments, control, supervision, MES, ERP and now cloud services are bought separately, owned by different departments and validated as if unrelated. A batch record is assembled across all of them — and so is the evidence an inspector will ask for. This page is about the whole, rather than the parts.
ISA-95 is useful less as a standard to comply with than as a way to have an unambiguous conversation about where a problem sits and who owns it. Most of what follows only becomes discussable once everyone is using the same names for the same layers.
Three bodies of work that are usually separated and should not be. Compliance is the thread: the data crossing these boundaries is the data your validation and data integrity position rests on.
Batch and material data, order confirmation, consumption postings, genealogy. The interface defined before the integrator starts: which system owns which object, what is confirmed, and what happens when a message fails overnight. This seam is a frequent source of overrun in integration projects.
Recipe and phase structure, parameter download, results and exceptions returning. Designed properly, a new product becomes a recipe change; designed without that structure, it becomes an automation project each time.
Tag design, alarm rationalisation, acquisition rates, and what reaches the historian in a form that can still be queried a year later.
Process cell, unit, equipment module, control module on one side; procedure, unit procedure, operation, phase on the other. Most recipe difficulties share a root cause: procedural logic written into equipment, or equipment assumptions written into recipes.
General, site, master and control recipes, with a clear owner for each. Getting the master recipe boundary right is what keeps validation effort proportionate as the portfolio grows.
Analytics, historian tiers, MES modules and AI services increasingly sit in Azure or AWS while control stays on site. That hybrid introduces a new boundary — data leaving the qualified estate. We design the flow, the segmentation and the supplier position as one problem rather than three.
Five systems validated in isolation leave the interfaces untested, which is precisely where inspectors look. We define the validated boundary across layers, test the data path end to end, and write traceability that follows the record rather than the purchase order.
ALCOA+ applied to a record assembled from four systems: consistent time synchronisation, one user identity model, audit trail coverage that does not stop at a layer boundary, and a defined answer to where the raw data lives.
Architectures drift: an interface is patched, a tag is added, a cloud service updates. Periodic review designed around the data path rather than around individual systems is what keeps the picture accurate between inspections.
MES and ERP are not agreeing, or the batch engine is returning unexpected results. Defining the interface properly usually recovers the schedule more effectively than adding people to the project.
An inspector asked where the raw data lives, or why two systems disagree on a timestamp. That is an architecture question raised in compliance terms, and answering it requires both competences.
The least expensive moment to get all of this right. Architecture, recipe model, cloud boundary and qualification strategy decided together, before anything is procured.
That is almost always how these conversations start, and it is usually enough for us to say whether the fix is an interface, a data model, or a decision that has not yet been taken.