Seven steps to a meaning layer

In this chapter

• Seven steps in order. One business area taken up the meaning levels, each step ending in a check.
• Done when, and how it fails. The check that closes each step, and the mistake that sinks it.
• One area before the next. Why approvals compound, and how to know the layer works.

Where do you start on Monday? You take one business area’s silver layer up the five meaning levels, which say how much a table tells its reader. AIMS (AI-ready, Meaning-first Silver) breaks that climb into seven steps. At each, the AI proposes and a person approves, along the line AI proposes, a person approves, templates generate draws.

Scope it the way our first book’s closing chapter did, one business area end to end before the second starts. Read the steps as dependencies, not calendar slots.

Figure 11.1: seven steps up the meaning level, with step 7 taken only on a requirement.

Step 1: Name the entities before anyone maps a column

Run a business modeling workshop for that business area. Give each entity its type, its definition and a draft of its grain sentence, the line that says what one row will mean. See The business model is the ontology.

You are done when every entity the sources carry has a type, a definition and a draft grain sentence your business expert has agreed. The way this fails is the undefined noun, three systems saying “customer” about an account, a person and a billing party.

Step 2: Profile the sources and keep their shape

While the workshop runs, engineers profile the business area’s source tables, collecting the column statistics the suggestions read. Each source table gets one source-aligned table at the same grain. Its default materialization is a view over persistent staging, the layer that keeps every version delivered. See Keep the shape of the source.

You are done when every source table has its source-aligned table at level 0, Typed, and its profile is accepted. The way this fails is “we will model later”. Level 0 is replication. The day somebody reports from it, the meaning gets invented inside the report.

Step 3: Write identity in a key you can read

For each entity and record source, the AI proposes a business key, its parts in order. A person approves each with its padding, history policy and delete policy. One customer’s key reads awlt||AU||00001042: record source code, company code, customer number. A person confirms each grain sentence, now naming its record source. That’s level 1, Identified. See A key you can read.

You are done when every business key passes its uniqueness test and every table has a chosen history and delete policy. The way this fails is a hash nobody can read, from a record source nobody wrote down. So the first clash between two systems’ customer numbers surfaces in a report.

Step 4: Relate every reference by its role

Every reference gets a role, a cardinality and a policy for a reference that doesn’t resolve, such as warn. Each role gets its own key column. Each entity gets its key register, every business key it has. That’s level 2, Related. See The business model is the ontology.

You are done when every relationship has a role and its orphan count is reported. The way this fails is two columns both called customer, joined on whichever one the analyst found first.

Step 5: Describe the critical columns first

Mapping starts with the critical columns, the ones that identify, relate, hold a code or sensitive data. Each maps to a business attribute with its semantic type and unit or currency. A code column gets its code list and an approved code mapping, such as the order system’s, where C means Cancelled. Level 3, Described, asks every column to be mapped or marked source-only. But the gate asks it only of the critical columns. The others’ coverage is measured, never gated. See Attributes are where the payoff lives.

You are done when every critical column is mapped or marked source-only and the attribute coverage number is known. The way this fails is mapping everything before shipping anything, the canonical model’s cost in a new coat.

Step 6: Publish the contract and let gold read it

The data contract is a projection of what the catalog holds after steps 1 to 5. So publishing is a review, from the grain sentence to the known limitations. A table that passes the publish gate (level 2 complete, the critical columns at level 3, and the acceptance checklist) counts toward the layer. Gold, the mart drafted from the same metadata, may read that table. A source that changes shape shows up as a contract diff. See The agent reads the contract.

You are done when the contract is versioned and the first consumer reads the table. The way this fails is a contract nobody diffs, so a dropped source column reaches gold as nulls before anyone reads what changed.

Step 7: Integrate by exception, then point an agent at the contract

Integration comes last, and only where a business requirement calls for it.

When finance asks for one customer list, an exact-match rule on tax number, approved by a person, gives the order system’s 00001042 and the sales system’s A-937 the shared key customer_account||tax_number||48123456789 on Customer Account’s key register. A golden record beside it carries a survivorship rule per attribute, saying which source’s value wins. That’s level 4, Integrated, where it’s earned. See Integration by exception.

Then ask an agent how many customer accounts in Australia had an order move to Cancelled last quarter, by sales owner. Give it eight instruction lines, rendered from the contract, telling it to read the grain sentence first and decline each clause with no mapping.

You are done when the answer cites the contract and declines the clause it can’t answer, the sales owner. The way this fails is entity resolution by guesswork. A merge on a likely match is wrong in every join downstream, and nobody downstream can see which.

Why finish one business area before the next?

Every approval compounds. It’s a fact for the next agent question and a demonstration for the next suggestion.

Two half-finished business areas give gold nothing it may read yet.

How will you know the layer works after go-live? It reports its own health without a model call, in quarantine rates, orphan counts, identity uniqueness, attribute coverage and drift.

One more measure belongs to the agent: a set of business questions with answers you’ve checked, including ones it should decline, run again after every contract diff and model change. Run your questions as each table climbs. The level where they start answering correctly is the level that business area needs.

You don’t need a new modeling method. You need a meaning layer, the meaning your methods always carried, written where machines can read it, with the people who always decided it still deciding.

Start this week with one business area and one workshop.

The structural answer	A vault team built hubs, links, satellites, the business vault and the marts in order, so a business key decided wrongly was already hashed into everything loaded after it.
What the agent reads	Nothing new: the seven steps produce the data contract in nearly the order the agent reads it.
Yours to decide	Which business area goes first, and which checked questions an agent must answer, or decline, after every contract diff.