From shared meaning to reliable agents: engineering an ontology you can trust in production

Last time I set out what it takes to build shared meaning: a governed vocabulary, a canonical model on global identity, governed metrics and data products. This piece picks up where that stopped. How do you turn that foundation into a formal ontology, prove it, and deploy it as production infrastructure that enforces your business rules, protects your data, and lets AI agents act without improvising?

Why agents raise the bar

A wrong number on a dashboard gets noticed by a person, usually before it does much harm. An agent that books, approves, reorders or escalates acts on what it believes, at machine speed, and nobody reads the reasoning first. The cost of an ambiguous definition, a duplicated customer or an unstated rule goes up sharply.

The foundation from last time answers "what do we mean?" Production agents also need four further answers:

• Is the model right? Does it say what we intend, and nothing we do not?

• Is it consistent, and can we show it? Not "it looked fine in review", but evidence

• Are the rules enforced where it matters? At ingest, at write, at the moment an agent acts

• Will it run at scale, securely? With the load, the access controls and the audit trail a production system needs

An LLM cannot supply these on its own, however fluent it is. They have to be engineered into the infrastructure the agent runs on, and the ontology is the place where they are written down once.

1. Formalise, in proportion

We do not start from a blank page. The SKOS vocabulary and canonical model from last time are the raw material, and the competency questions you wrote then become the specification: every question the ontology must answer is a test it must pass.

Formalising means moving from "these terms are related" to "this is what these terms necessarily mean", in OWL 2 — the Web Ontology Language. The skills go well beyond reading it:

• Modelling with restrictions and property characteristics. Transitive, functional, inverse and disjoint constraints are the difference between a diagram and a model a machine can check

• Choosing the profile deliberately. OWL 2 comes in profiles that trade expressivity for tractability. Existential Language (EL) and Rule Language (RL) reason in polynomial time and suit large data. Query Language (QL) is designed so that queries can be rewritten into SQL over the source databases. Full Description Logic (DL) is the most expressive and can be very expensive. This is a deployment decision as much as a modelling one, and it is the first one that determines whether the result will scale

• Ontology design patterns and reuse. Content patterns, the eXtreme Design method and modularisation let you model faster and more soundly than inventing every structure afresh

• Visual design for stakeholders. G-OWL, the complete visual syntax for OWL 2 that I mentioned last time, keeps the domain experts in the review loop, which is where most formal ontologies quietly lose them

The point I made from last time stands. Most of an enterprise value comes from the earlier layers, and a small, careful amount of formal ontology goes where it earns its keep: the core concepts that agents will reason over and act on.

2. Analyse before you assert

Formal languages let you say things that are wrong with great precision. The usual failures are not syntax errors. They are modelling errors: a role treated as a kind of thing, a part-whole relation mistaken for subclassing, a class that mixes things with different identity criteria.

OntoClean (Guarino & Welty) is the established method for catching these. You tag each class with four meta-properties (rigidity, identity, unity, dependence) and the rules show you where a taxonomy is unsound. E.g.: "Student" is a role a person plays, not a subclass of "Person", and a model that makes it one will misbehave the first time someone graduates.

Then anchor the model. A foundational (upper) ontology such as BFO — the Basic Formal Ontology (ISO/IEC 21838-2:2021), DOLCE or the business-oriented gist gives your concepts a consistent footing and makes your model easier to align with others. And reuse what already exists: FIBO in finance, SNOMED CT in health, QUDT for units. Reuse is cheaper than invention and makes you interoperable by default.

3. Prove it

"Prove" covers three levels of assurance, each stronger and narrower than the one before. A sensible programme uses all three, in proportion.

• Test. Treat the ontology like software. Competency questions become executable tests that run on every change, and pitfall scanners such as OOPS! catch common design errors. This level is cheap and catches a great deal

• Reason. A description-logic reasoner (HermiT for full OWL 2 DL, ELK for the EL profile) checks consistency and satisfiability, classifies the model, and, when something is wrong, produces justifications: the minimal set of axioms responsible. That turns "the reasoner says it is inconsistent" into a fixable defect

• Prove. OWL cannot express everything an enterprise cares about: relationships between more than two things, rules that cut across properties, general constraints. For those you move to first-order logic and Common Logic (ISO/IEC 24707:2018), written in its CLIF — Common Logic Interchange Format dialect. A theorem prover (Prover9, Vampire) shows that an intended consequence really follows from your axioms. A model finder (Mace4) searches for a counter-example, and finding one shows the axioms permit something you did not intend. Together they let you check consistency, intended entailments and whether each axiom pulls its weight. Repositories such as COLORE hold verified ontologies you can learn from and reuse

Be realistic about the third level. First-order proof can be slow and is not guaranteed to terminate, and it takes specialist skill. Apply it to the small core where a flaw would be expensive: the definitions that gate payments, safety decisions or regulated outcomes. For everything else, testing, reasoning and runtime constraints give you strong assurance at a fraction of the cost.

4. Enforce the rules

This is where business rules, structural constraints and integrity constraints stop being documentation. The key point is that different rules live in different places, and mixing them up is a common source of surprises:

• OWL says what things are, under the open-world assumption. A missing fact is unknown, not false, so OWL will not reject a record for being incomplete

• SHACL — the Shapes Constraint Language says what a valid record or action looks like, checked closed-world against the data in front of it: required properties, cardinalities, datatypes, value ranges, allowed value sets, relationships that must exist. These are your structural and integrity constraints, and SHACL reports each violation in a standard, machine-readable form. SHACL 1.2 is still a Working Draft at the W3C, so check which engine supports what

• Rules beyond OWL. Derivations and constraints that exceed description logic go in Semantic Web Rule Language (SWRL), Rule Interchange Format (RIF) or Common Logic, or in executable SHACL rules, depending on the engine you will run them on

• Transactional integrity still belongs in the systems of record. The semantic layer adds cross-system rules; it does not replace the database's own guarantees. We may need to express cross system reversal by compensating transactions at the business process level

The discipline is to write each rule once, in the ontology and its constraint set, under version control, and then enforce it at every point where it could be broken (figure 2 below). A rule copied into five applications will drift. A rule referenced from one governed source will not.

5. Build the graph

An ontology with no data is a diagram. The production graph is built with the techniques that connect your estate to the model:

• Declarative mapping. RDB to RDF Mapping Language (R2RML) and RDF Mapping Language (RML) describe how source tables, files and APIs map to the ontology, so the mapping is itself a governed, reviewable artefact rather than buried pipeline code

• Materialise or virtualise. Load the data into the graph, or leave it in place and let ontology-based data access (OBDA) tools such as Ontop answer queries by rewriting them to the source databases. Materialising is faster to query and simpler to reason over; virtualising avoids copies and stays fresh. Most estates end up using both

• Identity. A deliberate IRI strategy, and entity resolution (blocking, matching, probabilistic linkage, with tools such as Splink) so that four records for one customer become one. A governed ontology over duplicated entities is still wrong

• Pipelines with quality gates. Orchestration (Airflow, NiFi) with SHACL validation as a gate, so bad data is stopped and reported before it reaches the graph

6. Serve and act

Agents and applications need a governed way in. That means a serving layer: SPARQL (with property paths and federation), GQL and Cypher for property graphs, and GraphQL for application developers who want an API rather than a query language. Design it API-first, with caching and access control as part of the design, not afterthoughts.

The more interesting step is the operational semantic layer. Once the ontology describes your entities and how they relate across systems, you can describe actions on them too: approve this order, reassign this case, escalate this claim. An action has a type, parameters, preconditions and effects, all expressed in terms of the ontology. Systems that follow this pattern, Palantir Foundry being the best-known commercial example, can drive workflows across the whole estate without moving the data first.

This is what makes an agent's action safe to permit. The preconditions are the rules from capability 4, so an action that would break an integrity constraint is refused before it commits, whichever agent or person attempted it.

7. Scale and secure

Production brings the questions prototypes avoid.

Scale is largely won or lost through earlier decisions:

• The OWL profile you chose in capability 1 sets the ceiling on reasoning cost. Materialising inferences once at load time, rather than reasoning at every query, is a common and effective trade

• Modularise the ontology, so that each application loads what it needs, not everything

• Index and tune the graph (Cypher query optimisation, the right indexes, avoiding supernodes), use graph algorithms where they add insight, and choose between RDF and property graph per workload, with a bridge between them

• Cache the serving layer, and test with realistic volumes before a rollout, not after

Security needs to be designed into the same layers, not bolted on:

• Access control at the serving layer. Who may see which graph, entity type or property, and who may invoke which action. Enforce it where the query or action is executed, and keep the policy under version control with the ontology

• Least privilege for agents. Expose an agent to a narrow, explicit set of tools, authenticated and authorised in their own right. The Model Context Protocol (MCP) is becoming the common way to offer tools to agents, and its authorisation model builds on OAuth. Treat each tool as an API with a security review

• Do not rely on the model to police itself. A prompt that says "never do X" is a request, not a control. Prompt injection means an agent can be talked out of an instruction. The constraint has to sit in the infrastructure, where the agent cannot argue with it

• Provenance and audit. Record what was asked, which facts were used, which rules fired and what was done, using a standard such as PROV-O — the PROV Ontology. That is how you answer a regulator, or a customer, who asks why the system did what it did

