CASK 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 CASK, 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 CASK 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 CASK 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
CASK 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 — CASK 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 — CASK 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 — CASK 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 CASK?
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 CASK train on my data?
No. CASK 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 — CASK does not use your data for training, and local models eliminate network egress entirely.
How is CASK different from a compliance chatbot?
A chatbot generates text. CASK 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. CASK 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 CASK was built within. CASK 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.