RAG knowledge assistant for manufacturing

Each answer should record the source document, its revision identifier and the chunk it was drawn from, so a reviewer can open the exact version that was live at the time. The record is produced by the ingestion pipeline and the retrieval layer of the RAG engine, such as RAGFlow, AnythingLLM or Dify, which store document IDs and chunk references with each citation. Confirm during design that your revision scheme (for example, a controlled document number plus revision letter) is carried into metadata at ingestion rather than inferred from file names. DeployOpen prepares these records and tests them, but the auditor decides whether they are sufficient.

Approval evidence normally lives in your document control system, not in the assistant. The assistant should only ingest documents whose status is approved and effective, and the ingestion job should log the approved version, approver and effective date it received. Ask your partner how the connector reads status from the source system and what happens to a superseded revision. Where electronic records and signatures are in scope, the requirements in 21 CFR Part 11 are a useful reference for what the approval trail must show.

Query logs should capture the user identity, the time, the question, the collections searched and the documents returned. In a self-hosted stack these come from the application layer (the RAG engine or chat front end), optionally forwarded from an AI gateway such as LiteLLM or Apache APISIX. Confirm that the platform can attribute each query to a named user through your directory and that logs are written to storage you control. Dify, for example, documents separate SSO scopes for workspace access and web app access, which matters when reviewers ask who could see which collection.

Retention depends on the rules that apply to your plant and products, so set it from a written requirement rather than a default. For high-risk AI systems under the EU AI Act, Article 12(1) requires technical support for automatic event logging over the system's lifetime, and Article 19(1) requires providers to keep those logs for at least six months unless other law provides otherwise. Whether your assistant is in that category is a classification question to settle with counsel. Ask your partner to configure retention per log type and to show how deletion is enforced and recorded.

Re-indexing evidence is a job log that links each superseded revision to its removal and each new revision to its embedding run, with timestamps and counts. The ingestion scheduler and the vector database record these events; Qdrant, for example, can be configured with a JSON audit log of authenticated API operations from v1.17.0 onward, and snapshots can preserve the index state before a change. Ask the partner to demonstrate that a withdrawn procedure no longer returns in answers after its replacement is indexed, and to keep that test as a repeatable record.

Reviewers will want a documented test set of real questions with expected source passages, scored for retrieval hits, citation correctness and answer faithfulness, with results kept per release. Observability tools such as Langfuse or Phoenix can store traces and evaluation scores in your infrastructure, which gives you a time series across changes. Agree acceptance thresholds and who signs off on them before go-live. Ask what the test set covers for scanned pages and tables, since those are the most common failure points.

Network zoning evidence is an architecture diagram with the assistant placed in a zone that is separated from control networks, plus firewall rules, the list of permitted flows and change records. For industrial environments, the ISA/IEC 62443 series describes zones and conduits and the security levels expected of them, and NIST SP 800-82 Rev. 3 covers OT security more broadly. The assistant should not sit in a control network. Your network team owns the firewall and conduit records; DeployOpen can document the application side and the flows it needs, and confirm them against your design.

The cost is driven mostly by the document work, not the software. The main components are the parsing pipeline for scanned drawings, manuals and spreadsheets, the vector store, the compute for embeddings and answer generation, evaluation work to check answers against known procedures, and ongoing maintenance as manuals change. Open-source components such as RAGFlow, AnythingLLM, Dify or Open WebUI carry no license fee for most plant uses, but you still pay for infrastructure, implementation labor and the people who review answers. Ask any quote to split one-time build work from recurring operations, and to show how the parsing and evaluation effort scales with the number of documents and revisions in scope.

Plant IT can run it alone only if it already operates containers, a database, backups and identity integration, and has someone who can judge answer quality against the source manuals. Most teams find the hard parts are the first ingestion of messy documents, re-indexing when procedures change, and checking that retrieval respects document permissions. Dify's self-hosted Community edition is documented as a Docker Compose deployment that starts several core services plus PostgreSQL, Redis and Weaviate, so someone must patch and monitor that stack. Ask a partner which tasks they hand over, which they leave with your team, and what runbooks you receive.

Document owners must identify which manuals, maintenance procedures and quality records are current, name the approver for each revision, and confirm which documents are controlled and which are reference copies. OT security must review the network path from the assistant to plant systems, because the topic standards ISA/IEC 62443 and NIST SP 800-82 Rev. 3 treat industrial control environments as a separate security zone. Expect security to ask where the vector store sits, how it is authenticated, and whether any plant network segment is reachable from the internet. Confirm these needs with your OT security team before scoping.

The time to a pilot is set in the written scope, which is agreed before work starts. It depends on how many document sources are connected, how many scanned or tabular files need parsing review, whether the assistant must run inside a segmented plant network, and how quickly your team can name approvers and test users. Ask for a scope that lists the document set for the pilot, the connectors, the test questions used for acceptance, and the dates that depend on your side. DeployOpen does not publish a standard duration, so a timeline should come from the scope, not from a general figure.

Community editions can be enough for a single-workspace pilot, but several factors need checking first. The Dify Community edition is free for self-hosting but limited to a single workspace, and Dify Enterprise adds SSO, multiple workspaces, advanced security and professional support. Dify's license also restricts operating it as a multi-tenant service without authorization, which matters if plants from several sites or a partner share one instance. Confirm whether you need SSO integration with plant or corporate identity, audit trails, vendor support hours and a commercial license before choosing an edition.

A plant should keep only the document-derived embeddings needed for retrieval, stored on infrastructure it controls. Qdrant, for example, needs block-level storage and cannot run on NFS or S3-style object storage, and by default self-deployed instances listen on all interfaces with no authentication. Ask the partner to enable API keys, TLS and per-collection access controls, and to size storage for replication, since a replication factor of 2 doubles storage. Qdrant's Hybrid Cloud and Private Cloud options are priced through sales, so request that quote separately if you consider them.

A quote follows from a written scope, so ask every bidder to price the same list of components. The list should cover the parsing pipeline and document review, connectors and identity integration, the vector database and its sizing, model and inference compute, evaluation against agreed test questions, deployment into the plant network, documentation and handover, and the first year of support. Separate one-time build costs from recurring costs such as compute, patching, re-indexing and retainers. Ask each partner which assumptions drive the price, such as document count, scanned page volume and the number of users. DeployOpen does not publish a price list and provides a quote after the scope is agreed.