Security & trust
How Invariant keeps your data separate, and shows you when its history has changed.
Hosting model, data segregation, and security posture.
Hosting model
Invariant is a multi-tenant cloud application. Your organization’s data is logically isolated from every other tenant.
Data segregation
Isolation is enforced by org-scoped queries plus a database row-level-security backstop, so a missing scope cannot leak cross-tenant data.
- aOrg-scoped access: every query is scoped to the authenticated user’s organization; the org is derived server-side from the session and cannot be spoofed by a client.
- bDatabase row-level-security (RLS) backstop: even if application scoping were missed, the database itself filters rows by organization and rejects cross-tenant writes.
- cTested: a repeatable isolation proof demonstrates that same-org reads succeed while cross-org reads/writes are rejected at the database layer — this is provided as validation evidence.
Security posture
- a Encryption in transit and at rest
- b Role-based access control with organization scoping
- c Tamper-evident, hash-chained audit trail
Audit trail & tamper-evidence
- a Each covered audit record is cryptographically linked to the previous one, forming a continuous per-organization chain from an initial anchor — so altering any earlier record breaks the chain.
- b Every actor type (human, AI, system) and a reason for change are captured.
- c A shipped verifier re-walks the chain and reports any break, identifying the first divergent row.
We say tamper-evident: a database owner can still physically change a stored row. Our claim is that such a change is detectable.
- a A one-click, auditor-facing chain verification demonstrates integrity on demand.
- b The qualification evidence exercises the same verifier the product runs — the qualified program is the program you use.
Event Log
Covered create, update, approval, e-signature, and status-change events are shown in order with timestamp, actor, action, affected record, and captured details. Regulated electronic records must be attributable and reconstructable (Who, What, When, Why) — this is the single place an auditor, or you, can trace any decision end to end.
Actor Types: Human, AI, System
Each entry is badged by who performed it — a named user, the AI quality layer, or an automated system process. Human entries show the user’s email. As AI participates in quality workflows, attribution can’t blur; separating human, AI, and system actions keeps accountability explicit and reviewable.
Verify Integrity
One click recomputes the stored chain and checks each covered row’s hashed content and linkage, reporting the exact row when a mismatch is found. A passing result demonstrates that the stored chain is internally consistent at that as-of time — it does not prove completeness against a privileged wholesale rewrite or tail deletion without an external anchor. Run verification during data-integrity review and retain the as-of result with other evidence; do not present a green result as a full validation or completeness conclusion.
Change Details
Each entry records the specific fields that changed, so you can see the substance of an edit — not just that one occurred. When reviewing a deviation or CAPA history, compare successive entries to confirm edits match the documented rationale.
Both figures are illustrations of a check we ran in a test workspace built for this, never against customer records.
Try the check on the homepageHow our releases are made
Our own releases go through written proposals, approvals and release notes, and an update adds to your existing records rather than rewriting them.
Unlike single-tenant on-prem, multi-tenant SaaS updates all customers together. Invariant addresses this with a release change-management process: versioned release notes, change classification, and per-release regression evidence, so you can perform a risk-based re-validation assessment. See the Validation Accelerator Pack (artifacts A7 and A10).
Validation & compliance