About
temper.ai is founded by a Stanford-trained mathematician with 26 years in defense and the FBI.
The founder
Our founder is a Stanford-trained mathematician and engineer who spent 26 years building, hardening, and operationalizing safety-critical systems — U.S. Navy submarine combat systems, FBI cybersecurity architecture, and international telecom security standards (ETSI NFV, 3GPP SA3, SA3-LI). They founded temper.ai to bring that operational rigor to AI risk management, because the organizations that can't afford to get it wrong are the ones we serve.
When you spend that long watching systems fail — and fail in ways their designers never imagined — you develop a bias: toward controls that are structural, not bolted on; toward mechanisms that can be audited and reasoned about; toward treating AI as infrastructure that must be governable by design, not just governed on paper.
Credentials
- SAM.gov Registered
- NAICS 541715 — R&D, Engineering & Life Sciences
- NAICS 541511 — Custom Computer Programming Services
- NAICS 541512 — Computer Systems Design Services
- NAICS 541690 — Other Scientific & Technical Consulting
- TS/SCI · CI Polygraph
Government Trust Posture
Government and defense-adjacent work requires more than stated intent. The following frameworks govern how we design, document, and govern AI systems at temper.ai. We publish what we've done, and are transparent about what's in progress.
Documents
Our Framework
Most organizations treat alignment, safety, and security as a single undifferentiated concern. They map to different disciplines, different tooling, and different success metrics. A mature program names them separately, runs them separately, then stitches the results into a coherent assurance posture. Anything short of that is theater.
The concept of intent is the scalpel that separates them:
Alignment — is the system trying to do the right thing? If it fails by design, that's an alignment failure.
Safety — even when it's trying, can it still cause harm? If it fails by accident, that's a safety failure.
Security — can someone make it cause harm on purpose? If it fails on command, that's a security failure.
The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong, it usually turns out to be impossible to get at or repair. — Douglas Adams
Decades of work on safety-critical systems — submarines, telecom, FBI infrastructure — teaches the same lesson every time: systems designed without adversarial thinking eventually get exploited, and systems designed without structural constraints eventually drift. You can't bolt safety onto a fundamentally unsafe architecture after the fact, in submarines or in AI.
That conviction is also why Turing, our SNN research demonstrator, exists: as a working argument that safety can be structural rather than trained-in. It's the same conviction behind Temper Enclave — when the finding is a data-sensitivity risk, we don't just tell you to write a policy about it, we design and build the architecture that removes it. One thing is certain: AI will become. The only question is whether we make it, or merely let it.