In this chapter
- You have built this before. The ontology an AI agent reads is the business model your team already draws.
- Five ways to tell things apart. Entity classes, and the history each one implies.
- Roles and one sentence per table. Relationships that name their role, and a sentence that says what one row is.
Before anything is stored, somebody has to say what the business is made of. Every silver layer method that carries meaning starts there, and so does AIMS (AI-ready, Meaning-first Silver), with one difference. The business model stops being a diagram drawn before the tables. It becomes the ontology that the tables, the templates and the AI agents all read.
You have built an ontology before, and you called it a business model
An ontology sounds like something a research lab owns. It’s the named things your business runs on, how each is identified, how they relate and what each attribute means, written where a machine can read it. Your team already builds most of it in a modeling workshop and calls it the business model. That business model, plus the mappings that tie silver columns to it, is the meaning layer.
Lawrence Corr’s modelstorming puts people first, and John Giles insists a vault starts from a model of the business. Remco Broekmans’s Ensemble Logical Modeling walks from business stories to the things they name. Our first book argued for that order in “Speak before you store”: “The semantics that matter most were never columns, and no engine can extract what was never persisted.” AIMS adds the precision that lets a template generate from the model and an agent read it with nobody beside it.
Customer Account is not Person is not Organization
The failure a business model guards against is the undefined noun. Ask three systems what a customer is. The order system means an account per company code that orders are billed to. The sales system means an account a salesperson owns. A marketing list means a person with an email address.
File all three under “customer” and the silver layer has merged three things before anyone asked.
So each business entity, a business thing your data is about, gets a definition. A Customer Account isn’t a Person, because one person can hold accounts in two companies. It isn’t an Organization, because one organization can run several accounts. Where the business needs to connect them, AIMS records a specialization (a Customer Account is a kind of Party) or a relationship, never one identity.
The entity class says how you tell one thing from another
Once an entity is defined, how do you tell one instance from another? The answer comes in five shapes, which AIMS calls entity classes, using entity-relationship modeling’s words. Each carries a default history policy, how much history a table keeps (every event, the current record or every version). The AI proposes the policy with a reason, for a person to confirm. An independent entity’s past usually matters, so its default is versioned.
| Entity class | Identified by | History the AI proposes | In the worked example |
|---|---|---|---|
| Independent | Its own identity attributes, unique in their record source | versioned | Customer Account, Sales Order, Product |
| Dependent | The parent’s identity plus a local identifier | follows the parent | Sales Order Line (its order plus a line number) |
| Event | Its own identifier, or its participants plus the event time | append | none |
| Reference | A code in a code list | current | Order Status, Country |
| Association | The identities of two or more participants, each with a role | versioned, or append when the association is itself an event | none |
The class is derived, never picked, from what the model says. An entity typed as an event is an event, and one typed as a relationship is an association. One that’s part of another is dependent, one that owns a code list is reference, and everything else is independent. Our first book’s happening test settles hard cases: a happening gets its own entity only when the business names and identifies it separately. A payment with its own reference is one such happening.
Can one entity have two business keys?
The order system identifies a Customer Account by company code and customer number. The sales system uses an account identifier, with no company code.
One key column can’t hold both.
So AIMS gives an entity one business key per record source. Customer Account has two, one per system: awlt and wb. Two record sources never join until an approved match says they describe the same thing.
Relationships carry roles, or reports guess
A Sales Order refers to Customer Account twice, as the sold-to customer and as the bill-to customer. An unnamed line leaves every report guessing. So in AIMS a business relationship carries a role, a cardinality (how many rows on each side can match), an optionality and a policy for a reference that doesn’t resolve. Each role gets its own key column on the referencing table.
What happens when the referenced row is missing? A relationship can allow it and count the orphans (references with no match). It can warn and flag the row, or quarantine it, setting the row aside where it’s counted and can be fixed.
Warn is the default, because a late row is normal in a lakehouse, and the orphan count shows when late has turned into missing. The worked example overrides it once. An order line whose order is missing is quarantined, because a line without an order has no grain.
Readers of our first book met this in the Willibald demo dataset, a garden webshop whose customer table and club partner table point at each other. No constraint could say which pointer was membership and which the club’s contact person. A nine-minute meeting said it, and it mattered, because a contact person’s orders are attributed to the club.
With roles, membership and contact person become two relationships, and the next reader sees the role instead of a second foreign key.
Figure 4.1: the business model as the agent sees it. Six entities with their classes, business keys and record sources, code lists and roles.One sentence says what a row is
Every table that carries an entity gets one sentence before its column list, its grain sentence. It’s generated from the entity class and the history policy. A person confirms the sentence, and it opens the table’s data contract, the summary of what the catalog holds about it. If a source table mixes grains, say order headers and order lines, the sentence names the column that tells them apart. So an agent filters on it before it counts anything. For the worked example’s four source tables:
- The order system’s Customer table: one row is one Customer Account version from record source awlt.
- The order system’s SalesOrder table: one row is one Sales Order version from record source awlt.
- The order system’s SalesOrderLine table: one row is one Sales Order Line as currently known from record source awlt.
- The sales system’s Account table: one row is one Customer Account version from record source wb.
Two tables carry one entity from two record sources, so nobody will mistake their union for a customer list. And the order line is current while its order is versioned. That’s a deliberate override of the dependent class’s default that a reviewer can challenge in one line.
The workshop hands over to the meaning layer
The workshop’s output is a model a person can read. For its identities and relationships, the meaning layer adds what a machine needs to act without asking. That’s the class, a business key per record source, roles with their policies and a grain sentence per table. None of it needs a second workshop.
| The structural answer | A vault builds the worked example’s six entities as twelve tables (three hubs, three links, four satellites, two reference tables), and the bill-to role alone costs one. |
| What the agent reads | Each entity’s class, definition and business keys with their record sources, each relationship’s role and cardinality, and every table’s grain sentence. |
| Yours to decide | Creating or redefining an entity, its business keys, and every relationship’s role and cardinality. |
In DeltaVault today
DeltaVault, our metadata catalog, holds entities, attributes and relationships as metadata. Each entity has a type, such as Person, Place, Thing or Event. The catalog’s relationship diagram asks you to name the role when you draw a line.
Its business modeling workshop turns a plain description of how the business works into proposed things and the connections between them. Only what you keep reaches your business model. The AI never chooses keys. Below, concepts already in the model are marked so, and one judged out of scope carries its rationale.
