Ask a coding agent what a row in subscription means and you will get a confident, fluent, well-organised account of your domain. Most of it will be right. The parts that are wrong will not be marked, because the agent has no way to know which parts those are — and, on a first reading, neither do you.
This is not a reasoning failure. The agent did the only thing available to it: it inferred a conceptual model from a logical one. The trouble is that many conceptual models are consistent with the same logical one. A nullable column is equally consistent with this is genuinely optional, with this is mandatory but was added later, and with nobody ever decided. The information needed to tell those apart existed once, in a conversation with someone who understood the business. Then it was compressed into DDL, the compression was lossy, and the lossy artifact is the only thing anyone kept.
Object-Role Modeling is a fifty-year-old answer to a problem we have just started calling new. It describes a domain as elementary facts — Person works for Company — that carry no attributes at all. That sounds like a restriction and is in fact the whole mechanism: because there is nowhere to hide a property, every decision has to be stated as an explicit constraint. And because every constraint is explicit, every constraint can be read back as a sentence a domain expert can confirm or reject, and that a language model can consume with almost no ambiguity.
What you will learn
The notation, completely. ORM 2 has about a dozen marks. Every one is drawn here, beside the sentence it generates. Uniqueness, mandatory, frequency, all ten ring types, subset, exclusion, equality, value, cardinality, subtyping and objectification.
FORML, and why it removes the context wall. A dedicated chapter on the formal language that reads like English — its closed fifteen-form vocabulary, why absence of a sentence is information rather than ambiguity, and why a domain that fills forty tables of DDL fits in a prompt as a few hundred sentences.
A design procedure that produces models people actually confirm. Halpin's seven steps worked end to end, plus a chapter of strategies, six named anti-patterns, and the practice — sample populations — that lets a validator tell you your own data contradicts the constraint you just drew.
The Factum toolchain in depth. The VS Code editor, all eight CLI commands, schema drift detection against a pg_dump, model diffs rendered as sentences for code review, and an MCP server that gives Claude Code, Copilot or Cursor eight tools over the model — seven read-only, one guarded write that refuses to commit a broken schema.
Three real schemas, modelled properly. A six-layer agentic memory architecture with an epistemology layer. A promise graph for multi-agent coordination, built on Promise Theory, where rejections are first-class and a witness's assessment can disagree with the agent's own. An audit log whose hash chain and event ordering are stated as one-to-one constraints and an acyclic ring rather than assumed by the code that writes it.
Interoperability, treated separately and honestly. NORMA, the FBM Exchange MetaModel, Apache Ossie and the Unified Modelling Schema: what each can and cannot hold, why a conceptual format and a logical one are not interchangeable, and what the meta and hints objects exist to bridge.
How the book is built
Every ORM diagram in the book is rendered by Factum's own renderer, from a model file that ships with the manuscript — 38 of them, openable in the editor and taken apart. Every FORML sentence, every validator message and every line of generated SQL and Cypher quoted in the text is real tool output, not a paraphrase.
Four figures are deliberately wrong, because the text works through the error the validator reports. The build asserts that they still fail.
Who it is for
Someone building with agents who is tired of re-typing the domain into every prompt. Someone with a database nobody documented and an agent confidently inventing its semantics. Someone who has read about knowledge graphs for agent memory and wants a way to design one that is checkable rather than vibes.
You do not need prior ORM. You do need to have written a schema and regretted it.
What it is not
Factum is a VS Code extension; the book assumes you use it or read the JSON directly. The property graph mapping targets LadybugDB's Cypher DDL, and other graph databases will need small syntax adjustments. Derivation rules are stored and verbalized but not evaluated.
And nothing in the book calls a language model. The verbalizer, the validator and the mappers are deterministic code that would have worked identically in 2005. That is the point: the agent is your agent, running where you already run it, reading a file you own. The job of the fact layer is to make sure the file says something true.
Metagraph for AI Agents asks how to represent agent knowledge — hypergraphs, reification, the bipartite form, six layers of memory. Fact-Based Agents asks how to specify and check it. Where the first book shows you that an n-ary relationship has to become a node, this one draws the ternary fact type and lets the mapper produce the Levi form for you, with the acyclicity constraint carried into the generated script as a rule the application must uphold. The two are complementary; neither repeats the other.
