GSoC 2026: Pluggable allocation policies + audit trail — design question on east/west data transfer

[web1havv]

Hi @pradeeban and mentors,

I've been studying the project and the ongoing discussions carefully. Here's what I built before sending the proposal:

1. A WorkflowIntent schema — researchers submit a YAML file declaring privacy (strict-local / edge-only / public), latency (interactive / batch / best-effort), and compute (cpu-light / cpu-heavy / gpu-required). WATER decides where each step runs. No pipeline-specific logic anywhere in the framework.

2. A pluggable SchedulingPolicy interface with filter() and score() methods. filter() enforces hard constraints — privacy: strict-local removes cloud nodes from the candidate set entirely before scoring begins, not as a penalty. Three built-in policies: PrivacyFirstPolicy, LatencyOptimizedPolicy, DefaultPolicy. Swapping policy requires zero changes to the scheduler core.

3. A NodeAgent daemon that runs on each compute node, registers itself with the controller, and sends live CPU/RAM/GPU telemetry via outbound-only HTTP. No inbound ports required — works behind hospital NAT and firewalls naturally.

4. A Simulator that runs the full allocation engine on synthetic node fleets with no real Docker or SSH. You can validate that strict-local enforcement holds and compare policy trade-offs before touching a live network. Includes report.assert_privacy_respected() as a CI-safe invariant check.

5. A SHA-256 hash-chained audit trail — every step execution produces a receipt chained to the previous one. verify_chain() detects any tampering. Each receipt captures node ID, image, exit code, timestamp, and a snippet of output — addressing the tamper-evident audit log requirement for PHI-adjacent processing.

6. Three example workflows — medical imaging (strict-local, GPU inference), genomics variant calling (cloud-offloaded, public data), and federated learning across three hospital sites where only model weights cross site boundaries and each training step is hard-pinned to its local zone. No Niffler or CONTROL-CORE specific code in the framework itself.

Fork with 71 tests passing: https://github.com/web1havv/WATER

My specific question is for the federated case where weights need to move from hospital edge nodes to a coordinator - is rsync over SSH acceptable as a baseline for the satellite/WAN links in remote Alaska, or would an object-store approach (S3-compatible) be more realistic for that deployment context?

[pradeeban]

@web1havv As a new project, there are many right answers. Whatever approach you choose, please justify it in your proposal. After all, the proposals are getting evaluated. :)