Starting an Industrial DataOps project means running a deliberately bounded first deployment—one asset class, fifty to two hundred signals, two source systems, one semantic model, and one downstream consumer—measured against acceptance criteria agreed before any work begins. Thirty days is enough for that scope, and the constraint is the point: a pilot that cannot fail cannot prove anything, and a pilot without a defined boundary expands until it becomes an eighteen-month program with no decision gate.
Most first projects go wrong in scoping rather than execution. Teams connect everything they can reach, build dashboards that impress a steering committee, and arrive at month four with no reusable model, no quality baseline, and no criteria for whether to proceed. This specification is the alternative: what to include, what to exclude, a week-by-week plan, the pass and fail conditions, the roles required, and the gates that govern scale-out. It is written for integration architects who need a defensible plan and for transformation leaders who need to know what they are approving.
An Industrial DataOps project starts with a scope contract rather than a technology selection. The contract names the asset class, the signal count, the source systems, the single consumer that will use the output, the quality thresholds the data must meet, and the decision that will be made on day thirty.
This ordering matters because the first project’s purpose is not to deliver a use case—it is to prove that the architecture produces reusable data. A dashboard built from hand-mapped tags is a demonstration; a governed asset model instantiated against real machines and consumed by a real application is evidence. Only the second tells you anything about site fifty.
The prerequisite work is small but non-negotiable. You need an inventory of the assets in scope with their control platforms and protocols, confirmation that network paths and change-control windows exist, a time synchronization source, agreement on canonical naming and units, and a named owner for the semantic model. Teams that skip the naming agreement spend week three renegotiating it.
It also helps to be explicit about what Industrial DataOps is delivering, because expectations set by adjacent categories cause most of the confusion in kickoff meetings. Understanding how a PLC tag becomes a governed data product gives everyone the same picture of the pipeline stages the pilot will actually build, and clarifies that the historian, the SCADA system, and the unified namespace all keep their existing roles.
The scope contract has five inclusions and five deliberate exclusions. Getting both lists right is what keeps thirty days achievable.
Include one asset class rather than one line, because the objective is a reusable model. A pump, a filler, a CNC machine, or a compressor—something that exists in multiples across the estate, so the model has obvious reuse value. Include fifty to two hundred signals, enough to be representative and few enough to validate individually. Include two source systems of different types, typically a PLC or OPC UA server plus a historian or MES, because single-source pilots hide exactly the normalization problems that break at scale. Include one semantic model with canonical attribute names, units, and data types. Include one downstream consumer with a real user attached, such as an OEE calculation, a condition-monitoring view, or a data science team’s feature pipeline.
Exclude anything that expands the surface area without adding evidence. Leave out additional asset classes, however easy they seem. Leave out write-back to controllers, which needs its own safety review and should never ride along in a first project. Leave out custom application development—the consumer should be something that already exists. Leave out cloud migration decisions beyond the single consumer’s needs. And leave out any second site, which belongs to the scale-out phase and is a separate gate.
Selecting the right asset class is the highest-leverage decision. The best candidate has a known operational pain, exists at multiple sites, has reasonably documented tags, and has a stakeholder who will use the output. Choosing the most technically interesting machine rather than the most representative one is a common and expensive mistake, and it is worth reading the common myths about Industrial DataOps before finalizing the choice, since several of them shape scoping instincts.
Stand up the platform, connect both source systems, and bring the in-scope signals in raw. Then measure before improving anything: sample rates actually observed versus expected, missing or dead tags, timestamp behavior and drift between sources, unit inconsistencies, and duplicate identities for the same physical measurement. This baseline is what the day-thirty comparison is made against, and skipping it removes the ability to demonstrate improvement. Expect discovery to consume more of the week than configuration—documentation is usually wrong somewhere.
Author the asset model with canonical attribute names, units, data types, and any calculated attributes, then instantiate it against every in-scope machine by binding attributes to local tags. Where the two source systems disagree on units or timestamps, resolve the conflict in the model layer rather than downstream. By the end of the week, a query against the model should return correct values for every instance, with unbound mandatory attributes treated as defects rather than as gaps to explain. The reference architecture determines where this model resolves, and for a pilot that is almost always the plant edge.
Publish the contextualized model to its destination—a unified namespace topic structure, a database, a cloud endpoint—and connect the single downstream consumer. Then get a real user in front of it. This is where hidden requirements surface: a calculation that needs a field nobody modeled, a latency expectation nobody stated, an access control question nobody asked. Three weeks in is the right time to find these, and adjusting the model here is normal rather than a setback.
Instrument the quality metrics defined in the acceptance criteria, run them for a full production cycle including at least one shift change and ideally one planned stoppage, complete the security review, and assemble the evidence pack. The week ends with a documented pass or fail against the criteria and a scale-out recommendation, not with a slide deck seeking enthusiasm.
Acceptance criteria must be numeric, agreed in week one, and measured rather than asserted. Four categories cover a first project.
Coverage criteria confirm the model is complete: every mandatory attribute bound at every instance, every in-scope signal accounted for as either mapped or explicitly excluded with a reason, and zero unresolved duplicate identities. This is binary and should be at one hundred percent.
Quality criteria confirm the pipeline is trustworthy, expressed as service level objectives with thresholds. Source-to-consumer latency at the ninety-fifth percentile, completeness as the proportion of expected samples received per hour, and freshness as the maximum age of the newest value per asset. Thresholds should be set from the consumer’s actual requirement rather than from what the pipeline happens to deliver—the method for defining these is covered in detail in SLOs for latency, completeness and freshness.
Resilience criteria confirm the deployment survives normal plant conditions. Disconnect the uplink for a defined period and verify buffered data resumes in order with no duplicates and no loss. Restart the edge node and verify recovery without manual intervention. Change one PLC tag address deliberately and verify the failure is detected rather than silently producing nulls.
Reuse criteria are the ones that predict scale and the ones most often omitted. Can the model be exported and reviewed as an artifact? Can a second instance be bound in under a stated number of minutes? Can the full configuration be redeployed from a template to a clean node? A pilot that passes coverage and quality but fails reuse has delivered a working integration, not a scalable architecture, and the honest conclusion is that scale-out will cost per site what the pilot cost.
A thirty-day pilot needs five roles staffed and named, at partial allocation rather than full time. The controls engineer owns tag identification, PLC access, and change windows, and is usually the constraint—nothing progresses without their time. The integration architect owns the model, the bindings, and the platform configuration. The data consumer owns the acceptance definition for the downstream use and must be a real person with a real need. The OT security lead owns network paths, segmentation, and the review. The program sponsor owns the day-thirty decision and clears blockers.
Ownership of the semantic model deserves specific attention, because it is the artifact that persists after the pilot. If nobody owns it, the model drifts as soon as a second site starts adapting it, and the reuse benefit that justified the program disappears. Naming that owner in week one is a one-minute decision with multi-year consequences.
The security review should run in parallel from week one and complete in week four, not begin in week four. It covers network segmentation and which zones and conduits the data traverses, authentication and role-based access for every account created, certificate management and expiry ownership, patching path for the edge node, and audit logging. Treating this as a gate at the end is the single most common cause of a pilot overrunning its thirty days, and the practical guidance in integrating legacy machine data is worth reviewing early because brownfield assets drive most of the security exceptions.
Day thirty produces one of three outcomes, each with a defined next action. Pass means all four criteria categories met and scale-out proceeds to a second site under the same template. Conditional pass means quality or resilience criteria missed for identified and fixable reasons, with a two-week remediation and re-test rather than a scope expansion. Fail means the coverage or reuse criteria could not be met, which is genuinely valuable information: it is far cheaper to learn in thirty days that an approach will not scale than to learn it at site fifteen.
Scale-out gates should be explicit at each step. The second site is the template test—if it takes materially longer than a few days, the template is incomplete and fixing it is more urgent than adding sites. The first site group of five to ten proves grouped deployment and governance. The estate rollout follows only after the model versioning and rollback process is proven, because propagating an unversioned model to fifty plants creates a problem that takes months to unwind.
Between the pilot and the rollout sits the work that makes velocity possible: templated connectivity configuration, a versioned semantic model, deployment automation, and a governance process for change. That preparation is what turns a successful pilot into ninety-five sites in eighteen weeks rather than a successful pilot followed by ninety-five projects. For a fuller view of the sequencing across the whole program, the industrial data playbook covers the phases that follow this specification.
Litmus Edge is built for exactly this scope of first project: connect PLCs, OPC UA servers, historians, and SCADA systems without custom development, normalize tags at the edge, model assets as digital twins that combine static metadata with live data, and publish contextualized output over MQTT, OPC UA, or directly to cloud and database destinations.
The pilot-relevant capabilities are the ones that make the four weeks realistic. Pre-built protocol support removes most of week one’s uncertainty. Digital twins let the model be authored against live signals so unit and mapping errors surface immediately rather than after instantiation. Local store-and-forward makes the resilience criteria testable in a real plant. And because the same configuration becomes a deployment template, the reuse criteria can be demonstrated on day thirty instead of assumed.
Teams that want to validate the approach before a procurement conversation can start with the Litmus Edge Developer Edition and connect real assets in a lab or a single line. That is often the fastest way to de-risk the scope contract, because it converts assumptions about protocol coverage and modeling effort into observed facts before the thirty days formally begin.
The organizations that scale Industrial AI successfully are not the ones that started with the largest program. They are the ones whose first project produced a reusable model, a measured quality baseline, and a decision everyone had agreed in advance to respect.
Start with a written scope contract covering one asset class, fifty to two hundred signals, two source systems, one semantic model, one downstream consumer, numeric acceptance criteria, and the decision to be made on day thirty. Complete prerequisites first: asset inventory, network and change-control paths, time synchronization, canonical naming agreement, and a named owner for the model. Then run four weeks: connect and baseline, model, distribute and consume, measure and decide.
Fifty to two hundred signals is the practical range. Fewer than fifty rarely exercises enough variation to reveal normalization problems, while more than two hundred makes individual validation impractical inside four weeks. The signals should cover one asset class across multiple physical machines rather than one machine exhaustively, because the objective is a reusable model rather than a complete picture of a single line.
Thirty days is achievable for the scope described here and is the right target, because a longer pilot loses the decision discipline that makes it useful. The variables that extend it are network change-control lead times, security review cycles, and controls-engineer availability rather than platform configuration. If the scope cannot fit thirty days, reduce the scope rather than extending the timeline.
Four categories, all numeric and agreed before work starts. Coverage: every mandatory attribute bound at every instance, at one hundred percent. Quality: latency, completeness, and freshness thresholds set from the consumer’s requirement. Resilience: buffered data resumes in order after a defined outage, the node recovers unattended, and a deliberate tag change is detected rather than silently producing nulls. Reuse: the model exports, a second instance binds quickly, and the configuration redeploys from a template.
Five named roles at partial allocation: a controls engineer for tag access and change windows, an integration architect for the model and platform configuration, a data consumer who will actually use the output, an OT security lead for segmentation and review, and a program sponsor who owns the day-thirty decision. The controls engineer’s availability is usually the binding constraint, so it should be secured before the start date.
Unbounded scope. Projects that connect everything reachable produce demonstrations rather than reusable architecture, and arrive at a review with no quality baseline and no criteria for proceeding. The second most common cause is treating the security review as a final gate rather than a parallel workstream, which routinely adds weeks. Both are scoping failures rather than technical ones.
The second site is the next gate and the real test of the template—if it takes materially longer than a few days, the template is incomplete and should be fixed before more sites are added. After that, a group of five to ten sites proves grouped deployment and governance, and estate rollout follows once model versioning and rollback are proven. Adding asset classes and write-back capability are separate, later phases.