Phase-1: Initial Setup for Water

[naman9271]

Hi @pradeeban and mentors,

I’m Naman Jain, currently contributing to Project 8 (xlnscpp: Support for Logarithmic Number Systems in Large Language Models).
I’ve completed LFX ’25 (CNCF) and GSoC ’25 with Jitsi, and I’m very interested in contributing to WATER due to its strong intersection with DevOps, distributed systems, privacy-first architecture, and hybrid cloud design and also want to extend my knowledge in this.

I’ve studied the project and drafted a Phase 1 execution plan to validate my understanding.

---

Phase 1- Edge Data Ingestion & Harmonization (Weeks 1–3)

Goal: Build a fully local, privacy-safe DICOM ingestion pipeline before introducing orchestration or cloud logic.

---

Week 1 - Simulated Hospital Setup

• Deploy Orthanc PACS (Docker)
• Write bootstrap_data.py to fetch anonymized CT/MRI scans from TCIA
• Push DICOM studies into Orthanc
• Validate local PACS simulation

Outcome: Reproducible, zero-PHI clinical data source.

---

Week 2 - Live DICOM Stream Capture

• Configure Niffler SCP Listener
• Implement C-FIND (study discovery)
• Implement C-MOVE (async retrieval)
• Validate ingestion reliability

Outcome: Realistic hospital-style DICOM ingestion flow.

---

Week 3 - Flatten & Enforce Privacy Gate

• Recursively parse DICOM headers
• Flatten metadata → JSON (MongoDB)
• Replace PHI tags with 128-bit UUIDs
• Store encrypted UUID mapping (AES-256 SQLite)
• Implement PHI validation gate
• Add audit logging + quarantine flow

Outcome: Zero-PHI metadata ready for Phase 2.

---

System Design of Water as per my Understanding

Phase 1 Implementation

I would really appreciate feedback on:

1. Whether this Phase 1 aligns with architectural expectations
2. Any compliance or scaling assumptions I may be missing
3. Where I can begin contributing immediately

Looking forward to your feedback.

• Naman Jain

[pradeeban]

@naman9271 as noted in the closed PR, the given worklfow examples (Niffler and CONTROL-CORE) were just two examples. The actual workflows maybe something entirely different. The goal is to build a framework that is agnostic to what is running on top of it, allowing various healthcare services to run in the compute continuum.

While we all appreciate all your excellent outstanding contributions, this approach (same comment I made to another applicant in this forum #1) is largely a misunderstanding of the goal.

I have also elaborated more on the closed PR. Hope that makes sense. Please let me know if you have more questions.

[naman9271]

@pradeeban Really sorry for the earlier misunderstanding, and thank you for clarifying.

From what I understand now, the goal is to build a foundational platform that sits beneath any healthcare workflow, completely agnostic to what runs on top. Whether it’s a DICOM pipeline, federated learning, or something else, the framework only handles where and how execution happens across edge and cloud, focusing on resource discovery, smart allocation, and decentralized execution. Am I understanding this correctly?

Based on that, I’m thinking of starting with a minimal foundation: a Python orchestration layer, a node registry for edge/cloud capabilities, a plugin-style workload interface, and a basic allocation engine with swappable policies. Each node would run a lightweight agent to execute and report tasks, keeping everything workflow-agnostic by design.

Would it make sense to raise a PR with just this foundational skeleton to ensure alignment first, or should I draft out the proposal before opening one?

[pradeeban]

@naman9271 your revised approach makes sense. But I believe PRs at this point are largely unrealistic since the actual implementation will be specific to the interpretation. You are free to create PRs to demonstrate your experience. But we will likely close the PR or tag it "on-hold" (the same approach we follow for the BHV project).

[naman9271]

Proposed Approach: WATER

Hey @pradeeban, @Chali-healthy, sorry for the confusion earlier, after researching the project more deeply, here's my refined approach.

My goal is to build WATER as a unified, platform-agnostic orchestration framework for hybrid-cloud and multi-cloud healthcare workflows. The core idea is a decentralized execution mesh where, instead of a centralized scheduler, nodes dynamically allocate workloads across the edge-to-cloud continuum, keeping sensitive patient data pinned to hospital edge nodes for compliance, while offloading heavy ML/AI compute to the cloud. Every workflow, whether a Niffler DICOM pipeline, a CONTROL-CORE model, or any other algorithm, is treated as a black-box OCI container, keeping the framework 100% tool-agnostic and fully aligned with WATER's goal of facilitating edge workflow execution rather than just decentralized storage.

---

Phase 1: Brokerless Telemetry & Node Registry (Weeks 1–3)

The goal of this phase is to establish the decentralized communication backbone. This involves setting up ZeroMQ PUB/SUB with async message handling, building a Python daemon using psutil and GPUtil to broadcast live structured telemetry (CPU, RAM, GPU, bandwidth), and implementing a gossip-style peer discovery protocol so nodes self-organize into a synchronized resource mesh with no central registry.

Phase 2: Agnostic Cost-Function Allocator (Weeks 4–6)

This phase builds the mathematical "brain" of WATER. The focus is on designing versioned YAML/JSON workload and node-capability schemas with a validation layer, implementing a cost-function engine (Total Cost = Transfer Time + Compute Time + Privacy Penalty) that hard-locks phi_present: true workloads to edge nodes, and stress-testing the allocator against concurrent mixed workloads to confirm correct, deterministic, sub-100ms routing decisions.

Phase 3: OCI Execution & Cryptographic Audit Trail (Weeks 7–9)

This phase proves the tool-agnostic container execution model and establishes a tamper-proof audit trail. It covers building a worker agent via docker-py that pulls images, mounts volumes, and runs isolated containers; wiring the full Allocator → Worker → telemetry feedback loop over ZeroMQ; and generating SHA-256 execution receipts (over logs, container ID, timestamp, and node ID) stored in a lightweight receipt store any node can query.

Phase 4: Real-World Integration & Demo (Weeks 10–12)

The final phase validates that WATER works beyond simulation. This includes packaging real Niffler and CONTROL-CORE workflows as WATER-compatible OCI containers, deploying the full system across a hybrid environment (local edge node + a cloud provider like AWS or GCP) to verify end-to-end routing under realistic latency, and delivering a CLI dashboard, developer documentation, and a recorded demo showing a sensitive DICOM task pinned to edge while an ML job is automatically offloaded to cloud.

[naman9271]

@pradeeban @Chali-healthy Would it make sense to raise a PR with just this foundational skeleton to ensure alignment first, or should I draft out the proposal before opening one?

[pradeeban]

@naman9271 As I noted above, I do not think a PR to an empty repository, especially in the context of GSoC, makes much sense. Your approach now makes more sense though.

[naman9271]

Thanks, @pradeeban Sir, for the thoughtful feedback. I’ll refine the proposal accordingly and share the draft over email soon.