Anthony Vigliotti, Chief Product Officer at Adlib, identifies a foundational distinction in enterprise AI that most industrial organizations have not yet fully reckoned with. In brownfield manufacturing and regulated industrial operations, the cost of that gap is becoming harder to ignore.
The distinction is this: a document can be treated as a data source, or it can be treated as evidence. These are not the same thing. They lead to different architectures, different governance postures, and ultimately, different answers to the question that every serious industrial AI program will eventually face: can you defend what your AI decided, and show the complete chain of provenance that led to it?
Most industrial AI programs today, particularly those being built on top of brownfield operations, are designed around the data source model. They extract what they need from documents, structure it, push it downstream, and move on. The document served its purpose. The data is in the system. The pipeline advances.
That design is not wrong for every context. But in brownfield manufacturing and industrial operations, where documents carry decades of operational history, where compliance obligations extend years into the future, where safety decisions and regulatory filings must be traceable and defensible, treating documents as data sources creates a governance failure that is structural, compounding, and largely invisible until the moment it becomes a problem.
Understanding why requires being precise about what each model actually means, and what it costs when the wrong one is applied. This is also why so many AI initiatives stall before delivering value, because the underlying document layer is not AI-ready in the first place.
What It Means to Treat a Document as a Data Source
The data source model is the design philosophy that most data extraction platforms and document processing pipelines were built around. Its logic is sequential and terminal: a document arrives, it is classified, relevant fields are extracted, the structured data is exported to a downstream system, and the document’s active role in the process ends.
Under this model, the document is raw material. Its value is in what can be mined from it. Once that value has been extracted, the document itself becomes an operational afterthought, typically archived somewhere, increasingly disconnected from the data it generated, and functionally inaccessible to the AI, analytics, and compliance systems that now depend on what came out of it.
This model was designed for a specific era and a specific problem: reducing the manual effort of data entry at scale. For that purpose, it works. Invoices get processed. Claims get filed. Records get digitized. The operational throughput is real. This extraction-first mindset reflects how most traditional document processing systems were designed, focused on throughput rather than trust.
But the data source model makes three assumptions that do not hold in brownfield industrial operations.
It assumes the document’s value is fully realized at the moment of extraction. In industrial operations, this is rarely true. A maintenance record does not stop being operationally relevant the moment its timestamp and action code have been written to the MES. It remains part of the evidentiary basis for every future maintenance recommendation, every safety investigation, every audit of that asset’s operational history. Its value is ongoing, not terminal.
It assumes that extracted data is a sufficient substitute for the original document. It is not. Extracted data is an abstraction. It captures field values, but not the spatial relationships in an engineering drawing, not the annotation context in a HAZOP study, not the sign-off chain in a corrective action record, not the revision markers that distinguish the current version of a procedure from the one that was in place during a specific production run. When AI systems reason over extracted data that has been severed from these contextual layers, they are working from an impoverished representation of the operational reality that the original document actually reflects.
It assumes the link between extracted data and source document can be reconstructed after the fact if needed. In practice, it usually cannot, not reliably, not at scale, not with the precision that a regulatory audit or a safety investigation requires. Once the data and the document have been separated into disconnected systems, the reconstruction is manual forensics. It depends on naming conventions, timestamp matching, version assumptions, and institutional memory, none of which constitute an evidentiary chain.
What It Means to Treat a Document as Evidence
The evidence model starts from a different premise: that in regulated industrial operations, documents are not raw material to be consumed and discarded. They are artifacts with legal standing, operational permanence, and ongoing compliance value. They are the institutional record of what was decided, what was approved, what was done, and why. They are what organizations produce when a regulator asks “show me”, and they need to be ready to answer that question years after the fact, not at the moment of processing alone.
Under the evidence model, a document is treated as something that must be:
Preserved with fidelity: stored and maintained in a format that faithfully represents the original: its structure, its visual logic, its context, its revision state. A PDF/A rendering that preserves the engineering drawing as a navigable artifact is not a compliance formality. It is the foundation of an evidentiary chain that holds up under scrutiny. An extraction that discards the visual layer to capture only field values is evidence reduction, not evidence preservation.
Validated before its contents are trusted: verified against documented rules, classification standards, and operational expectations before any downstream system acts on it. The moment a document’s content reaches a digital twin model, a predictive maintenance algorithm, or a regulatory reporting system, that system begins treating the content as fact. Validation has to happen before that moment, not after, and the validation itself must be logged as part of the evidentiary record.
Linked to everything derived from it: so that every data element, every AI output, every compliance decision that traces back to a document carries a navigable citation to the specific document, revision, page, and section that generated it. This is what makes AI outputs defensible in industrial contexts. Not confidence scores alone. Not accuracy metrics alone. The ability to say: here is the recommendation, here is the data that informed it, here is the document that generated that data, here is the validation record for that document.
Accessible and citable after extraction: not archived and orphaned, but available for retrieval and citation by both humans and AI systems for the full duration of the operational and compliance obligation. In manufacturing, that duration is often years. Regulatory retention requirements, safety investigation timelines, product liability windows, and ISO audit cycles all extend well beyond the moment a document was initially processed. The evidence model requires that documents remain first-class operational assets throughout that entire horizon.
Auditable throughout their lifecycle: with a clear, documented chain of custody that shows what happened to the document, what was extracted from it, what confidence levels applied, where human review occurred, and what decisions it informed. This is the difference between a processing record and an evidence trail.
Data Source Model vs. Evidence Model: Key Differences
| Dimension | Data Source Model | Evidence Model |
| Document role | Raw material consumed at extraction | Artifact with ongoing operational and compliance value |
| Post-extraction status | Archived, disconnected from derived data | First-class operational asset, governed and accessible |
| Source linkage | Severed after extraction | Maintained through every downstream handoff |
| Validation | After downstream use, if at all | Before downstream handoff, logged as part of evidentiary chain |
| Audit capability | Manual forensic reconstruction | Structured, navigable citation trail |
| Regulatory readiness | Reassembled under pressure from disconnected systems | Audit package as structured pipeline output |
| Scaling behavior | Multiplies governance debt with each new facility | Extends a correct governance architecture |
Why Does the Evidence vs. Data Source Distinction Matter Most in Brownfield?
Brownfield facilities face the highest stakes because they carry decades of accumulated documentation in legacy formats that were never designed for AI consumption, managed by systems built when document management meant printing and filing, spanning organizational changes, technology migrations, and operational evolutions that each left their own documentary residue. Every AI program built on that documentation inherits the design decisions made about how those documents were processed.
Greenfield facilities can, in principle, design evidence-grade document handling from day one, establishing policies, formats, and pipeline architectures before any documents exist and before any AI systems depend on them.
Brownfield operations cannot afford that luxury. They are working with the documentation they have: decades of accumulated operational history across disconnected systems.
In that environment, the gap between the data source model and the evidence model is not a theoretical governance concern. It is a daily operational reality that manifests across every AI system in the facility.
Consider what that stack actually looks like in a brownfield facility. Predictive maintenance AI reasoning over maintenance histories where the source records are inaccessible. Digital twin models built from P&ID extractions where the engineering drawing context has been discarded. Safety management systems making procedure-based recommendations from SOPs that were processed without revision-level citation anchors. MES and PLM systems carrying production data that originated in engineering change orders now archived in disconnected silos. Operational AI assistants retrieving procedure guidance from knowledge bases built on extracted content severed from its source documents. Regulatory compliance programs dependent on permit conditions and reporting thresholds extracted from regulatory documents now disconnected from the data they generated.
In each case, the data source model produced structured data that reached the downstream system. And in each case, the evidence model would have produced something different: structured data plus provenance, plus validation record, plus source citation, plus the preserved document that makes all of it verifiable.
The difference between those two outputs is not visible during normal operations. The predictive maintenance model runs. The digital twin updates. The compliance report gets filed. Everything appears to be working.
The difference becomes visible at three specific moments.
The first is a safety incident or near-miss investigation. Investigators reconstruct the AI recommendation chain and need to verify that every document input was complete, current, accurate, and correctly extracted. Under the data source model, that reconstruction is manual, imprecise, and dependent on records that may have been silently degraded at extraction. Under the evidence model, the citation trail is navigable.
The second is a regulatory audit or inspection. The regulator asks to see the document trail behind a specific compliance decision or production record. Under the data source model, that trail requires manual assembly from disconnected systems, with no guarantee of completeness. Under the evidence model, the audit package is a structured output of the pipeline, not a reconstruction.
The third is an AI scaling decision. The organization wants to extend an AI program from one facility to five, or from one process to twenty. Under the data source model, scaling multiplies the governance debt already embedded in the architecture. Every new document processed without citation anchors, without source linkage, without validation records, adds to the evidentiary gap that will need to be addressed eventually, under pressure, at cost. Under the evidence model, scaling extends a governance architecture that was designed correctly from the start.
What Does the Evidence Model Require Architecturally?
The evidence model requires an upstream architectural layer, inserted in front of every industrial AI system, that normalizes, validates, and preserves documents before they become data. This is not resolved by adding more logging. It is not resolved by better downstream validation. It is not resolved by requiring higher accuracy thresholds on extraction. All of those things are valuable, but they address symptoms rather than the design philosophy that creates the problem.
The architecture implication is upstream. It requires inserting a layer in front of every industrial AI system (in front of the predictive maintenance platform, the digital twin, the MES/PLM integration, the operational assistant, the safety management system, the regulatory compliance program) that treats every document as evidence before it becomes data.
That layer normalizes and preserves. It converts the heterogeneous document population of a brownfield facility (CAD drawings, P&IDs, scanned maintenance logs, legacy SOPs, proprietary engineering formats) into fidelity-preserving, machine-navigable outputs that retain the structure, context, and visual logic of the originals. Not extracted fields alone. The documents themselves, in a form that AI can navigate and humans can verify.
It validates against documented rules before downstream handoff. It establishes accuracy thresholds by document class, routes exceptions to human review with logged decisions, and produces a validation record that becomes part of the evidentiary chain for every document it processes.
It maintains source linkage through every downstream handoff. Every extracted data element carries a citation anchor back to its origin. That anchor travels with the data into the predictive maintenance model, the digital twin, the MES, the operational assistant, so that when any of those systems produce an output, the evidence trail is intact and navigable.
It keeps the document as a first-class operational asset after extraction. The source document does not become an orphan. It is preserved, governed, and available for retrieval and citation for the full duration of the applicable compliance obligation. The data and the document remain linked, not separated into disconnected archives that lose touch with each other over time.
This is what an AI Accuracy & Trust Layer (or an AI Production Layer) is designed to do. It is the architectural expression of the evidence model, the layer that ensures brownfield industrial AI is built on documents that can be trusted, traced, and defended, rather than documents that were consumed and discarded. Early implementations of this approach have shown 40 to 60 percent fewer exception queues and 30 to 50 percent faster document cycle times.
The Question That Defines the Architecture
The evidence model versus the data source model is ultimately a question about what kind of industrial AI program an organization is building.
A data source architecture produces AI that performs well under normal conditions, improves throughput, and delivers measurable operational value, until the moment it needs to be defended. At that moment, the governance gaps embedded at the design level become visible, expensive, and sometimes irreversible.
An evidence architecture produces AI that performs well under normal conditions and also holds up under scrutiny. It can be audited. It can be cited. It can answer the questions that regulators, investigators, and compliance leaders will eventually ask. It is both an operational system and an accountable one.
In brownfield manufacturing and industrial operations, the stakes are high enough that the second standard is the right one. The documents in these environments are not raw material. They are the operational and compliance record of facilities that have been running, in some cases, for decades. They describe what was built, how it was maintained, what safety controls were in place, and what compliance obligations were satisfied. They are evidence, and they need to be treated accordingly.
The industrial AI programs that will prove durable over the next decade will be the ones that build on that foundation. The ones that treat documents as evidence from the start, rather than retrofitting governance onto a data source architecture after the costs of that choice have already materialized.
That is the architectural decision that matters most in brownfield industrial AI right now. And it is the one that is made, or missed, in the design of the layer that sits in front of every system in the stack.
Anthony Vigliotti will explore these ideas further at the upcoming IIoT World AI Manufacturing Day panel, “From Brownfield to Agentic: Retrofitting Brownfield Plants with an Accuracy & Trust Layer for Trusted Action.” Joining Chris Huff (Adlib) and Mathias Oppelt (Siemens), the discussion will focus on how manufacturers can move beyond extraction-first architectures and instead build an accuracy and trust layer that makes AI outputs traceable, defensible, and ready for real-world operational decisions, especially in complex, regulated environments.
Sponsored by Adlib Software.
Frequently Asked Questions
1. What is the difference between treating a document as a data source vs. treating it as evidence?
A data source model treats a document as raw material, extract its useful content, structure it, push it downstream, and the document’s role is effectively complete. An evidence model treats a document as an artifact with ongoing operational and compliance value, preserving it with fidelity, validating it before use, linking every derived data element back to its source, and keeping it accessible and citable for the full duration of its regulatory and operational life. In regulated industrial environments, the evidence model is the correct standard.
2. Why does this distinction matter specifically in brownfield operations?
Brownfield facilities carry decades of accumulated documentation in legacy formats across disconnected systems. Every AI program built on that documentation inherits the design decisions made about how those documents were processed. If those decisions were made under a data source model (extract and discard) the governance gaps compound over time across every system in the operational AI stack. Brownfield operations also face the longest regulatory retention horizons and the most complex audit trail requirements, which makes the evidence model operationally necessary.
3. Which industrial AI systems are most affected by the data source vs. evidence distinction?
Every major AI system in a brownfield facility is affected, predictive maintenance and asset health AI, digital twin platforms, safety and incident management systems, MES/ERP/PLM integrations, LLM-based operational assistants, and regulatory compliance programs. Each one depends on document-derived content, and each one is more defensible, more accurate, and more auditable when that content is treated as evidence rather than extracted data.
4. What does a Document Accuracy & Trust Layer do that traditional data extraction doesn’t?
Traditional data extraction optimizes for extraction throughput and treats documents as disposable once their data has been harvested. A Document Accuracy & Trust Layer sits upstream of other industrial and AI systems, converting documents into fidelity-preserving, validated, machine-navigable outputs with documented provenance, accuracy signals, and citation anchors that link every extracted data element back to its source document. The document remains a first-class operational asset after extraction, not an archived orphan.
5. Is this a replacement for existing document management or data extraction systems?
No. A Document Accuracy & Trust Layer is designed to integrate in front of existing systems, improving the evidence quality of what those systems receive without requiring them to be replaced. It is an additive architectural layer, not a replacement.
6. What is the first step for a brownfield facility assessing its document evidence posture?
Select one operational AI system (a predictive maintenance model, a digital twin, or a compliance reporting program) and trace a sample of its outputs back through the data inputs to the source documents that generated them. Assess whether those documents are accessible, fidelity-preserving, validated, and structurally linked to the data they produced. The gaps that exercise surfaces will define the governance remediation priority for the rest of the stack.
About the author
