Giving the AI Access to Your QC Manual: Vector Stores and Tool-Calling for Inspection Queries

An inspector on site should be able to ask a question and get an answer grounded in their company's actual QC procedures — not a generic response from a model that has never seen their contract documents. We built per-organization AI knowledge bases using OpenAI vector stores, and gave the AI access to the system's own data through tool-calling governed by the same access policies that apply to human users.

The problem with generic AI in QC

A general-purpose AI assistant can answer questions about welding procedures, inspection standards, and ASME codes with reasonable accuracy. What it cannot do is tell you what your QCM says about hold point requirements for socket welds on your current project — because it has never seen your QCM.

In construction QC, "what does the standard say" and "what does our procedure say" are different questions with different answers. The second question is the one that matters on site.

Per-organization vector stores

Each organization in AIMQC gets its own OpenAI Vector Store. When a QC manager uploads the company's QC manual, procedure documents, or client-specific specifications, those documents are chunked and embedded into the organization's vector store.

The vector store is scoped per organization. A user from Org A cannot retrieve documents from Org B's vector store. The isolation mirrors the access policy model that governs the rest of the system.

Tool-calling from ZenStack schemas

The AI assistant does not just search documents. It has tools — generated automatically from the ZenStack Zod schemas — that give it CRUD access to the system's data.

An inspector asking "what ITRs are pending on system 3?" does not get a generic response. The AI calls a tool that queries the ITRRegister table for the relevant system, filtered to the inspector's organization, and returns the current list.

// Tools are auto-generated from Zod schemas
const tools = generateToolsFromSchemas({
  models: ['ITPIndex', 'ITRRegister', 'IRLog', 'NCRLog'],
  operations: ['read', 'list'],
  context: { organizationId: user.organizationId }
})

The key design decision: the tools are bound to the same access policies as the rest of the system. An AI operating on behalf of an inspector cannot read records the inspector cannot read. It cannot write records the inspector cannot write. The compliance guarantees are not special-cased for the AI — they apply automatically because the tools go through the same enhanced Prisma client.

What this enables

An inspector with a question about an in-progress activity can ask:

• "What is the required witness notification time for welding on this ITP?" → retrieved from the ITP step definition
• "Are there any open NCRs on this system?" → queried from NCRLog
• "What does our QCM say about fit-up inspection for pressure piping?" → retrieved from the org vector store

The answer is grounded in real data from the current project and the organization's own documents. It is not a best-guess from training data.

The access policy constraint

The AI's access to the system's data is not open-ended. It is bounded by the same rules that govern human access. A QC viewer cannot delete records. An AI acting on a viewer's behalf cannot delete records either. The boundary is structural, not enforced by prompt instructions that could be worked around.

This matters for regulated systems. An AI that has access to QC records but is not constrained by the same compliance rules as humans introduces an audit gap. When the AI operates through the same access layer, the audit trail covers it equally.

Current state

The vector store integration is live for QC manual uploads. Tool-calling for structured queries is in active development. The query tools are read-only in the current build — write access via the AI layer will be introduced with additional confirmation workflows.

David Olsson is CTO at AIMQC. Contact: dolsson@aimqc.com