Attributes are where the payoff lives

In this chapter

Defined once, mapped everywhere. A business attribute, and the facets that make a column comparable across sources.
Keep the source code, add the mapped value. Code lists, code mappings, and a code nobody mapped.
The contract is a projection. What a published table says about itself, and why it isn’t a separate table.

Which column is the customer’s name? What currency is each amount in? Which status code means Cancelled in this system? In most estates the answer lives in every gold model that needed it, written again by whoever built the report. Two reports that answered differently both look right.

Identity lets an agent join two systems. Only attributes let it compare them. That’s where AIMS (AI-ready, Meaning-first Silver) pays for itself.

The column everyone re-derives is the one nobody mapped

Our first book put the remedy in one line in “The mapping is the deliverable”: “this table is that entity, this column carries that attribute.” AIMS makes the second half metadata that every source shares. A business attribute is one meaning, defined once on its entity. An attribute mapping ties each column that carries it to that meaning. The attribute’s description, quality rules, classification and conformance travel with it instead of being rewritten per column. The order system’s Name and the sales system’s AccountName both map to Customer Account Name, so a consumer of either reads one definition.

Two source columns from two systems connected to one business attribute, Customer Account Name, defined once with its description, rules, classification and conformance.

Each facet of a business attribute answers a question a consumer would otherwise answer by guessing.

Semantic type says what kind of value it is, such as an identifier, a monetary amount or a date. An identifier is never summed. A monetary amount needs a scale and a currency.
Attribute role says what the column does in the row (identity, descriptive, measure, relationship, status, temporal or classification). The role gives dimensions and facts their first draft.
Unit and currency say where the unit lives: fixed on the attribute, in a column beside the value, or set per record source.
Code list names the reference entity a code belongs to. Like any entity, it relates to others, so Country rolls up to Region along a relationship with a role, never a guessed mapping.
Classification applies your sensitivity, personal data and regulatory schemes once, on the attribute.

Every mapped column inherits its attribute’s classification. So you map once and mask everywhere. The attribute’s conformance rule applies to every mapped column unless a mapping states its own.

On the worked example’s sales order table, the company code and order number are identifiers that make the key. The table’s two customer numbers are relationships, and its currency and status are codes on their code lists.

Every column is mapped, source-only or unmapped

An attribute mapping carries a state. The state makes the gap countable.

Mapped columns point at a business attribute, keeping the mapping’s origin, confidence and rationale.
Source-only columns deliberately carry no business meaning, such as the sales system’s OwnerUser, an internal user identifier, which stays in the table classified internal.
Unmapped columns are debt, and AIMS counts them.

A column a person confirms has no business meaning becomes source-only, so “we looked and it means nothing” no longer reads the same as “nobody looked”. A source that departs from the attribute’s rule gets a conformance expression on its own mapping, such as a code mapping or a unit conversion. Our first book named the cost of leaving meaning implicit: “sniffing and inference are contract debt.”

An unmapped column is that debt with a number on it.

Keep the source code, add the mapped value

Codes are where comparison breaks first. The order system sends order status as C, O and S. A second system that sent CXL for Cancelled would need its own translation.

So AIMS names reference entities one by one (Order Status, Country, Currency). Each owns a code list (reference data, in most tools) of business values with definitions, such as Cancelled, Open and Shipped. Per record source, a code mapping (elsewhere, a value mapping) says which source code means which value. A person approves it. It’s dated, so a changed mapping keeps its history.

The source-aligned table keeps the source code untouched. Where the attribute is marked for conformance in silver, the table also gains a generated mapped value column. So the sales order table keeps C in status and adds Cancelled beside it. The mart templates apply every other code mapping downstream from the same attribute, so silver doesn’t grow a column per attribute. A code with no approved mapping maps to nothing, visibly, as a null and a warn finding, never to a guess.

The sales order table keeps its status code C and gains a mapped value Cancelled beside it from the Order Status code list, while an unmapped code maps to nothing and a warning.

Why not keep one catch-all list of every code in the estate? Because one Cancelled would have to serve every status list at once, and it couldn’t define any of them.

Ask an agent for the value of Cancelled orders by month. It reads amount as a monetary amount whose currency sits in the next column, so it groups by currency instead of adding two currencies together. And it filters on the mapped value Cancelled, not a letter it would have to guess.

The critical columns are mapped, and the rest is measured

The five meaning levels run from 0 Typed to 4 Integrated. A table publishes when every reference to another business thing is tied to it (level 2) and its critical columns are mapped (level 3). Publishing also needs its acceptance checklist to pass: identity, values, history, rules and governance. Then gold and agents may read the table.

Critical columns are the ones that identify, relate, hold a code or hold sensitive data. Your project, the unit of work a set of tables is organized and generated in, may add classes. On the sales order table, six of the nine source columns are critical. The order date, the amount and the change time count toward coverage instead.

Coverage is a measure, not a bar. Below your project’s threshold, 80 percent by default, it raises a warn finding and never blocks. The layer ships. The debt stays visible as one number per table and per entity, falling as columns get mapped in use.

The five meaning levels, with the publish gate at level 2 plus the critical columns of level 3, and attribute coverage shown as a measured number rather than a bar to clear.

Why is the data contract a projection, not a new table?

In AIMS, a published table’s data contract already exists, because it’s projected rather than written. It’s what the catalog holds about the table: owner and steward, entity, synonyms and grain sentence, business key and record source, history and delete policies, time columns, relationships with roles and cardinalities, every column’s mapping and semantic type, quality rules with their failure actions, lineage, classification, the freshness target and the known limitations (the unmapped columns and unmapped codes). It’s versioned with the metadata it’s projected from.

The sales order table’s contract opens on its grain sentence: one row is one Sales Order version from record source awlt. It closes on its coverage, 100 percent.

The data contract drawn as a projection of the catalog's rows into one document that opens on the grain sentence and closes on its coverage, with the separate contract table passed over.

We passed over a separate contract table. It would drift from the catalog the first time someone edited one and not the other. We passed over prose too. One team wrote what its agent needs as markdown files. The modeling happened, but it moved into a paragraph. A projection keeps it a row, which a template can render and a diff can catch.

At LinkedIn, structured table and column attributes lifted the share of an agent’s answers rated correct from 11 percent to 24, and example queries lifted it to 49. But free-text notes about the business lowered it to 42. Meaning tied to tables and columns helped, there as in the text-to-SQL benchmarks. Exporting the contract in the Open Data Contract Standard’s shape is later work.


The structural answer	A canonical model or a vault’s business satellite translates codes inside its load logic, so the mapping is readable by whoever reads that load.
What the agent reads	Each column’s mapping, semantic type and other facets, each code’s dated mapping, coverage, and each table’s contract.
Yours to decide	Any conformance that changes a value, every classification sign-off, and adding a critical class to your project or removing one it added.

In DeltaVault today

DeltaVault, our metadata catalog, already holds business attributes. A mapped column shows its attribute’s classification as derived. The catalog’s metadata is serialized to readable YAML that’s reviewed, committed and versioned in Git.

Below are its classification settings, with the Sensitivity scheme open.

The classification settings with the Sensitivity scheme open beside the Personal Data Categories and Regulatory tabs, listing Public, Internal, Confidential and Restricted.