The authorative Guide to Industrial DataOps

If you are a digital transformation lead or CIO at a multi-site manufacturing organization, you have almost certainly encountered the term "Industrial DataOps" in the last twelve months. Analyst firms are publishing reports on it. Vendors are rebranding existing products around it. Conference sessions are filling up with it. The category is real and the problem it addresses is real. What is not yet clear, for most buyers, is how to evaluate the platforms competing for the budget.

This guide is not a vendor scorecard. It is a framework for thinking through four decisions that will determine whether your Industrial DataOps investment compounds into a genuine operational advantage or becomes another layer of infrastructure that solves yesterday's integration problem and creates tomorrow's AI readiness problem. Those four decisions are: how the knowledge model gets built, what database architecture underlies the platform, how governance works across many sites and many functional namespaces, and how configuration is versioned and protected.

The platforms discussed here (HighByte Intelligence Hub, MaestroHub, and Timebase Atlas) represent three distinct architectural approaches to the same fundamental challenge. Understanding why the approaches differ is more useful than reading a feature comparison table, because the differences are structural and they compound over time.

Why Industrial DataOps Is Not Just Better Data Integration

Before evaluating platforms, it is worth being precise about what the category is actually solving. The original data integration problem in manufacturing was about connectivity: getting data out of PLCs, historians, SCADA systems, and MES platforms and delivering it to consumers who needed it. That problem is mostly solved. A competent integration team with modern tooling can connect most industrial systems to most consumers. The connectivity problem is not why AI pilots fail and not why digital transformation programs stall.

The problem that Industrial DataOps was invented to address is a different one. It is the absence of meaning. A manufacturing operation can have a perfectly functioning data infrastructure (clean time-series in the historian, consistent topic naming in the MQTT broker, reliable pipelines to the data lake) and still be unable to answer the question an AI agent or a process engineer actually needs answered: why did this batch fail, which downstream processes are affected by this upstream condition, what was the system configuration during this quality event three months ago? Those questions require more than data. They require a model of how the facility works.

The DataOps platforms that stop at connectivity and contextualization are solving the integration problem more elegantly. The platforms that build toward a queryable knowledge model are solving the meaning problem. For most multi-site manufacturers investing in AI capabilities today, those are not the same investment.

The most consequential decision in any Industrial DataOps evaluation is how the model gets constructed and maintained over time. There are three fundamentally different answers to this question across the platforms in this category.

Manual Building
The first answer is fully manual authoring. The domain expert, data engineer, or system integrator opens the platform, configures connections, defines data model structures, and maps sources to model elements by hand. This approach is familiar, predictable, and does not require the vendor to solve the AI problem on your behalf. It also does not scale. A 14-site manufacturer with hundreds of thousands of tags, dozens of domain experts, and processes that change continuously cannot maintain a manually authored model without a dedicated team whose full-time job is keeping the model current. Most organizations do not have that team and should not need to build one.

External Agent
The second answer is an MCP server that exposes the platform's data and models to external AI agents of the customer's choosing. This is HighByte's current approach. The Intelligence Hub exposes an Industrial MCP Server through which AI agents built on Amazon Bedrock, Azure OpenAI, or any compatible framework can make data requests and pipeline configuration calls against the platform. This is a meaningful step forward from a fully manual workflow. It allows a general-purpose language model to assist with certain modeling tasks and to access live and historical data from connected industrial systems. What it does not provide is a domain-aware AI partner that understands how manufacturing processes should be structured, what modeling patterns apply to a specific process type, or how the description a process engineer is giving about a CIP circuit translates into the graph structures that will make future AI reasoning reliable. An MCP server is a connection point. It is not a modeling discipline.

Embedded AI Harness
The third answer is an embedded agent harness specifically built for the manufacturing knowledge modeling task. This is Timebase Atlas's approach. The agent harness is not a feature added to a database. It is the primary mechanism through which the knowledge model gets built. The agent understands manufacturing process structures, the relevant standards (ISA-95, ISA-88, ISA-5.1, and others), and the modeling patterns that apply to different process types. It engages domain experts in structured modeling conversations that progressively externalize what the engineer knows into a form the graph can hold. The engineer remains the authority on what is true about their facility. The agent provides the modeling discipline, the standards awareness, and the translation between operational experience and graph structure.

