Thinking out loud
on ML, privacy & AI systems.

The distinction matters because retrofitted privacy and designed privacy have fundamentally different threat models. When you add DP after training, you're protecting against post-hoc inference attacks on the final model. But the training process itself — gradient exchanges, intermediate checkpoints, the server's view of client updates — remains unprotected.

Real privacy-by-design starts at the data partitioning stage. It asks: what does the server need to learn? In federated settings, the answer is almost always "less than you're currently sending." Aggregation protocols like DP-EMAR that I've worked on try to enforce this at the weight level — repairing model weights without ever exposing raw gradients.

The engineering tradeoff is real: ε-DP bounds get worse as you apply them earlier and more aggressively. But accepting a slightly worse bound in exchange for a fundamentally better threat model is usually the right call for production systems.

In standard federated learning, you average model weights. The implicit assumption is that the weight space is Euclidean — that a convex combination of two good models produces a model that's at least as good as either. This assumption is shaky even for MLPs, but for GNNs it breaks harder.

GNN weights learn relative to graph topology. A node embedding layer trained on a dense social graph is doing something structurally different from the same layer trained on a sparse citation graph, even if the weight matrices look numerically similar. Averaging them in weight space doesn't preserve the geometric structure either learned — it destroys it.

My work on this proposes coherence-aware aggregation: instead of averaging in weight space, we project to a shared geometric manifold first, aggregate there, then project back. The result is a global model that preserves local geometric structure far better than FedAvg baselines, especially under high client heterogeneity.

The most operationally significant difference: GDPR assumes consent is granular and withdrawable at any point. DPDP shares this principle but introduces the concept of "deemed consent" for certain public interest purposes — which creates ambiguity for agentic AI systems operating over national data infrastructure.

For Anumati, the system I'm building at IIIT-B, this ambiguity is the design problem. When a citizen interacts with a government data system, there are often multiple layers of consent involved — some explicit, some implied, some delegated. An NLP-driven consent management layer needs to model all of these simultaneously and surface conflicts to human reviewers.

The engineering pattern that's emerging: treat consent as a graph, not a boolean. Each data access request traverses a consent graph where nodes are data categories and edges are delegation relationships. An access is permitted only if a valid path exists from the request origin to the data category under the applicable regulatory regime.

The noise that makes NISQ devices frustrating for general quantum computation is actually useful in some federated learning contexts. Native quantum noise can serve as a physical randomization layer — a form of "hardware differential privacy" that's harder to remove than software-applied noise.

The catch: you need the aggregation protocol to be noise-resilient rather than noise-free, which means redesigning the aggregation step to extract signal from noisy quantum circuits reliably. That's the core of the NR-QFL work from WinTechCon 2025.

Current NISQ devices (20–100 qubits, gate fidelities around 99–99.5%) are useful for small aggregation tasks — think 10–20 client federated settings with shallow aggregation circuits. Not production-scale yet, but the trajectory is clear.

The honest answer is: it's sustainable until it isn't, and the line is thinner than I expected. The OMSCS program forces breadth in a way that pure research roles don't — you're not just reading adjacent literature, you're producing deliverables in it. That's good for generating ideas and terrible for going deep.

What actually worked: treating each thread as a 2-hour minimum context-switch. Anything less and you're just reading your own notes and not actually thinking. The morning is for the hardest thread, afternoon for communications and reviews, evening for lighter reading across threads.

What I'd do differently: commit to one publication per thread per year at most. I over-submitted in 2026 and it showed in review quality — some of those papers needed another month of work that I didn't give them because I was threading too many needles at once.