Building an Engineering Knowledge Base for AI with Intel AI PC
During the last few months I have been building a production-oriented engineering knowledge repository for regulated industries. While designing the repository, one question kept coming back:
Should AI repositories store documents—or should they store knowledge?
That question eventually led to a completely different repository architecture.
In a production knowledge system, the repository needs to evolve from “a folder of PDFs” into a pipeline of knowledge containers.
This architecture is still evolving.
It has not yet reached version 1.0, and that is exactly why I would appreciate feedback from engineers working with Intel AI PC, OpenVINO, RAG pipelines, knowledge graphs, or MCP.
Why traditional RAG repositories become difficult to maintain
Traditional RAG repositories often optimize for the first successful answer. They usually contain source files, extracted text, chunks, embeddings, prompts, and scripts in loosely connected folders. This creates several engineering problems.
First, traceability becomes fragile. A chunk may answer a question, but the team may not know which document version, page, section, clause, or review decision produced it. Second, reproducibility becomes weak. If a PDF is reprocessed with a different parser, chunk size, embedding model, or prompt, the downstream behavior changes. Third, quality control becomes informal. Regulatory and engineering teams need clear states: received, reviewed, blocked, approved, superseded, released.
For AI systems that may support regulatory interpretation or engineering decisions, “we embedded some PDFs” is not enough. The system needs source governance, provenance, quality gates, evaluation, and controlled release packages.
From PDFs to knowledge containers
The architectural review of IVD_SOURCE_LIBRARY showed a useful starting point: canonical PDFs are treated as immutable sources, while metadata, provenance, inventory, quality flags, ingestion planning, and graph relationships are separated. That is the right direction. The next step is to make the separation explicit across the entire AI transformation pipeline.
A knowledge container is a folder or dataset with one responsibility, one lifecycle, and one validation rule. It should be clear whether the container is human-authored, machine-generated, reviewed, temporary, or releasable.
Proposed architecture
Source documents are the immutable foundation. PDFs, standards, audit guides, and technical references should not be edited in place. Every downstream artifact must trace back to them.
Metadata describes each source: document ID, title, version, domain, type, checksum, language, lifecycle state, and processing constraints.
Provenance records where the document came from, when it entered the repository, what rights status is known, and whether it is approved for downstream use.
Quality tracking records document issues: missing source, poor scan quality, obsolete version, duplicate candidate, incomplete metadata, or blocked ingestion.
Controlled extraction is the first transformation stage. It extracts text, layout, tables, and page maps without changing the source PDF.
Normalized Markdown stores reviewed human-readable text derived from extraction. It should preserve headings, page anchors, tables, figures, and source references.
Semantic units are the AI-facing knowledge records: requirements, risks, controls, audit criteria, definitions, lifecycle phases, and evidence statements.
The evidence index maps every semantic unit back to document ID, page, section, and text span. This is the backbone of trustworthy RAG.
The ontology defines entity types and relationships: requirement, hazard, risk control, audit criterion, evidence, clause, process, and obligation.
Retrieval indexes define how search works: dense embeddings, sparse retrieval, BM25, metadata filters, reranking, and hybrid search.
Evaluation datasets contain golden questions, expected answers, expected citations, retrieval benchmarks, and regression tests.
Agent contracts define which tools agents can use, what they may read, what they may write, and where human approval is required.
MCP contracts expose repository resources and tools in a structured way, such as document metadata lookup, citation resolution, graph traversal, and integrity verification.
Runtime profiles describe how the system runs on Intel CPU, Intel GPU, Intel NPU, OpenVINO Model Server, or Intel AI PC deployments.
Release packages are versioned exports for downstream systems such as `IVD_AI_KB`. They should include manifests, checksums, evaluation results, and compatibility notes.
Separating raw documents, extracted data, semantic knowledge, and AI artifacts
This separation is deliberate. Raw documents are legal and engineering sources. Extracted data is parser output and may contain errors. Semantic knowledge is curated and reviewable. AI artifacts such as embeddings, indexes, prompts, and agent plans are runtime products.
Mixing these layers makes it difficult to audit the system. Separating them makes it possible to rerun extraction, compare versions, evaluate retrieval, rebuild indexes, and release approved knowledge packages without changing the source documents.
Engineering benefits
Traceability improves because every answer can point back to a source, page, section, and evidence span. Regulatory compliance improves because rights, provenance, review state, and quality flags are visible before ingestion. Reproducibility improves because each stage has defined inputs and outputs. AI quality improves because retrieval and generation can be tested against evaluation datasets. Maintainability improves because each container has one responsibility. Agent interoperability improves because MCP resources and agent contracts can expose stable interfaces instead of fragile folder assumptions.
This is especially important for future regulatory AI systems and engineering knowledge bases. The goal is not only to answer questions. The goal is to answer with controlled evidence, known limitations, and repeatable behavior.
Why this fits Intel AI PC and OpenVINO
This architecture remains model-independent. The repository does not depend on a specific embedding model, vector database, agent framework, or inference backend. That makes it suitable for Intel AI PC, Intel CPUs, Intel GPUs, Intel NPUs, and future OpenVINO optimization.
OpenVINO can later accelerate local inference, embedding generation, reranking, classification, extraction assistance, and model serving. Intel AI PC deployments are especially relevant when engineering or regulatory knowledge should stay local. The architecture allows the same approved knowledge containers to feed different runtime profiles: local desktop, workstation, on-prem server, or edge deployment.
The important point is sequencing. Hardware acceleration should come after source governance, extraction, semantic units, evidence indexing, and evaluation. Faster inference does not compensate for weak knowledge architecture.
Questions for the Community:
I would especially appreciate feedback on several design decisions:
• Should semantic units be immutable objects or versioned independently?
• Would you introduce a vector index earlier in the pipeline?
• Is an Evidence Index sufficient, or should provenance become a graph from the beginning?
• How would you integrate Intel OpenVINO into this architecture?
• Which knowledge containers would you add or remove?
If you are building AI systems for engineering, manufacturing, industrial quality, compliance, or other knowledge-intensive domains, I'd genuinely like to hear how your repository is organized.
Are knowledge containers the right abstraction for the next generation of engineering AI systems, or do you see a better architecture? I'd be very interested in your experience and suggestions.
Link Copied