Platform security (identity management, network, secrets, encryption) is a discipline in its own right and belongs with your enterprise security architects. The semantic layer's job is to make sure the access rules are expressed against meaningful entities and enforced at the point of use.

8. Ground and guard the agents

Now the agent. Grounding means it works over the governed graph rather than raw tables or a pile of text chunks.

• Retrieval that follows relationships. Vector RAG finds similar passages. GraphRAG and KAG (knowledge-augmented generation) retrieve over the graph, which suits multi-hop questions, identity-dependent questions and anything that turns on a rule. Evaluate them rather than assume: DeepEval and RAGAS measure whether answers are faithful to the retrieved facts

• Context as an engineered asset. A context graph gives the agent memory and a stable picture of the entities it is dealing with, rather than whatever fits in the prompt

• A neuro-symbolic loop. The model proposes, the ontology disposes. The agent drafts a plan or an answer, and the symbolic layer checks it against the constraints and the facts before anything happens. A rejected proposal returns to the agent with the reason, so it can try again

• Guardrails and an evaluation harness. SHACL and reasoner checks at run time, an automated test suite of realistic scenarios, monitoring in production and a record of every run. This is where "reliable" is earned. It is measured, not asserted

One more thing about speed. An LLM can draft candidate classes and axioms in minutes, and used properly it is a real accelerator. Used carelessly it produces a vibe ontology: plausible, fluent and unverified. The safe pattern is the one from last time, assisted then verified: LLM drafts, then competency questions, OntoClean, reasoner and SHACL as gates, with a human reviewing and the provenance recorded.

Governing it as software

An ontology that drives production systems is a production artefact. It needs the lifecycle you would give any critical software: an owner, versioning, a change process, automated tests on every change, a release process, and a way to deprecate rather than delete. Methodologies such as NeOn give you a full ontology-engineering lifecycle. The practical rule is simple: nothing reaches production that has not passed the tests.

A minimum viable production kit

As before, you do not need all of it at once. For one domain and one agentic use case, a defensible first production release is:

• A verified ontology core with its competency-question test suite, and a reasoner consistency report

• A SHACL constraint set covering the structural, integrity and business rules for that use case

• A source-to-graph mapping and a populated graph with entity resolution and quality gates

• A governed serving layer with access control, and one typed action with its preconditions

• One grounded agent with run-time guardrails, an evaluation harness and an audit trace

• A governance pack: owners, versions, change process and release gates

That is a small system, but it is complete: it can be run, tested, secured, audited and extended. The next domain reuses most of it.

The skills, in one place

Last time the role was the semantic translator. The role here is the person who turns that translation into infrastructure, an ontology and knowledge engineer for agentic systems:

• Formal modelling: OWL 2 with deliberate profile choice, design patterns, and ontological analysis with OntoClean and upper ontologies

• Verification: competency-question testing, DL reasoning, and first-order proof and model finding for the critical core

• Constraint engineering: SHACL and rule languages, and the judgement to put each rule in the right place

• Data engineering for graphs: declarative mapping, OBDA, identity and entity resolution, pipelines with quality gates

• Serving and action design: SPARQL, GQL, GraphQL, access control and action modelling

• AI engineering: GraphRAG and KAG, context engineering, agent guardrails, evaluation and monitoring

• Governance: ontology lifecycle, versioning, provenance and audit

It is a demanding profile, but it is learnable. Most of the people who can learn it are already in your organisation, working as modellers, data engineers and architects.

How we're approaching it

This is the ground the second course of our pathway covers, under the same line as the first: Build Shared Meaning Today to Engineer Reliable Agentic Automation Tomorrow.

Course 2 — Engineering Reliable Agentic Automation is for modellers and ontologists, data, ML and AI engineers, and solution architects. It builds on Course 1 (or equivalent: RDF and OWL basics, SPARQL and property graphs) and expects some programming familiarity, for example in Python. Over four and a half days it works through capabilities 1 to 8 at working-to-deep level:

• rigorous modelling: OWL 2 in depth, design patterns, OntoClean and upper-ontology alignment

• constraints, validation and formal reasoning: SHACL, DL reasoners, Common Logic and CLIF, and verification with a theorem prover and a model finder

• engineering the knowledge graph: mappings and OBDA, entity resolution and pipelines, graph performance and algorithms, and the serving layer in SPARQL, GQL and GraphQL

• the operational semantic layer and agentic AI: virtual knowledge graphs, the action layer, GraphRAG and KAG, and grounding agents with context engineering

• reliability, safe acceleration and a capstone: guardrails, evaluation and governance, LLM-assisted construction done safely, and an end-to-end system presented to peers

Every skill is taught on open standards, with the mainstream tools named for each topic. Access control and auditability are built into the serving, agent and reliability sessions. Wider platform security remains the job of your security architecture, and we say so. Participants leave with a working system for a domain of their own: a verified ontology, its constraint suite, a populated graph, a serving layer and a grounded agent with its guardrails and evaluation harness. More on both courses in the posts that follow.

Details of our two course path →

If you would like to discuss the implications of the above for your specific organisation or situation, please book a slot with me:

References and standards

1. W3C, OWL 2 Web Ontology Language Primer, 2nd edition, 2012 — https://www.w3.org/TR/owl2-primer/ · OWL 2 Profiles, 2nd edition, 2012 — https://www.w3.org/TR/owl2-profiles/

2. Guarino, N. & Welty, C. (2009), "An Overview of OntoClean", in Handbook on Ontologies, 2nd edition, Springer.

3. ISO/IEC 21838-2:2021, Top-level ontologies — Basic Formal Ontology (BFO). Arp, R., Smith, B. & Spear, A. (2015), Building Ontologies with Basic Formal Ontology, MIT Press.

4. Presutti, V. et al. (2009), "eXtreme Design with Content Ontology Design Patterns"; Gangemi, A. & Presutti, V. (2009), "Ontology Design Patterns", in Handbook on Ontologies.

5. Glimm, B. et al. (2014), "HermiT: An OWL 2 Reasoner", Journal of Automated Reasoning; Kazakov, Krötzsch & Simančík (2014), "The Incredible ELK", Journal of Automated Reasoning.

6. Poveda-Villalón, M., Gómez-Pérez, A. & Suárez-Figueroa, M. C. (2014), "OOPS! (OntOlogy Pitfall Scanner!)", International Journal on Semantic Web and Information Systems.

7. ISO/IEC 24707:2018, Information technology — Common Logic (CL). Grüninger, M. et al., COLORE: Common Logic Ontology Repository.

8. W3C, Shapes Constraint Language (SHACL), Recommendation, 2017 — https://www.w3.org/TR/shacl/ (SHACL 1.2 in Working Draft). Labra Gayo, J. E. et al. (2018), Validating RDF Data, Morgan & Claypool.

9. W3C, R2RML: RDB to RDF Mapping Language, Recommendation, 2012 — https://www.w3.org/TR/r2rml/. Dimou, A. et al. (2014), "RML: A Generic Language for Integrated RDF Mappings of Heterogeneous Data".

10. Xiao, G. et al. (2018), "Ontology-Based Data Access: A Survey", IJCAI. Calvanese, D. et al. (2017), "Ontop: Answering SPARQL queries over relational databases", Semantic Web.

11. W3C, SPARQL 1.1 Query Language and Federated Query, Recommendations, 2013 — https://www.w3.org/TR/sparql11-query/. ISO/IEC 39075:2024, GQL.

12. W3C, PROV-O: The PROV Ontology, Recommendation, 2013 — https://www.w3.org/TR/prov-o/

13. Model Context Protocol — https://modelcontextprotocol.io/ (check the current specification and its authorisation section).

14. Edge, D. et al. (2024), "From Local to Global: A Graph RAG Approach to Query-Focused Summarization" — arXiv:2404.16130. Liang, L. et al. (2024), "KAG: Boosting LLMs in Professional Domains via Knowledge Augmented Generation" — arXiv:2409.13731.

15. Pan, S. et al. (2024), "Unifying Large Language Models and Knowledge Graphs: A Roadmap", IEEE TKDE.

16. Suárez-Figueroa, M. C., Gómez-Pérez, A. & Fernández-López, M. (2012), "The NeOn Methodology for Ontology Engineering", in Ontology Engineering in a Networked World, Springer. Kendall, E. & McGuinness, D. (2019), Ontology Engineering, Morgan & Claypool.

17. Grüninger, M. & Fox, M. (1995), "Methodology for the Design and Evaluation of Ontologies", IJCAI Workshop on Basic Ontological Issues in Knowledge Sharing.

Closing the shared-meaning gap: what it actually takes

Last week's piece was about the problem: your data has structure but not meaning, and AI now acts on that gap at machine scale. This one is about the work. What should an organisation build, what skills does a data architect or analyst need, and which techniques, languages and standards should they use, in what order?

Start with a diagnosis, not a purchase

The most common failure in this field happens before any modelling starts. Someone says "we need a semantic layer", a vendor demonstrates one, and the budget goes on a tool aimed at a different layer from the actual problem.

Last week I described five senses of "semantic layer": a shared vocabulary, a canonical domain model, the analytics or metrics layer, the operational or integration layer, and formal ontology. The first skill is to tell them apart under pressure. When two dashboards disagree, is that a vocabulary problem (people mean different things), an identity problem (the same customer is four records), or a derivation problem (the same result calculated twice)? Each has a different fix and a different owner.

