A response to Ridhdhi Desai’s “Privacy Is No Longer a Requirement. It’s an Architectural Constraint” (HackerNoon, Aug 2026)
There’s a line in Desai’s piece that I underlined twice: privacy and accessibility aren’t policies you enforce; they’re constraints you design against, the same way you design against latency or memory. If they aren’t in the architecture, they aren’t in the product, no matter what the handbook says.
I run data protection and governance for a media network operating across most countries, under close to 300 different media regulations. I didn’t come to that sentence as a reader. I came to it as someone who has spent the last year rebuilding the actual architecture, not the metaphorical one, that’s supposed to make it true. So I want to sit with three of Desai’s claims and tell you where they hold up exactly, and where the real work starts once you try to operationalize them at scale.
Deletion is a graph traversal, not an API call
Desai is right that deletion is the place the illusion breaks first. Encryption is one write. Deletion has to reach backups, caches, indexes, derived aggregates, replicas, and anything trained on the record.
What I’d add is that this isn’t only a systems problem; it’s a governance problem hiding inside a systems problem. We recently rebuilt our retention program from the ground up, and the single hardest design decision wasn’t technical; it was definitional: reconciling what the organization is entitled to keep against what its systems are actually configured to keep. Those two positions drift apart constantly, and most retention policies never measure the gap — they just assert a schedule and assume compliance. We built reconciliation into the program as a first-class recurring activity, not a one-time audit finding. A retention period that was never checked against system capability isn’t a control. It’s a hope.
The other trap Desai doesn’t mention: legacy policy language often explicitly carves backups out of scope, “designated for operational purposes, not for data retention”, which is precisely backward from an architectural standpoint. If the record exists in recoverable form anywhere, the deletion obligation follows it there. Any retention or deletion program that doesn’t apply to every copy, including backups and derived data, is describing an intention, not a constraint.
The allowlist example is the whole argument in miniature
Desai’s twelve-line code sample- a telemetry event can only carry fields it declared; anything else fails the build- is doing more work than its length suggests. I’ve watched the failure mode he’s describing happen in production: a screen refactor flattens a data object, a field that used to stay client-side rides along into the analytics pipeline, and nobody notices because every functional test still passes. The bug isn’t in the behavior. It’s in the shape of the data nobody was asserting against.
The fix we ended up converging on independently is structurally identical to his: allowlisted telemetry enforced at build time, plus scanning in CI/CD before anything reaches a warehouse. But the part that took longer to get right wasn’t the enforcement mechanism; it was deciding that data-protection-by-design belongs inside the SDLC as a gate, not downstream of it as a review. Once privacy is a build gate instead of a pre-launch checklist item, the question stops being “did anyone catch this” and becomes “could this have shipped at all.” That’s the actual distinction Desai is drawing, and it’s worth being precise about: automating the invariant only works if you’ve first relocated where in the pipeline the check lives.
Accessibility’s blind spot is bigger than the UI layer
Desai’s screen-reader example: a button that renders correctly, passes every functional test, and announces nothing to assistive technology is a clean illustration of a contract gap: your tests assert behavior, but the thing that broke was semantics. Right diagnosis.
Where I’d extend it: at a media organization, that same gap exists one layer up, in content itself, and it’s less automatable than he suggests. We recently mapped our accessibility controls across the organization and found something structurally telling: every one of our product-facing accessibility controls existed and was testable exactly the way Desai describes: contrast, focus order, labels, dynamic type. But we had no equivalent control set for editorial accessibility: alt text quality, caption accuracy, and structural navigation through a long-form article for a screen reader. Those aren’t UI-tree assertions. They’re judgments about whether a description actually serves someone who can’t see the image, made at publication speed, at volume, across a newsroom. You can assert that alt text exists. You can’t yet assert that it’s good, the same way you can assert a field is on an allowlist. That’s the honest edge of “assert the tree, not the behavior”; it works beautifully for interaction semantics and runs out of road at content semantics.
Where the judgment actually goes
The piece closes on something I think is the most transferable idea in it: automation handles the rules, and you reserve human judgment for the exceptions; and that most teams have it backward, with humans re-checking known rules every release and nobody with the authority to catch what’s genuinely new.
That’s the design principle behind how we structured review authority across our own control framework: a tiered model where the bulk of recurring checks get validated through self-attestation and direct sampling, and the scarce resource, a person with real domain depth, gets reserved for determinations that have never come up before. We also drew a related line that I’d offer as a corollary to Desai’s: a statutory obligation can’t be risk-accepted. You can risk-accept exposure. You cannot risk-accept a decision not to comply. That distinction matters because “automate the invariant” only protects you if someone has already decided which invariants are non-negotiable inputs versus which are genuinely a judgment call about proportionality. Get that categorization wrong and you’ll either automate away discretion that needed a human, or route routine, well-understood checks to a reviewer who should never have had to see them.
The takeaway underneath the takeaway
Desai’s closing line is that trust is a property your architecture either has or doesn’t. I’d sharpen that one step further: trust is a property your architecture has only if someone is continuously reconciling what the architecture asserts against what it actually does. Every example above — deletion, telemetry, accessibility, review authority — has the same shape. The policy says one thing. The system does another. The gap is invisible until someone builds the mechanism to measure it. That mechanism is the real constraint. The checklist was never it.