The Kitchen Pass — facade, physical plating and specifications that sign off the plate

“The kitchen is for the cook. The menu is for the diner. Whoever mixes up the two ends up with neither a kitchen nor a diner.”

The kitchen pass, Friday at 8:15

It’s Friday night at Marlene’s branch in Chicago. 8:15. The kitchen has sent out fifteen orders in the last twenty minutes and there are nine more in the queue. On the pass, lined up perfectly, the pizzas wait for the servers: three Neapolitans, two quattro formaggi, one Californian, two Chicago Deep Dish — and, on top of one of the Chicagos, a small card, folded in half, written in clean ink.

The card says five things: which pizza it is, which ingredients go into the dough (validated against the product freshness rule v4.0), which controlled allergen it contains, how long it spent in the oven, which branch plated it and signs it. The card doesn’t say which version of the San Marzano tomato sauce was used, or how many joins the system ran in the cellar, or whether the loyal-customer materialization was refreshed at six this morning or at eleven last night. That information exists — it’s in the kitchen, in the packing slips, in the central system’s logs, in the signatures of the Vault Components the branch consumes. It’s all there. But it isn’t served to the customer. The customer doesn’t need it. The customer needs to eat.

The server picks up the plate and takes it to table seven. The couple who ordered the Chicago Deep Dish with honey gold know nothing about Vault Components. They don’t know that product freshness is calculated with a formula the food-quality team validated, or that the loyal-customer score is made up of three metrics with weights certified by management. They know the pizza is hot, it’s on their table, and it smells good. Five minutes later, they’re eating. An hour later, they pay, leave a tip, and head out happy. They come back the following Friday.

What just happened — the plated pizza with its little card, not the kitchen, not the mother sauces, not the physical rig of accelerators holding it up — is what the consumer receives. And the care with which the branch plates is the difference between a chain the customer recognizes and a chain the customer abandons. That plated pizza is a data product. And the technical doctrine behind it is the last piece of the block I’ve been building — from the start of the block until today.

Today I open the pass. Three technical pieces. The whole fourth pillar of Data Mesh — Data as a Product — and the human piece that separates a branch that thrives from one that shuts down close the block in the next part. Today we get to know the machinery: how a signed plate is served to the consumer.

Let’s take it step by step.

Axis 1 — The Facade pattern: the pass that shields the customer from the kitchen

There’s a software design pattern that’s been simmering in the field for three decades, cataloged by the Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides) in Design Patterns (1994). It’s called the Facade pattern, and it solves a problem anyone who has touched a complex subsystem knows well: when you have many pieces, many contracts, many internal rules — and consumers who just want to do one specific thing — you give them a single door. That door is the facade. Behind it sits all the complexity; in front of it there’s a single interface — clear, stable, with its own contract. The consumer doesn’t see the complexity. The complexity is still there.

The metaphor is exactly the kitchen pass. Behind the pass: the kitchen with forty domains, two hundred satellites, eighty Vault Components, five layers of physical accelerators we’ll look at in the next axis. In front of the pass: the plated dish with its little card. The facade is the pass.

Carried over to the data model we’ve been building, a facade is a view per use case, with its explicit contract:

• Consumer identity: who consumes it — a marketing team, a fraud system, an executive dashboard, a regulatory feed.
• Output contract: which columns it returns, with which types, with which semantics. Stable. Versioned.
• Declared origin: which Vault Components it consumes, which satellites it touches underneath, which quality rules the plate signs.
• Guarantees: which properties it meets — maximum staleness, maximum latency, completeness, accuracy.
• Inherited traceability: if an auditor asks “which version of the calculation was behind this view on March 14,” the answer is attached to the artifact, not buried in logs.

When a consuming system — the fraud engine, say — needs the customer’s consolidated score, it doesn’t query the Customer hub directly, or the loyalty satellite, or the scoring Vault Component. It queries a facade called “consolidated score per customer — fraud view v2.1.” That facade signs its card: “this view gives you score, calculation date, calculation freshness, associated alerts. I guarantee latency under 30 seconds. Behind me I use Vault Components A, B, C, in such-and-such versions. If any of the three breaks its contract, I’ll warn you first. If you want a new version, tell me and we’ll negotiate it.”