Two techniques make the diagnosis concrete.

• Map the domain as a graph. Sketch the ten to twenty things that matter as nodes and their relationships as named edges. Then mark where the current models let you down: meaning that lives only in a column label, identity that is local to one system, a missing row treated as "false", and schemas that are siloed or brittle

• Write competency questions. Before modelling, write down the questions the model must be able to answer, in business language, and agree them with the people who will ask them (Grüninger & Fox, 1995). They set the scope, they are your acceptance tests, and they stop the model growing to cover everything

None of this needs a tool. It needs someone who can facilitate a room full of people who each think their definition is the obvious one.

1. A governed shared vocabulary

This is the cheapest semantics that pays, and the step most often skipped because it looks too simple. Most "data quality" disputes are vocabulary disputes in a technical costume.

A governed vocabulary means every business term has a preferred label, a written definition, a named owner, its synonyms, and its place in a hierarchy. The skill is writing definitions that settle arguments ("a customer is a natural or legal person who holds at least one live product") rather than restating the word, and then running a change process that people actually use.

• SKOS — the Simple Knowledge Organization System (W3C Recommendation, 2009) is the standard way to publish it: concept schemes, prefLabel and altLabel, broaderand narrower, and mapping properties (exactMatch, closeMatch) for aligning two vocabularies that grew up apart.

• ISO 25964 covers thesaurus construction and interoperability; ISO/IEC 11179 covers metadata registries and how to name and define a data element properly.

• Tools range from a well-governed glossary in your data catalogue to dedicated vocabulary managers such as VocBench, PoolParty or TopBraid EDG.

One confusion is worth dealing with early: SKOS broader is not subclass of. "Espresso machines" can sensibly sit under "Coffee" in a navigation hierarchy, but a machine is not a kind of coffee. Vocabularies organise terms; ontologies make logical claims about things. Mixing them up causes trouble further on.

2. Thinking in graphs

This is the skill shift, and in my experience it is harder for excellent data modellers than for beginners, because their relational instincts are so practiced.

Entity-relationship modelling, UML and Information Engineering remain a solid foundation, and nearly all of it carries over. What changes is a small set of assumptions:

• Relationships are first-class. A relationship can carry its own properties, be queried directly and be followed across many hops

• Open world, not closed. In SQL a missing row means "no". In semantic systems a missing fact means "unknown". Queries, validation and reasoning all behave differently as a result

• No unique-name assumption. Two identifiers might denote the same thing unless you say otherwise. That is exactly the situation integration puts you in

The labelled property graph is the most accessible way to build this skill. It is close enough to relational thinking that a modeller is productive within a day, and it answers the questions relational databases handle worst, such as "every customer who bought a product made from this contaminated lot". Learn a repeatable recipe for translating an ER model into a graph, and the patterns that separate a good graph from a relational schema with arrows on it: model facts as relationships rather than string properties; promote a property to a node when you need to query or relate it; use intermediate nodes for facts involving more than two things.

The languages are Cypher (openCypher, as in Neo4j and others) and now GQL — the Graph Query Language (ISO/IEC 39075:2024), the first new ISO database query language since SQL. SQL/PGQ (part of ISO/IEC 9075:2023) brings graph pattern matching into SQL itself.

3. A canonical model on global identity

A property graph fixes connection. It does not, on its own, fix meaning across systems, because its node identifiers are still local to one database. The step that turns a data model into an interoperability layer is global identity.

• RDF — the Resource Description Framework reduces everything to the triple (subject, predicate, object) and names things with IRIs — Internationalized Resource Identifiers. Two systems that use the same IRI are making the same claim about the same thing, and their graphs merge without any mapping code. RDF 1.1 (2014) is the current Recommendation; RDF 1.2 reached Candidate Recommendation in April 2026.

• RDFS — RDF Schema adds classes, properties and hierarchy. The classic trap: rdfs:domain and rdfs:range infer types; they do not constrain data. A modeller who expects them to behave like foreign keys will be surprised

• Reuse before you invent. schema.org, FIBO (the Financial Industry Business Ontology), SNOMED CT, QUDT for units, DCAT for datasets and PROV-O for provenance already cover much of what enterprises model from scratch. Evaluating a standard is its own skill: is it good as a vocabulary, as logic, or both?

• Lift the estate you already have. R2RML (W3C, 2012) and RML map relational and file-based sources into the canonical model declaratively, without rewriting the sources

• SPARQL queries the result and, with SERVICE, runs one query across graphs held by different organisations without copying the data

The architectural pay-off is a hub. n systems integrated point to point need up to n(n−1)/2mappings, each with its own quiet assumptions. With a canonical model, each system maps once, to the hub.

Should it be RDF or a property graph? Increasingly the answer is both, with a bridge between them: property graphs for connected operational workloads, RDF where identity, reuse and meaning have to travel. The skill is choosing per use case rather than per ideology.

4. Formal meaning, in proportion

OWL 2 — the Web Ontology Language (W3C, 2012) lets you say what terms necessarily mean, in a form a reasoner can check and draw conclusions from. It is powerful and, as I argued last week, often the most over-applied technique on the map.

For most practitioners the skill needed is reading, not engineering: understand classes, properties and restrictions; know the difference between a primitive class (necessary conditions only) and a defined class (necessary and sufficient, so a reasoner can classify into it); and predict what a reasoner will and will not infer

Visual notations help analysts here. G-OWL (Héon & Paquette) is a complete visual syntax for OWL 2, so a diagram round-trips to Turtle (RDF serialisation) and back, and VOWL offers a lighter-weight view. Both let a domain expert check a formal model as easily as an ER diagram.

The warning from last week still applies. A language model will draft you an ontology in minutes. Without competency questions, analysis and validation, you get a vibe ontology: fluent, plausible and unverifiable. We can use LLMs to do the grunt work, but we need to validate and then verify.

5. Governed metrics: the analytics semantic layer

Everyone agrees what a customer is, but two dashboards still disagree on the count, because the calculation lives in two places. This is metric drift, and it has a boardroom cost.

The fix is to treat a metric as a contract: defined once, with its entities, dimensions, measures, time grain, owner and version, and then served headlessly, so the dashboard, the notebook and the agent all call the same definition instead of reimplementing it. The tools include the dbt Semantic Layer (MetricFlow), Cube, AtScale and LookML.

The link to the earlier steps is what makes this work. A metric's dimensions should come from the governed vocabulary, and its grain from the canonical model. A metrics layer over four unreconciled customer records computes flawlessly and is still wrong.

6. Data products, contracts and governance

Meaning does not stay shared on its own. In a decentralised estate it needs structure:

• Data products with semantic contracts. Data mesh's four principles (domain ownership, data as a product, self-serve platform, federated governance) depend on semantics as their connective tissue. A product's "order" should be the canonical model's Order, with its real relationships intact

• Naming, versioning and stewardship. Conventions people can follow; deprecation rather than deletion; and distinct roles for who defines a term, who owns the data and who approves change

• Lineage and provenance. Metric-level impact analysis ("what breaks if we change active customer?"), recorded in a standard way with PROV-O — the PROV Ontology

• Validation at the boundary. The model can stay open-world while data entering a product is checked closed-world. SHACL — the Shapes Constraint Language (W3C, 2017; 1.2 in draft) is the standard for that. OWL says what things are; SHACL says what a valid record looks like

The human side matters as much as the apparatus. A lightweight change process that people use beats a thorough one they avoid.

7. Grounding AI

An agent working over raw tables has no stable notion of an entity, invents joins, and delivers wrong answers with full confidence. Everything above gives it something firmer to stand on: entities with global identity, governed definitions it can call, and paths it can follow and explain.

Practitioners need to understand the retrieval options well enough to choose between them. RAG retrieves text chunks by similarity. GraphRAG retrieves over a knowledge graph, so the answer follows real relationships. KAG (knowledge-augmented generation) goes further, reasoning over the graph's structure and logic. A graph earns its place over a vector index when the question depends on relationships, identity or rules rather than on finding similar text.

Shared meaning is the prerequisite for reliable AI, not the polish on it.

Putting it together: a minimum viable kit

An organisation does not need all of this at once. It needs a small, coherent starting point that the next team can build on. In practice that is five artefacts for one domain, each of which feeds another:

• A governed vocabulary, which names the model's entities and supplies the metric's dimensions

• A canonical model, which sets the metric's grain and supplies the data product's entities

• One governed metric, wired to the model

• One data product with a stated contract

• A one-page governance note that gives each an owner, a version and a change process

Add the competency questions the kit can now answer, so whoever picks it up knows what it is for and can test it. That is a defensible first rung, not a half-built system. The next rungs are formal rigour on the model, SHACL validation against real data, and agents that act on the graph. They cost more, and each stands on the one below.

The skills, in one place

Taken together, this describes a role many organisations already need but rarely name: a semantic translator between the business and the data and AI teams. The profile is:

• Diagnosis: placing a problem on the right layer, and saying so to a sponsor

• Elicitation: competency questions, and definitions that settle arguments

• Modelling: ER and UML fluency, plus graph thinking and the open-world gear-change

• Standards literacy: SKOS, RDF, RDFS, SPARQL, Cypher and GQL at working level; OWL and SHACL at reading level

