Claims a reviewer can verify, not adjectives.

Ivren reads interface configuration and message structure on the customer’s machine. Nothing is uploaded; there is no telemetry, no account, no phone-home. The console states it plainly: “Nothing is uploaded. The files are read in this process, on this machine.”

Passwords found inside imported engine exports are stripped at import and reported for rotation — they never render in the UI.

The message archive, when the engine runs interfaces, is the only component holding raw message content. It lives on the customer’s disk. Customer-managed storage with customer-held encryption keys (S3-compatible, envelope encryption) is built for it.

AI features are optional, off by default, and require the customer to supply their own model API key.

What may cross to a model: run metadata, counts, field paths (like PID-11), tokenised values, verdicts. What may never cross: raw or partial message content, untokenised values, free-text clinical fields.

Enforced by two independent gates — one before bytes leave the machine, one on the service side — both fail closed. Refusals never echo the refused value. The test suite includes canary tests that plant marker values and assert they can never reach an output.

• Deployment gate: missing evidence can never become PASS; production-class replay targets are structurally refused.
• Signed artifacts: licenses, gate decisions, and releases are signed with domain-separated keys — a signature for one purpose can never verify as another.
• Hash-chained, append-only audit logging with tamper detection, behind server-side role-based access control — every sensitive view and change recorded.

“We do not claim what we cannot prove.”

• Ivren is not a medical device; it makes no clinical decisions.
• We say Ivren is designed for HIPAA-regulated environments, with the specifics above that let a reviewer verify the design — never “HIPAA certified,” because no such certification exists.