Engineering Notes

Why On-Device: The Privacy Tradeoff Behind SentinelEdge

March 2026 · ~3 min read

The easy version of SentinelEdge sends call audio to a cloud model. It would have been faster to build, easier to make accurate, and easier to demo in a hackathon's single day. We didn't build that version, and the reason is the whole point of the project: the people most likely to be targeted by phone scams are often the least equipped with technical defenses, and asking them to trust a cloud pipeline with their call data is exactly the kind of tradeoff they shouldn't have to make.

So the constraint came first: nothing leaves the device. Everything else — model choice, architecture, even how we scoped the day — got decided in service of that constraint, not around it.

A constraint you design for beats a constraint you retrofit

Privacy-by-retrofit usually looks like: build the cloud version, then figure out what has to change to make it "private enough." Privacy-by-design meant the model had to be small enough to run on a phone from the start, which ruled out entire classes of architecture before we ever wrote code. That's a harder starting line, but it means the final system doesn't have a false floor of "private, except for the parts we didn't get to."

Federated learning as the answer to "but how does it improve?"

The obvious objection to on-device-only: how does the model get better over time without seeing real data? Federated learning updates were our answer — the model improves from aggregated, on-device learning signal without any raw transcript ever being transmitted. It's a more complex answer than "just send us the data," and choosing the complex answer was the actual bet of the project.

The takeaway

Judges in AI hackathons see a lot of cloud-first demos. What made SentinelEdge stand out wasn't a bigger model or a slicker UI — it was that the hardest constraint in the room became the reason the project existed at all. I've started asking, on every project since, whether there's a constraint I'm treating as a limitation that should actually be the design driver.