Silent Witness
On-device privacy inference for domestic violence survivors.
This project has different angles depending on who's looking. A hiring manager cares about PM methodology. An investor wants to understand founder thinking and market timing. An engineer digs into architecture and the multimodal constraints of on-device inference.
I respect your time. The teaser above is true for everyone. Pick your role, and I'll show you the version built for you.
Recruiter View
If you're sourcing or evaluating, you're looking at three things: problem selection, scope under constraint, and how frameworks outlast projects.
- How I filtered from dozens of "good problems" down to one where on-device inference is disqualified from use (not optional, not slow cloud).
- Framework-first thinking: a seven-filter rubric that my co-founder and I ran independently, converging on the same finalists.
- Killer assumption upfront: Can base Gemma 4 produce useful injury documentation from photos? Test it before you build the thing that depends on it.
- Full artifact chain: problem statement, capability map, build contract with acceptance tests, competitive analysis, system prompts.
Investor View
You're reading to understand founder thinking: how problems get chosen, how to separate signal from enthusiasm, and whether the architecture holds under real constraints.
- The deployment lock: why cloud AI is disqualified on sight (abuser monitoring the phone sees uploads, API calls, push notifications, detection triggers escalation).
- Regulatory arbitrage: because inference is local, HIPAA, CLOUD Act, and data-residency frameworks sidestep themselves.
- Founder insight: the protagonist is a person at 2 AM, whispering into their phone, needing the evidence to exist without the evidence existing. That clarity shaped every architecture decision.
- Market signals: 736 million people worldwide have experienced intimate partner violence. Prosecution faces 60 to 74 percent case dismissal rates due to missing evidence.
- Capital efficiency: what ships with hackathon resources in a 40-day sprint, and where money adds leverage vs. where it doesn't.
Engineer View
You're here for the architecture and the technical choices. This view is wired for depth: how constraint shapes solution, what Gemma 4 specifically enables, and where the hard problems actually live.
- Why on-device inference isn't just slow cloud, it's a different problem category entirely (zero HTTP requests, zero notifications, zero unusual storage signatures).
- Quantization strategy: Gemma 4 E2B at Q8 quantization is about 4.4 GB on a phone with 6GB+ RAM. Trade-offs at Q6 and Q4 tiers.
- Multimodal routing: vision for injury documentation, audio for testimony, text for safe entry. Why you need thinking mode for cross-incident pattern detection.
- Descriptive (not diagnostic) injury documentation from photos, on-device speech-to-text, pattern analysis across incidents, caseworker-style legal structure in 140+ languages.
- Build contract with binary pass/fail tests. The killer assumption: can base Gemma 4 produce useful injury documentation without fine-tuning? If yes, the architecture holds. If no, we scope to audio+text only.
Just here as a person
No pitch, no costume. You read the teaser, something landed, and you wanted to see what's behind it. That's enough of a reason.
- I built this because one survivor, at 2 AM, should be able to keep receipts without the receipts keeping her visible.
- It's a heavy problem. I'd rather talk about it honestly than wrap it in product copy.
- If you know someone this could help, or you want to push back on something I missed, that conversation is the whole point.
Let's Talk
The versions above are the most common approaches. But maybe you're reading this because the problem itself moved you, or you have a completely different angle on why this technology matters for this community. That's the conversation I actually want to have.
- Direct conversation gets you exactly what you need faster than guessing.
- Tell me what moved you. I'll respond with what's actually relevant.