Domain First
Start from business vocabulary and map data assets to domain concepts, not the other way around.
Outcome: Stable language for product, data, and model teams.
🕸️
How to Develop An Open Source Ontology & AI Pipeline
From domain vocabulary to governed agentic execution and release.
Most AI systems fail in production because they rely on prompts without a stable semantic layer. This lab shows how to model domain concepts as a versioned ontology, wire them into a multi-stage AI pipeline, and enforce quality with measurable gates.
You will walk through the full lifecycle: schema contract checks, ontology modeling, context retrieval, agentic reasoning, evaluation, release, and rollback. The entire approach is tool-agnostic and built on open source components.
Ontology Engineering Agentic AI Governance Evaluation Open Source
Lab Blueprint
Open Source Ontology + AI Pipeline, End to End
This lab is a practical architecture for teams that want grounded AI systems instead of prompt-only prototypes. You define a versioned ontology, enforce schema contracts, route tools using ontology context, and ship with evaluation gates and rollback controls.
Artifacts Over Prompts
Persist ontology terms, mapping rules, and pipeline configs as versioned files in Git.
Outcome: Reproducible behavior across model upgrades and team handoffs.
Evaluation as CI
Treat ontology and agent behaviors as testable software with deterministic checks in CI.
Outcome: Fewer silent regressions and safer release cycles.
Human Governance
Keep policy checkpoints for schema changes, high-impact intents, and model outputs.
Outcome: Auditability and trust for production use.
Worked Example
Fraud Detection — From Concepts to Artifacts
One small domain followed end to end. The diagram is the mental model. The files below are what you actually commit on day one.
Concept Graph
ConceptEventRule
Canonical business entities. Owned by domain leads, not engineers.
ontology/concepts.yaml
id: https://superml.ai/ontology/fraud
name: fraud_ontology
version: 0.4.0
classes:
Customer:
slots: [customer_id, name, risk_tier]
Account:
slots: [account_id, owner, opened_at]
Merchant:
slots: [merchant_id, name, mcc_code, country]
Transaction:
slots: [transaction_id, account, merchant, amount, currency, occurred_at]
Rule:
slots: [rule_id, name, version, severity]
FraudEvent:
slots: [event_id, transaction, rule_fired, severity, opened_at]Six-Stage Pipeline
Select a stage to inspect
📥 Ingestion + Contract Validation
Ingest source schemas and enforce contracts before ontology updates.
Inputs
- → Source schemas
- → Data contracts
- → Domain glossary changes
Process
- ⟳ Run schema diff and contract checks on PR
- ⟳ Validate naming and ownership metadata
- ⟳ Reject incompatible fields without migration plan
Outputs
- ← Validated schema snapshot
- ← Change manifest
- ← Ownership map
Quality Gate
0 contract violations and complete ownership coverage.
dbtGreat ExpectationsOpenMetadata
Reference Implementation
pipeline/ingest/expectations/transactions.yml
# Great Expectations contract for the transactions source.
# Runs on every PR that touches the warehouse schema.
expectation_suite_name: transactions.contract.v1
expectations:
- expectation_type: expect_table_columns_to_match_set
kwargs:
column_set:
[transaction_id, customer_id, account_id, merchant_id,
amount, currency, occurred_at]
- expectation_type: expect_column_values_to_not_be_null
kwargs: { column: customer_id }
- expectation_type: expect_column_values_to_match_regex
kwargs:
column: transaction_id
regex: "^TXN-[0-9]{10}$"
- expectation_type: expect_column_values_to_be_in_set
kwargs:
column: currency
value_set: [USD, EUR, GBP, INR]
meta:
owner: data-platform@superml.ai
domain: payments
contract_version: 1.3.0Ontology Design Layers
Concept Layer
Canonical business entities such as customer, contract, invoice, fraud_event.
Key Artifacts
concepts.yaml · glossary.md · owners.yaml
Version Rule: Semantic versioning. Breaking rename bumps major.
Relationship Layer
Typed links such as owns, initiated_by, settled_in, depends_on.
Key Artifacts
relations.yaml · constraints.yaml
Version Rule: Any cardinality change requires migration notes.
Operational Layer
Physical mappings to warehouse tables, event topics, and feature views.
Key Artifacts
mappings.yaml · lineage.json · feature_registry.yaml
Version Rule: Mappings must keep backward-compatible aliases for one minor release.
30-Day Delivery Plan
Week 1: Define ontology scope and governance model.
Deliverables
Domain glossary · Owner matrix · Versioning policy
Exit: Approved glossary with domain owners and review workflow.
Week 2: Implement ontology package and schema mappings.
Deliverables
Ontology files · Mapping validators · Migration templates
Exit: CI validates ontology package with zero breaking issues.
Week 3: Integrate retrieval and agent execution pipeline.
Deliverables
Routing graph · Tool adapters · Structured output contracts
Exit: End-to-end dry run succeeds on benchmark scenarios.
Week 4: Operationalize evaluation, release, and rollback.
Deliverables
Eval suite · Dashboards · Release runbook
Exit: Canary release with automated rollback verification.
Release Principle
Publish ontology and pipeline as separately versioned artifacts, but promote them together only after compatibility tests pass against your golden question set.
Starter Repository Layout
ontology-ai-pipeline/
ontology/
concepts.yaml
relations.yaml
mappings.yaml
policies/
pii-policy.yaml
access-policy.yaml
pipeline/
ingest/
contract_checks.py
retrieval/
context_builder.py
router.py
execution/
orchestrator.py
tools/
sql_tool.py
graph_tool.py
eval/
datasets/
golden_questions.jsonl
tests/
test_semantic_accuracy.py
test_policy_adherence.py
deploy/
Dockerfile
helm/
values.yaml
scripts/
canary-watch.sh
.github/workflows/
ci-ontology.yml
release-pipeline.yml
docs/
ontology-governance.md
release-runbook.md