This distinction has a practical consequence that compounds over time. An organization using a manual authoring tool or an MCP-connected general-purpose AI will find that the hardest part of building a model is not the tool. It is the expertise required to know what to build and how to build it correctly for future reasoning. That expertise either has to live in the vendor's tool or the customer has to hire or develop it internally. An embedded harness built for the manufacturing domain is the only architecture that puts that expertise in the tool.

The database architecture of an Industrial DataOps platform determines not only what the platform can do today but what it will be capable of supporting as AI requirements mature. This is the category where the architectural differences between platforms are most stark, most consequential, and least visible in a feature comparison.

Most Industrial DataOps platforms, including MaestroHub and HighByte, organize data in hierarchical or relational structures. MaestroHub explicitly organizes data in an ISA-95 hierarchy: enterprise, site, area, work center, work unit. HighByte builds asset models that follow a similar structural logic, with instances mapped to model templates and data flowing through pipelines to configured targets. These structures are well suited to what these tools do best: standardizing, normalizing, and delivering data to consuming systems. A hierarchy is an efficient structure for navigation, aggregation, and reporting.

The limitation of hierarchical and relational structures becomes visible when the questions being asked require traversing lateral relationships, the connections between entities that do not fit in a tree. A heat exchanger that serves multiple process lines. A utility system that feeds equipment across different hierarchy levels. A CIP circuit whose operational state affects assets that belong to different parts of the ISA-95 model. A batch recipe whose stages depend on equipment that the hierarchy places in different areas. None of these relationships can be expressed in a tree without duplicating nodes or building workarounds that degrade the structure's usefulness over time.

For a single-site manufacturer running a relatively simple process, this limitation may never become critical. For a multi-site manufacturer deploying AI agents that need to reason about process dependencies, equipment interactions, and the operational context of historical events, it becomes the central architectural constraint. An AI agent pointed at a hierarchical model can retrieve values at a coordinate. It cannot traverse a relationship that the structure does not contain. The questions that matter in a manufacturing operation (why did this happen, what is affected, what were the conditions) require following relationships, not navigating a tree.

Timebase Atlas is built on a custom SOA/CSR backend that is not derived from a third-party graph database. This is a deliberate architectural decision, not a gap. Commercial graph database platforms bring significant overhead (installation complexity, licensing dependencies, resource consumption) that makes them poorly suited to the manufacturing environment, where software needs to run reliably on modest hardware alongside operational systems. Atlas's graph engine was built specifically for millions of objects and relationships at the install footprint appropriate for an industrial deployment, where every entity in the model is typed. Every relationship is named and traversable. The graph can be queried using Cypher over REST, which means both humans and AI agents can ask structural questions about the facility rather than just retrieving values at a given tag name and timestamp.

The practical consequence of this architectural difference is most visible in the AI use case. An AI agent reasoning on a knowledge graph can follow a relationship from a production anomaly to the equipment involved, from the equipment to the recipe state active during the event, from the recipe state to the upstream conditions that influenced it, and from there to the specification the batch was supposed to meet. Each step follows a named, validated relationship in the graph. The agent is not inferring. It is traversing. An AI agent pointed at a hierarchical model with the same data can retrieve values at addresses and look for patterns. The quality of the reasoning those two agents produce is not comparable, and the difference does not shrink as AI models improve. It grows, because better AI models do more with better structure.

Multi-site manufacturers considering a platform that does not use a native graph architecture should ask a direct question before committing: when an AI agent or a process engineer needs to understand how a specific event at one site compares to a similar event at another site, running the same product through comparable equipment, can the platform answer that question by traversing relationships that are already in the model? If the answer requires exporting data, writing custom queries, or asking someone who knows both sites personally, the platform is not providing the cross-site reasoning capability that justifies the investment.

Governance in an Industrial DataOps platform means more than access controls and audit logs, though both matter. It means the platform can answer the question: who owns which part of the model, how do changes get made, how does the model stay current as equipment changes and processes evolve, and how do the contributions of domain experts at 14 different sites compose into a coherent enterprise model without requiring a central architect to hold the whole thing together?

