intellimetrics Learning
Building Trustworthy Data Products Module 2 · Know What You Were Given

What You May Not Join

Last reviewed · content updated

Advanced

What you'll learn

~18 min
  • Read data classification as an inherited constraint on what you may build
  • Recognize the joins that produce an output more sensitive than either input
  • Route a sensitivity question to a decision instead of making it silently in a WHERE clause
ℹLeadership brief

What it is: deciding, before a join runs, whether combining two permitted datasets produces something neither of them was cleared for.

What it buys: the sensitivity question gets answered by someone authorized to answer it, at design time, on the record — instead of being settled implicitly by an analyst writing a query, and discovered later by an auditor or a customer.

What to fund: a named person who can rule on aggregation questions within a day, and the expectation that analysts route to them rather than guess.

You are not setting the classification

If you came through the Zero Trust training you met data labels as a security control — something you apply, enforce, and use as a policy input. Set that seat aside. Here, classification is something you inherit and must not violate. Somebody already decided that the customer table is restricted and the circuit topology table is internal. Your job is not to reclassify them. It is to know what those labels permit you to build.

That reframing matters because the failure mode is different from each side. A security engineer’s failure is a label applied incorrectly. Yours is a perfectly correct label on each input, and an output that quietly belongs in a category neither input was in.

Prompt first: find and measure, never rule

An agent is useful for finding these:

Here are the schemas and classifications of the tables I plan to join
[paste]. My output grain is [grain], audience is [audience].


Identify where this join could produce an output more sensitive than
its inputs. Specifically check for identity reassembly, small-cell
aggregation, and sensitivity inheritance through the join key. For
small cells, write me the query that counts how many output groups
fall below thresholds of 5, 10, and 25 entities.


Do not tell me whether this is permitted. That is not yours or mine
to decide - produce the facts I need to take to the person who rules
on it.

The final instruction is not politeness. An agent asked whether something is allowed will produce an answer, and that answer will be a general-purpose inference about privacy norms with no knowledge of your organization’s actual policy, your regulator, or your contracts. It will sound authoritative. Taking it as a ruling means an unauthorized person made a compliance decision, and the fact that the unauthorized person was software does not improve the situation.

Agent finds and quantifies. Human with authority decides.

KNOWLEDGE CHECK

You join two internal-classified tables. You select no restricted columns, and every access check passes. Your output aggregates to segments, 40 of which serve fewer than 10 customers. What is the right next step?

Aggregation and the mosaic problem

Two datasets, each cleared for your use, can combine into something that is not.

Meridian’s case: circuit topology is internal — which circuits exist, where they run, how many customers each serves. Outage history is internal — which circuits failed, when, for how long. Both are fine for you to read.

Join them, aggregate to a small enough grain, and you can produce a table showing which specific neighborhoods lose power most often, with durations. At the level of a circuit serving 4,000 customers that is an operational metric. At the level of a circuit segment serving 12 customers, it is close to a statement about identifiable households — and there is a real question about whether it should be published to a dashboard that forty people can open.

Neither input was sensitive. The join and the grain made the output sensitive. Nothing in the platform will stop you, because every access check you passed was a check on the inputs.

⚠The three joins to look for
  • Identity reassembly — separately innocuous attributes that together identify a person or household. Meter-level anything is usually one join away from this.
  • Small-cell aggregation — a group-by whose smallest groups contain few enough entities that a row is effectively about a named party. The threshold is a policy decision, not a technical one.
  • Sensitivity inheritance — joining anything to a restricted table generally makes the result restricted, even if you selected no restricted columns. The join key itself carried information.

The question you must not answer alone

When you find one of these, the wrong move is to decide it yourself — in either direction. Proceeding because it seems fine is obviously risky. Silently abandoning the analysis is the failure people notice less, and it is expensive: a genuinely valuable metric gets dropped because an analyst was uncertain and had nowhere to take the question.

Route it instead. What the decision-maker needs from you is short and specific:

SENSITIVITY QUESTION - circuit reliability by segment


INPUTS        circuit_topology (internal), outage_history (internal)
OUTPUT        one row per circuit segment per month, with outage count
              and total duration
CONCERN       at segment grain, 340 of 5,100 segments serve fewer than
              25 customers; 40 serve fewer than 10. A row about a
              10-customer segment is arguably a statement about
              identifiable households.
AUDIENCE      distribution planning supervisor plus ~40 operations staff
              with dashboard access
ALTERNATIVES  (a) suppress segments under 25 customers - loses 6.7% of
                  segments, including some of the worst performers
              (b) roll up to circuit grain - loses the precision that
                  makes the metric actionable
              (c) publish at segment grain to a named-access group of 6
ASKING FOR    a ruling on which of the three, or a fourth I have not seen
DECIDE BY     2026-09-08 (build starts after)

That is a document somebody can rule on in ten minutes. It names the concern honestly, quantifies it, and offers options with their costs — rather than asking “is this okay?”, which is unanswerable and gets deferred.

Key takeaway

Classification reaches you as an inherited constraint, not a control you are setting, and the failure mode is an output more sensitive than either input: identity reassembly, small-cell aggregation, or sensitivity inherited through a join key. Every access check you passed examined the inputs, so none of them will catch it. When you find one, do not rule on it in either direction — quantify the concern, cost the alternatives, name the audience, and route it to whoever decides. Use an agent to find and measure these, never to say whether they are permitted. Module 3 begins the build, with a profile and a constraint list in hand.

LEADERSHIP DECISION   name who rules on aggregation sensitivity, and
                      commit them to a turnaround an analyst can plan
                      around
PRACTITIONER ACTION   check every join for identity reassembly, small
                      cells, and inheritance through the key; route with
                      quantified options rather than asking "is this ok?"
SUCCESS MEASURE       zero published data products whose sensitivity
                      question was settled inside a WHERE clause; every
                      routed question ruled on within the committed window
Search lessons