At ten in the morning a theatre coordinator has to decide whether tomorrow’s orthopaedic list can absorb three more cases. The answer is spread across six systems, none of which will answer alone. By the time it has been assembled by telephone the list has gone out short.
What one scheduling decision costs
To say yes the coordinator needs the session minutes actually left, against durations that are often defaults rather than estimates. Then the bed position, the implants on the shelf rather than in the catalogue. Six answers, six owners, six phone calls, and the first is stale before the sixth arrives. That is not a slow query. It is a query whose result decays while you assemble it. They wanted a defensible yes or no by eleven.
Where the meaning actually lives
Point a capable model at the raw schema and it answers confidently and wrongly. “Discharged” is a recorded event in one system, a released bed in the second, a judgement of readiness in the third and physical departure in the fourth, so asked for discharges it picks one of four plausible dates and returns a figure nobody audits. The meaning of a hospital is not in its tables. It sits in naming conventions nobody wrote down and in people’s heads.
What the ontology gives it
Declare that meaning and the guessing stops. An ontology is a written model of what the organisation actually is: the objects one decision touches, bounded by the decision rather than the source schema, the links between them, and the write each produces. Eight objects answer the eleven o’clock question. Four hundred is a data platform. The test that earns most of them is disagreement: if the ward and the bed manager disagree about it, it is an object. “Ready for discharge” is not a flag on a patient, it is an assertion made by someone, at a time, in a system.
Given that model the same agent stops guessing. It reads across the six systems in place, in the vocabulary theatre managers already use, and answers by eleven. That is what makes AI useful for a decision rather than for drafting text: not a better model, a described domain. The ontology is a declared file, written by people who know the estate. Anyone offering to discover it by pointing a tool at your database is selling a warehouse.
Purpose decides what it reads
The same row can be lawful under one purpose and unlawful under another. Data held for a patient’s care may be used for that care; using it for service planning or research is further processing, with its own lawful basis. So purpose cannot be an instruction in a prompt. In Monarch it is one database role per purpose with column-level grants, and every read runs under that role inside a transaction. An agent that improvises a query it should not run takes a permission error from the engine holding the data.
Consent moves. An objection is registered, an approval is narrowed, and what was lawful on Tuesday is not on Thursday. So the action is staged rather than executed: a proposed write persists as a pending approval under the purpose captured when it was proposed, shows a dry-run diff, and holds until a person commits or rolls it back. A saved decision is bound the same way: re-opened under a narrower purpose it re-derives and reports that the answer changed, rather than serving a cached number.
Where this is the wrong tool
Anything bearing on diagnosis, treatment or the triage of an individual is a different regulated object. That line belongs in the model, as a constraint on what any purpose may grant, not in a policy nobody reads at query time. And where the capture is bad, no ontology repairs it.
This is method: the examples illustrate a class of problem, not a deployment. The hard part was never the answer. It is showing, afterwards, that you were allowed to ask.