Most hierarchical modeling tools were designed with a central architect in mind. Someone designs the structure, defines the templates, and populates the instances. That approach works at one site with a small, dedicated team. It does not work at enterprise scale, where the knowledge that needs to be captured is distributed across every site, every function, and every equipment domain, and where the people who hold that knowledge are process engineers and maintenance leads, not data architects.

MaestroHub and HighByte both support governance in the access-control and pipeline-management sense. MaestroHub describes a unified, governed data layer with role-based management. HighByte includes data governance capabilities focused on pipeline administration, secrets management, and configuration control. These are operational governance features. They manage the platform, not the knowledge.

What neither platform describes is a federated authoring architecture where the knowledge model is constructed by domain experts across sites and functions, each contributing their slice independently, with those slices composing into a coherent enterprise graph without requiring centralized coordination. That architecture is the only one that scales to the knowledge capture problem a multi-site manufacturer actually has. Timebase Atlas is federated by construction, and the distinction matters enough to spend a moment on what that means structurally.

The model in Atlas is organized into Domains, which are self-contained knowledge graphs that are independently authenticated, independently versioned, and independently queryable. A domain might represent a site, a process function, a product line, or any other meaningful unit of operational ownership. Domain experts author their domain. They do not need to understand the full enterprise model to contribute correctly to their piece of it. When domains are linked, the linkages are explicit relationships in the graph, not assumptions built into a shared hierarchy that breaks when someone at Site 7 names something differently than Site 3.

Above domains, Libraries provide pluggable type definitions serving as the shared vocabulary that makes cross-domain composition coherent. ISA-95, ISA-88, ISA-5.1, ISO 15926, ISA-18.2, CESMII profiles, and others are available as library packs, which means a manufacturer building a model for a batch process does not design the ISA-88 type hierarchy from scratch. They load the library and model against it. A domain at Site 7 and a domain at Site 3 that both reference the same library type are, by construction, comparable, even if their equipment is different, their naming conventions differ, and they were modeled by different engineers who never spoke to each other.

Atlas also includes what the platform calls a System Domain: a queryable graph representation of the organization's own operational philosophy, processes, naming conventions, and change management procedures. This is the governance layer that most platforms do not attempt, not access control, but a structured record of how the organization has decided to think about its operation. When a new site is onboarded, the System Domain provides the template. When a process changes, the System Domain records the decision and the context. When an AI agent is asked why something was done a certain way, the System Domain is the queryable record of that reasoning.

For multi-site manufacturers evaluating governance capabilities, the question to ask is not whether the platform has roles and permissions. Every platform does. The question is whether the governance model is designed for distributed ownership of the knowledge or centralized administration of the data. Those are different problems, and only one of them matches the organizational reality of a 14-site manufacturing operation.

The fourth evaluation category receives less attention in most platform discussions but becomes critical the moment something goes wrong, or the moment an AI agent produces a result that differs from expectations and someone needs to understand why.

Versioning in an Industrial DataOps context means the platform maintains a complete, structured history of how the model was configured at any point in time: which types were defined, which instances existed, which relationships were active, and which values those relationships held. This is not the same as storing time-series data in a historian. The historian records what the sensors measured. Versioning of the model records what the model said those sensors meant, which equipment they belonged to, and how those equipment pieces were related to each other, at the moment any historical query or AI analysis was run.

Without model versioning, an AI agent analyzing a quality event from six months ago is reasoning on the current model as if it applies to the past. If equipment was reconfigured, a process line was modified, or a domain expert updated the type definitions since that event, the agent's reasoning reflects the current state of the model, not the state of the operation at the time the event occurred. In manufacturing, where equipment configurations change, recipes are revised, and process improvements are implemented continuously, this is not an edge case. It is the normal operating condition.

MaestroHub's documentation does not describe a model versioning capability beyond standard data governance features. HighByte's pipeline management includes configuration management for pipeline structures, but does not describe a time-aware model versioning system that supports historical queries in the context of the model state at the time of past events. It is recommended that you reach out directly to both MaestroHub and HighByte for information on how they address this real-world manufacturing dilemma.

