Why Clean Rooms Aren't Enough

When two organizations need to analyze data together but can't merge it, the default reflex is to build a clean room – a neutral environment where both parties load data and run joint queries without seeing each other's raw records. But step into a regulated or cross-jurisdictional setting, and the model strains. A clean room is still a centralization; the data has just moved into a third party's environment instead of yours. For a bank bound by data-residency law, an agency holding records at different classification levels, or coalition partners under treaty constraints, the directive: "move it into someone else's trusted environment" is often answered in the end with "you can't." 

‍

This problem shows up constantly. Intelligence agencies hold partial pictures at different classification levels. Banks can't pool customer records across jurisdictions even when regulators want them to coordinate on fraud. Grid operators are bound by CEII and NERC CIP. In each case, the analysis would be straightforward if the data were in one place. But the data is precisely what cannot be moved into one place. The result is decisions made on partial information, decisions that can't be independently verified, or no decision at all because nobody holds the whole picture.

‍

Most AI initiatives in these sectors don't stall because the model is wrong. They stall because the data can't legally, operationally, or politically be brought together, and the plan quietly assumed it could. So the question that decides the outcome isn't which model you use. It's whether you can produce a decision that every participant can trust and reproduce without ever pooling the data. That is the problem clean rooms were designed to address. In practice, they only solve part of it.

‍

The Trilemma

Most teams in these environments are trying to satisfy three requirements at once: 

1. Capability: use AI to stay competitive.
2. Protection: meet data residency and security requirements.
3. Accountability: show how each decision was reached. 

‍

In practice, they get two. Centralize into a lake or a clean room, and you get capability and accountability while straining protection and expanding your attack surface. 

‍

Stay distributed, and you preserve protection but struggle to produce consistent, explainable outcomes across boundaries. That tension, in which maximizing capability usually means weakening protection, and proving accountability usually means centralizing the very data you're protecting, is the real constraint. 

‍

It's an architecture problem, not a model problem.

‍

Move the Computation, Not the Data

The alternative to moving data is to move computation to the data and exchange only derived results. Each participant runs the agreed analysis locally against its own records and emits intermediate outputs: scores, encrypted set elements, one-way feature encodings, and confidence vectors. Those intermediates are combined into a joint result. How they're combined without leaking – secure aggregation – is itself a substantial design problem, and I treat it as out of scope here. Raw records never leave their home environment. The objective is not distributed computation for its own sake; it is to produce a result that, for the right class of computations, is equivalent to what centralization would have produced, without requiring centralization.

‍

This complements, rather than replaces, secure multiparty computation, confidential computing, and homomorphic encryption, each of which carries its own cost in compute, hardware trust, or coordination. Those protect data or computation during execution; the problem here is different: ensuring that independent organizations run the same decision logic, produce reproducible outcomes, and can reconstruct how a result was reached. You can run this pattern inside an enclave or over an MPC protocol. But none of those alone gives you consistency or reconstructability.

‍

This is not new in the abstract; federated analytics and privacy-preserving record linkage have a deep literature. What determines whether it works in production is less the local computation than the coordination: how independent systems with different schemas, semantics, and update cadences agree on what they are computing and prove they computed the same thing. That agreement has to be made explicit. In a centralized system, it's implicit in a shared data model; across organizations, it has to be written down.

‍

Making Decision Logic a Contract

The durable pattern is to express the decision logic as a declarative contract: a structured specification of which inputs participate, how they're transformed and weighted, what thresholds determine an outcome, what evidence is required, and which outputs are permitted to cross the boundary. The data stays local; the contract is the portable artifact every participant executes.

‍

Practitioners have several established formats to express this rather than inventing one. The OMG's Decision Model and Notation (DMN) standardizes decision tables and is designed to be readable by non-engineers. Open Policy Agent's Rego handles policy and access logic. JSON Logic and plain declarative YAML or JSON configs cover weighted scoring and threshold rules. Feature-store contracts pin transformation semantics. The common thread is that the logic is data, not code buried in an application. It's inspectable, diffable, and versioned.

‍

The harder engineering question is cross-node validation: how do you guarantee every participant is running the same contract? The techniques are familiar from software supply-chain security. Validate the contract against a published schema (JSON Schema, protobuf). Content-address it – hash the canonical form so each node can verify byte-for-byte that it's executing the identical specification, so a decision can later be tied to the exact contract version that produced it. Sign it. Version it immutably under semantic versioning so "the same contract" is an unambiguous claim. Run a shared conformance suite at each node so identical inputs yield identical outputs before anything goes live. None of this is exotic, but it's the part teams skip, and it's the part that makes a distributed decision reproducible instead of merely plausible. The point isn't merely to run the identical computation everywhere. It's to ensure that every participant can later prove why the result was produced.

‍

Federated Does Not Necessarily Mean Degraded

The objection I hear most is that distributing the computation must cost accuracy, that a federated result is an approximation of the "real" centralized one. That assumption is worth qualifying. For certain classes of deterministic computations – exact entity matching, weighted scoring against agreed thresholds – federated execution can be constructed to yield the same result as centralized execution. That's because the same versioned computation runs over the same inputs; distribution changes where the work happens, not the outcome. This is a bounded claim, not a universal one. Other privacy-preserving methods, including differentially private mechanisms, deliberately trade fidelity for protection, and an approach that compares lossy derived features (more on those below) is equivalent to a centralized computation over those same derived features, not over the raw records. 

