Manufacturing Knowledge Engineering Platform
An independent knowledge engineering prototype exploring how fragmented manufacturing information can be transformed into structured, traceable, and verifiable knowledge assets.
On this page
Independent manufacturing knowledge engineering project (2026)
An Ontology-Driven, Governed Knowledge Graph & AI Agent Prototype
- My role
- Manufacturing domain modeling, knowledge architecture, governance design and competency-driven evaluation; implementation supported by AI Coding Agents.
- Representative problem
- A product's quality acceptance limits must not be confused with the measurement range of inspection equipment.
- Design decision
- Establish semantic boundaries and governed evidence before expanding graph instances or Agent capabilities.
- Ontology classes
- 66
- Source inventory
- Graph entities
- 93
- Repository-derived
- Competency Queries
- 19/19
- Reproducible suite
- Previously reported tests
- 319
- 4 conditional skips
Independent prototype using synthetic scenarios and controlled data. Not an official employer project or an enterprise production system.
The problem: fragmented information, uncertain meaning
Production records, quality incidents, engineering specifications, PFMEA, Control Plans and SOPs each describe part of a manufacturing system. The same machine can have several identifiers; the same term can mean different things across departments. Relationships, provenance and effective versions are often unclear. Passing documents to an LLM does not resolve these problems.
How can manufacturing knowledge become a reliable, governed foundation for AI-assisted reasoning?
Informed by experience in automotive and semiconductor manufacturing, this independent prototype explores that question with synthetic scenarios and controlled data. It does not claim a production implementation at an employer.
System architecture: govern knowledge, constrain reasoning
The knowledge lifecycle and a user query are different paths. The first diagram describes conceptual responsibilities, not one linear request; the second describes the Agent runtime.
- Knowledge acquisition: controlled extracts / manual authoring
- Semantic governance: Ontology / Canonical Identity / SHACL
- Knowledge repository: governed graph / governed documents
- Access boundary: authorization, provenance, effective version and publication state
Source synchronization and manual publication converge on a governed knowledge boundary. This is not live enterprise integration or a sequence executed by one service.
- User question → constrained semantic parsing
- Canonical reconstruction → Ontology validation → safe query plan
- Authorized graph retrieval + document evidence retrieval
- Evidence Pack → Template / LLM / Hybrid answer composition
- Claim / Citation / Authorization validation → release or block
The LLM does not execute arbitrary Cypher. Deterministic backend controls govern query templates, retrieval scope, evidence and answer publication.
The central decision: constrain probabilistic LLM capabilities within deterministic boundaries of knowledge, authorization and evidence governance. Sessions, turns, asynchronous runs, SSE, heartbeats, Last-Event-ID, replay, recovery, persistence, timeouts, retry and cancellation make interactions traceable.
Ontology & knowledge modeling
The Ontology defines manufacturing concepts, relationships and constraints. The Knowledge Graph represents specific instances. Shared canonical IDs connect production, quality and engineering perspectives: operation.op30, machine.m220 and quality-characteristic.leak-rate identify objects independently of their UI labels.
RDF/OWL define the semantic model, while SHACL validates specified structural and data constraints. Runtime schema validation does not imply unrestricted OWL reasoning.
| Model layer | Verified repository inventory |
|---|---|
| Ontology | 8 modules; 66 classes; 54 object properties; 146 datatype properties; 665 triples |
| SHACL | 18 Node Shapes; 41 attached property constraints |
| Canonical graph | 93 unique entities; 230 unique relationship assertions; 47 relationship labels |
| Document evidence | 23 scenario-level registry records; 21 unique document IDs; 51 addressable chunks |
Graph counts are the ID-deduplicated union of three canonical scenarios. There are 237 raw cross-scenario relationship records, not 237 unique assertions. These are repository-derived counts, not live Neo4j or production database statistics. All 23 document records link to graph objects; chunks use stable section/locator addressing.
Source inventory was checked against revision 887f33e on 2026-10-12. The modeling value is shared meaning, explicit relationships and verifiable provenance, not graph size alone.
Governed knowledge lifecycle
- Controlled extracts: bounded MES / QMS / PLM records
- Mapping: source fields to canonical objects
- Validation: checksums, validation and quarantine
- Source synchronization: checkpoints, idempotency, tombstones and lineage
- Governed repository: atomic persistence and traceable publication
Validated with controlled extracts and localhost fixture HTTP adapters. No live enterprise MES/QMS/PLM endpoints, CDC or source-system writeback are implemented.
- Draft: create a knowledge change set
- Validate: identity, types, relations and source ownership
- Submit: request a separate review
- Approve: record the approval and version baseline
- Publish: release to the governed repository
Request Changes, Reject and Withdraw are supported. Editing approved content invalidates approval. Draft, submitted and approved-but-unpublished changes do not enter formal Agent retrieval or evidence.
Both paths follow Canonical Identity, Provenance, Authorization, Validation, Publication State and Evidence Governance. Implemented controls include Principal, a replaceable authenticator, a controlled static Bearer adapter, roles, tenant/domain checks, session ownership, object/document filtering and protected Trace/Evidence/Audit access.
These are prototype authorization boundaries, not complete enterprise IAM. Enterprise OIDC/JWKS, revocation, enterprise group mapping and centralized SIEM export remain deferred.
Evidence-grounded AI Agent
The implementation supports 13 governed intents. Semantic parsing can be Deterministic / LLM / Hybrid; answer composition can be Template / LLM / Hybrid. Neo4j retrieval uses safe, parameterized read-only templates, not arbitrary Text-to-Cypher.
The LLM Answer Composer receives a governed Evidence Pack projection, not unrestricted database context. The Citation Gate validates structured claim references, evidence associations and required validation states. Responses that fail these checks are blocked from publication. This mechanism does not establish the semantic truth of arbitrary natural-language statements.
The DeepSeek Chat Completions adapter is implemented. Semantic parsing, answer composition and the four-domain pipeline have historical live acceptance records using deepseek-v4-flash, with fallback false. The OpenAI Responses adapter is implemented, but live acceptance remains pending. No Provider calls were rerun for this portfolio page.
A verifiable example: CQ-012
Prototype acceptance example, not a live Agent response.
- Manufacturing question: What is the currently effective Leak Rate acceptance limit for Brake Booster at OP30? Product acceptance criteria must remain distinct from equipment measurement capability.
- Structured interpretation: resolve Brake Booster, OP30 and Leak Rate; select a current, approved Specification and its upper-specification-limit relation.
- Repository-backed evidence: document.specification.bb-leak-rate.rev-a, Section 4.1 / Acceptance Criteria, records target 0.18, LSL 0.00 and USL 0.30 sccm as synthetic demo values.
- Validation boundary: the SPARQL competency runner verifies that CQ-012 returns repository data. Fixture checks, runtime Neo4j retrieval, and Agent claim/citation validation are separate validation paths.
This demonstrates question interpretation, modeled scope, repository evidence and the verified boundary. It does not fabricate an end-to-end model answer.
Primary references: CQ-012 query, repository-backed synthetic fixture, and competency-query runner. The three values are explicitly labeled in the fixture as target, lower specification limit and upper specification limit. They are demo-only, not a production specification.
Competency-driven evaluation
Competency Questions define what the knowledge system must demonstrate before testing retrieval, valid evidence and boundaries. Evaluated areas cover Production, Quality, Engineering, Bottleneck and Cross-domain questions: effective specifications, quantitative projection, measurement capability, reaction plans, calibration/MSA, program changes and the sufficiency of causal evidence across domains.
| Acceptance evidence | Result |
|---|---|
| Previously reported automated test result | 319 passed / 4 conditional Neo4j skipped / 0 failed |
| Reproducible Competency Query suite | 19/19, CQ-001 through CQ-019 |
| Formal multi-domain acceptance | 38/38 with scoped citation coverage of 100% |
| Governed authoring acceptance | 36/36 versioned deterministic cases |
Evidence level: the 38/38 result has a fixed-commit successful CI run (Level 1). The 19-query catalog/runner and 36-case authoring dataset provide fixed-revision, reproducible source evidence (Level 2), but no matching immutable original success log was located. The 319/4 result remains a previously reported historical result (Level 3), not a newly rerun test result.
These records apply only to the defined prototype acceptance scope, not 100% accuracy for arbitrary questions. Website build and UI tests are separate validations. Dependency status is also time-bound and requires a fresh audit before release.
My role
Project Owner · Knowledge Architecture · Domain Modeling · AI-assisted Development
- Domain & knowledge design: manufacturing problem analysis, ontology modeling direction, semantic architecture and Competency Questions.
- Architecture & governance: system architecture, knowledge contracts, lifecycle, authorization boundaries, evidence validation and product requirements.
- Implementation & evaluation: functional requirements, acceptance criteria, AI Coding Agent coordination, technical review, iterative testing and release validation.
I led the ontology architecture, manufacturing domain modeling, governance design and competency-driven evaluation, while using AI Coding Agents for substantial implementation, testing and iteration. It is an independent personal prototype, not an official ZF project or an enterprise production system.
Explore the project
Browser checks on 2026-10-12 confirmed Route loading, Ontology node selection and detail display, and access to the Agent entry page and Scripted Workspace, with no captured JavaScript errors along those paths. Live Agent presents an access-token gate. No credentials or conversation were submitted, and neither the live Provider nor the database was revalidated. Public presentation availability does not establish acceptance of every online feature. No production deployment or service changes were performed for this task.