An ontology built around constraint rather than expressiveness, for a domain where a data system's output can cost a person their liberty. What it represents, what it refuses to represent, and the modeling decision I got wrong.

Most of what is written about ontology in enterprise software argues that an ontology is better than a schema. That argument has been won, repeatedly, since Gruber (1993). It is also now the marketing copy of every platform in the public safety category.
This paper argues something narrower and, I think, more useful. In a domain where the output of a data system can cost a person their liberty, an ontology earns its keep by what it refuses to represent rather than by what it can infer. The valuable property is not expressiveness. It is constraint. Governance controls in this category are typically positioned downstream of the data model, as access rules and audit logs over a permissive graph, and the evidence that controls in that position fail is now substantial. Moving them into the ontology, where a prohibited assertion cannot be written at all, is a different architecture with different failure modes.
What follows is a description of the ontology I built, including the modeling decision I got wrong the first time, why the mistake was invisible for months, and what replaced it.
Consider a single utterance of the kind that arrives roughly 45,000 times a day across the systems I run at Multido:
10-38, navy Tahoe, tag Adam Boy Charles one two three, 2300 block Monroe
A general-purpose named entity recognition model, run over that transcript, produces three confident and wrong answers. It extracts a person named Adam Boy Charles. It extracts a location called Tahoe. It extracts a point address on Monroe. Each output is well-formed. Each would pass a type check. Each is false.
The first failure is systematic rather than incidental. Most American law enforcement agencies spell over the air using the 1940 APCO alphabet: Adam, Boy, Charles, David, Edward, Frank, George, Henry, Ida, John, King, Lincoln, Mary, Nora, Ocean, Paul, Queen, Robert, Sam, Tom, Union, Victor, William, X-ray, Young, Zebra. Seventeen of those twenty-six are common English given names. Add Lincoln and Young as surnames and nineteen of twenty-six are person names of some kind. The NATO alphabet, where Alpha, Bravo, Delta, and Echo are not names, does not have this property. The most common way a license plate is communicated in this domain produces a token sequence that any language model will read as a person.
The second failure comes from a different direction. A meaningful share of American vehicle models are named after places: Tahoe, Yukon, Sedona, Santa Fe, Durango, Sierra, Colorado, Malibu, Denali, Tacoma. An extraction pipeline that types Tahoe as a location has produced a row that satisfies every structural constraint in a well-designed schema. Type systems do not catch it.
The third failure is not a model error at all. It is a modeling shortcut. Every commercial geocoding service, handed "2300 block Monroe," returns a point. A block is not a point. Converting it to one asserts a precision nobody spoke and, at the limit, implicates a specific residence that no one named.

The disambiguation signals are ordinary. Run length matters most: three or more consecutive tokens drawn from the APCO set is strong evidence of spelling, while two is ambiguous, because David Frank is a plausible name. A governing noun helps, since plate, tag, and registration precede the run. A following digit sequence matches plate morphology. None of this is exotic. It is a sequence-labeling problem with a domain gazetteer.
What matters is not that the disambiguation can be done. It is what happens when it fails, which it will. That is a question the extraction pipeline cannot answer. It is a question about the shape of the model underneath.
An earlier version of this paper described a first-class edge in the data model linking offenses to the radio transmission that originated them, and called it a structural differentiator no competing platform possessed. The claim was wrong in an instructive way. The edge existed in the specification. It had never been implemented. No table, no column, no configuration referenced it. It survived for months because nothing in the system validated the specification against the schema, and because I had two divergent lists of relationship types in the codebase, one of which was dead and never imported at runtime.
The repair was not to build the edge. The edge was the wrong shape. Provenance is not a relationship between two domain entities; a transmission is not a peer of a person or a vehicle. Provenance is a property of the assertion itself.
What replaced it is the W3C provenance vocabulary, PROV-O (Lebo, Sahoo, and McGuinness 2013), expressed as columns with a check constraint. Every entity and every relationship carries either a non-null pointer to the transmission it was derived from together with the model that derived it, or a non-null pointer to the human who asserted it. There is no third case, and the database enforces the disjunction rather than the application. The vocabulary maps directly: the source pointer is prov:wasDerivedFrom, the extraction model is prov:wasGeneratedBy, the human author is prov:wasAttributedTo.
This is a stronger property than the edge would have provided, and it is cheaper. No machine-derived assertion can exist in the graph without the audio that produced it. In a domain where a derived claim can end up in a case file, an assertion no one can trace is worse than no assertion.
The general lesson is narrower than it sounds. A specification that drifts from the schema is invisible until something validates it. Write the constraint, not the document.
Public safety data arrives in kinds that are routinely collapsed into one. A transmission happened, which is close to an irreducible fact. A machine believes that transmission referred to a person, which is a claim about the utterance. A human asserts that this person is the subject of an incident, which is a record with an author. Those have different truth conditions, different lifetimes, and different accountable parties. Collapsing them is what allows a phonetic string to become a person.
I separate them into strata and make the stratum boundary the only place a gate is needed.

