Concepts & glossary
Every term in plant-floor language. Two to three sentences each. Technical docs link here on first use.
View as .mdA short glossary of every term you’ll see in Conversational Factory’s docs and UI. Each entry is two-to-three sentences in plant-floor language. Technical docs link here on first use.
For the full architecture, see the system architecture. For the runbook, see the operator quickstart.
The product
Conversational Factory
The product itself: a system that lets a plant operator (or an AI client like Claude) ask questions about a plant in plain language and get answers grounded in real network data, with a full audit trail. It bundles the witness, the historian, the conversational gateway, the operator console, and the deployment packaging into one shippable thing.
IIA — Industrial Independence Architecture
The architectural foundation Conversational Factory sits on. IIA is a separate, openly-published specification (CC BY-SA 4.0) for how a sovereign industrial-monitoring appliance should be structured: one zone per box, identical at every level of the plant hierarchy, with security enforced by the architecture rather than by policy. Conversational Factory is one implementation of IIA — the conversational, AI-native one.
What’s running
Witness
The component that watches your network. It listens passively (no agents on PLCs, no polling, no device changes) and decodes whatever it sees — Modbus, EtherNet/IP, OPC UA, and 30+ other industrial protocols. Everything it observes flows into the lake and the asset database.
Historian
The system of record for “what happened, when.” In Conversational Factory the historian is not a separate database — it’s a view over the witness’s lake. You can ask for the value of any tag at any past timestamp, even if you didn’t tell the system to track that tag in advance.
Asset database
The current-truth view of every device the witness has ever seen on the network. Each row carries vendor, role (PLC, HMI, sensor, etc.), Purdue level, IP, MAC, current state, and risk score. This is what populates the witness UI’s “Assets” tab.
Query plane
The thin Rust service that sits between the witness and any AI client. It speaks i3X v1 (see below) on its outside, and translates those queries into calls against the witness on its inside. Listens on port 8090. You usually don’t talk to it directly.
Conversational gateway
The front door for AI clients. It exposes the witness’s data as a small set of MCP tools (see below), translates natural-language requests into the right tool calls, and writes every interaction to the audit chain. Listens on port 8091. This is what Claude Desktop connects to.
Operator console
The witness’s web UI at http://127.0.0.1:5001. Where humans go to upload PCAPs, view the asset map, see findings, manage scans, and configure the witness. Operators don’t typically need the gateway or query plane directly — the console plus a Claude conversation cover most needs.
Concepts on the wire
Medallion lake
The shape of the witness’s data store. Raw packet captures come in as Iron (pcapng files). The witness decodes them into typed events — that’s Bronze. Events are correlated into conversations and asset relationships — that’s Silver. Aggregations and rollups for dashboards are Gold. You query at whatever tier is appropriate for your question.
VQT — Value, Quality, Timestamp
The shape of every reading the system returns. Every answer about “what’s the current state of X” carries the value (the actual number/string), a quality stamp (Good, GoodNoData, Uncertain, Bad), and a timestamp. Quality is how the system honestly tells you “I have an answer but it’s stale” or “I never saw this thing.”
elementId
How the system names a thing on the network. The format you’ll see most often is asset:{site}.{zone}.{subzone}.{ip}.{mac} — for example asset:_._._.10.5.0.10.001c06aabb01 for an asset at 10.5.0.10. Stable across restarts, unique within a witness.
Object types and relationships
The witness organizes everything it sees into typed objects (Asset, Conversation, Finding) with typed relationships between them (asset talks-to asset, asset belongs-to zone, finding raised-on asset). When an AI asks “what’s connected to this PLC,” it’s asking the query plane for related objects of a specific type.
The AI surface
MCP — Model Context Protocol
The open standard (spec) AI clients use to talk to tools. Claude Desktop, Cursor, and others all speak it. Conversational Factory exposes the gateway as an MCP server so any MCP-aware client can ask the plant questions without custom integration work.
i3X v1
The open standard for AI-to-OT data access. It defines a small, opinionated set of endpoints — list objects, get current state, get history, get related — that any industrial system can implement. Conversational Factory’s query plane is one reference implementation.
Tools
The 10 verbs the gateway exposes to AI clients: get_server_info, list_namespaces, list_object_types, list_relationship_types, list_objects, get_objects, get_current_state, get_history, get_related_objects, ping. Every AI question becomes one or more tool calls — there is no free-form database access.
Audit chain
A line-per-tool-call append-only log written by the gateway. Each line records: the natural-language question, the tool dispatched, the parameters, every downstream witness call (path, latency, status), and the result returned to the AI. This is how you answer “why did the AI tell me X?” — by reading the audit line.
Read-only
Conversational Factory has no write path to any plant device. The AI cannot order a setpoint change, write a register, or push a configuration. This isn’t enforced by policy — there is no MCP tool that does it. Even if an attacker controlled the LLM, the worst they could do is read.
Security and trust
Signed configuration
In production deployments, the witness’s configuration is not a live API. It’s a signed text artifact — generated offline, signed with an Ed25519 key, and applied by a constrained-grammar parser inside the box. There is no POST /config endpoint that mutates running state. If someone wants to change a baseline, they sign a new bundle.
mTLS
Mutual TLS — both sides of a connection prove their identity with certificates. In production, the gateway-to-query-plane and query-plane-to-witness hops use mTLS with operator-issued (or SPIFFE) certs, so no one can MITM the seam between the AI surface and the plant data.
Mesh
How witnesses on multiple boxes share information. Each zone box is fully autonomous — it captures, historizes, and answers operator questions even if disconnected. When the mesh is up, sites and zones replicate asset truth to their parent (upward only, never sideways).
Attestation observes prevention
A core IIA principle. The IDS isn’t a separate add-on — every communication is governed by an explicit data contract, and the IDS continuously checks the wire against the contract catalog. Anything off-contract emits an attestation event. This means the system can show you not just “the firewall blocked X” but “the firewall behaviour matches the contract.”
Where Conversational Factory fits
Brownfield
Plants with 40-year-old PLCs, 20-year-old HMIs, and brand-new VFDs all on the same wire. Conversational Factory is brownfield-friendly by design: the witness observes whatever’s there, in whatever protocol, without requiring upgrades or device changes.
PERA / PERA+
The Purdue Enterprise Reference Architecture — the layered model (Level 0 sensors up to Level 4 enterprise IT) every industrial control person knows. Conversational Factory is fractal across PERA: every zone box is a complete product for its level, identical in shape from the smallest cell to the largest plant.
Edge profile
How an IIA box exposes its data outward. Operators pick one per deployment: Sparkplug B (for plants on MQTT/SCADA), OPC UA pub/sub, structured query API on mTLS, or batch Iceberg/Delta to a lakehouse. Conversational Factory is profile-agnostic.