• Analytics: governed metrics and a headless semantic layer

• Governance: ownership, versioning, lineage and data contracts

• AI literacy: why grounding matters and which retrieval pattern fits which question

Most of it needs no formal logic at all, and it returns most of the value.

How we're approaching it

This is the ground we built our training pathway around. It has two courses, under one line: Build Shared Meaning Today to Engineer Reliable Agentic Automation Tomorrow.

Course 1 — Building Shared Meaning is for analysts, BI practitioners, data modellers and domain experts, and needs no programming or logic background. Over four and a half days it works through capabilities 0 to 6 above at hands-on depth and 7 at awareness level: diagnosis and domain mapping; property graphs with Cypher and GQL; a governed SKOS vocabulary; RDF, RDFS, reading OWL through G-OWL, and SPARQL; governed metrics in dbt and Cube; data products, governance and lineage; and the connection to AI. Each day produces one artefact of the minimum viable kit, and participants leave with the whole kit built for a domain of their own.

Full details here: https://www.inspired.org/course-1-build-shared-meaning

Course 2 — Engineering Reliable Agentic Automation takes the upper rungs: formal rigour, SHACL validation, the operational layer and grounded agents. More on that in the next post.

References and standards

1. W3C, SKOS Simple Knowledge Organization System Reference, Recommendation, 2009 — https://www.w3.org/TR/skos-reference/

2. ISO 25964, Thesauri and interoperability with other vocabularies; ISO/IEC 11179, Metadata registries

3. ISO/IEC 39075:2024, Information technology — Database languages — GQL; ISO/IEC 9075-16:2023, SQL/PGQ

4. W3C, RDF 1.1 Concepts and Abstract Syntax, Recommendation, 2014 — https://www.w3.org/TR/rdf11-concepts/ · RDF 1.2 Concepts and Abstract Data Model, Candidate Recommendation, April 2026 — https://www.w3.org/TR/rdf12-concepts/

5. W3C, R2RML: RDB to RDF Mapping Language, Recommendation, 2012 — https://www.w3.org/TR/r2rml/

6. W3C, SPARQL 1.1 Query Language and Federated Query, Recommendations, 2013 — https://www.w3.org/TR/sparql11-query/ (SPARQL 1.2 in Working Draft)

7. W3C, OWL 2 Web Ontology Language Primer, 2nd edition, 2012 — https://www.w3.org/TR/owl2-primer/

8. Héon, M. & Paquette, G., "G-OWL: A Complete Visual Syntax for OWL 2 Ontology Modeling and Communication", Semantic Web journal — semantic-web-journal.net

9. W3C, Shapes Constraint Language (SHACL), Recommendation, 2017 — https://www.w3.org/TR/shacl/ (SHACL 1.2 in Working Draft)

10. W3C, PROV-O: The PROV Ontology, Recommendation, 2013 — https://www.w3.org/TR/prov-o/

11. dbt Labs, dbt Semantic Layer / MetricFlow — docs.getdbt.com · Cube — cube.dev/docs

12. Grüninger, M. & Fox, M. (1995), "Methodology for the Design and Evaluation of Ontologies", IJCAI Workshop on Basic Ontological Issues in Knowledge Sharing.

13. Dehghani, Z. (2022), Data Mesh: Delivering Data-Driven Value at Scale, O'Reilly.

14. Robinson, I., Webber, J. & Eifrem, E. (2015), Graph Databases, 2nd edition, O'Reilly.

15. Allemang, D., Hendler, J. & Gandon, F. (2020), Semantic Web for the Working Ontologist, 3rd edition, ACM Books.

16. Edge, D. et al. (2024), "From Local to Global: A Graph RAG Approach to Query-Focused Summarization" — arXiv:2404.16130

17. Liang, L. et al. (2024), "KAG: Boosting LLMs in Professional Domains via Knowledge Augmented Generation" — arXiv:2409.13731

Your data has structure. It doesn't have meaning

Why enterprise AI has made a thirty-year-old question urgent — and what the move from Information Engineering, UML and relational modelling to graph, semantic and ontology-driven execution actually demands of practitioners.

The problem is not the model. It's the ground truth.

Shared meaning is not a new problem. Warehouse teams have been fighting "whose definition of revenue?" for thirty years. What changed is who is now reading the data.

A traditional report was read by an analyst who knew that "active customers" in the marketing dashboard was not the "active" the risk team used. She carried the caveat in her head, applied it, and moved on. The ambiguity was real but bounded — it lived in a few expert skulls and travelled no further than a meeting.

Put an agent in that seat. Ask it "how many active customers do we have in the North region, and what is their total exposure?" It will join the marketing table's active flag to the risk system's exposure column, sum the result, and return a confident number in fluent prose. It does not know the two systems mean different things by customer. It has no caveat. And its output looks exactly as authoritative as a correct answer would.

Three properties of AI-mediated work turn latent ambiguity into active cost:

• Amplification. A human analyst makes one join an hour. An agent makes thousands, unsupervised. Every wrong assumption about what a field means is now executed at machine scale

• Composition. Agents chain steps. A subtly wrong definition at step one propagates, and by step five the provenance of the error is gone. The answer is wrong and unexplainable at once

• Opacity of confidence. The failure mode is not a crash or a NULL. It is a plausible, wrong, actionable answer - the expensive kind

The instinct, when the agent gets it wrong, is to reach for a bigger model or better prompts. But the error is not in the model's reasoning. It is in the ground truth the model reasoned over. If customer denotes four different things in four systems, no amount of model capability recovers the one you meant — because that thing was never written down anywhere a machine could read it.

Semantics is the missing input, not a missing capability.

"Semantic" means five different things

Here is where most programmes go wrong before they start. "Semantic layer" is the most overloaded phrase in enterprise data. Serious people use it to mean at least five distinct things that live in different places, are owned by different people, cost different amounts and solve different problems.

They are not rival definitions. They are a stack:

Read one word — customer — down that stack and the point becomes clear. Each reading is legitimate. Each is owned by a different team. Each fails in a different way.

Why this matters commercially: a retail bank funds a "Single View of Customer" programme. The deck talks about AI. The budget goes on a layer-3 analytics semantic layer, because that is what the vendor demonstrated. Eighteen months later the executive dashboard still shows three different customer counts — because the actual problem was layer 2. The same person exists as four unreconciled records in four systems, and no metrics layer reconciles identities it was never given. The programme built a precise calculator on top of an unresolved question.

Buying layer 3 to fix a layer-1 or layer-2 problem is the single most expensive mistake in this field.

Four demands, and the standards that answer them

1. Shared meaning — a common controlled vocabulary

Before anything else: do people agree what the words denote? "A customer is a natural or legal person who holds at least one live product with the bank." Plain language, agreed by humans, no code.

Most "data quality" disputes are vocabulary disputes wearing a technical costume. The formalisation is cheap and unglamorous: SKOS — the Simple Knowledge Organization System (W3C Recommendation, 2009) gives you concepts, preferred and alternative labels, broader/narrower hierarchies and mappings between schemes. ISO 25964 covers thesaurus construction and interoperability; ISO/IEC 11179 covers metadata registries and the discipline of naming and defining a data element properly.

This is the twenty per cent of the stack that needs no logic at all and returns most of the value. Skip it and everything above inherits the ambiguity.

2. Agreed derivation — the semantic layer for BI

Everyone agrees what a customer is, and two dashboards still disagree on the count, because the calculation lives in two places. The answer is a governed metric definition — active customer = at least one transaction in the last 90 days — written once, over the warehouse, and resolved identically by the dashboard, the notebook and the agent.

This is the sense most vendors mean today: the dbt Semantic Layer, Cube, AtScale, LookML. It is genuinely valuable, and it is also where the confusion concentrates, because it is the layer with the biggest marketing budget. A metrics layer computes flawlessly over whichever records you feed it. If those are four unreconciled customers, the metric is precise and wrong.

The real prize here is not the dashboard. It is that an agent can call a governed metric instead of misjoining raw tables.

3. Integration and interoperability — semantic expression

Point-to-point mapping does not survive past a handful of systems: n systems need n(n−1)/2 mappings, each with its own quiet assumptions. Meaning that travels needs to be expressed in a form that is not owned by any one system.

• Semantic data is best expressed in graphs. A graph is a connected set of statements, conceptually nodes and edges. e.g. John -worksFor-> Enron -sells-> Oil

• Graphs can be stored in simple fact statements (see RDF) or Labelled Property Graphs (see LPG)

• RDF — the Resource Description Framework (W3C; RDF 1.1 in 2014, with RDF 1.2 reaching Candidate Recommendation in April 2026) reduces everything to the triple: subject, predicate, object. e.g. John worksFor Enron; Enron sells Oil. RDFS — RDF Schema adds classes, properties and subsumption (class subtyping)

• IRIs — Internationalized Resource Identifiers replace local primary keys with globally resolvable names, so "the same customer" is a claim two systems can actually make

• SPARQL — the SPARQL Protocol and RDF Query Language (1.1, 2013; 1.2 in draft) provides queries and updates across a graph of triples

• RDF vs LPG — RDF data stores (otherwise known as Triple Stores) can accommodate data without schema (or with) and can expand easily to accommodate new data without structure change. They are best for integrating data from heterogeneous sources. Labelled Property Graphs are more efficient and best for transactional and operational data

