Ontology Architecture — MidWest Manufacturing

The Cognitive Gap the Ontology Solves

Quality engineers at MidWest think in vehicles, parts, batches, and suppliers — not database tables. Before Foundry, answering "which vehicles used brake components from supplier LOT-2024-0847?" required a quality engineer to know that the answer lived across SAP QM (QALS, QAVE, QMUR tables), a MES system, a supplier portal, and a warranty database — then manually join them with six Excel lookup tables.

The ontology collapses this complexity. After SDDI builds the integration layer (Appendix B), the ontology builds the semantic layer on top: objects that mirror how the business actually thinks, linked together in ways that reflect how the business actually operates.

The graph: Vehicle → Part → Batch → Supplier → Process. Every relationship traversable in both directions. Every property validated, typed, and access-controlled.

Object Definitions

Vehicle Object

Unique Identifier: VIN (17-character ISO 3779 standard)
Source Datasets:
  - MES_Production_Records (SDDI curated)
  - Warranty_Database (SDDI curated)

Properties:
  - VIN: String (required, unique)
  - ProductionDate: DateTime
  - Plant: Enum [Denver, Detroit, Memphis]
  - WarrantyStatus: Enum [Active, Expired, Extended]
  - ModelYear: Integer (validation: 2020–2025)
  - ProductionStatus: Enum [Planned, InProduction, Hold, Completed, Shipped]

Links (Outbound):
  - CONTAINS → Part (one-to-many, required)
  - HAS_DEFECT → Part (one-to-many, optional)

Security:
  - Read: Quality Engineers, Production Managers, Executives
  - Write: Production Systems (automated), Quality Managers (manual override)

Part Object

Unique Identifier: MaterialNumber (MATNR from SAP, fuzzy-matched across systems)
Source Datasets:
  - SAP_QM_Material_Master (MARA/MARC tables)
  - MES_Part_Assembly_Data

Properties:
  - MaterialNumber: String (required, unique, fuzzy match enabled)
  - PartType: Enum [Brake, Transmission, Engine, Electrical, Body]
  - ComponentCategory: String (hierarchical taxonomy)
  - InspectionStatus: Enum [Pending, Passed, Failed, Conditional]
  - SupplierPartNumber: String (original supplier identifier)

Links (Inbound):
  - Vehicle CONTAINS → Part (many-to-one)
Links (Outbound):
  - PRODUCED_FROM → Batch (many-to-one, required)

Security:
  - Read: All authenticated users
  - Write: Quality Engineers only

Batch Object

Unique Identifier: BatchNumber (CHARG from SAP QM)
Source Datasets:
  - SAP_QM_Quality_Batches (CHARG field)
  - Supplier_Quality_Certificates

Properties:
  - BatchNumber: String (required, unique)
  - ProductionDate: DateTime
  - FurnaceTemperature: Float (units: Fahrenheit, validation: 1750–1850°F)
  - QualityScore: Float (validation: 0–100, calculated)
  - QualityRiskScore: Float (validation: 0–100, model-generated)
  - InspectionLot: String (PRUEFLOS from SAP)

Links (Inbound):
  - Part PRODUCED_FROM → Batch (many-to-one)
Links (Outbound):
  - SUPPLIED_BY → Supplier (many-to-one, required)
  - USED → Process (one-to-many, required)

Security:
  - Read: Quality Engineers, Supply Chain, Finance
  - Write: Quality Engineers (manual), Automated Systems (model scores)

Display Rules:
  - FurnaceTemperature: Red if out of spec (< 1750 or > 1850)
  - QualityRiskScore: Color gradient (green < 70, yellow 70–89, red ≥ 90)

Supplier Object

Unique Identifier: SupplierID (LIFNR from SAP vendor master)
Source Datasets:
  - SAP_Vendor_Master (LFA1 table)
  - Supplier_Portal_Metadata

