Federated active learning across multi-site wet-labs

Abstract

Multi-site drug-discovery customers cannot pool raw experimental data across their sites — for compliance reasons, sovereignty reasons, or because individual sites are organised as separate legal entities. The default behaviour of running one independent campaign per site loses the cross-site information; running one centralised campaign loses the data sovereignty. We describe how federation in the autonomous-lab runtime ^[1] resolves the dilemma: each site keeps raw data on its own infrastructure; aggregated model updates flow between sites through secure aggregation; the active-learning planner ^[2] has visibility into per-site instrument capabilities and queue depth without ever seeing the per-site measurements. We document the architecture, the per-site policy enforcement, the instrument-aware planning, and the latency cost — federation closes the active-learning round in roughly twice the time of a single-site equivalent but achieves ~30% faster time-to-measured-lead on simulated multi-site benchmarks.

1. The multi-site problem

Some customers run multiple wet-labs in multiple jurisdictions. Their drug-discovery programmes don't naturally pool their data — sometimes because the sites operate under different regulatory frameworks (one site is GxP, another is research-grade), sometimes because cross-border data transfer is constrained, sometimes because the sites are organised as separate legal entities for tax or partnership reasons.

The default operational response is to run independent campaigns per site. Each site's active-learner ^[2] gets its own measurements, builds its own posterior, picks its own next batch. This works site-by-site and loses cross-site information: a compound series that is producing strong signals at site A could inform what to make next at site B, but the signal cannot travel because the raw data cannot.

The alternative is to push all the raw data into a central environment and run a centralised campaign. This solves the information-sharing problem but creates a sovereignty problem. Regulators dislike it, partnership contracts often prohibit it, and customers in regulated environments often cannot deploy it. The right architecture sits between the two extremes.

2. What federation does

Federation in the autonomous-lab runtime ^[1] lets a campaign treat multiple physical sites as one logical lab — without aggregating raw data centrally. Each site keeps its data on its own infrastructure; the model gets shared updates via secure aggregation; the active-learning planner has visibility into every site's queue depth and instrument capabilities, but not into the raw measurements those instruments produced.

Concretely, the architecture is: per-site runtime instances ^[3] connected by a federated control plane. Each site runs its own complete agent runtime (memory store, capability gating, instrument drivers, audit traces). The control plane mediates cross-site communication. Per-site state is durable in the site's infrastructure; cross-site state is durable in the control plane but contains only aggregated and metadata-level information.

From the chemistry team's perspective, the campaign looks unified. The active-learner proposes a batch; the planner picks where each compound is made and where it is tested; the runtime executes; the results inform the next round. The federated boundaries are invisible at the campaign-decision level and respected at the data-access level.

3. Per-site policy

Policy is per-site, not global. A site that is GxP-compliant runs the strict policy; a site that does only fragment screens runs a lighter one. The runtime enforces the strictest applicable policy when an action involves multiple sites — e.g. when a compound made at one site is shipped to another for an assay, the receiving site's policy must approve the receipt and the sending site's policy must approve the dispatch.

Policy composition follows the join-of-strict rule. An action that crosses two sites is subject to the union of restrictions from both. This sometimes produces actions that neither site alone would have blocked but the combination does block; we document this explicitly in the operator console so customers can see why a cross-site action is failing and decide whether to relax one of the contributing policies.

Capability gating ^[4] is per-site for site-local actions and per-action for cross-site actions. A compound dispatch from site A to site B requires an explicit `cross-site.dispatch` capability grant at both sites; the grants are independent and revocable. This is what makes federation defensible under audit — every cross-site action has a documented authorisation chain on both ends.

4. Secure aggregation

Model updates flow between sites through secure aggregation. Each site computes its local update from its own measurements; the local updates are encrypted with per-site keys; the control plane combines the encrypted updates into a single global update that the sites can apply locally; no site sees another site's raw update or measurements.

The underlying cryptography is standard. We use a threshold-based secure-aggregation scheme well-characterised in the federated-learning literature. The protocol is auditable; customers can verify the construction, and we publish the details under NDA to academic groups working in the area.

What is aggregated: gradient updates to the active-learner's posterior, decision-level metadata about which compounds were picked and why, and aggregate statistics about the readouts (without the readouts themselves). What is not aggregated: raw assay results, structural details of individual compounds, plate logs, chain-of-custody records, or any data the customer's policy classifies as sensitive.

5. Instrument-aware planning