• R2RML — the Relational DB to RDF Mapping Language (W3C, 2012) and RML — the RDF Mapping Language lift the relational and file-based estate you already have into RDF form, declaratively, without rewriting the sources

• JSON-LD — JavaScript Object Notation for Linked Data (1.1, W3C, 2020) carries the same meaning inside ordinary API payloads, which is how layer 4 gets done in practice

• On the property-graph side, GQL — the Graph Query Language (ISO/IEC 39075:2024) is now an ISO standard in its own right, and SQL/PGQ (part of ISO/IEC 9075:2023) brings graph pattern matching into SQL. The RDF-versus-LPG argument is largely over: mature programmes run both and bridge between them

• Reuse beats invention: There are many sources of well defined models addressing generic requirements as well as specific disciplines. Consult schema.org, FIBO — the Financial Industry Business Ontology, SNOMED CT — Systematized Nomenclature of Medicine, Clinical Terms, QUDT — Quantities, Units, Dimensions and Data Types, PROV-O — the PROV Ontology for provenance, DCAT — the Data Catalog Vocabulary for datasets

Using these technologies allows merging and reaching consensus on definition and holding that stable and shared in a standard format.

4. Reliability and agentic automation — formal ontology backed by logic

Here the stakes change. If an agent acts on your model, "roughly right" stops being a documentation problem and becomes an operational risk. That demands semantics formal enough for a machine to check.

• OWL 2 — the Web Ontology Language (W3C Recommendation, 2012) sits on description logics, a decidable fragment of first-order logic. Its profiles — EL, QL, RL and the full DL — are deliberate trade-offs between what you can say and what a reasoner can compute in reasonable time. Choosing the profile is an architectural decision, not a detail

• SHACL — the Shapes Constraint Language (W3C Recommendation, 2017; 1.2 drafts in progress) does the job OWL was never designed for: validating that actual data conforms to a stated shape. OWL says what things are; SHACL says what a valid record looks like. Conflating them is the most common beginner error in the field

• Common Logic (ISO/IEC 24707:2018), and its CLIF — Common Logic Interchange Format syntax, expresses the constraints description logic deliberately cannot: n-ary relations, multi-property rules, conditions over time. Paired with a theorem prover and a model finder, it also lets you verify an ontology — state the intended models, prove the entailments you expect, and check that your axioms are independent and consistent. This is the discipline that separates an engineered ontology from a plausible-looking one

• Top-level ontologies give your concepts somewhere to stand: BFO — the Basic Formal Ontology (ISO/IEC 21838-2:2021), DOLCE — the Descriptive Ontology for Linguistic and Cognitive Engineering, and gist (Semantic Arts small business high level ontology). OntoClean (Guarino & Welty) supplies the analytical tests — identity, rigidity, unity, dependence — that catch the taxonomy errors everyone else ships

Only at this rung does an agent get something it can be held to: classifications it can derive, constraints it can be blocked by, and an audit trail explaining why it concluded what it concluded.

The transition practitioners actually have to make

To be fair to the tools we already use, they carried us a very long way and none of this asks you to throw them out.

Codd's relational model (1970) gave data a rigorous mathematical foundation and the normalisation theory that removes update anomalies — arguably the most successful idea in applied computing. Chen's entity-relationship modelling (1976) gave us the picture: entities, attributes, cardinalities, drawn so a business person can read it and a database can be generated from it. UML class diagrams and the wider Information Engineering tradition added object structure and the discipline of conceptual → logical → physical design. The patterns literature — Hay, Simsion & Witt — is full of hard-won wisdom that remains correct: the Party pattern, role versus thing, resolving many-to-many relationships properly.

All of it comes with you. Graph modelling is not a rejection of data modelling. It is data modelling with the assumptions resolved.

The hard part is not the standards. It is the unlearning — and in my experience excellent data modellers find this transition harder than beginners do, precisely because the old instincts are so good. Thirty years of closed-world reflexes ("if there's no row, it didn't happen") do not switch off because you read the OWL primer. Training has to be designed around that, not around the specification.

Where to start

Most enterprises need a great deal of layers 1 to 3 and a careful, small amount of layer 5. Formal ontology is the most powerful and the most over-applied technique on the map. Reaching for OWL when a governed glossary and a resolved identity would have done is how semantic programmes acquire their reputation for cost and delay.

There is a newer failure mode too. Large language models will happily draft you an ontology in minutes. Without competency questions, OntoClean analysis, SHACL validation and reasoner checks, what you get is a vibe ontology: fluent, plausible, and unverifiable — the same failure as the confident wrong answer, one level further up the stack. Assisted, then verified. In that order.

What we're doing about it

These threads — shared vocabulary, the canonical model, the semantic layer, integration, formal ontology, and the bridge into agentic AI — are what we have spent this year building a training path around.

We're introducing it as two courses: a transition course for commercial analysts, BI practitioners and domain experts who need to become the bridge to semantic work; and an advanced engineering course for modellers, ontologists and AI implementors who have to build the solution and put it into production.

Ready to make this shift on your own data estate?

Course 1: Building Shared Meaning starts 19–23 October.

References and standards

Standards

1. W3C, RDF 1.1 Concepts and Abstract Syntax, Recommendation, 2014 — w3.org/TR/rdf11-concepts; RDF 1.2 Concepts and Abstract Data Model, Candidate Recommendation, 2026 — w3.org/TR/rdf12-concepts

2. W3C, SKOS Simple Knowledge Organization System Reference, Recommendation, 2009 — w3.org/TR/skos-reference

3. W3C, OWL 2 Web Ontology Language Primer, 2nd edition, 2012 — w3.org/TR/owl2-primer

4. W3C, Shapes Constraint Language (SHACL), Recommendation, 2017 — w3.org/TR/shacl; SHACL 1.2 Core, Working Draft — w3.org/TR/shacl12-core

5. W3C, SPARQL 1.1 Query Language, Recommendation, 2013 — w3.org/TR/sparql11-query

6. W3C, R2RML: RDB to RDF Mapping Language, Recommendation, 2012 — w3.org/TR/r2rml

7. W3C, JSON-LD 1.1, Recommendation, 2020 — w3.org/TR/json-ld11

8. ISO/IEC 39075:2024, Information technology — Database languages — GQL

9. ISO/IEC 24707:2018, Information technology — Common Logic (CL)

10. ISO/IEC 21838-2:2021, Top-level ontologies — Basic Formal Ontology (BFO)

11. ISO 25964, Thesauri and interoperability with other vocabularies; ISO/IEC 11179, Metadata registries

Literature

1. Codd, E.F. (1970), "A Relational Model of Data for Large Shared Data Banks", Communications of the ACM 13(6).

2. Chen, P. (1976), "The Entity-Relationship Model — Toward a Unified View of Data", ACM TODS 1(1).

3. Berners-Lee, T., Hendler, J. & Lassila, O. (2001), "The Semantic Web", Scientific American.

4. Guarino, N. & Welty, C. (2009), "An Overview of OntoClean", in Handbook on Ontologies, Springer.

5. Allemang, D., Hendler, J. & Gandon, F. (2020), Semantic Web for the Working Ontologist, 3rd edition, ACM Books.

6. Hogan, A. et al. (2021), "Knowledge Graphs", ACM Computing Surveys 54(4).

7. Noy, N. et al. (2019), "Industry-scale Knowledge Graphs: Lessons and Challenges", Communications of the ACM 62(8).

8. Suárez-Figueroa, M.C. et al. (2012), Ontology Engineering in a Networked World (the NeOn methodology), Springer.

9. Grüninger, M. & Fox, M. (1995), "Methodology for the Design and Evaluation of Ontologies", IJCAI Workshop on Basic Ontological Issues in Knowledge Sharing.

10. Lewis, P. et al. (2020), "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", NeurIPS — arXiv:2005.11401

11. Edge, D. et al. (2024), "From Local to Global: A Graph RAG Approach to Query-Focused Summarization" — arXiv:2404.16130

Graham McLeod · Inspired.org

Back to the Future, with a Twist

In the early days of AI, rules were laboriously translated to code to provide logic guiding expert systems. These had some success in very narrow use cases. They failed in the broader context of general business and industry. Often this was due to their lack of context (general knowledge), lack of standards for rule definition, inability to understand natural language and sheer effort of encoding the expert knowledge in machine usable form.

The field took a leap forward with machine learning - using computer power to iterate massively on algorithms or large sets of data and, with human guidance, allow the system to improve its performance. Transformer architecture and massive data sets (aka the Internet, social media, wikipedia etc. ) took this to another level in large language models. These are spookily capable, generally well informed (in terms of general knowledge), handle natural language competently and perform well on generic problems. They do still, however, exhibit hallucinations where they can give confident, well articulated answers which are totally wrong. This shows that they do not understand what they are processing, but work on prediction and probability. They can be made deterministic, but only if we can provide local data, context and rules in a very structured, standard, machine accessible format, preferably at scale and at runtime.

