The domain model is the program

Onto’s core thesis is that the domain model is primary. Every other approach loses the domain model in translation: experts tell stories, developers turn them into code, meaning leaks out. Onto deletes ␡ the translation step. You author a model in three small DSLs (Stories, Rules, Formulas) and the model compiles structurally to reactive Datalog; the running app is just the model firing.

<aside> 💡

Onto: Stories + rules in → facts and rules out. The app is what happens when they fire.

</aside>

Start with stories

A story is a single concrete linear path- one way things actually happened, beat after beat. No branches, no conditionals, no "if"- just anirreducible sentence:

Actor —acts on→ Object

Barista prepares Order

Anything that varies by condition is not story- it's a Rule.

Classify at commit

Stories stay prose until you commit. Then a deterministic-first classifier extracts, per beat:

• Action Category — one of a closed nine, derived from the algebra of EAV deltas: instantiate · modify · transition · associate · derive · query · capture · emit · log
• Actor Markers — human vs. agent, inside vs. outside the org
• Object Archetype (Coad) — moment-interval, role, party-place-thing, description
• Execution Locus — in-runtime, external-software, physical-world
• Noun Kinds — every noun becomes an entity (its own type), a property (a field on its parent), or a part; declared entities override every heuristic (resolve, don't infer)
• Exogenous Inputs and a no-source lint: no object appears from nowhere

What can't be resolved deterministically is never guessed; it becomes a coaching prompt ("you said the buyer's tier matters, Buyer has no tier field").

Rules and Formulas

Rules are all words — six relations (is, is not, is more than, is less than, is at least, is at most), four atom shapes (state, comparison, identity, cardinality), flat DNF, negation on atoms only: