Is it the supplier's problem or the franchise's? — the catalog that learns and the rejection trail

The rule put to the test

Last week I left the chef on the Mediterranean with a very specific phone call at 7:30 p.m. on Thursday, March 18. The card for San Marzano DOP tomatoes — version 1, signed January 12 — had let through a batch that was technically correct but substantively wrong. DOP seal visible on the box. Certification number right where it should be. But the seal belonged to a batch from last year, already used up. Rule R3 checked that the seal was there; it didn't check that it was valid against the Consorzio's official registry.

And I also left you version 1 of the cancelled-contract rule in banking — “if status = CANCELLED, then balance = 0”. Three words, CRITICAL severity, running every night without incident. Until the day the business approves rounding off residual balances of up to five euros for accrued interest, and the rule starts blocking cases that are now legitimate.

Both rules are the same scenario in two different domains: yesterday's correct rule is incomplete or wrong today. The chain has to learn. And the question is: how does it learn without shutting down the kitchen, without a three-week committee, without an email to all forty branches?

Today I'm answering that question. And before this Pulse is over I'll answer the one in the title: was Tuesday's BLUE-LINE truck — the five thousand liters of crushed tomato nobody ordered — the supplier's problem, the franchise's problem, or something else?

Let's take it one step at a time.

Axis 1 — When reality evolves: the catalog that learns

There's a pattern that shows up in every chain that scales, and that most quality implementations don't account for. The pattern is this: the right rules today aren't the right rules tomorrow. Not because they're wrong today — because reality changes, the business changes, suppliers change, regulators change. A living chain needs a mechanism so that the rule catalog evolves with reality, without throwing out what came before, without waiting for a quarterly committee, without leaving the update to the heroics of a central team.

Back to the chef on the Mediterranean. The complaint is legitimate — rule R3 (“DOP visible on the box”) lets through a batch that technically complies (the seal is there, the number is there) but that substantively isn't what the chain signs off on as San Marzano DOP tomatoes. The seal belonged to a batch from last year.

What happens next?

At a traditional company, here's what happens. The complaint goes into the ticketing system, reaches a quality committee weeks later, gets discussed, and a proposal document is produced. The document is approved the following month, somebody updates the procedure and notifies the branches by email. Half the branches read the email and the other half don't. And the batch that shows up next Tuesday at another Mediterranean branch with the same problem slips through again. Because the procedure, even updated, isn't executed — it's only described.

At the franchise with living documentation, here's what happens. The chef's complaint comes in on Thursday the 18th at 7:30 p.m. Headquarters' quality lead opens the Products domain repository. He edits the Recipe — version 1 — and adds a fourth rule (using a three-tier severity system I'll explain a little further down):

Card 2 — Refined Recipe for San Marzano DOP tomatoes (version 2, refined March 18 after a call from the Mediterranean branch)

INGREDIENT          : San Marzano DOP tomatoes
CONTRACT SIGNED BY  : Chain Quality Management
IN FORCE SINCE      : 2026-03-18 19:47   (← version 2, replaces version 1 in force since 2026-01-12)
DOOR RULES          :
  R1 — origin           = Campania (Italy)                         · severity: CRITICAL
  R2 — variety          = San Marzano                              · severity: CRITICAL
  R3 — certification    = DOP visible on the box                   · severity: CRITICAL
  R4 — cross-check      = certification number against the         · severity: CRITICAL
                          official Consorzio registry
                          (API lookup; cache 24h)
REASON FOR v2       : Mediterranean branch complaint, Mar 18 — DOP
                       seal was on the box but belonged to a batch
                       from the previous harvest, already used up.
                       Checking against the Consorzio catches
                       this case. Retroactive review pending
                       for the last 30 days.
ACTION if CRITICAL  : return the batch to the producer with a reason
ACTION if WARNING   : accept and flag for human review
ACTION if INFO      : accept and leave a trace in QSAT

By 7:47 p.m. on Thursday, the Recipe has been edited. The platform automatically generates the new executable test from rule R4. It deploys it. Starting that night — the night of March 18 to 19 — every batch of San Marzano DOP tomatoes that comes into any of the 40 branches goes through the cross-check against the Consorzio. No email to the branches. No waiting for the next committee. No manual update to a procedure. The rule is in the catalog, the catalog runs every night, the catalog learned.

And the trail stays. V1 isn't deleted — it's closed with an end-of-validity timestamp (“in force from January 12 to March 18”). V2 comes in with a start timestamp (“in force since March 18 at 7:47 p.m.”). Anyone who asks six months from now “which rules were in force on March 14 when batch XYZ came in?” gets an answer. V1, not V2. The chain doesn't pile up debt — it consolidates knowledge.

And this pattern — the rule that starts out simple, runs into reality, and learns — isn't an isolated kitchen case. It's the structural pattern of every chain that scales. And this is where the callback comes in to the Accounts domain example I already laid out in Week 5.

The cancelled contract, V1 → V2

In Week 5 I showed an example of the chef's pass in the Accounts domain. The V1 rule was this: “If a cancelled contract has a balance of €500,000, I don't buy it. If status = CANCELLED, then balance = 0”. Three words, one rule, CRITICAL severity. It lived in the Accounts domain Recipe. It ran every night. And it rejected — correctly — the contracts where a migration or source failure had left a non-zero balance after cancellation.

Until one day the business changed its policy. Because of rounding in the calculation of accrued interest, it was approved that a cancelled contract could keep a residual balance of up to five euros without that being an error. Reality had evolved. The V1 rule — “if CANCELLED, then balance = 0” — was now blocking legitimate cases: cancelled contracts with a residual of €1.73 or €4.27 that the new operating policy considered normal.

At a company with traditional documentation, what would happen is predictable: the quality PDF still says “balance = 0”. The technical team, under pressure from the operational noise, would loosen the rule by brute force — commenting it out, bypassing it, patching things downstream. Documentation and reality would drift apart for good. And the next time an auditor read the PDF, they'd see a rule the system hasn't honored in nine months.

At the franchise with living documentation, the path is different. The operations complaint lands in the Accounts domain repository as a refinement request. The domain owner — who knows the new operating policy — opens the Recipe and updates it. V1 is closed:

Recipe Accounts — Rule R-CUENTA-CANCEL-001
v1 — in force from 2025-09-01 to 2026-04-15
    if status = CANCELLED then balance = 0
    severity: CRITICAL

v2 — in force since 2026-04-15
    if status = CANCELLED then (balance = 0 OR balance < 5)
    severity: CRITICAL
    reason: refinement following approval of rounding for
            residual balances on accrued interest (Q2 2026)

From the night of April 15 on, the V2 rule is in production. Cancelled contracts with a balance of €4.27 pass; the ones with €500,000 still don't. The catalog learned. The documentation moves with reality — because the documentation is reality, executed. Zero desync window.

And this is where the intellectual piece that closes the axis comes in. Because the natural question is: “OK, rules evolve, but how do we tell when a rule is learning from when it's just being loosened out of laziness? What holds it up operationally?” The answer is almost two decades old and has a specific author worth naming before we go on.

Maydanchik and the three severities — the traffic-light framework

There's a false dilemma that poisons almost every operational conversation about data quality: “Either we validate everything at the entrance, and then nothing gets in and the business grinds to a halt, or we validate nothing, and then anything gets in and nobody knows what we've got.”

It's a false dilemma. It's false because it's framed wrong. The right question isn't “do we validate or not?”. The right question is “at what severity do we validate each kind of rule?”

The person who solved this before anyone else, with a rigor that's still the operational standard in the field, was Arkady Maydanchik in his book Data Quality Assessment (2007). His concrete contribution is a clean separation between three severities of rule, each with a different operational behavior:

• CRITICAL — the hard rule. The record doesn't get into the model. It's diverted to quarantine with a recorded reason. Examples: a duplicate business key (the case of the BLUE-LINE truck we'll see in the next axis), an empty mandatory field (a null NIF on a Policies customer), a broken format (a date reading March 32), a failed San Marzano Consorzio rule.
• WARNING — the soft rule. The record gets into the model, but with a flag attached. It's formally valid, but there's something about it that deserves a human look. Example: a 78-year-old policyholder takes out a life insurance policy with a €95/month premium; it gets in, it can be used to operate, but it's flagged for a person to review in the morning.
• INFO — the note in passing. The record gets in and gets noted. No alert. No human review expected. But the system leaves a trace of the observation in case someone wants to build a historical series in the future. Example: supplier X's onions arrive today at €1.20/kg; on previous Mondays they were €1.00.

All three severities in the same franchise. All three running every day as part of the living catalog. All three attached to the corresponding hub/satellite/link.

And this is where the second Data Mesh pillar closes. Zhamak Dehghani — the creator of the Data Mesh framework — describes Federated Computational Governance as the property by which, as she'd put it, governance can't be a committee; it has to be code that runs. Living documentation with its three severities is exactly that: governance in execution, with three levels of operational response, each suited to the kind of problem. It's not a committee. It's a traffic light. And the traffic light is configured by the domain that knows the context, on top of the canonical contract signed by headquarters.

Maydanchik provides the intellectual framework for the traffic light. The shift left doctrine — which we wrapped up last week — provides the principle. But the operational engine is provided by living documentation — the catalog that runs every night, leaves a trace, and learns with every complaint. A framework without an engine is a PDF. An engine without a framework is heroics. Put the two together and you get a franchise that scales.

One question is left — the last one — to close out the day. “OK, the rules run, the three severities live in the catalog, the catalog learns. But when a CRITICAL rule rejects a record — Tuesday's BLUE-LINE truck — where does the trace stay? In a log? In an errors folder?” That question has a concrete answer, and it has a name.

Axis 2 — The BLUE-LINE truck: the structural trail of learning

We leave the central kitchen and go back to Tuesday's loading dock to answer the day's second question: the rejection trail.

Five thousand liters of crushed tomato arrive on the BLUE-LINE truck. Label: “Italian-style crushed tomatoes”, batch MZ-7842-IT. The dock operator scans the code and the system responds immediately: CRITICAL — duplicate business key. Batch MZ-7842-IT was already registered in the system, marked on February 14 as “not delivered — supplier BLUE-LINE stated the batch had been withdrawn due to a labeling problem at origin”. The batch that was “not delivered” on February 14 is landing today at a different dock. Something doesn't add up.

The hard rule rejects it. The truck stays outside. The five thousand liters go back to the supplier with a documented return. The branch's operations staff decide nothing — the rule decided.

But the trail stays — or it should. And here's the operational nuance worth separating out.

The record didn't get in. The model is clean. The hard rule did its job — that's the fundamental guarantee, and it needs nothing more. But “the record didn't get in” answers the model's safety question, not the business question: “how many BLUE-LINE batches have we rejected this quarter?”, “which rule is firing the most rejections this week?”, “can you prove to compliance that batch MZ-7842-IT did not get into the model on March 18?”. Those questions need the rejection event to be stored somewhere with structure — not in an errors/ folder nobody looks at until it's too late.

The option with the greatest native analytical traceability in the Data Vault 2.0 toolkit is a piece with a name of its own: the QSAT — Quality Satellite. It's another satellite in the same machinery, made of exactly the same stuff as the satellites we saw two weeks ago — the difference is what it records. Where the satellite of a Customer hub records versioned customer attributes, the QSAT records versioned quality events: which rule fired, on which record, at what moment, with what severity, for what reason, what action was taken. The rejected record doesn't get into the model. The news of the rejection does.

Card 3 — The QSAT row for batch MZ-7842-IT (Tuesday, March 18, 09:14:32)

QSAT — row of 2026-03-18T09:14:32

Rule fired          : R-HUB-LOTE-001 — duplicate business key check
Severity            : CRITICAL
Rule version        : v1 (in force since 2025-11-04)
Business key        : MZ-7842-IT
Source              : BLUE-LINE (supplier — Hub PROVEEDOR)
Reason              : Batch already registered on Feb 14 as "not delivered".
                       Appearance at north dock on Mar 18 inconsistent.
Action              : Rejected — returned to source
Return code         : DEV-2026-0318-MZ-7842-IT
Operator            : marina.lopez@objectville.com (north branch)

That row lives in the model. Because the QSAT is, structurally, just another satellite, like any other row in the model. The query that answers “which batches have we rejected for duplicate business key this quarter?” is the same SQL query as the one that answers “which customers have renewed their policy this quarter?”. They're satellite queries — one with customer events, the other with quality events. The machinery is the same.

And this closes the technical callback we've had open since the first week of B2: quality isn't a layer mounted on top of the model. It's another face of the model. The QSAT is pure Data Vault 2.0 — a satellite — used to record the machinery's own behavior when it rejects a record. Quality and operations live inside the same structure. Rejection traceability doesn't require another tool, another server, another team. It requires one more query against the same model.

What does that change in practice? Let me ground it with an example from the domain we covered in Week 6 — Policies — because the mechanics are exactly the same and it's worth seeing them across ingredients.

Quality lives in the model — the Policies domain case

Week 6 closed with a Policies domain Recipe that had three quality rules signed by the business: “The NIF has a valid format. The score is between 0 and 10. Net premium = Gross premium - Reinsurance, with a tolerance of 0.01”. Three levels — property, entity, relationship. Three severities — all three CRITICAL in that initial Recipe.

All three run every night. Every time a customer, a policy, a transaction comes in. And every time one fires, it leaves a trace in the Policies domain QSAT. If on April 18 a batch of new sign-ups arrives with three badly formatted NIFs, the QSAT records three rows. Each with its rule, its severity, its business key, its timestamp, its action. Three returns to the source system with a specific reason.

And the question a bank's internal control team wants to be able to ask at any moment is this: “how many transactions have we rejected this quarter for a badly formatted NIF, from which sign-up provider, and trending how compared to last quarter?” In most implementations, that question sets off an odyssey of digging through logs in five different systems. In an implementation with a QSAT, that question is one SQL query against the Policies domain QSAT — grouped by provider, filtered by CRITICAL severity, aggregated by quarter. The answer comes back in milliseconds. No extra work. No team dedicated to reconstruction.

It changes things when, six months from now, the fraud team asks “how many times has BLUE-LINE tried to sneak a suspicious batch past us this year?” — the answer comes out of the QSAT in one query. It changes things when the compliance team asks “can you prove that batch MZ-7842-IT did NOT get into the model on March 18?” — the answer is the QSAT row with CRITICAL severity and the return code, not a search through old logs. It changes things when a new supplier asks “what rejection rate do you have with your current suppliers?” — the answer comes out of a dashboard on top of the QSAT and the supplier hubs, with no extra work.

And above all, it changes what we've already repeated several times and what takes on real weight today: quality as code, not as audit. Audit arrives late — when the bad data has already spread. Quality as code intercepts the bad data at the door and leaves a structural trail of the rejection. The difference isn't one of process. It's one of architecture.

Closing the loop — the supplier or the franchise?

Now I can answer the question in the title in one stroke.

Is it the supplier's problem or the franchise's? In a chain with living documentation, the line isn't drawn by a committee. It's drawn by the rule catalog running in Staging every night — before the data touches the model.

If the catalog fires in Staging — CRITICAL at the door, batch rejected, row in the quality table — it's the supplier's problem. The base data arrived bad. The email goes out to the producer with the return code and the specific reason. The branch doesn't investigate its own process because the process never got to touch the data. The dock operator scans the code, the system decides, the truck goes back.

If the catalog lets it through — all rules green, data gets into the model, usable for operations — and afterwards some odd behavior shows up downstream, it's the franchise's problem. Your transformation. Your Facade. Your Vault Component that combines two satellites badly. That's where you step in with judgment, because the base data was fine.

And if the catalog lets it through and later a branch discovers the rule was incomplete — Thursday's chef on the Mediterranean — then we're in the third case, the learning case. The catalog wasn't wrong: it was incomplete. The complaint comes in. V2 is born. By the next day the whole chain is protected. The catalog learned. The franchise consolidated structural knowledge. And the chain didn't pile up debt.

Three questions. One single piece. Living documentation.

And this is where I'd wrap up the day… if it weren't for one loose end we've left dangling. The big one.

What's next

That's one half of the problem. The other half is still missing: what happens when data that got in cleanly turns out to have been wrong — and nobody knows how far the error has spread?

I'll leave you the twist with a concrete image. One Friday in March, a small Objectville branch in a coastal town up north calls headquarters. On the line, the manager, her voice tight:

— The DOP cheese we got six weeks ago. The one we signed off on as Pecorino Romano DOP. We just got the official notice: the supplier's lab sent the wrong certificate. It wasn't real DOP. It was grass-fed pecorino, sure, but without the designation of origin. We've served pizzas with that cheese. How far has it spread?

Silence in the room. Headquarters can't answer the same day. How many pizzas? At which branches? To which customers? Which independent auditor, tomorrow, will be able to read the menu with DOP written on it and check what was actually served each day? And how do you do all of that without destroying anything that's already in the model?

Those three questions can't be answered with quality like today's. They're answered with a property of the model called Audit-Only-Never-Delete. And they're answered with a concrete mechanism: replaying the past against the rule of the moment, without deleting anything. That's what I'll open up next Tuesday. The factory that never forgets.

Today we closed the process side of the Federated Computational Governance pillar — the side that decides what gets in and what stays out, with whom and under what severity, and that learns every time reality teaches it something new. Memory — the other half — I'll open up next week. And with it, the whole pillar closes.

See you next week.