Extraction writes into stratum 1 and nowhere else. A misclassified phonetic run becomes a person_mention: bound to a single transmission, expiring in ninety days, unjoinable across incidents. It cannot become a person, because the only path across that boundary requires a criminal predicate submitted by a named human with a written basis, which is how I implement the reasonable suspicion standard that 28 CFR Part 23 has required of federally funded criminal intelligence systems in substantially its current form since 1993.
This is the point of the architecture. The extraction model will be wrong at some rate, and that rate is an engineering problem subject to ordinary improvement. What a wrong answer costs is a different problem, and it is settled by the shape of the model rather than by the quality of the model.
The strata also turned out to explain a product decision made on other grounds. A pre-incident detection product would have to write into stratum 2 from inference alone, which is the one operation the boundary forbids. The architecture ruled on the question before the roadmap did.
Roles live on edges, never on entities. The most common error in this domain is subtyping person into suspect, victim, witness, and officer. Those are not kinds of people. They are incident-scoped, time-bounded, frequently reversed assignments, and the same individual is a witness on one call and a subject on another the same night. Involvement is therefore an association object carrying a role, an author, and a validity interval. No person is ever typed as a suspect. Retracting a role is a supersede rather than a delete, which makes the retraction exactly as durable as the accusation.
Resolution is a recorded, reversible event. Wrongly merging two people is a real harm, and a merge implemented as a destructive foreign key update cannot be undone or audited. Identity membership is derived from a log of resolution decisions, each naming the references consumed, the model or human that decided, the confidence, and the time. A bad merge is corrected by a superseding decision and both remain visible. A useful side effect is that resolution accuracy becomes measurable, because the decision history is the evaluation set.
Two clocks, not one. Every person-linked relationship carries valid time, meaning when the fact held in the world, and transaction time, meaning when the system came to believe it. A vehicle's registered owner changes. An address's occupant changes. Without valid time, a momentary observation is silently promoted to an eternal assertion, which is both factually wrong and the specific mechanism by which stale intelligence damages people years later.
The list below is the part of this architecture that is worth more than any feature, because it is checkable by anyone who reads the schema.
There is no biometric template, face embedding, voiceprint, or gait signature class or column. There is no attribute for political affiliation, religious affiliation, or organizational association, which is the collection 28 CFR 23.20(b) prohibits absent a criminal nexus. There is no person without a predicate authored by a named human. There is no cross-agency identity merge without a sharing agreement object naming both agencies. And machine writes terminate at stratum 1, so no identity is ever created by inference.
The strongest of these is the one most likely to be misread as an omission. There is no edge between two person entities except through an incident. There is no associates_with. A person-to-person graph unmediated by a specific event is an association network, and association networks are the thing the federal regulation governing criminal intelligence systems was written to constrain.
These are enforced as assertions over the live schema in continuous integration, so a violation is a failing build rather than a policy memo. That distinction is the entire argument of this paper compressed into one sentence.