Timebase Atlas addresses this through Git-backed configuration. The full Atlas configuration (types, instances, relationships, domain definitions, library references) is maintained as a Git repository. Every change to the model is a commit. The history of every change is available for inspection, rollback, and comparison. This means the model state at any historical moment is recoverable from the Git history, which makes historical AI reasoning on the correct model state technically feasible rather than aspirational. Git-backed configuration also provides a governance trail that satisfies operational and regulatory requirements in ways that database snapshots and proprietary backup formats do not. Every change has an author, a timestamp, a commit message, and a diff showing exactly what changed. Rollback is a standard Git operation, not a vendor-specific recovery procedure. The configuration can be managed through standard software development workflows (branch, review, merge), which means the same organizational practices that govern software code can govern the knowledge model.

What Git provides is the floor. Because Atlas allows users to define any properties they want on any type, a manufacturer can extend the model itself into a self-documenting change record without building any additional tooling. Every equipment instance, every process definition, every relationship in the graph can carry properties that track when it was last modified, who changed it, why the change was made, and where the previous version of the supporting documentation lives. That last property is particularly useful in practice: rather than storing historical documentation inside the graph, the model carries a pointer to wherever the prior version resides, whether that is a document management system, a versioned PDF, or a specific Git commit. The graph becomes the index and navigation layer for the documentation ecosystem, not a replacement for it.

The consequence of combining Git-backed configuration with entity-level change properties is that the knowledge graph itself becomes the audit record, not a system that produces an audit record when asked. An AI agent reasoning about a quality event from six months ago can traverse to the equipment involved, read the modification history on that entity's model entry, identify that a type definition changed in the weeks before the event, follow the documentation link to the previous version, and surface all of that as part of its reasoning without anyone assembling the picture manually. The change history is operational context the agent can reason on, not a separate trail it cannot see.

For multi-site manufacturers with quality management requirements, change management procedures, or regulatory compliance obligations, this is not a minor convenience. The ability to demonstrate exactly what the model said at the time of a specific production event, including the complete change history that led to the current model state and the authorship trail behind every modification, is the kind of operational record that audit teams require and that proprietary backup systems rarely provide in a form that is independently verifiable. The difference between a compliance record and a compliance posture is that the record is produced when asked, and the posture means it was never not there.

The Multi-Site Warning: What Happens When the Model Is Not a Graph

Everything described above converges on a warning that multi-site manufacturers should take seriously before committing to a platform architecture.

The multi-site manufacturing environment has a property that single-site evaluations do not surface: dynamic relationships that change across sites, across time, and across functional perspectives. The relationship between a piece of equipment and the process it serves is not static. Equipment is shared across process lines. Recipes change by product. Maintenance events alter the operational context of downstream measurements. Utility systems have dependencies that cut across the ISA-95 hierarchy. At one site, a competent engineer can hold these relationships in their head. Across 14 sites, with AI agents expected to reason across all of them, those relationships need to be in the model.

A hierarchical model cannot hold these relationships without workarounds that degrade over time. The workarounds are not theoretical. They are the actual artifacts that accumulate when a hierarchical tool is pushed to represent a network. The artifacts are predictable: duplicated nodes, custom attributes that encode relationship information in a format the tool was not designed to query, spreadsheets maintained alongside the model to record connections the tool cannot hold, and documentation that lives outside the platform because the platform has no structure for it. These workarounds work, after a fashion, for reporting and navigation. They do not work for AI reasoning, because an AI agent cannot traverse a relationship that has been encoded as a text string in a custom attribute field.

The consequence for AI enablement is direct and severe. An AI agent deployed against a hierarchical model at a multi-site operation will be able to retrieve values, aggregate across levels of the hierarchy, and generate reports that reflect the data at each node. It will not be able to answer questions that require following a relationship the hierarchy does not contain. It will not be able to compare a quality event at Site 7 to a structurally similar event at Site 3 without someone building a custom query that encodes the cross-site relationship the model lacks. And as the model grows, as more sites are onboarded, more equipment is connected, more processes are added, the relationships the hierarchy cannot hold grow faster than the relationships it can. The gap between what the AI is asked to do and what the model enables widens over time, not shrinks.

Why Timebase Atlas Made the Choices It Made

The four architectural decisions that distinguish Timebase Atlas from other platforms in this category are not independent product decisions. They reflect a single coherent answer to the question of what a manufacturing knowledge platform needs to be to support AI reasoning at multi-site scale.

