Model the facts,
not the tables.

One artifact. Three readers.

Fact-based modelling says everything in sentences, states every rule explicitly, and refuses to leave anything implied. That is what a domain expert needs in order to approve a model. It is also, exactly, what a language model needs in order to stop guessing.

ORM facts are the layer LLMs have been missing

Point a coding agent at a codebase and it reconstructs your domain from the only evidence it has: column names, foreign keys and a few migrations. Is a nullable column optional by rule, or by accident? Is that unique index a business rule or an old performance fix? It will answer. It has no way to be right — because nobody wrote the answer down.

CREATE TABLE person (
  id          int,
  company_id  int NULL
);

Each Person works for exactly one Company.
It is necessary that each Person has
  exactly one PersonNr.
It is obligatory that each Employee
  has a Salary.

Retrieval gives a model text that is similar to your domain. A conceptual schema gives it text that is true about your domain. Factum keeps that text in a file in your repository, checks it in CI, and serves it to your agent over MCP.

Why fact-based modeling

ORM describes a domain as elementary facts — Person works for Company — rather than as tables or classes. Because those facts carry no attributes, every constraint has to be stated explicitly, and the whole model can be read back in plain language.

Read your model back in English

Verbalization is what makes a conceptual schema reviewable. Factum generates it from the constraints themselves, so the sentences cannot drift from the diagram.

Each Person works for exactly one Company.
In each population of "Person has Skill", each Person, Skill combination occurs at most once.
It is necessary that the possible values of GenderCode are {'M', 'F'}.
Each Manager is a kind of Person.

A mandatory role plus a uniqueness constraint reads as exactly one; drop the mandatory dot and the same fact type reads at most one. The wording follows the model.

Learn the method, not just the tool

Factum ships with a short book on ORM 2 — elementary facts, the constraint family, subtyping and objectification, and Halpin's seven-step design procedure worked end to end. Every diagram in it was drawn by the extension, and every figure links to the model behind it, so you can open any example and take it apart.

You don’t have to pick a format

The fact-based modelling community has no agreed exchange standard, and three candidates are in play. Rather than back one, Factum reads and writes all of them — so a model can move between tools instead of being trapped in whichever one drew it.

Every conversion reports what it could not carry rather than dropping it quietly. Exporting a model with an objectified fact type to Ossie tells you Ossie has no objectification; importing UMS tells you that what came back is the shape of the data rather than the facts behind it.

Check the model against reality

Models are just files

A model is one .orm.json file holding the schema, its layout and its examples, described by a published JSON Schema so any tool can validate it. It diffs, merges and reviews like the rest of your source, and it is safe to hand-edit — the diagram is a custom editor over the text document, so VS Code's dirty state, undo stack and file watching all work normally.

Every element can carry metadata and per-target generation hints, and any x- prefixed key is yours to use — preserved untouched, so another tool can round-trip data we know nothing about.