The facade does four things at once:

1. It shields the consumer from the complexity of the kitchen. The fraud engine doesn’t need to know there are 47 satellites on the Customer hub, or 12 versioned Vault Components, or that the loyalty materialization refreshes every half hour. It just needs the score and the facade’s contract.
2. It stabilizes the consumption contract even when the kitchen changes. If tomorrow the loyalty Vault Component moves from v1.5 to v1.6, the facade can absorb the change internally without touching the outward contract. The fraud engine keeps consuming as before. If the migration requires a visible contract change, the facade negotiates it explicitly — nothing sneaks through.
3. It concentrates consumption governance in one identifiable point. When an auditor comes asking about the traceability of a case, the answer isn’t “we need to reconstruct 200 SQL queries.” The answer is “this query comes in through facade X. Here is its card. These are the Vault Components it signs for. These are the satellites they touch.” Traceability in a single conversation.
4. It makes explicit who the data’s customer is. Every facade has an identified consumer. And therefore every facade has an owner who maintains it — the domain that signs it. That is what turns data into a product rather than a by-product. (The whole pillar — Data as a Product — and how the domain takes responsibility closes in the next part.)

“If the kitchen is the complexity and the diner is the point of the work, the facade is the only thing a customer touches. That’s why it deserves more care than the kitchen.”

What a consumer sees is the facade. What a consumer consumes is the facade. What a consumer remembers is the facade. The kitchen, however complex, certified and well built, doesn’t get served. It gets respected. Maintained. Looked after. But not served.

And here comes the operational question that anyone who has handled data at high volume has had in mind since the previous pillar: if there’s a big machine behind the facade, how do you make sure the facade is fast? The answer is the whole family of accelerators we’ve been promising since the previous part.

Axis 2 — The physical plating family: PIT tables, bridge tables and materializations (pure performance, no logic)

When I closed the Open/Closed sweet spot I left two modeling rules — group by cadence, limit assembly depth — and promised I’d cover the whole family of physical performance today. Here it is. And I’ll start by recalling the boundary we drew in the previous part, because it’s what makes everything that follows make sense:

The three physical pieces share a property that makes them fundamentally different from the Business Vault: they don’t decide anything the business should have decided. They are transparent accelerators. If you delete them all, the business result doesn’t change — only the speed does. That property is what puts them in the serving layer, not the modeling layer.

PIT (point-in-time) tables

Imagine a frequent consumer — an executive dashboard, a regulatory system — asks every day “what was customer Pepe’s state on the last day of each month over the past year?” Without any help, that query forces the system to reconstruct the customer’s bi-temporal state for 12 different dates, joining the satellites across their validity ranges. At high volume, that weighs a lot.

A PIT table is an auxiliary table that precomputes, for a specific entity, its most-queried states as of specific dates. For each customer, for each month-end, one row with pointers to the satellites in effect that day. The dashboard query goes from reconstructing the validity ranges on every call to doing a direct read of the PIT table.

The key point: the PIT table doesn’t change the result. It only precomputes it. Delete it and the system still computes the same thing, just slower. There’s no business logic inside the PIT table — only pointers. It’s canonical DV 2.0 vocabulary, described by Linstedt and industrialized by the whole serious ecosystem (Scalefree, AutomateDV, dbt vault).

Bridge tables

Some queries cross several hubs through multiple links. “For each customer, their home branch, their contracted products, and their assigned advisor” — that’s four hubs joined by three links. Without help, that’s several deep joins every time the query runs.

A bridge table is an auxiliary table that precomputes the frequent path between hubs. One row per customer-branch-product-advisor combination, with its canonical keys ready to join. The query goes from rebuilding the path every time to reading straight from the bridge table.

The key point, once again: the bridge table doesn’t change the result. It only precomputes the path. Delete it and the data is still there; the query just takes longer. There’s no business logic: only combined canonical keys. Also canonical DV 2.0 vocabulary.

Selective materializations

The simplest form of physical plating: a frequently used business view is computed once a day (or every hour, or every minute, as needed) and crystallized into a table. Queries read the table instead of recalculating the view each time.

