Knowledge engineering by domain

Why a domain, and not the whole organization

Knowledge engineering fails more often from scope than from tooling. A programme that sets out to model the enterprise before proving value on one use case tends to stall at the specification stage, having produced a document nothing runs on. A bounded domain is the only scope that finishes.

There is a structural reason beyond project management. The April 2026 preprint cited below organizes its domain layer hierarchically — an agent working in fintech.payments inherits the concepts of fintech and adds the payment-specific ones — and uses that hierarchy to decide which tools an agent may even see. Model a bounded domain and the inheritance works. Model everything and there is nothing to inherit from.

This is also where a staged approach pays. The ontology pipeline set out by Jessica Talisman in the talk cited below is explicit that each stage is usable on its own: an organization with a controlled vocabulary and private metadata schemas may have all the context it needs for now. A domain playbook is a way into that ladder, not a commitment to climb it all.

The method, the same on every page

Each domain page answers six questions in the same order, so the pages can be compared rather than merely collected.

1. What to reuse. The published standard, vocabulary or model that covers most of the domain, named with its number and year where it has one.
2. What to scope to for a first attempt — one reporting line, one clinical pathway, one repository — rather than the whole domain.
3. Which questions to agree first: ten to twenty concrete questions the knowledge must be able to answer, settled with domain experts before any modelling begins.
4. The smallest artifact worth building, which is almost always a vocabulary of terms with definitions and stewards, plus a small set of hard constraints.
5. How to validate it, against a system of record or against the domain experts themselves rather than against a demonstration.
6. The failure the domain is prone to — the specific way an agent goes wrong here without raising an error.

The ten

Two of the ten are written. The other eight are named with their backbone so the shape of the set is visible, and no link is published until the page behind it exists.

Which one to start with

Not the domain the model already handles well. The preprint cited below reports that the gain from ontological grounding is largest where the model's pretrained knowledge is weakest, which it calls the inverse parametric knowledge effect. That inverts the usual instinct: a general-purpose domain is the worst first choice, because the model sounds competent there and the errors are quiet.

Two practical tests for a first domain. Is there a published backbone to align to? That decides the cost. And is there a system of record to validate against? That decides whether you can tell whether you succeeded.

What these pages do not do

• They do not rank vendors, and they do not score an organization's maturity. A score that nobody acts on is a report, not a result.
• They do not link a standard they could not verify from an automated client. The W3C, the Library of Congress, IFLA and ISNI answer such requests with a Cloudflare challenge; those are cited by name, number and year instead.
• They do not present the preprint's numbers as settled. It is one preprint, self-reported, and it is labelled as such every time it is cited.