What protects your data — and what we don't claim.

Roster, activity entries, configuration, meetings, coaching and follow-ups are held in the browser's local storage on the device where they were entered. There is no server copy of that data yet; the built-in backup export is the copy you control, and the product tells you to take one regularly.

Sign-in, organization membership and the vertical catalog live in the Orvik platform database, isolated per organization as described below.

The tenant schema, roles and isolation tests below already exist for it; the product's writes are being cut over path by path. Flow's current build likewise keeps its data in the browser; its production service is not built yet.

Isolation is enabled and forced in PostgreSQL. A query with no organization context returns zero rows; a known row of another tenant reads as absent.

Every tenant foreign key carries the organization on both sides, so a cross-tenant reference is impossible to write, not merely unlikely.

The isolation tests enumerate the database catalog rather than a list of known tables, so a table added later without protection fails the suite.

The server performs the OAuth code exchange with PKCE and state validation and seals the session into an HttpOnly cookie. Browser JavaScript never holds an access or refresh token.

Credentials are handled by the identity provider. Orvik maps the provider's subject to an internal identity; it never adopts the provider's id as its own.

Return paths are validated by a whitelist of shape and re-serialized from a parse; state-changing requests are checked against the configured origin.

Which organizations a person belongs to, and with what role, lives in Orvik's own database under row-level security — not in the vendor.

The application role has column-scoped grants and no table-wide write on history; organization creation is a narrow, separately-credentialed capability the application role does not hold.

Effective-dated history tables have no update or delete path at any depth, and audit fields cannot be forged by a client.

Managers, reps and admins see different surfaces of the same data. Reps see their own numbers; a manager's operations are refused to a rep at the database level.

The server refuses to start a non-loopback origin over plain HTTP, and refuses production without HTTPS, so a session cookie can never travel without the Secure flag.

Connections to the hosted PostgreSQL database require TLS.

Server-side data lives in managed PostgreSQL and relies on the hosting provider's storage encryption at rest, which the provider documents; Orvik adds no application-level field encryption of its own. Device-local Analytics data is protected only by the device (disk encryption, OS account).

Analytics exports the whole workspace as JSON and validates a backup before restoring it. API keys are stripped from every export. Because workspace data is device-local today, this export is your server-independent copy.

The optional Anthropic key for coaching notes is stored locally in the browser, never on Orvik's servers, and never in a backup file.

A writing provider — Orvik's or yours — receives the writing context and your text: not the workspace, not other users' data, not other prospects.

The platform design specifies periodic encrypted database dumps to independent storage with a tested restore, alongside the provider's daily backups. This is designed and not yet proven in production.

The product server refuses to start half-configured — a missing or malformed secret is a refusal at boot with a named variable, never a silent degradation.

Provider keys are server-only by construction on both the product and this website; this site sets a per-request Content Security Policy and standard security headers.

Centralized security and anomaly logging is specified in the platform design and is not yet in place.