‍

Within those bounds, you earn the guarantee by making the computation deterministic and verifying it by replay.

‍

Determinism across independent systems isn't free. Floating-point arithmetic, asynchronous processing, and silent model drift can all produce different answers from ostensibly identical computations. Production systems address this through canonical ordering, deterministic reductions, and version pinning, so decisions can be replayed later.

‍

That replay property is what lets you demonstrate equivalence rather than assert it. Run the same versioned contract over the same inputs six months later, and you should get the same result… and you can show whether you did.

‍

When identical logic runs against the same versioned inputs, it should produce identical output regardless of where it executes.

‍

More importantly, replay is not only a verification mechanism; it is the foundation of accountability in a distributed environment. It's the thing that lets a result be reconstructed long after it was produced.

‍

A related design choice makes this tractable: separate the probabilistic stage from the deterministic one. Let machine-learned models do what they're good at → high-recall candidate generation. Hand their output to a deterministic, decomposable scoring stage that makes the actual decision. The probabilistic part proposes; the deterministic part disposes. The decision that gets recorded is one in which every outcome can be decomposed into weighted contributions and replayed, while the model's role is bounded and explicit. In a similar vein, these systems should refuse rather than guess: when evidence is insufficient, abstain instead of interpolating, because in regulated settings an unverifiable conclusion is worse than no conclusion.

‍

Entity Resolution: One Worked Example

Entity resolution is a useful illustration because it's both common and measurable. But it's one instance of the pattern, not the whole of it. It helps to separate two distinct classes of cross-boundary computation that behave differently. One resolves whether records describe the same entity, matching. The other scores many heterogeneous signals into a decision or risk level – say, a utility weighing grid, weather, and demand signals to decide on load reduction. They have different fidelity and privacy properties, and conflating them is a common mistake; the example here is the matching class.

‍

Deciding whether two records refer to the same person, vessel, account, or device is something organizations constantly need to do together and often can't, because it means comparing identifiers. The federated version exchanges derived or encrypted information instead. Private set intersection lets two parties learn which entities they share without revealing the ones they don't. One-way derived features (phonetic encodings like Soundex, geospatial bucketing like geohash, temporal bucketing) let nodes compare on transformed values that don't expose the underlying records. Blocking and locality-sensitive hashing keep it feasible at scale. What crosses the boundary is a match, a confidence score, and the evidence for it. The records stay home, and either side can later reconstruct which contract version produced which match.

‍

That last point needs a caveat, because it's where naive implementations get people hurt: keeping raw records local is necessary for privacy, but not sufficient. Derived features and model outputs can themselves leak through inversion, membership-inference, and attribute-inference attacks. "Raw data stayed home" is the beginning of a privacy argument, not the end of one. Any production deployment needs an explicit threat model and leakage analysis, and where the analysis demands it, differential privacy, secure aggregation, or confidential computing layered on top.

‍

What's Still Genuinely Hard

This approach is not a solved problem, and it's worth being honest about where it strains. Cross-modality fusion – combining text, sensor, and geospatial signals into one decision – remains difficult. Restricted observability means each node sees only a slice, so global decisions are made on partial information, with all the bias and blind-spot risk that implies. Real-time coordination across nodes introduces latency that some missions can't absorb. Preserving consistency when systems change underneath you and reconciling genuinely conflicting signals across domains is unsolved in the general case. And federated settings have their own adversarial surface: data poisoning and Sybil-style participation that a centralized system doesn't face in a similar manner. Structured problems like entity resolution are tractable today; rich multi-source, multi-modal fusion is still an active research and engineering frontier.

‍

What Practitioners Can Do Now

A few things are defensible regardless of which tools you adopt. Stop treating centralization or a clean room as the default; start by asking what minimum information actually has to cross a boundary, and whether the computation can go to the data instead. Separate your probabilistic recall stage from a deterministic, auditable decision stage. Make your decision logic an explicit, versioned, schema-validated artifact rather than behavior implicit in an application. Design for replay and auditability from the beginning, because retrofitting them is far harder than building them in. Build in the ability to defer when evidence is thin. And start with structured problems before reaching for multi-modal ones.

‍

The mindset shift under all of it: the biggest mistake organizations make is treating governance as a constraint on collaboration. In distributed environments, governance is the mechanism that makes collaboration possible.

‍

The objective is not simply to compute across boundaries. It is to produce a result every participant can trust, reproduce, and defend. In a centralized architecture, trust is largely assumed because the data and the computation share one environment. In a federated architecture, it has to be engineered explicitly, and the ability to replay, verify, and attest to a decision becomes as important as the decision itself.

‍

Organizations need to be able to use AI to produce decisions that are consistent, reproducible, and defensible across data they do not own and cannot centralize. The challenge is making decisions that can be trusted.

‍

Author Bio

Chris Yonclas, CPO and Co-founder of Axonis (axoinis.ai), is a veteran intelligence systems architect with more than three decades of experience integrating fragmented data ecosystems and enabling evidence-based decision-making in complex government and enterprise environments.