Concepts
Ontology
Durable entities and relationships in three layers.
What it is
Ontology is the durable structure behind predictions: the entities, relationships, and properties your business is made of, persisted across runs so every workflow reads the same world. It answers "what exists" once, instead of every workflow re-deciding it.
What it holds — three layers, never mixed
- Definition: the model — entity types, relationship types, properties, identifiers, constraints. A versioned asset: branchable, diffable, rollback-able. Model changes are reviewable decisions.
- Build logic: the recipe — how source records map onto entities, how relationships derive, how identity resolves ("Acme Inc" and "Acme, Inc." become one customer), and whether writes create, update, or upsert on conflict. Lives inside plans, not beside them.
- Runtime: the result — materialized entities and relationships with provenance, timestamps, and run linkage. Operational state you inspect, never hand-edit.
How it relates
- Plans build ontology state; ontology never appears on its own. A plan references a definition and carries the mapping steps.
- Ontology is one output among others. Plans also write to normal destinations — structure where it compounds, deliver where people read.
- Predictions read runtime state, so weak identity or mapping shows up as weak forecasts. Fix the layer, not the score.
- Corrections flow through the loop: fix definition, mapping, or source data, then rerun. Direct runtime edits bypass provenance and teach nothing.
What this means for you
- Start with a slice (customers and orders), not the business.
- Reruns should enrich state; duplication means identity rules need work.
- If a colleague cannot recognize the business in your definition, the definition is wrong — not the colleague.
Image: the three layers as stacked bands — definition, build logic in plans, runtime state — with arrows between them.
Next
- Shape a slice: Shape your first ontology.
- Rule-level fields: Ontology mappings.