The custom SOA/CSR graph engine was built because no commercial graph database provides the combination of graph-native modeling, relationship traversal, and industrial deployment simplicity that the manufacturing environment requires. A graph database that requires a dedicated infrastructure team to operate is not compatible with the operational reality of a manufacturing site. Atlas's graph engine was built to run on modest hardware, alongside operational systems, without introducing a new infrastructure discipline that manufacturing IT teams are not equipped to support.

The federated domain approach with libraries composed of libraries was designed because the knowledge that needs to be captured in a manufacturing model is not owned by any single team or architect. It is distributed across sites, functions, and experience levels. A modeling architecture that requires centralized design fails before the first site is fully modeled. Atlas's domain model puts authoring authority where the knowledge lives, meaning the domain experts who understand their piece of the operation, while providing the shared vocabulary and composition rules that make independently authored domains coherent at the enterprise level.

The embedded AI harness with manufacturing-specific Skills was built because the bottleneck in knowledge model development is not tool complexity. It is the distance between how domain experts think about their facility and how a graph model needs to represent it. A general-purpose language model connected via MCP does not close that gap. An agent that understands manufacturing process structures, knows the relevant standards, can read the organization's existing documentation, and knows how to conduct a modeling conversation that produces graph-ready outputs closes it substantially. The agent is leverage on the engineer's expertise, not a substitute for it.

The Git-backed configuration was designed because a knowledge model that cannot be versioned is not a governed knowledge model. It is a current snapshot. For AI reasoning on historical events, for regulatory compliance, for rollback when a change introduces errors, for change management workflows that give model updates the same rigor as software code. Git is not a clever implementation choice. It is the governance architecture that makes the model trustworthy over time.

Taken together, these four decisions reflect a view of what Industrial DataOps needs to become as AI requirements mature: not a better integration platform, not a more convenient contextualization tool, but a governed, queryable, AI-native knowledge graph that gives manufacturers the semantic foundation their AI investments require. The category is real. The problem is real. The architectural choices made now will determine whether the investment compounds or constrains.

Beyond DataOps: What Atlas Makes Possible When the Model Is the Platform

The four evaluation categories in this guide (how the model gets built, the underlying database architecture, multi-site governance, and versioning) are the right lens for comparing Industrial DataOps platforms on their own terms. But for manufacturers evaluating Timebase Atlas specifically, stopping at DataOps as the category understates what the platform actually enables. Atlas is not competing to be the best DataOps tool. It is competing to be the operational brain of the manufacturing enterprise, and the distinction matters for how an organization should think about the investment.

Atlas as the Unified Namespace
The UNS movement identified the right ambition; a single, decoupled place where every producer publishes and every consumer subscribes, organized by a consistent naming structure that reflects the actual operation. What most UNS implementations delivered was a broker with a topic taxonomy. The transport works. The naming convention holds, more or less. What is absent is the queryable model of what everything means, how everything relates, and what the historical structure of the operation was at any point in time.

Atlas is what the UNS movement was pointing at before the architecture existed to deliver it. The knowledge graph is the namespace. Not a topic string encoding meaning that consumers have to parse, but a structured, queryable model where types are defined, relationships are named, and the operation's full context is accessible to any consumer without domain knowledge of the underlying systems. The broker layer that a manufacturer has already built continues to handle real-time transport. Atlas sits above it as the semantic namespace, adding the four things a broker cannot provide: a queryable ontology, traversable relationships, time-aware structure, and a model that composes across sites and organizational boundaries.

For manufacturers who have invested in MQTT infrastructure and topic taxonomies, this is not a rip-and-replace proposition. The existing transport investment stays intact. What changes is that consumers stop parsing topic strings and start querying a model that already knows what the strings meant. The shift in what downstream applications can do with the data is not incremental. An application that queries a knowledge graph for the current state of a process, including the equipment involved, the recipe active, and the upstream conditions present, is doing something categorically different from an application that subscribes to a topic and receives a number.

Building MES Components Directly in the Model
One of the less obvious capabilities that Atlas's flexible property and relationship system enables is the construction of manufacturing execution logic directly within the knowledge graph. Because Atlas imposes no constraints on what properties a type can carry or what relationships can exist between instances, a manufacturer can model not just the static structure of their operation but its dynamic execution logic.