In parallel, the fields of logic, reasoning and ontology have grown up. Efforts like the Semantic Web and the Human Genome Project required defining, capturing, linking and integrating huge quantities of information. Standards have emerged for describing data in terms of conceptual graphs (RDF, RDFS, OWL) as well as constraints, derivations, inferences (SHACL, CLIF). These have been used to define standard top level ontologies (BFO, UFO) which provide a foundation on which to build more specific domain ontologies. OWL, SHACL and CLIF provide ways to link the logic to the data and express it in standard, technology neutral ways.

We are now witnessing the emergence of platforms (Palantir, SAP Knowledge Graph, Microsoft Fabric IQ, Enterprise Web) which leverage enterprise ontology at run time to provide an integrated application landscape for business execution. This is filling the gap to enable reliable agentic processes by providing AI with structured, rigorous guidance on data and business logic. Some of these platforms encode the ontology in proprietary or technology specific format with resultant danger of vendor lock in. I predict that there will be a second wave where this knowledge is captured by organisations themselves as their digital business operating model and a core IP asset. They can then deploy this on a platform of choice able to ingest it using the standards mentioned above.

Watch this space for news of our own ontology modelling and execution platform (Sapiento) and an emerging enterprise ontology based upon standards (AEON). 

AI - Achieving Benefits

It’s not only about the technology…

In the last few posts I posited that we are at an inflection point in the capabilities of AI and its potential to deliver major benefits IF used correctly and for the right use cases. The last post teased that we need different forms of AI to achieve deterministic outcomes - where we can rely on the results without the delay and cost of human oversight.

LLM based systems rely on prediction based upon statistical correlations from training data. This is very powerful when dealing with language but less so when we need precision. LLMs struggle with logic, maths and problems requiring a chain of thought. All kinds of workarounds have been developed to break down problems, overcome memory limitations, provide richer context, use specialised systems for parts of tasks etc. These all improve performance markedly, but they do not guarantee reliable results.

There are different AI models that rely less on syntactics (language) and more on knowledge (ontology) and logic (axioms, rules expressed formally). These systems are not new, but are more difficult to design and take more effort to configure - for example, we need to reach consensus on agreed and capable ontologies in a given domain (e.g. healthcare, manufacturing). Fortunately, these efforts are now starting to pay off, leading to AI systems that are reliable and orders of magnitude more efficient. They can be incorporated into production systems with real time response and little to no human supervision.

Benefits are not achieved by technology alone. We have to employ it properly. This involves selecting the right technology for particular use cases, selecting applications that are within the capabilities available, considering the full architecture of a solution, including:

• human concerns (roles, safety, desirability, ethics, experience)

• organisational (stakeholders, goals, customers, offerings, process, resources)

• systems (functionality, workflow, interfaces, integration, security, efficiency)

• data (scope, definition, design, sourcing, management, security, privacy)

• technology (types, integration, standards, infrastructure, performance, scale, security)

• governance (principles, policy, projects and change, quality assurance, risk management)

So we should remember the adage:

“There is almost always a management solution to a technology problem.
There is almost never a technical solution to a management problem”

AI can deliver enormous benefits, if we use it well. That is the bigger challenge.

Explore more in our upcoming workshop →

AI — Hitching a Ride, or Driving?

Many organisations are still using large language models mainly as conversational advisors. Others are making strategic shifts and using AI to drive deterministic outcomes. In between are many organisations trying to move forward while burning time, resources, patience, and sometimes reputation.

The difference often comes down to skill sets, mindsets, and workflows. The tools are powerful and improving weekly.

Hitching a Ride

To use AI effectively at the conversational level, important skills include:

• Prompting well

• Providing the right context

• Breaking tasks into steps that fit model limitations

• Choosing appropriate models

• Guiding the conversation toward a useful result

Typical applications include:

• Summarising or improving text

• Generating images or design work

• Accelerating research

• Creating presentations or communication artefacts

• Getting business or product advice from a “virtual board”

Most workflows here occur through chatbot interfaces such as ChatGPT, Claude, or Gemini. It’s a bit like discussing ideas with a knowledgeable colleague or delegating work to a capable intern.

Driving

At the next level, things change significantly:

• Moving from advice and text transformation to action

• Using agentic tools that can execute tasks: generate documents, presentations, code, tests; create files; update codebases; run tests; integrate applications; and perform transactions

Tools such as Microsoft Copilot, Claude Code / CoWork, and Gemini Enterprise support this through:

• APIs for integration into applications and workflows

• Desktop, browser, and mobile clients for defining and managing agents

• Parallel goal-seeking agent workflows that can run for extended periods

• Permissions allowing agents to interact with local systems, operate services, and perform transactions

Many of these tools rely on Model Context Protocol, which enables interoperability between AI systems and traditional software.

Skill sets for this level shift toward strategy, architecture, design, management, and quality assurance — much closer to executive and organisational capability.

It also opens the possibility of embedding AI directly into core operational capabilities, requiring careful choices about application areas, technologies, and organisational change.

Moving Beyond LLMs

Large language models are fundamentally prediction machines trained on large public corpora such as literature, the internet, and social media. Their answers reflect averages and biases in that material, and they can hallucinate — producing plausible but incorrect responses.

This can work where humans remain in the loop. It is far less suitable where reliable automation of operational tasks is required.

For deterministic outcomes — and lower compute consumption — we will increasingly need other forms of AI based on ontology and axioms.

More on this in the next post.

Read about our upcoming workshop here.

Architecture of AI: Navigating Today’s Accelerating Capabilities

We have hit an inflection point in AI capabilities. AGI? No. Usefulness ++. Capability much higher than you think… Risk, absolutely.

We have been researching, analysing and preparing for our upcoming workshop Architecture of AI | Architecting for AI. Things are moving fast, and accelerating. Many things I would have said ”Nah, not really” to in November are now firmly a “Yes, provided you do it right”.

Several trends and developments are converging in powerful ways:

• Foundation models have become very good at understanding language, both input and output

• Smaller, cheaper, local and on-device models are now very capable for particular applications

• Agentic capabilities are maturing and allowing models and tools to act instead of just inform or advise. They also allow spawning multiple long running, goal seeking tasks in parallel

• Natural language interfaces, both written and spoken, are dissolving UI barriers across productivity software, technical environments (operating systems and development tools) and enterprise software (ERP and SaaS). Users can now build complex workflows across heterogeneous environment without technical specialists

• World View models are maturing - endowing AI systems with 3D real world knowledge and enabling them to operate in the physical world (Robots, androids, self driving vehicles)

• Tools for developers are growing up fast, integrating tightly into toolchains, local file systems, remote code repositories and deployment infrastructures. A select few shops are getting massive productivity gains, while others are finding AI slows productivity! The difference is in the lifecycle, workflow and skills. The benefits are achievable, but not easy to realise

• Ontologies and formal logic are underpinning next generation AI systems that will provide deterministic behaviour, eliminating hallucinations, while improving efficiency by orders of magnitude

What we are seeing is a plethora of power tools. There are titanic battles taking place for infrastructure, market share, capabilities, emerging “standards” and dominance. It is an exciting but dangerous time. To use an analogy of carpentry: power tools will allow some to build houses twice as fast, while others may chop off limbs.

At an individual level, the risks are mainly to privacy, accuracy and productivity. At a corporate level there are major security, privacy, intellectual property, reputation and competitive capability risks. There are grave dangers of enterprise architectures, policies and governance unravelling. OTOH there are massive opportunities that we cannot ignore without losing competitiveness.

Today’s rabbit picture suggests that we should at least hitch a ride, rather than getting run over or plodding through the landscape. Join our workshop coming up on 23- 24 March to see how →

Watch this space for the next instalment!

Introducing Architecture of AI | Architecting for AI: 2-day workshop

We are thrilled to be working with Jay van Zyl and ecosystem.Ai to bring you an essential workshop - Architecture of AI | Architecting for AI

Many organisations we talk to are convinced that they will need to take advantage of AI to remain competitive and agile. At the same time, given the pace of developments, most are not sure what the capabilities of current AI are, what application areas to tackle, which AI systems to use, or how to architect solutions that will deliver value and be sustainable.

Jay van Zyl brings immense experience of working internationally, architecting products and developing world leading recommender systems now deployed at major banks, telcos and retailers. ecosystem.Ai is also at the forefront of using AI internally to develop their own products and recently released their own AI coding and deployment platform.

My colleagues and I (Graham McLeod) at Inspired.org have led in integrated business and I.T. strategy through holistic architecture frameworks, methods, language and tools for over a decade. We advise leading corporates on digital transformation and operating models. Inspired uses AI to assist with enterprise modelling, ontology, consulting, research and marketing.

Together we will:

• Explore the state, architecture, capabilities, risk and implications of current AI offerings

• Identify which types of AI are suited to what applications, with examples and case studies to illustrate

• Cover the organisational, societal and business implications of AI

• Unpack what it takes to architect for successful deployment of AI and related technologies, including:

  • Principles and policies

  • Governance, skills, capabilities

  • Data preparation and training

  • Choice of application areas and suitable AI types, models and products

  • Business case development

  • Training and execution/inferencing infrastructure

  • Integration with other applications and services

  • Risks and amelioration

  • Scaling and continuous improvement

Don’t miss it!

Read more and reserve your place now →

Business Architect Capabilities - Revised Scorecard

We are encouraged to see many more job advertisements seeking Business Architects. The role now seems well established as senior, strategic and value adding in most leading corporates and quite a lot of government and non-profits.

