Why I built Vivari Guard

I have spent most of my career on systems where a wrong change is an incident. I led a 12-person team to ship a SaaS XDR security platform designed for hundreds of millions of telemetry sources. I led financial-crime engineering at a fintech: fraud detection, KYC, and real-time decisioning, where a bad call locks someone out of their own money or waves fraud through. In both worlds, code that worked on the happy path was the easy part. The hard part was proving what changed, that it was allowed to, and that you could undo it before it hurt someone.

Then AI agents arrived in the codebase, and I watched the same class of change get made faster than anyone could review it. Agents now touch the migration, the auth path, the config that quietly governs who can see what. That speed opens an accountability gap. The tooling I saw filling that gap answered a risky change with another model's opinion, and shipped your code out to a service to be judged. For the systems I have worked on, neither is acceptable.

Vivari Guard, the deterministic review engine, comes out of the systems I have shipped: a security platform built for telemetry from hundreds of millions of sources, and fraud, KYC, and real-time payment decisioning at a fintech, where a wrong change is an incident.

That is why Guard is built the way it is. Deterministic, because a review you cannot reproduce is a vibe, and a vibe does not hold up when someone asks why a change shipped. Guard scores a change across 17 weighted signals with no LLM in the safety call, so the same change always gets the same verdict, and you can read exactly why. Local-first, because your code never leaves your machines: it runs on your hardware, with no cloud dependency, and nothing gets shipped out to be judged. I wanted the tool I would have trusted in the rooms where I have had to stand behind a change.