A work order, for example, is not just a record in an ERP. It is a relationship between a product specification, a set of equipment, a set of process conditions, a time window, and a set of quality requirements. All of those are entities in an Atlas knowledge graph, and the work order is a relationship that connects them with properties that carry status, sequence, operator assignment, and execution history. A batch record is the same structure with time-stamped values attached at each step. A recipe is a typed set of relationships between process stages, each carrying the conditions that govern transitions between them.

What this means in practice is that manufacturers can build lightweight MES components directly into their Atlas model rather than maintaining a separate MES system that integrates against the knowledge graph through yet another connector. The Atlas model becomes the execution record, the equipment allocation system, the recipe manager, and the batch history in a single queryable structure. For manufacturers running legacy MES platforms that were never designed to expose their data in a form downstream systems could use, Atlas provides a path to capturing the same execution logic in a model that is natively queryable, natively AI-readable, and natively federated across sites.

This is not a claim that Atlas replaces every MES capability in every context. Manufacturers running highly regulated production processes with deep MES integrations into equipment control systems have requirements that a knowledge graph platform is not positioned to address at the control layer. What Atlas (when combined with Flow Software's Infohub) can replace is the MES's role as the record of what happened, why it happened, and how the production execution relates to the equipment, the recipe, and the quality outcome. That record, moved into a knowledge graph, becomes something an AI agent can reason on rather than a database a developer has to query with custom code.

Solving the N-Times-M Integration Problem at Its Root
The N-times-M integration problem is familiar to every digital transformation lead in manufacturing. N data sources multiplied by M consumers equals an unbounded number of bespoke integration projects, each fragile, each undocumented, each maintained by whoever built it and broken by whoever changes the source. The conventional DataOps response to this problem is to build a better pipeline: standardize the transport, normalize the formats, reduce the integration overhead per project. That is a real improvement. It does not solve the underlying problem.

The underlying problem is not that integrations are hard to build. It is that every consumer integrates against every source because there is no shared model that makes the data meaningful to all of them at once. Each consumer needs its own integration because each consumer needs its own interpretation of what the raw data means in its specific context. A dashboard that shows equipment status needs to know what each tag represents and what the normal range is. An AI agent that reasons about a batch failure needs to know how the equipment relates to the recipe and the process conditions. A quality management system that records a deviation needs to know which production event generated the data and which specification it was measured against. Each of those contexts requires a bespoke integration because none of the source systems carry the context natively.

Atlas dissolves the N-times-M problem at its root rather than making it cheaper to manage. When the knowledge model captures what every data point means, how every entity relates to every other entity, and what the operational context of every measurement is, every consumer reads from the same model rather than integrating against the same sources. A new dashboard is a query against the model. A new AI use case is a query against the model. A new quality reporting requirement is a query against the model. The integration work that previously multiplied with every new consumer becomes a one-time act of building the model, after which the marginal cost of adding a consumer approaches zero.

That is a different value proposition from any DataOps platform whose architecture routes data through better pipelines. Better pipelines reduce N-times-M. A knowledge model eliminates it. For a multi-site manufacturer whose digital transformation budget has been consumed by integration projects that never quite finished, the distinction between reducing and eliminating is the difference between a platform that helps and one that changes the structure of the problem.

The Compounding Problem

The thread connecting all of these capabilities is that they compound rather than add. A manufacturer who deploys Atlas to solve the integration problem is, as a byproduct of that work, building the semantic namespace that completes their UNS investment. A manufacturer who builds MES execution logic into the knowledge graph is, as a byproduct of that work, creating the structured training corpus that will make their future AI models facility-specific rather than generic. A manufacturer who solves the N-times-M problem by building a shared model is, as a byproduct of that work, creating the AI surface that lets an agent reason across every system in the operation without a custom integration for each one.

No DataOps platform whose architecture is a pipeline produces this compounding.

A pipeline moves data from where it is to where it needs to go. A knowledge graph turns data into something that means the same thing to every consumer that reads it, and something that an AI agent can reason on without being told in advance what it will need to know. That is what Atlas is building toward, and it is the reason the evaluation categories that matter most for a multi-site manufacturer investing in AI are not the ones that appear on a DataOps feature comparison table.