Compute-to-data: send the algorithm to the data instead of the data to the algorithm

The usual way to analyse someone's data is to get a copy of it. Compute-to-data inverts that: the analysis travels to where the data sits, runs there, and only the result comes back. The data never moves and the analyst never holds it.

Pod does not do this. Nothing on this surface runs submitted code against stored data, and this page exists to explain a mechanism rather than to claim one.

The problem it solves

Two parties want something from each other and neither can give what the other asks for.

A researcher needs to train on a hospital's records. The hospital cannot hand them over. A model builder wants a bank's transaction history. The bank cannot release it. In both cases the blocker is not price or willingness, it is that copying the data is the thing nobody is allowed to do.

Compute-to-data removes the copy from the transaction. The algorithm is submitted, it executes in an environment the data owner controls, and what leaves is the output.

How it works in practice

The owner publishes a description of a dataset without publishing the dataset. A consumer submits a job. The job runs in an isolated environment beside the data, and the result is returned.

Two things make that safe enough to be useful, and both are non-obvious.

The job is confined. No outbound network, no arbitrary file access, a fixed runtime. Otherwise the algorithm just uploads the data somewhere and the whole arrangement is theatre.

The output is constrained. A model summary or an aggregate leaks far less than raw rows, but it leaks something, and a sufficiently clever job can reconstruct individual records from outputs that look harmless. This is a known and unsolved-in-general problem, and it is why serious deployments review what jobs are allowed to return rather than trusting the sandbox alone.

Why a pod is not this

A pod is storage with permissions. It answers which agent may read a resource. Compute-to-data answers a different question: what may an agent learn from a resource without reading it.

Those compose in principle. A pod could hold the data and an execution layer could run beside it, with the pod's permissions deciding which jobs get to see what.

Nobody has built that here. Pod has no compute surface, no job submission, no sandbox, and no policy for what a result may contain. The absence is checkable: pod's route modules expose eight GET and five POST handlers, and none of them executes submitted code.

The honest reason it is not on our roadmap

It is a much harder problem than the one we have not finished.

Running untrusted code safely beside sensitive data is a specialist discipline with a long history of sandbox escapes. Deciding what an output may reveal is an open research area.

Saying that is not modesty. It is the correct order of work.

Where to go if you need it

The project our notes credit as the implementer has built compute-to-data alongside its data-token model, and our own rating of it as mature and well engineered is theirs rather than ours to dispute. Federated learning and trusted execution environments answer overlapping versions of the same question from different directions.