Properties:
  - SupplierID: String (required, unique)
  - SupplierName: String
  - Location: GeoPoint (lat/long for mapping)
  - CertificationStatus: Enum [Certified, Conditional, Suspended]
  - ReliabilityScore: Float (validation: 0–100, model-generated)
  - TierLevel: Enum [Tier1, Tier2, Tier3]

Links (Inbound):
  - Batch SUPPLIED_BY → Supplier (many-to-one)

Security:
  - Read: Quality Engineers, Supply Chain, Procurement
  - Write: Supply Chain Managers only
  - Supplier Portal Access: Suppliers see only their own data

Process Object

Unique Identifier: ProcessID + Timestamp (composite)
Source Datasets:
  - Supplier_Portal_IoT_Data
  - Furnace_Logs

Properties:
  - ProcessID: String (required, equipment identifier)
  - Timestamp: DateTime (required)
  - Temperature: Float (units: Fahrenheit)
  - Pressure: Float (units: PSI)
  - Duration: Integer (units: minutes)
  - OperatorID: String (masked for privacy)
  - EquipmentID: String (furnace/machine identifier)

Links (Inbound):
  - Batch USED → Process (one-to-many)

Security:
  - Read: Quality Engineers only
  - Write: Automated ingestion from supplier portals
  - PII Masking: OperatorID visible only to Quality Managers

Link Type Specifications

Vehicle CONTAINS Part
- Type: One-to-Many (one vehicle has many parts)
- Cardinality Validation: 1 vehicle → 500–800 parts (typical range)
- Properties: AssemblyDate, AssemblyPlant, AssemblyLine
- Traversal: Bidirectional

Part PRODUCED_FROM Batch
- Type: Many-to-One (many parts from one batch)
- Cardinality Validation: 1 batch → 1,000–50,000 parts
- Properties: BatchSequence, QualityInspectionResult
- Traversal: Bidirectional

Batch SUPPLIED_BY Supplier
- Type: Many-to-One (many batches from one supplier)
- Cardinality Validation: 1 supplier → 10–500 batches/month
- Properties: PurchaseOrderNumber, DeliveryDate
- Traversal: Bidirectional

Batch USED Process
- Type: One-to-Many (one batch uses multiple process steps)
- Cardinality Validation: 1 batch → 1–10 process steps
- Properties: ProcessSequence, ProcessType
- Traversal: Bidirectional

From SDDI to Ontology: The Binding Process

The six-step process that transforms raw, scattered data into a queryable semantic model:

• Step 1 — SDDI Integration: Scattered data sources (SAP QM, MES, Supplier portals) consolidated into unified datasets. Fuzzy matching resolves identifier mismatches (the BC-2847 problem).
• Step 2 — Curated Datasets: Cleaned, joined data with business-readable columns. Column Namer translations applied (PRUEFLOS → InspectionLot).
• Step 3 — Ontology Binding: Datasets mapped to Object types (Vehicle, Part, Batch, Supplier, Process). Unique identifier properties established.
• Step 4 — Link Creation: Join keys from SDDI become semantic Links. Cardinality validation ensures data quality.
• Step 5 — Property Exposure: Relevant attributes exposed as typed Properties with validation rules, display rules, and security rules applied.
• Step 6 — User Access: Quality engineers query the ontology, not the underlying databases. Graph traversal replaces SQL joins. Business language replaces technical jargon.

The Unanticipated Question

The brake recall crisis was resolved when the quality engineer could ask "show me every vehicle affected by supplier LOT-2024-0847" — a 30-second traversal across the entire graph.

But the more important question came next: "What OTHER components came from that supplier?"

That question was never in any requirements document. Nobody planned for it. But because the ontology is a graph of real business relationships — not a reporting schema designed for known queries — the answer was a single additional traversal. MidWest discovered that the same supplier also provided transmission gears with similar furnace temperature anomalies. That discovery prevented a $30M second recall.

This is what the ontology enables that a data warehouse cannot: the ability to answer questions you didn't know you needed to ask.