There is still not total agreement on what capabilities, skills and knowledge a business architect should have in the industry.

In 2021 we developed a competence survey which probed the dimensions which we believe are necessary for high performance. This has been taken by over 1000 respondents. We revised that in March 2025. We have again tweaked it slightly based upon feedback to make it a bit easier to answer.

Take the free assessment here →

EDGY Support in EVA

EDGY is an innovative and light weight approach to Enterprise Design which rapidly gained ground in Europe and is spreading quickly to other regions. There is an obvious overlap with our approach to Business Architecture based upon our Holistic Architecture Language (HAL). We like to ensure that we are not missing anything critical, so we review emerging approaches. We found a high correlation between our approach and models and EDGY. We did like the simple way in which EDGY is presented. There is good online methods guidance and sample models, making it accessible. Training is being offered. There is currently very limited tool support for EDGY.

Our Enterprise Value Architect (EVA) Platform and HAL models allow us to support multiple frameworks and perspectives, so we added support for EDGY.

This includes support for the EDGY meta model (concepts, properties, relationships), the EDGY navigation map, EDGY based graphical models, canvasses for each EDGY facet and online reference for EDGY itself.

Using EVA as a platform automatically gives us a multi-user environment with secure repository, web UI, Reporting, Search, Import/Export and many other capabilities.

Integrating EDGY requirements with our comprehensive HAL models allows extending from Enterprise Design as covered in EDGY into related domains (e.g. Application Architecture, Information Architecture, Enterprise Risk, Programme Management) seamlessly.

Please message or eMail me if you would like to be on the list for early evaluation access.

Background and further information

EDGY Approach
HAL Holistic Architecture Language (Integrated meta model)
EVA Enterprise Value Architect Tool Platform
View demonstration of EDGY support in EVA

Wardley Maps in EA

Pleased to confirm I will be presenting a paper on support for Wardley Maps in our Enterprise Value Architect (EVA) tool platform at the Practice of Enterprise Modeling (POEM) conference in Geneva, 3rd-5th Dec.

The paper details how we were able to rapidly adapt our Holistic Architecture Language models in EVA to support the Wardley Map concepts and requirements, as well as adding support for the graphical notation in the Graphical Modeler.

Wardley maps add a key dimension to strategy and enterprise/business architecture by providing a time/evolution dimension to various elements, including products, services, support systems and technology. They facilitate examining how key elements will evolve during the planning horizon and assist in anticipating road blocks.

The paper also suggests how integrating with the broader EA models adds rigour and value to the Wardley Maps themselves.

You can read the paper here.

From the abstract:

...The paper discusses why Wardley Mapping is a good complement
to EA models, how Wardley Mapping can be integrated with EA and the
advantages that this can realise. It offers potential extensions to Wardley Maps
and a meta model fragment to integrate maps with the EA world.

More on EVA here →

Watch the webinar with Simon, the creator of Wardley Maps →

More on Wardley Maps in general →

Raising Capabilities for Desirable Change

We recently wrapped up the 3-4Q 2025 programme of our Business Architecture Mastery Programme with excellent feedback from a strong cohort. This programme has now trained over 100 senior Business Architects to a mastery level. If we add to that the 230+ individuals who attended our five day Techniques and Deliverables of Business Architecture course, that is a significant contribution to building serious business architecture / digital transformation skills and capabilities.

We are now accepting enrolments for the first cohort in 2026 which will run from 26th March to 9 July 2026. Sessions take place for 3.5 hours each Thursday. Full details can be found on the course page here. Book now to lock in 2025 pricing and early bird discounts.

If you are not ready for the full high level programme yet, consider the Techniques and Deliverables of Business Architecture course.

Lets make a bigger, better difference in 2026!

Business Architect / Digital Strategist Competence - V2

Our 2021 BA Scorecard assisted aspirant/current BAs to assess their capabilities. Of 2256 visitors, 917 proceeded to the scorecard. We just updated the Scorecard to V2.

Take the revised survey here ➔

Some insights from the original in the graphic below.

• Overall scores balanced: Low 34%; Medium 50%; High 17%, indicates that most participants need further skill development. Expected as the cohort is keen to transition to a professional business architect role.

• Lowest score categories: Learning and Development; Qualifications and Experience; Business Architecture Scenarios.
  Few individuals/employers commit enough time and effort to growing skills necessary to maintain competence in this fast evolving discipline. More formal training and certification needed. BA is a young discipline, so experience levels are low relative to other fields.
  BA Scenarios are uniquely covered by the Business Architecture Guild, so many are not familiar with these

• Highest score categories: Soft Skills; Management, Leadership and Culture; Ontologies and Taxonomies.
  Augers well for attention to people, organisation, stakeholder management and communication aspects required of BAs. Participants are relatively senior and have gained important skills in their current roles.
  Good appreciation for the value of ontologies/taxonomies and meta models to structure work, gather information, assess maturity and achieve integration

• Good capabilities found for: Related Disciplines; Modelling Skills; Maturity, Readiness and Quality.
  Good knowledge of related disciplines can support alignment and communication.
  Familiarity with some modelling paradigms/techniques, but few participants with the broader set available.
  Fair use of maturity models and QA techniques.

• Modest capabilities for: Strategy Tool Use and Business Model knowledge.
  Strategy Tools use was quite low, reflecting the state of BA, often seen as a progression from EA, with strong I.T. / I.S. emphasis. Most practices today have an internal focus. The scorecard reflects our view that BA involves the design of future business and requires high competence in strategy tools, business models and awareness of contextual factors

What have we changed?  We kept the broad structure and categories with relatively small adjustments. We did extract some core competencies into a new category labelled “Modes of Thinking”. Some detailed changes:

• Broke up a question which reduced completion

• Combined some separate questions into multiple selection questions to save time

• Added the Modes of Thinking category

• Explicitly included Change Management

• Added Wardley Maps

• Provided examples to clarify some questions

• Added AI Reference Model

• Refined question around Solution Delivery Approach

• Tweaked balance of scores to reflect needs across categories

Graphic below shows categories assessed and relative scores.

Take the revised survey here ➔

Feedback is welcome! Send us your thoughts at BASurvey@inspired.org.

BA Forum Webinar: Integrated Business and Enterprise Architecture Planning with HAL 2.0

Date:

Time:

Cost:

Presenter:

Venue:

1 October 2024

14h00 - 15h00 SAST / 12h00 - 13h00 UTC

Free

Graham McLeod

Zoom (link provided on registration)

The Holistic Architecture Language (HAL), now at Version 2.0, is Inspired’s integrated language and meta model supporting strategy, business and enterprise architecture, risk and change management. It has evolved over two decades and was revised in 2014, 2019 and again earlier this year. It is now arguably the most comprehensive, integrated model available globally.

It has been benchmarked against popular EA and Business Architecture frameworks, as well as lesser known, but academically rigorous, frameworks and models.

Graham McLeod, Chief Architect at Inspired and the primary author of the language, will cover:

• Why we need such a language

• How it was developed

• What it covers

• Advantages and benefits

• Support in tools

• Further information available

The talk will be approximately 35 minutes, with adequate time afterwards for questions and discussion.

Please register to join us!

A visit to Lille for ESUG and IWST

I spent a week in Lille, France, where the European Smalltalk User Group conference (ESUG) was held at Inria/Lille University. This was in parallel to the International Workshop on Smalltalk Technologies (IWST). Lille is a beautiful city with historic Art Nouveau and Victorian era districts, but also stylish modern developments. It has a mix of northern French and Belgian culture, food and drink.

Despite the age of Smalltalk, it is still one of the purest, most productive and cleanest languages and tool environments for doing complex stuff reliably. We have used it in our tool development since the mid 90’s and see no reason to change.

ESUG brought the community together across Europe, but also the Americas and even a couple of Africans. A great deal of innovative work was on show and there is no shortage of interesting products, libraries, techniques and evolution to address new computing models and requirements. Standout items for me included:

• Continuing rapid development of the Glamorous Toolkit platform by Feenk which now hosts multiple development languages seamlessly, integrates with the Gemstone Object database and AI language models and allows developers to extend the tool itself with minimal effort

• Multiple Smalltalks that will run in the browser, either targeting the Javascript VM, transpiling to Javascript, compiling to web assembly, or running on smalltalk specific browser plugin VMs.

• High quality, cross platform modern widgets and controls via Toplo, which leverages BLOCK and supports SPEC 2.0 UIs

• Many projects which target and improve testing, debugging and monitoring

• Support for Virtual Reality and Augmented Reality

• The usual rapid evolution of major implementations such as Pharo (open source) and VAST (proprietary). Key themes include Unicode, stability, performance and interoperability

• Work which is keeping up with latest developments in virtual machines, memory management, garbage collection, just in time compilation and other techniques required for robust, scalable and performant systems

In the IWST workshop, I presented a paper on the work Gareth Cox and I did on creating a Graphical Language Server in Smalltalk (previously only done in Java and TypeScript). Glad to say this achieved an award for innovation and 3rd rank overall, which was pleasing for a modelling oriented paper in a primarily computer science workshop.

In the paper we were able to show how working at a higher level of abstraction and in a dynamic language allowed us to do more than the reference implementation in a fraction of the source code and memory footprint. You can view the presentation or read the paper.

Thanks to all the organisers for a great conference and workshop.

