Trust · Privacy
Privacy architecture
Privacy in OpenLegal is structural, not a setting. The system is built to assume the worst about itself: routing fails closed, unknowns are blocked, and nothing consequential leaves the local loop without passing a gate.
Fail-closed routing
Classify before you transit
Data is classified before any model routing decision. The classification is the first gate — no dispatch happens unclassified.
Route or refuse
If a provider’s privacy posture cannot be verified, the request is refused — it is never routed “best-effort.”
ZDR required
External providers must demonstrate a verifiable zero-data-retention posture. Until they do, OpenLegal reports them as UNKNOWN and keeps data local.
Local by default
The default state is LOCAL_ONLY: the loop runs, research and strategy proceed, and no external transit occurs until the operator explicitly enables a verified provider.
The honesty rule that matters
If a compliance property — like zero data retention — cannot be verified for a provider, OpenLegal labels it UNKNOWN. It does not pretend to be compliant. This is the fastest path to privacy trust and the exact behavior a legal practice needs.
Every action is gated and traceable
Human approval
Drafts, approvals, and pause/resume live in an operations gate. The loop can propose; only a human disposes.
Provenance on events
Each realtime event carries a provenance record, so every piece of matter state can be traced to where it came from.
Hash-only audit
Model invocations are recorded as hash-only audit entries — no raw content, prompts, or secrets are persisted.
Auditable loop
Audit, memory, and checkpoints close the loop, giving an operator a defensible record of what the system did and why.
Boundaries
This page is the public conceptual boundary of OpenLegal’s privacy story. It describes the architecture and principles — it intentionally contains no credentials, no configuration, no runtime state, and no case data. The per-installation privacy posture is available from the application itself: