Ontology Strategy & AI Readiness
Assess data, risks and use cases; define the semantic roadmap.
- Use-case & data inventory
- Sensitive-data exposure map
- Prioritised semantic roadmap
OWL · SHACL · RDFSemantic access controlGraphRAG · MCPUSA · AU · EU
Ontology engineering for AI applications
Your AI is fluent.Make it understand your business.
We design enterprise ontologies that give every LLM, copilot and agent one governed model of your concepts, rules and relationships — so answers are consistent, sensitive data stays protected, and every decision traces back to evidence. Delivered across the USA, Australia and Europe.
3delivery regions · USA, AU, EU
6regulated domains modelled
100%open W3C standards
0vendor lock-in · open W3C standards
policy-decision · trace
query"Summarise claim CLM-20931 for the repair vendor"
agentclaims-assist · role=VendorLiaison · purpose=repair
resolveGRAPH Claim → Policy → Vehicle → Claimant
factALLOW Claim.lossDescription
factALLOW Vehicle.vin, Vehicle.damageArea
factMASK Claimant.name → "J. D."
factDENY Claimant.taxId · dpv:SensitivePersonalData
factDENY Claimant.injuryNotes · purpose mismatch
evidence4 facts · 2 sources · SHACL ✓ · prov:wasDerivedFrom
decision 38 ms · policy v2.4.1audit ✓ logged
Sensitive fields blockedbefore retrieval, not after
Ontology v2.4.1412 classes · 0 SHACL violations
The problemLLMs read your data.
LLMs read your data.
They don't understand it.
Agents now query warehouses, open documents and call tools on their own. Without a shared model of what things mean and who may use them for what, every integration becomes a privacy and accuracy gamble.
Meaning gets guessed
"Customer", "member", "insured" and "policyholder" live in five systems with five definitions. The model picks one — silently — and the answer is wrong in a way nobody notices.
Sensitive data leaks sideways
Row-level security protects tables, not inferences. A vector index, a chained tool call or a summarised document can expose health, financial or personal data the user was never allowed to see.
Answers can't be defended
Regulators, auditors and customers ask "why?". Without provenance from answer → fact → source, you can't show it — and you can't prove a restricted fact wasn't used.
Industry analysts now treat governance as the main failure point: Gartner's 2026 data & analytics predictions, as reported by Atlan, expect half of AI-agent deployment failures by 2030 to trace back to governance gaps and broken interoperability.
The power of enterprise ontology
One model of meaning. Every system, every agent, every decision.
An enterprise ontology is the formal, machine-readable definition of how your organisation works — its concepts, rules and relationships. Once it exists, data integrates faster, AI stops guessing, and governance becomes something software can enforce.
Without an ontology
Q: Is claim 20931 covered?
“Likely yes — most auto policies cover collision damage.”
“Likely yes — most auto policies cover collision damage.”
- “Policy” means five things in five systems
- No source, no rule, no audit trail
- Sensitive data may already be in the prompt
With an enterprise ontology
Q: Is claim 20931 covered?
“Yes. Collision coverage C-2 on policy P-88412 applies; deductible $500. Evidence: policy schedule §4.2, loss report LR-771.”
“Yes. Collision coverage C-2 on policy P-88412 applies; deductible $500. Evidence: policy schedule §4.2, loss report LR-771.”
- Coverage resolved through governed relationships
- Answer → rule → source, every time
- Restricted fields filtered before retrieval
Shared meaning
One vocabulary across CRM, ERP, claims, EHR and the data lake — reconciled identities, consistent definitions.
Enforceable guardrails
Sensitivity, purpose and consent encoded once and checked on every retrieval, prompt and tool call.
Evidence-backed answers
Every fact keeps its provenance, so AI answers are explainable to auditors, regulators and customers.
Faster integration
Map a new source to the ontology once; every app, report and agent can use it immediately.
Agents that follow process
Process and task ontologies give agents an explicit model of how work flows and which rules apply.
Change without chaos
Versioned, tested and reviewed like code — the model evolves as fast as your business does.
What we do
Professional ontology services, built for AI teams
From the first competency question to a governed, versioned ontology running behind your agents — we design it, build it, wire it in, and teach your team to own it.
Domain Ontology Engineering
OWL / RDF / SHACL models built from competency questions.
- Competency-question driven
- Reuse of FIBO, FHIR, ACORD…
- SHACL validation shapes
AI Guardrails & Semantic Access
Sensitivity, purpose and policy as machine-checkable knowledge.
- Sensitivity & purpose ontology
- ALLOW / MASK / DENY policies
- Retrieval-time enforcement
Knowledge Graph & Semantic Layer
Map sources, resolve entities, keep provenance end-to-end.
- Source-to-ontology mappings
- Entity resolution
- Lineage with W3C PROV
GraphRAG & Agent Grounding
Ontology-aware retrieval, MCP tools and evidence-linked answers.
- Ontology-aware retrieval
- MCP servers for agents
- Evaluation harness
OntologyOps & Governance
Versioning, CI validation, change control and team enablement.
- Git-based versioning & CI
- Change impact analysis
- Training & handover
How it works
From raw data to governed AI answers
Every fact your AI touches is typed by the ontology, tagged for sensitivity and purpose, and checked at a semantic policy gate before it ever reaches a prompt, an embedding or a tool.
Raw dataSemantically typed factAllowed to AIMasked / minimisedDenied at the gate
01
Connect sources
Databases, documents, SaaS APIs and streams stay where they are.
02
Map to meaning
Columns and extracted entities become ontology classes and properties.
03
Build the graph
Resolved entities, relationships and lineage in one knowledge graph.
04
Enforce policy
Role, relationship, purpose and sensitivity decide each fact.
05
Ground the AI
Agents receive only permitted, evidence-linked context.
Sensitive-data guardrails
Restrict what AI can see — by meaning, not by table.
Traditional access control asks "can this user open this table?". AI needs a harder answer: "may this agent use this fact, for this purpose, in this context?" We encode that answer in the ontology so every retrieval, prompt and tool call is checked the same way.
- Sensitivity classes on every property
- Purpose-bound access (DPV / ODRL)
- Relationship-aware rules (ReBAC)
- Masking & minimisation by default
- Filter before embed and retrieve
- Scoped tools for MCP agents
- SHACL-validated policy data
- Answer → fact → source provenance
claims-guardrails.ttlTurtle · OWL · DPV
# 1 · Classify the property, not the column ofa:taxId a owl:DatatypeProperty ; rdfs:domain ofa:Claimant ; ofa:sensitivity dpv:SensitivePersonalData . ofa:injuryNotes a owl:DatatypeProperty ; ofa:sensitivity dpv:HealthData . # 2 · Bind access to purpose and role ofa:RepairCoordinationPolicy a odrl:Policy ; odrl:permission [ odrl:assignee ofa:VendorLiaisonAgent ; odrl:action odrl:read ; odrl:target ofa:Vehicle , ofa:LossDescription ; odrl:constraint [ odrl:leftOperand odrl:purpose ; odrl:rightOperand ofa:RepairCoordination ] ] ; odrl:prohibition [ odrl:target dpv:HealthData , dpv:SensitivePersonalData ] . # 3 · Validate before any agent can use it ofa:ClaimantShape a sh:NodeShape ; sh:targetClass ofa:Claimant ; sh:property [ sh:path ofa:taxId ; sh:maxCount 1 ; sh:pattern "^[0-9]{9}$" ] .
Domains
One method. Your domain's meaning.
The engineering pattern is reusable; the vocabulary, sensitive-data rules and evaluation questions are not. We start from the open standard your industry already speaks.
AI & SaaS builders
Ship agents enterprises can trust.
See domain modelInsurance
Policies, claims, parties, ACORD-aligned.
See domain modelHealthcare & life sciences
FHIR-aligned, minimum-necessary by design.
See domain modelFinancial services
FIBO-grounded entities, exposure and KYC.
See domain modelManufacturing
Assets, parts, suppliers and process lineage.
See domain modelSecurity & defense
Threat intel, assets and need-to-know.
See domain modelGlobal delivery
Three regions. One standard of rigour.
Remote-first teams aligned to your time zone and regulatory landscape — on site when it matters.
Americas
United States
Financial services, insurance and healthcare programmes designed with sector regulation such as HIPAA and state privacy laws in view.
Asia-Pacific
Australia
Insurance, banking and public-sector work shaped around the Privacy Act and prudential expectations.
EMEA
Europe
Manufacturing, finance and life-sciences engagements built for GDPR and EU AI Act readiness.
Implementation patterns
What teams build with us
Representative patterns from regulated-domain work. Every engagement is scoped to your data, constraints and success criteria.
Insurance · Agentic claims
Claims agent that never sees what it shouldn't
Claim, policy, party and loss ontology with purpose-bound policies; the vendor-facing agent receives vehicle and loss facts while health and identity data stay behind the gate.
ACORD-alignedODRL policiesSHACL
Healthcare · Clinical RAG
Minimum-necessary retrieval for care teams
FHIR-aligned patient, encounter and condition model; retrieval filters by care relationship and consent before chunks are embedded or returned.
FHIR R4Consent modelGraphRAG
Financial services · Research
Issuer events traced to portfolio exposure
FIBO-grounded instrument, issuer and holding graph lets analysts' copilots answer multi-hop exposure questions with a visible path to source filings.
FIBOMulti-hopPROV-O
How we engage
Start small. Prove it. Scale it.
Scope, deliverables and acceptance criteria are agreed before we build. You own every artefact.
Discover
Pick one workflow. Write the competency questions it must answer and the data it must never touch.
2–3 weeksModel
Reuse standards, design the domain and sensitivity ontology, validate with SHACL and real examples.
3–5 weeksConnect & govern
Map sources, build the graph, wire the policy gate into retrieval and agent tools.
4–8 weeksOperate
OntologyOps: versioning, CI checks, change review and a team that can extend it without us.
Ongoing5 layersof AI data control: classify, bind purpose, relate, minimise, audit
100%open standards — OWL, SHACL, SPARQL, PROV — portable across graph stores
2–3 wksto a readiness assessment with an exposure map and roadmap
Day 1knowledge transfer — your team pairs with ours from the start
FAQ
Questions we hear every week
What exactly is an ontology, and why does AI need one?
An ontology is a formal, machine-readable model of the things in your business, how they relate, and the rules that govern them. LLMs are excellent at language but have no reliable model of your definitions or permissions; the ontology supplies both, so retrieval, reasoning and access decisions use the same meaning everywhere.
How do you stop an AI agent from seeing sensitive data?
We classify sensitive properties in the ontology (for example personal, health or financial data), bind access to role, relationship and purpose, and enforce those rules at retrieval time — before content is embedded, retrieved or passed to a tool. Masking and minimisation are defaults, and every decision is logged with provenance.
Do we have to replace our databases or data platform?
No. The ontology and knowledge graph sit alongside your warehouse, applications and document stores. We map existing sources to the ontology and can virtualise or materialise data depending on latency, cost and governance needs.
Which standards and tools do you use?
W3C OWL 2, RDF, SHACL, SPARQL, SKOS and PROV-O, plus privacy and policy vocabularies such as DPV and ODRL. We reuse domain standards like FIBO, HL7 FHIR, ACORD, ISA-95 and STIX, and work with RDF and property-graph stores including Neo4j, GraphDB, Stardog and Amazon Neptune.
Is an ontology overkill for our use case?
Sometimes, yes. If plain search answers your questions and access is simple, we'll say so. Ontologies earn their cost when definitions conflict across systems, when answers need multi-hop relationships or provenance, or when sensitive data must be governed for autonomous agents.
How do you build an ontology without endless workshops?
We follow established methods — competency questions from TOVE and NeOn, specification-first practice from METHONTOLOGY — accelerated with LLM-assisted term extraction from your schemas and documents. Humans approve; the model drafts. Each module is test-driven against its questions.
Where do you work?
We deliver engagements for organisations across the United States, Australia and Europe. Most work is remote-first and aligned to your time zone, with on-site workshops when they add value.
Can we start without sharing confidential data?
Yes. A workflow description, schema extracts and synthetic samples are enough to scope. Any access to real data, hosting location and permitted use is agreed in writing before delivery begins.
Who owns the ontology when you leave?
You do — every model, mapping, shape, test and document lives in your repository. Our OntologyOps practice and training are designed so your team can extend the model without us.