Enterprise Modelling at Duisburg-Essen University

I recently had the privilege of visiting this leading group for a week. We exchanged ideas, experiences, critique and camaraderie. I presented my work on design and support of effective visual modelling languages, while local participants provided insights into work on multi-level modelling, generation of multi-level models from more conventional models and supporting tooling.

The team is led by Prof Ulrich Frank and has a deep history and impressive track record in enterprise modelling, meta modelling and multi-level modelling. One product of this research is Multi Perspective Enterprise Modelling (MEMO), a meta modelling foundation and several integrated modelling languages which address strategy, organisation, goals, process, information and other aspects crucial to enterprise success. This has been one of several motivations behind our own Holistic Architecture Language and integrated Strategy and Enterprise Modelling approach.

The group collaborates with Prof Tony Clark at Middlesex University, North London on multi-level modelling, language design and tool development. Part of this work is the development and evolution of the X-Modeler, an innovative modelling and language execution platform. This work is one of the sources informing our own meta modelling approach.

Personally, I met Ulrich at my first international academic conference, and the first instance of the European Conference on Information Systems, at Henley on Thames, in 1993. His work and a subsequent visit to the Gessellschaft fur Matematik und Datenverwerking (GMD) research institute in Cologne (Koln) inspired much of my early research and provided validation of ideas I and colleagues were working on less formally.
We share a lot of common understanding, beliefs and approach to methods, models and modelling, tool building and what is important to the effective use of models.

Thanks to Ulrich and the group for their sharing and hospitality. Long may our fruitful interaction continue!

Inspired Holistic Architecture Language© Vsn 2.0

Holistic Architecture Language Van 2.0 - Top Level Executive view

Since the introduction of the Holistic Architecture Language in 2019, we have gained a great deal of experience in its application as well as conducting in depth academic research. These activities have allowed us to refine the meta models to more completely integrate strategy, business architecture, IT architecture domains and the change dimension. We have also expanded coverage to include more project stakeholder management and support for scenarios.

We benchmarked the leading and most popular EA, Business Architecture and Enterprise Engineering methods and models to ensure that we were not missing anything important. We checked that we could support the new versions of TOGAF® Framework and ArchiMate®. In this exercise we again became convinced that the HAL models are the most comprehensive, consistent and integrated available.

We took the opportunity too, to ensure that the models will support all the deliverables, models and analysis products that we cover in our Business Architecture/Desirable Futures method as covered in the Techniques and Deliverables of Business Architecture course and the Business Architecture Mastery Programme and which we apply in practice in client projects.

We are working to support the new models in EVA, with intuitive dashboards and canvasses, making the use of the models much easier for novices and experienced architects alike.

EVA Dashboard for Business Architecture

Please contact us if you would like to know more.

Academic work leading to the new models includes the following papers:

• Extending and automating maturity models for more value

• An advanced meta meta model for visual language design and tooling

• Integrated meta model for enterprise modelling including strategy, business architecture, risk and change

• A graphical language server on the Smalltalk platform

TOGAF® and ArchiMate® are trademarks of The Open Group

Advanced Business Architecture Skills by 2024! Transform your skills to a leadership level in 16 weeks

WEEKLY LIVE SESSIONS Thursdays 14:00-17:00 SAST / 12:00-15:00 UTC VIA ZOOM FOR 16 WEEKS

An intensive online programme to help senior enterprise and business architects, strategists and business analysts quickly and competently analyse a business, make well founded recommendations for transforming it, ensure stakeholders' buy-in, and mobilise for implementation.

Includes thought leadership in integrated meta models, stakeholder modelling, process architectures, integration of strategy, architecture and programme management.

LEARNING OUTCOMES

• Rapidly identify the real strategic issues

• Transform your own capabilities, then your organisation or client

• Develop the skills to be at the table where strategic decisions are made

• Have a real positive impact on your organisation, industry, customers, and other stakeholders

• Engage thoroughly with business executives in a way that they appreciate

• Exploit change and emerging technology to your advantage instead of suffering its effects

• Become a valued change agent in your organisation and industry

• Understand powerful meta skills that you can apply in countless situations, techniques and throughout your career

UNIQUE COVERAGE

The course links Business Strategy, Business Architecture, Implementation Architectures, and Programme Management.

It goes beyond TOGAF®, Zachman, BizBoK, Business Model Canvas (Osterwalder & Pigneur), Enterprise Engineering (Dietz et al), ArchiMate®, and others in addressing the context in which business finds itself and the many dimensions that must be integrated to make informed coherent decisions to achieve desirable futures.

It includes techniques to facilitate innovation, design business operating models, customer journeys, ground breaking products and services and exploit digital transformation, including AI.

SYLLABUS

See graphic above or visit the course page.

APPROACH

Online, via Zoom with interactive discussion and breakaway groups. Half the time is "hands on" with individual and group assignments to apply concepts and techniques. Rich use is made of case study material allowing students to apply concepts through a full lifecycle.

Extensive notes are provided and enrichment via short videos, provided articles, references and links. We provide a comprehensive eBook on Business Architecture.

Read more and enrol here.

"The course was well managed with materials at a similar quality to that of Oxford University. The subjects covered extend beyond the traditional content that you would expect - to starting to think outside the box, different perspectives, what matters to the design of a business and its people… If you are looking for a course that will introduce you to some of the latest research in this field and beyond, I would highly recommend this course.”

TOGAF® & ArchiMate® registered marks of The Open Group
#businessarchitecture #strategy #training #enterprisearchitecture#digitaltranformation

Business Architecture Mastery Programme Kicks Off

We are about to start our next Business Architecture Mastery Programme this Thursday (26th). It runs for 16 weeks until 11th May. We have an excellent cohort and it promises to be another great experience.

This time round we have added new material on how AI and related topics will impact business plans and architectures, as well as how to use Wardley maps to leverage the projected lifecycle of technologies in our forward planning.

Some comments from the delegates:

“Business Architecture is a lot more than just identifying capabilities and modelling. I really appreciated how it brought a wide breadth and depth of concepts together that illustrated what Business Architecture actually entails and what impact it has.”

“Very comprehensive set of techniques and best practices, one of the main benefits was drawing on [Graham's] wealth of experience and wisdom and really learning from the examples presented.”

“[The programme] has given an overarching view of all of the different elements that need to be set up as the organisation is growing and expanding... what are these elements that we need to put in place and consider if we want to grow in a very healthy way.”

“I also think that your course is very well-structured and it leads you over different aspects of the business architecture work and it was a pleasure for me. And thank you and all of the others attending the course, thank you.”

“So as key takeouts I will take these tools that you’ve not only presented to us but managed to teach us how to use them because most of the courses only present the tools and don’t give the chance to implement these tools and find a way to use them in your daily work.”

We believe this programme is the most comprehensive yet practical available. This was borne out by very positive comments from some very seasoned attendees who still derived major value and gained new insights. It runs over 16 weeks with a half day live session each week.

For full details please see the course page.

#businessarchitecture #strategy #enterprisearchitecture #ai #training

Practice of Enterprise Modelling (POEM)

I am at Heathrow, returning from the UK and the POEM Conference, hosted by Middlesex University. First international trip since the pandemic and it’s great to get out and about again!

The nature of “Enterprise” has changed from the simplistic company or organisation to diverse concepts, including:

• A legal entity

• A commercial, government or not for profit entity

• An extended value chain of partners and potentially, customers

• A project to bring about some desired change

• A value adding operating model, possibly including algorithms,AI and platforms that deliver value

Which can pretty much be summarised/abstracted as “any coordinated effort that results in value delivery”.

The activity of modelling is also under the spotlight, changing and being asked to justify its existence. With the speed of business change and the promotion of agile approaches, modelling is often pushed aside, regarded as old fashioned or not adding sufficient value. Of course, many of these projects and transformations subsequently come to rue that decision. Nevertheless, I was pleased to see a recurring emphasis at the conference on ROME, i.e. Return on Modelling Effort.

ROME looks at who models are for (stakeholders), what they are intended to achieve (goals, e.g. understanding, insight, consensus, decision support, design) and how effective and efficient they are in achieving that. We look for techniques to improve the value of models, including:

• Properly understanding stakeholders, concerns, goals & domain of interest

• Choosing, adapting or designing modelling languages and notations to suit the problems, domain, process and stakeholder goals and capabilities

• Improving efficiency and reducing effort by using automated information gathering (e.g. mining), inferencing algorithms, effective notations that exploit human visual and cognitive capabilities

• Tools that support design of modelling languages, importation/capture of relevant data, analysis, visualization, design, verification, collaboration in effective and efficient ways

Many of the presentations at the conference addressed these issues.

Other themes which were prominent and recurrent were Digital Twins and Ontologies.

Use of ontologies (and confusion over their definition!) has increased substantially. Part of the confusion arises from the use of the term in philosophy (for centuries) where it is about the existence and nature of things versus its use in computer science where it is used to mean the concepts, properties describing them, and relationships between them (in other words a domain or meta model).

Good ontologies can underpin modelling languages and models, making them more consistent, meaningful, rigorous and effective in promoting interoperability. Taxonomies (expected categories of instances in the ontology) can also accelerate data gathering, help to find redundancies and gaps. Obviously, this can improve ROME.

#enterprise #modeling #ROME