Run your model on their data. See neither.

David Uzan · 14 August 2026

Some of the most valuable models in the world spend their lives locked in a drawer.

A bank's credit-risk model is the distilled result of years of lending history; the bank will not hand it to a fintech partner, because the model is the business. The fintech, meanwhile, holds exactly the customer data that model should be scoring, and won't share a single record of it, because regulation and customer trust say no. Both sides would profit from running the model on the data. Neither side will move first. So the deal doesn't happen, or it happens through a slow, legally exhausting arrangement that satisfies nobody.

The same standoff repeats everywhere a model and the data it should score live in different companies. A payment processor's fraud model and a merchant's transactions. A hospital's diagnostic model and another hospital's patient symptoms. An insurer's underwriting model and applicant records held by a data broker.

What Decision Tree Inference does

Decision Tree Inference is the JuLenny function that ends the standoff. One party brings a trained decision tree model. The other brings the data. The model runs on the data, and the only thing that comes out is the classification result.

The data owner encrypts its records locally with the JuLenny client and uploads only ciphertext. The model owner uploads its tree. The platform runs the model over the encrypted records, and the prediction comes out encrypted too, released only when the parties approve, to whoever the collaboration's visibility rules say should see it.

The data owner never reveals a single record. The model owner never reveals its thresholds, its features, its logic. And JuLenny sees ciphertext throughout: the joint key is split between the parties, so there is nothing we could read even if we wanted to.

How a model can run on data nobody can read

It's a fair question, because a decision tree is built out of decisions: if income is above this threshold, go right, otherwise go left. How do you take that branch when the income value is encrypted and nobody can look at it?

The answer is that the computation never looks. Instead of choosing a branch, the circuit evaluates both branches and blends them, weighted by an encrypted indicator of which way the comparison went. The math flows through every path of the tree, and the encrypted weights make the wrong paths contribute nothing. At no point does any machine learn which branch was taken, because the branch decision itself stays encrypted. This technique comes from peer-reviewed cryptography research, and it's a fixed, auditable circuit like every function in our signed registry: no logic can quietly change between runs.

You don't need to retrain anything to use it. Models come in from the tools data teams already use, scikit-learn and XGBoost among them.

Where this lands

Credit scoring: a bank scores a partner's customers without the partner exposing individual records, and without the bank exposing the model it spent a decade refining.

Fraud detection: a payment processor's model runs over a merchant's transaction stream. The merchant keeps its transactions; the processor keeps its detection rules. Fraudsters lose the gap between them.

Medical triage: one hospital's diagnostic model classifies another hospital's patient symptoms. No patient data leaves the second hospital's control, which is the difference between a compliance project and a compliance problem.

Insurance underwriting: an insurer's risk model scores applicant data held by a broker, without the broker seeing the model or the insurer seeing raw records.

The asymmetry that makes this one different

Our other launch functions are symmetric: two parties contribute the same kind of input and learn something about the overlap. Decision Tree Inference is asymmetric, and that's its power. One side has intelligence, the other side has information, and until now the only way to combine them was for somebody to surrender something. A model owner can now offer scoring as a service without ever shipping the model. A data owner can buy that scoring without ever shipping the data.

That's a new kind of commercial relationship, and we suspect our partners will find uses for it we haven't thought of. The math is the contract.

If you have a model that should be running on someone else's data, or data that someone else's model should be running on, get in touch.