Architecture Proposal

[SIDDHANTCOOKIE]

Hi @pradeeban and other mentors,
I was exploring this project and would like to propose an allocation-first approach for the core architecture

My idea is to primarily on a lightweight, decentralized routing and execution layer.

To keep the platform truly tool-agnostic out of the box, the core framework would feature:

• Standardized workflow descriptors: A universal schema defining compute needs, latency tolerance, privacy levels, and data size.

• Cloud node modeling: Dynamic telemetry of node capabilities (CPU, memory, bandwidth, utilization, constraints).

• Data-Gravity & Privacy-Aware Routing: A heuristic engine that treats data movement costs and healthcare compliance as first-class citizens. Instead of just looking at CPU load, it ensures sensitive, high-volume data is processed locally (Edge), while intelligently stripping, anonymizing, or splitting non-sensitive compute fragments to be offloaded to the cloud.

• A multi-factor execution engine: The intelligence layer that evaluates the descriptors, node models, and privacy constraints to finalize whether to execute locally, offload to the cloud, or split execution.

By decoupling the execution logic from specific data pipelines, WATER will be able to intelligently handle arbitrary healthcare workflows (ML models, AI pipelines, etc.) securely and efficiently.

I've always been drawn to the architecture of decentralized systems; I love how they democratize resources and distribute trust rather than relying on centralized bottlenecks.

I’d love to get your thoughts on this, does starting with this generalized, privacy-aware execution platform align well with the project's ultimate vision? If it aligns I can start to set up a base for this approach.

[pradeeban]

@SIDDHANTCOOKIE I actually like this approach. You are really following a platform-agnostic approach, just the way @Chali-healthy and I were discussing recently.

[SIDDHANTCOOKIE]

@pradeeban yes it was supposed to be that and one more question should I start with some basic implementation in this project during this current application period or just proceed with drafting the proposal?

[pradeeban]

A proposal draft sounds like a better strategy to me.

[SIDDHANTCOOKIE]

Aight:) thank you so much!

[thedevyashsaini]

hi @pradeeban @Chali-healthy

the allocation-first direction makes a lot of sense.. from the discussion it seems the core of WATER is really the decision layer - determining where a workflow should execute across edge and cloud nodes while staying agnostic to the actual pipeline being run.

I've previously worked on a distributed benchmarking pipeline where a controller schedules containerized workloads across multiple worker nodes (this work was recently accepted at IEEE ReACS)... so the orchestration aspect here is particularly interesting to me

just to confirm my understanding,, the goal would be for WATER to primarily handle allocation and routing -- while the actual execution can be delegated to existing runtimes on the node (containers, workers, etc.), rather than WATER implementing a full workflow runtime itself, rit?

would love to know if that aligns with the intended direction

[pradeeban]

@thedevyashsaini sounds about right. WATER being an abstraction layer and starting from that... Handling everything end-to-end will be over-ambitious. Might be logical to have the allocation and scheduling/routing through WATER and perhaps have some sample applications (docker, VM, ...) as a starting point is a likely route.

[SIDDHANTCOOKIE]

@pradeeban @Chali-healthy I've mailed you my GSoC 2026 proposal draft and cc'd other mentors as well. Awaiting your valuable feedback!