In the summer of 2022, a major European chemical manufacturer piloted a retrieval-augmented generation system to assist process engineers with compliance queries against their safety manuals. The system passed internal testing. It answered questions fluently. Then, during a routine pressure-vessel inspection workflow, it retrieved a truncated chunk from a superseded SOP revision and synthesized an approval recommendation that contradicted the current specification by a 12% margin. The system did not know the document was outdated. It retrieved the closest embedding. It answered confidently.
The error was caught manually. But the incident identified a structural problem that prompt engineering cannot fix: RAG is not a compliance architecture. It is a document retrieval architecture with language generation layered on top. In consumer applications, that distinction is acceptable. In heavy industry, it is the distinction between a controlled incident and a regulatory shutdown.
This paper introduces the Policy Graph — a neurosymbolic architecture that replaces probabilistic inference with compiled, executable logic. Where RAG retrieves and summarizes, the Policy Graph traverses and enforces.
Why RAG Fails in Industrial Environments
Retrieval-Augmented Generation was designed to address the knowledge cutoff problem in large language models — to give them access to information that postdates their training or that is too domain-specific to appear in their weights. It accomplishes this by embedding a document corpus into a vector space, retrieving the N most semantically similar chunks at query time, and injecting them into the model's context window before generation.
This is a reasonable engineering solution for many applications. It is not a reasonable solution for safety-critical industrial operations, for five compounding reasons.
Figure 1
RAG Failure Mode Severity Index — Industrial Deployments
Normalized severity index (0–100) for each failure mode based on consequence scope in safety-critical operational environments.
Model invents spec thresholds not present in retrieved documents
Rare operating conditions fall outside embedding similarity radius
Long SOPs exceed context limits; critical clauses silently dropped
Vector index lags document updates; outdated rules enforced
Adversarial text embedded in retrieved chunks redirects model behavior
Illustrative index derived from published AI safety incident analyses and operational risk frameworks. Severity reflects consequence scope under ISO 31000 and IEC 61511 risk classification criteria.
Retrieval does not equal comprehension
A RAG system retrieves the most semantically similar text. It does not retrieve the most logically complete rule set. A query about tensile strength requirements may retrieve ten relevant chunks — without retrieving the eleventh chunk that contains the critical exception clause, because that clause uses different vocabulary.
Generation is not execution
After retrieval, a language model synthesizes a response. It does not run a rule check. The model's output is a statistically likely answer given the retrieved context — not the result of evaluating a condition against a live data point. There is no moment at which the rule is actually enforced.
Embeddings do not track document versions
When an SOP is revised, the vector index must be manually reprocessed. In practice, this creates drift windows — periods during which the system answers based on an outdated corpus. In regulated industries where SOPs can be revised on short notice in response to an incident or regulator request, this drift is not theoretical.
No audit trail maps to a specific rule
When a RAG system approves an operation, there is no record of which rule it applied, which clause it evaluated, or whether the data against which it reasoned matched the current system state. The audit trail is a natural language response from a language model — not a structured record that maps to a source document, a data value, and a compliance threshold.
Context window limits impose a hard ceiling on rule completeness
Industrial SOPs can exceed hundreds of pages. A context window — even a large one — cannot hold an entire regulatory framework plus a query plus a reasoning chain simultaneously. RAG systems address this by retrieving the most relevant chunks. But “most relevant” is a semantic judgment call, not an exhaustive compliance check.
What Is a Policy Graph?
A Policy Graph is a directed acyclic graph (DAG) in which every node represents a compiled industrial policy rule, and every edge represents a dependency relationship between rules. The graph is not learned from data. It is compiled from your documents.
The distinction matters because it means the graph has the same properties as software — not the same properties as a language model. It is deterministic: the same query, evaluated against the same data, always produces the same result. It is auditable: every traversal path is logged with timestamps, node IDs, input values, and source document references. It is updatable without retraining: when a specification changes, the affected subgraph is recompiled from the revised document. The rest of the graph is untouched.
Figure 2
Architecture Comparison: RAG vs. Policy Graph
Two fundamentally different answers to the same question — how does an AI system know whether to approve or halt an industrial operation?
Standard RAG
Critical Gap
No rule is ever executed. The LLM infers compliance from document text — the same way it infers everything else.
Policy Graph
The Difference
Rules are compiled once from your documents. Every answer is the product of rule execution — not model inference.
The Policy Graph sits downstream of LLM-based natural language processing — but upstream of any operational decision. The LLM is used once, at query intake, to identify intent and extract parameters. Once those parameters are extracted, the LLM exits the decision path entirely. Every subsequent step is graph traversal and logic gate evaluation.
The language model understands your question. The Policy Graph answers it.
The Compilation Pipeline
Building a Policy Graph begins with the same inputs that would populate a RAG vector store: your unstructured industrial documents. The difference lies entirely in what happens to them.
Figure 3
Policy Graph Compilation Pipeline
Unstructured industrial documents are compiled — not summarized — into an executable graph of interdependent logic gates.
01
Source Documents
SOPs, specs, regs
02
Entity Extractor
Named constraints
03
Relation Mapper
Dependency edges
04
Logic Gate Compiler
Executable rules
05
Policy Graph
Runtime enforcement
Compilation is a one-time offline process. When SOPs are revised, only the affected subgraph is recompiled — no model retraining, no embedding regeneration, no downtime.
The compilation process has four phases:
Entity extraction
A document parser identifies named constraints within source documents: numerical thresholds, material specifications, procedural preconditions, regulatory clause references. Each extracted entity becomes a candidate policy node. The parser is trained on industrial document structures — clause numbering conventions, specification table formats, BOM hierarchies — to maximize extraction recall.
Relation mapping
Once entities are extracted, the relation mapper identifies dependencies between them. A batch release rule may depend on a lot certification rule, which in turn depends on a material specification threshold. These dependencies become the edges of the graph. The mapper handles both explicit dependencies (cross-references in the document) and implicit ones (shared data fields, temporal ordering constraints).
Logic gate compilation
Each policy node is compiled into an executable logic gate — a function that takes a set of input values and returns a binary outcome: PASS or FAIL. The gate encodes the specific condition from the source document: the threshold value, the comparison operator, the applicable data field, and the source document citation. The gate is version-controlled alongside the document revision that produced it.
Graph assembly and validation
Compiled nodes and edges are assembled into the runtime graph and validated for structural correctness: no cycles, no orphaned nodes, no dangling references. A human review step surfaces ambiguous extractions — cases where the source document is insufficiently precise for unambiguous compilation — before the graph is deployed.
Graph Traversal at Runtime
When an operator submits a query, the Policy Graph runtime resolves it through three sequential phases: intent resolution, parameter extraction, and graph traversal.
In the intent resolution phase, a lightweight LLM classifier identifies which policy domain the query targets — batch release, material approval, equipment certification, process deviation authorization — and maps it to the corresponding root node in the graph. This is the last point at which the LLM participates in the decision.
In the parameter extraction phase, the classifier also identifies the specific operational parameters referenced in the query — part numbers, lot IDs, measurement values — and resolves them against live data feeds from your ERP or MES system. These values become the inputs to the logic gates.
Figure 4
Policy Graph Traversal: From Query to Deterministic Verdict
Each query resolves by traversing a compiled path through policy nodes. Every branch condition is a logic gate — not an LLM inference.
“Approve batch #B-5512 for release?”
Tensile Strength
≥ 1,100 MPa
PASSLot Certification
QC-Manual §4.3
PASSMoisture Content
< 0.02%
FAILBATCH HOLD — RELEASE BLOCKED
1 of 3 policy nodes failed. Execution halted. Alert dispatched to QA Manager.
All three node checks run concurrently. The graph requires every compiled condition to pass before emitting an approval verdict. A single FAIL propagates to a root-level HOLD regardless of other node results.
In the traversal phase, the runtime walks the graph from the root node to its leaf conditions, evaluating each logic gate against the extracted parameters. All nodes are evaluated. A root-level approval verdict requires every leaf condition to pass. A single failure propagates upward, halts execution at the root, and triggers the compiled exception routing path for that policy domain.
The entire traversal produces a structured output record: the verdict, the traversal path, every node evaluated, the input value and threshold at each gate, and the source document citation for each rule. This record is written to an immutable audit log, timestamped and cryptographically signed. It exists before any human sees the answer.
Compliance, Auditability, and the Regulatory Standard
Industrial operations are governed by a complex of overlapping standards — ISO 9001, AS9100, IEC 62443, GMP, ITAR, and sector-specific regulatory frameworks — that share a common requirement: when a system makes a decision, that decision must be traceable to a documented rule, applied to a specific data point, at a specific time, by an identified entity.
Standard AI systems — including RAG architectures and fine-tuned models — cannot satisfy this requirement structurally. The output of a language model is a natural language response. It is not a structured record mapping a decision to a rule, a data value, and a timestamp. Even when a RAG system provides citations, those citations identify the source chunks that influenced the response — not the specific rule that determined the outcome, because no specific rule determined the outcome. The model's probability distribution did.
The Policy Graph satisfies the auditability requirement because the requirement is satisfied structurally — not by post-processing or explanation generation. Every compliance verdict is a rule execution event. The audit record is a byproduct of the architecture, not an afterthought.
| Capability | RAG | Fine-Tuned LLM | Policy Graph |
|---|---|---|---|
| Deterministic output on identical queries | ✗ | ✗ | ✓ |
| Zero hallucination on compiled rules | ✗ | ✗ | ✓ |
| Auditable citation to source document | Partial | ✗ | ✓ |
| SOP update without model retraining | ✗ | ✗ | ✓ |
| Prompt injection resistance | ✗ | Partial | ✓ |
| Regulatory-defensible decision record | ✗ | ✗ | ✓ |
| Runtime rule enforcement (not suggestion) | ✗ | ✗ | ✓ |
Neurosymbolic Design: Why Both Layers Are Necessary
The Policy Graph architecture is explicitly neurosymbolic: it combines a neural language processing layer (for intent resolution and parameter extraction from unstructured input) with a symbolic reasoning layer (the compiled graph) for all consequential decisions. This is not a compromise between the two approaches. It is a deliberate allocation of responsibility based on what each layer does well.
Language models are extremely capable at processing natural language — understanding intent, resolving ambiguity, extracting entities from unstructured text. They are not capable of guaranteeing that a specific rule was applied to a specific value in a specific way. That is a software problem, not a language problem. The Policy Graph handles it as a software problem.
This division also means the neural layer can be upgraded, swapped, or fine-tuned without touching the policy layer. When a more capable extraction model becomes available, it improves the interface — not the rules. The rules are the rules. They do not change because a model changed.
Deployment and Integration
The Policy Graph deploys within your existing infrastructure perimeter. It connects to your ERP, MES, and SCADA systems through a read-write integration layer — querying operational state to populate logic gate inputs and pushing halt signals or structured alerts back into your workflow systems when violations are detected.
Policy graph compilation begins with your existing document library. Most industrial facilities already have the inputs required: SOPs, quality manuals, material specifications, regulatory submissions. The compilation pipeline processes them in a governed review workflow — your domain experts review extracted nodes and approve the graph before deployment. There is no model training, no GPU cluster, and no dependency on a third-party AI provider's uptime.
The initial deployment scope is scoped to a pilot workflow — a single process, a single product family, a single compliance domain. Pilot timelines for most environments run 30 days from document ingestion to live enforcement. Expansion to adjacent workflows reuses the compiled graph infrastructure; the incremental cost of each new policy domain falls as the graph grows.
The Limits of Retrieval
The industrial AI market is converging on a set of capabilities — document Q&A, process co-pilots, inspection analysis — that all rest on the same underlying architecture: retrieve, generate, present. These systems are useful. They are not sufficient for the decision layer of a safety-critical operation, because retrieval is not execution.
The question regulators, quality teams, and engineering managers will eventually be forced to ask is not “does the AI give good answers?” It is “when the AI said this was compliant, was a rule actually checked?” The Policy Graph is the only architecture for which the answer is yes.
Heavy industry does not need smarter retrieval. It needs compilation.
Get Started
See the Policy Graph in Your Environment
We'll map your existing SOPs and compliance documents into a pilot Policy Graph scoped to one workflow. Most environments reach live enforcement within 30 days.
Book a Deployment CallEnterprise scoping calls are free. No commitment required.