Compass exists because the people who built it have done the work it aims to replace. The founders served as DPO, security head, and engineering lead at organisations where compliance was a live operational concern — not a consulting exercise. The product philosophy comes from that experience: trust work should be provable, not plausible.
The Scramble We Lived
Before Compass, the founders worked at organisations where compliance operated the way it does at most companies: evidence in spreadsheets, policies in shared drives, questionnaires answered from memory, and every audit cycle starting from the last email thread instead of the last audit.
The scramble is the pattern everyone in compliance recognises. A customer sends a security questionnaire, and three people spend two days gathering evidence that exists but is not organised. An auditor asks for an access review log, and the control owner searches six months of email to find it. A regulator requests a policy version, and the compliance team discovers the current version was never approved.
These are not tooling gaps. They are operating-model gaps. The work exists; the trail does not.
Why We Build for Skeptical Operators
Trust professionals are paid to be skeptical. A compliance tool that expects blind trust from its users — "just accept what the AI generates" — misunderstands the job. The user's job is to verify, approve, and take responsibility for every output.
Building for skeptical operators means:
- Every claim a tool makes must be verifiable — citations are not optional, they are structural
- Every output must pass through a human review gate — nothing leaves the workspace unapproved
- Every limitation must be stated — what the tool does not do is as important as what it does
A tool that hides its uncertainty — that fills gaps silently and produces polished output without requiring verification — is not built for trust professionals. It is built for people who do not have to defend the output.
The Three Commitments
Three commitments guide every product decision. They are not marketing lines — they are constraints that shape what Compass will and will not do.
Evidence Before Claims
The agent reads the workspace and produces output only from what it finds. If the evidence does not support a claim, the agent marks it as unsupported — "Not Provided / no source found" — rather than inventing an answer.
This commitment means Compass will never produce output that is faster to generate than to verify. A gap surfaced in the output is a gap the team can close before the auditor finds it.
Approval Before Record
Nothing the agent proposes becomes part of the permanent record until a human accepts it. Every proposal is a pending change — visible, reversible, and attributable to the agent run that produced it. The accept or reject action is logged.
This commitment means the human stays in the decision loop even at speed. The agent handles the drafting, reading, and mapping. The human handles the judgment.
Control Before Scale
Compass is local-first, BYOK, and telemetry-off-by-default because the team believes that trust tools should not require trust in a vendor's infrastructure. The most sensitive data an organisation produces — its policies, evidence, risk registers — should not depend on a cloud provider's security posture.
This commitment limits some capabilities today. There is no shared dashboard, no cloud-hosted workspace, no SaaS deployment. Those limits are deliberate. Scale that requires compromising on data control is not scale worth pursuing for trust work.
What We Deliberately Won't Do
The product boundaries are as important as the features:
- Auto-submit without review — Compass will not produce output that bypasses human approval. Even if the user instructs it to "just fill everything in," the agent blocks the instruction and surfaces the gate.
- Upload data to train models — Compass does not train on user data. The workspace is local. The model provider sees only the content of the current agent run through the user's own key.
- Claim general-AI versatility — Compass is not a chatbot, a writing assistant, or a general productivity tool. It is built for compliance work and optimised for that domain. It will not answer general questions, draft marketing copy, or assist with non-compliance tasks.
These boundaries are not gaps to be filled in a future release. They are choices.
FAQ
Who built Compass?
The team includes a former DPO (Arvind Subramaniam, CEO), a former enterprise security head (Pawan Raviee, CPO), and a former blockchain and cyber defence engineer (Sachin Kamath, CTO). All three worked in organisations where compliance was a live operational concern, not a consulting exercise.
Why local-first instead of SaaS?
Because the most sensitive data an organisation manages — policies, evidence, risk registers — should not require trusting another vendor's cloud infrastructure. Local-first means the data stays on the user's machine, telemetry is off by default, and the user controls where their data lives.
Does Compass train on my data?
No. Compass is a desktop application. Your workspace files are stored locally. When you use a cloud model through BYOK, that provider sees only the content of the current agent run — Compass does not use your data for training, and local models eliminate network egress entirely.
How is Compass different from a compliance chatbot?
A chatbot generates text. Compass produces cited, reviewed, and approved artifacts. Every output traces to a source, passes through a human review gate, and leaves an operation log. A chatbot is a generator. Compass is a harness around generation that enforces grounding, citation, and approval.
The three commitments — evidence before claims, approval before record, control before scale — are not features on a roadmap. They are the constraints Compass was built within. Compass by Truvara is a local-first, BYOK, human-approved compliance workspace where agents handle the work and humans keep the judgment. Read our story. Join the waitlist.