The case against this constraint is not weak. An investigator working a homicide with three witnesses and a partial plate is doing association analysis whether or not the software supports it, and forcing that work into notebooks removes it from audit rather than preventing it. A person-to-person edge that carried its own predicate, author, and expiry might be defensible. I have not found a formulation I trust, and until I do I would rather the model refuse than approximate.
There is a formalism argument underneath the design choice, and it is worth stating because it explains an omission that would otherwise look like a gap.
The Web Ontology Language was built to infer missing facts from incomplete data under an open-world assumption. That is the correct tool for a great many problems and the wrong tool for this one. A system of record for law enforcement should not infer missing facts about people. The Shapes Constraint Language, standardized later, operates under a closed-world assumption and exists to validate rather than to derive. This ontology follows the second tradition. It does not run a reasoner. Its axioms exist to refuse assertions, not to generate them.
The practical argument is stronger than the formal one. The dominant pattern in this category, as far as public product documentation reveals, places controls downstream of the data model, as access rules and audit trails over a permissive graph. Those are detective controls. They report that something happened after it has happened, and only if someone requests the log, reads it, and acts. A 2020 California State Auditor review of four agencies' automated license plate reader programs found that they conducted little to no auditing of user searches, and that officials were either unaware of the auditing requirement in state law or had run audits that did not examine searches at all (California State Auditor 2020). The control was present, mandated, and inert.
A preventive control sits before the write. It produces a different artifact, too. When a constraint refuses an operation, the refusal record contains a timestamp, an agency, a role class, the purpose attempted, and the axiom that fired. It contains no subject, because the operation never executed. Refusals are therefore publishable without redaction as a matter of content rather than as a matter of policy, which makes continuous public reporting possible without a records request. That is a downstream consequence of putting the constraint in the model, and it is not available to an architecture that logs accesses instead.
Bitemporality roughly doubles write complexity on person-linked relationships and makes every query time-aware. Reversible resolution means carrying a decision log that will exceed the entity tables in row count within a year. Supersede-never-delete grows storage monotonically, which sits awkwardly beside a retention regime and forces the purge to operate over the whole supersede chain rather than the current row.
The largest cost is the prohibition on person-to-person edges. Link analysis across people is the most requested capability in this category. Foreclosing it publicly and permanently will lose deals. That is the trade, stated plainly, and it should be made deliberately rather than discovered later by a buyer.
None of the three problems this work sits on is conceptually open. Entity resolution has been formalized since Fellegi and Sunter (1969). Provenance has been a W3C recommendation since 2013. The regulation describing what a criminal intelligence system may retain, and for how long, has been in force for decades. What has been missing is not the theory. It is anyone willing to encode the constraints in the schema, where they bind, rather than in a policy document, where they do not.
Bechhofer, S., et al. (2004). OWL Web Ontology Language Reference. W3C Recommendation.
Bureau of Justice Statistics. (2022). Census of State and Local Law Enforcement Agencies, 2018: Statistical Tables (NCJ 302187). U.S. DOJ, Office of Justice Programs.
Byun, J.-W., & Li, N. (2008). Purpose based access control for privacy protection in relational database systems. The VLDB Journal, 17(4), 603-619.
California State Auditor. (2020). Automated License Plate Readers: To Better Protect Individuals' Privacy, Law Enforcement Must Increase Its Safeguards and Oversight (Report 2019-118). Sacramento, CA.
Christen, P. (2012). Data Matching: Concepts and Techniques for Record Linkage, Entity Resolution, and Duplicate Detection. Springer.
Code of Federal Regulations. 28 CFR Part 23: Criminal Intelligence Systems Operating Policies. U.S. Department of Justice. 58 FR 48452 (September 16, 1993).
Fellegi, I. P., & Sunter, A. B. (1969). A Theory for Record Linkage. JASA, 64(328), 1183-1210.
Gruber, T. R. (1993). A Translation Approach to Portable Ontology Specifications. Knowledge Acquisition, 5(2), 199-220.
Hogan, A., et al. (2021). Knowledge Graphs. ACM Computing Surveys, 54(4), Article 71.
Knublauch, H., & Kontokostas, D. (2017). Shapes Constraint Language (SHACL). W3C Recommendation.
Lebo, T., Sahoo, S., & McGuinness, D. (2013). PROV-O: The PROV Ontology. W3C Recommendation.
Lewis, P., et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS, 33, 9459-9474.
Neuhaus, F. (2018). What is an Ontology? arXiv:1810.09171.
Studer, R., Benjamins, V. R., & Fensel, D. (1998). Knowledge engineering: Principles and methods. Data & Knowledge Engineering, 25(1-2), 161-197.