The planner respects which assays can be run at which sites. A high-content imaging assay at the imaging-equipped site, an in-vitro binding assay at the biophysics-equipped site, a kinetic solubility measurement at the analytical site. The active-learner picks compounds; the planner picks where they're made and where they're tested.

The planner has access to per-site state — current queue depth, instrument availability, reagent inventory, scheduled maintenance — but not to raw measurements. It picks site-routing decisions to minimise cycle time while respecting per-site capacity and policy. The decisions are visible to operators at each site, who can override if site-local factors (e.g., a scientist's unscheduled absence) make the planner's allocation suboptimal.

Cross-site logistics — shipping a compound from one site to another for assay — are tracked in the chain-of-custody ^[4]. Each side of the shipment is recorded with the corresponding authorisation chain. Shipping cost and lead time are inputs to the planner's cost-aware acquisition ^[2]; a compound that requires an expensive cross-site shipment is preferred only when its expected information gain justifies the cost.

6. What is and isn't shared

The boundary matters in practice; we document it explicitly.

• Shared: aggregated gradient updates to the active-learner's posterior; decision-level metadata about which compounds were picked and why; aggregate statistics about per-site readouts (counts, distributions over scored properties); cross-site logistics records (shipments, custody transfers).
• Not shared: raw assay results from any individual site; per-compound structural identities (a compound made at site A is identified across the federation by an opaque token, not by its structure); plate logs and instrument-level telemetry; customer-tagged sensitive metadata; readouts that the customer's policy classifies as confidential.

The boundary is enforced at the storage layer rather than at the application layer ^[4]. The control plane's API simply does not have endpoints that would return raw site-local data; the per-site runtime checks the requesting principal's scope before returning any record. Bugs at the application layer cannot leak data because the data is not reachable.

7. Cross-site benchmark

We benchmarked federation against single-site equivalent campaigns on a set of simulated multi-site discovery scenarios. The simulation captures realistic per-site capacity and instrument heterogeneity (three sites with different assay capabilities, different per-site throughput, different reagent inventories) and a target compound space drawn from public chemistry databases.

On the benchmark set, federated campaigns hit measured leads roughly 30% faster than the best single-site equivalent. The improvement is driven by two factors: (a) the planner can route each experiment to the site where it runs fastest given current queues, and (b) cross-site information flow reduces redundant exploration in the early rounds.

The improvement varies with the heterogeneity of the sites. For homogeneous sites (matched capacity and capability) the gain shrinks to roughly 10% because the routing benefit is minimal. For heavily-heterogeneous sites (one site can do imaging, another cannot) the gain is larger because the planner can keep all sites near capacity.

8. Where it falls down — the latency cost

Federation adds latency. The active-learning round closes in roughly twice the time of a single-site equivalent, because the planner has to wait for the slowest site's local update to complete before secure aggregation can produce the global update. Total round-trip time is dominated by the slowest site.

For fast-cycle programmes (rounds closing in days), this is material — the federation overhead doubles the time-per-round and only the ~30% time-to-lead improvement justifies the architectural cost. For slower programmes (rounds closing in weeks, where the binding constraint is bench throughput rather than model decision), federation comes out ahead unambiguously.

We document the cost explicitly during deployment and let customers choose. Some multi-site customers run federated campaigns for high-value programmes and single-site campaigns for fast iteration on individual chemotypes; the two modes coexist in the runtime and the choice is per-campaign.

9. Limitations

Three meaningful limitations. First, federation depends on each site having sufficient capacity to absorb its share of the campaign — federation cannot rescue an under-resourced site. Second, the secure-aggregation protocol assumes a threshold of honest participants; cryptographic failure scenarios exist and we document them in the protocol specification under NDA. Third, latency scales with the slowest site; sites with poor connectivity to the control plane can degrade the whole campaign and we recommend customers monitor per-site round-trip times.

Reproducibility: the simulated multi-site benchmark is open under the Research tier. Customer-campaign details are not shareable; aggregate performance numbers are.

10. Conclusion

Multi-site customers can run unified active-learning campaigns without pooling raw data. Federation in the autonomous-lab runtime ^[1] makes this possible: per-site policy separation, secure-aggregation of model updates, instrument-aware planning that respects per-site capacity, and explicit boundaries on what is and is not shared. The cost is roughly 2× per-round latency; the benefit is roughly 30% faster time-to-lead on heterogeneous multi-site benchmarks. The architecture is one of the load-bearing pieces of the autonomous-lab story for customers who cannot use centralised solutions.