The key point, for the third time: materialization doesn’t change the result. It only crystallizes it. And this is where something needs saying plainly, because it’s where the layers get muddled the most: you don’t materialize to hide logic; you materialize to make it cheaper to read something the business consumes every day. If you need to materialize so you can offer a latency guarantee the facade signs, materialize. If you materialize to dodge a decision you should be making in the model — “I’ll stick this calculation in the materialization because it’s easier than creating a Vault Component” — you’re creating a Vault Component in disguise, with no signature, no version, no traceability. And that’s the road to the ungovernable model. The boundary is technical common sense, but it needs saying.

Why the whole family lives here

All three pieces — PIT tables, bridge tables, materializations — are pass infrastructure. They exist so the facade can sign for reasonable latency without recomputing everything from scratch each time. Without them, a facade that crosses several hubs and several Vault Components would be slow. With them, the facade is fast without paying for duplicated logic. And that’s why they’re plating, not modeling: they exist to serve, not to decide.

“The Business Vault decides. PIT and bridge tables accelerate. The facade signs. Mixing up the three is the recipe for an ungovernable model. Telling them apart sharply is what lets the physical machinery grow without governance dissolving.”

And that connects with the next piece, because the facade isn’t just abstraction — it’s also a quality signature. And the signature needs a language of its own.

Axis 3 — The Specification pattern: quality rules as evaluable objects

When the facade hands the plate to the consumer, it signs a guarantee. That guarantee isn’t a PDF pinned to the internal documentation — it’s an executable object. Eric Evans gave it its canonical technical name in Domain-Driven Design (2003): the Specification pattern is, quite simply, an evaluable predicate. It takes an object, evaluates whether it meets certain criteria, returns true or false — and, optionally, returns the detail of which criteria it meets and which it doesn’t. A specification isn’t quality documentation: it’s a piece of code that can be executed and composed with others. “Valid customer for this facade” can be a specification composed of “active customer” AND “tax-identified customer” AND NOT “customer blocked for regulatory compliance.” Each of the three is a primitive specification. The composite one is built by combining them with logical operators.

Applied to data plating:

• Each facade declares the specifications it signs. The facade “consolidated score per customer — fraud view v2.1” can sign three specifications: calculation freshness under 24 hours, minimum 98 percent completeness, accuracy of the underlying Vault Component certified in the latest deployment.
• Specifications are evaluated on every read — or in configured time bands — and produce a result. That result is returned along with the data. The consumer doesn’t just get the number; they get the number with its signature.
• When a specification fails, the plate doesn’t go out to the pass. The facade can take one of three paths: (1) deliver the data with an explicit warning, “this plate goes out with the freshness specification down,” (2) deliver the last valid data with the date of the last full signature, (3) block consumption and return a signed error. The decision belongs to the facade’s owner — the domain.

This is what in Block 1 we called “quality rules as objects, not as comments in SQL.” Same thing, now with its canonical technical name — Eric Evans, 2003 — and with the exact role it plays in the machinery: signing off the plate before it reaches the customer.

This is where you see the difference between an organization that has quality and one that says it has quality. When quality lives in comments in internal documentation, the rules drift out of date within six months and nobody notices until the regulator asks. When quality is evaluable specifications signing every facade, divergence between the rule and reality is impossible — because the rule is the execution. If the rule isn’t met, the system says so. If the rule changes, the system reflects it in the next deployment. Documentation is alive — a concept that already came up earlier in the block — because the code is the documentation.

“A quality rule that isn’t evaluated isn’t a rule — it’s a wish. The difference between a franchise the regulator certifies and one it doesn’t is whether the rules live in code or in PowerPoint.”

And that connects directly with the fourth pillar of Data Mesh — Data as a Product — which is where everything from today lands. But the whole pillar, with its operable asymmetry and its human piece, is for the next part.

What’s next

Today we opened the pass: facade, physical plating with no business logic, specifications that sign before serving.

What’s missing is who decides what gets plated — the whole fourth pillar — and the human piece I’ve been saving: Brooklyn, the neighborhood table, what a chain can kill without meaning to.

In the next essay: everything distilled into one thing.

Until then.