Data Isolation

EQUIRE is a multi-tenant platform where tenant records are scoped to an organization. For organization members under ordinary authenticated use, there are no paths to read, modify, or enumerate another organization's deal-room data—the database and API layers enforce the same boundary together.

Platform operators. Authorized super-administrator accounts (internal engineering and support, contractually constrained) may use administrative tools that can reach across tenants—for example viewing another organization's pipeline when diagnosing an incident or validating a migration. Those capabilities are intentionally narrow; tenant users signing in day-to-day do not bypass organization membership.

Organization Scope

Every deal, document, valuation model, IC memo, prospecting record, extracted data point, conflict, and audit event is owned by exactly one organization. Users belong to one or more organizations and have a role — admin, manager, analyst, or viewer — within each. Switching the active organization changes the entire visible record set: deals, documents, rent roll data, sourcing results, audit logs, and team membership all reflect the selected organization and nothing else.

How Isolation Is Enforced

Database-Layer Row Security

Database-level row security policies tie tenant rows to your active organization. Many tables store an explicit org_id; others inherit scope through their deal (the deal carries the org, and child rows inherit access via joins in policy definitions). Postgres evaluates these policies when the API uses cookie-authenticated sessions that respect Row Level Security—so ordinary sessions cannot widen the tenant boundary purely in application code.

Operational jobs. Automated tasks (cron, webhooks, and similar) run with privileged server contexts that intentionally bypass tenant session semantics; they operate only on narrowly scoped payloads and guarded routes—not on arbitrary browser sessions.

Application-Layer Checks

Application-level checks add a second layer for authenticated product routes. Organization- and deal-scoped endpoints verify membership and deal access before returning or mutating data. Public routes (/docs, OAuth discovery, cron with secrets, authenticated party uploads, etc.) follow separate contracts documented on those flows.

Platform super-administrator accounts may bypass some membership gates for cross-tenant troubleshooting; tenant users remain bound to memberships and roles.

Independence of the Two Layers

Together, Postgres RLS and these API checks provide defense in depth: a buggy filter in one route does not by itself mean the tenant database will serve another customer's rows through a cookie-bound Supabase client. Operational service paths are a deliberate exception layered on top—not something a normal user's browser session inherits.

Authentication and Access

Login and Signup

EQUIRE uses email and password login. New accounts are created through an OTP-verified signup flow: after submitting an email and password, users confirm their address via a one-time code before any organization or deal data is provisioned. Password reset is handled by a recovery email sent to the registered address.

Session and Invite Scoping

Login sessions are scoped to one user. Invite flows are scoped to one organization: an invitation is issued for a specific organization and can only be accepted by the invited email address. Invitations expire after seven days.

What Is and Is Not Shared

Not Shared Across Organizations

Nothing specific to your organization's work is shared across organizations. The following are not shared across organizations: deals, documents, extracted data, valuation models, assumptions, IC memos, deliverables, rent roll data, prospecting results, sourcing profiles, origination briefs, audit logs, comments, team membership, organization roles, and invite records.

Shared Infrastructure

What is shared is the underlying platform infrastructure — application code, the database cluster, hosting, and upstream services (including retrieval used by AI features within the safeguards described under AI Trust and Safety). Another organization's authenticated session cannot see your records unless you explicitly share outside the tenant boundary (such as publishable URLs in the callout below).

Audit and Observability

Many material actions are recorded in an append-only audit trail scoped to your organization. Typical entries include deal creation and deletion, document upload and processing, data export, team membership changes, organization switches, account deletion requests, and share-link lifecycle events. Audit records carry a timestamp, user identifier where applicable, organization identifier, and action type. Opening a publishable share link increments analytics on that link row (for example view counts); those opens are not necessarily mirrored one-for-one into the audit trail. Organization admins review audit activity for their tenant in product surfaces designed for compliance visibility.

Immutability

Audit rows are inserted, not rewritten after the fact—they are tamper-evident records of what the system logged, not editable history.

Account and Data Deletion

EQUIRE-Only Deletion

An immediate deletion removes the user's identity and access from EQUIRE while leaving the organization and its deals intact — any remaining org members retain access to the existing records.

Full Deletion

A full deletion removes the user's identity from all connected platforms and goes through a seven-day grace period before executing; the grace period allows the user to cancel if the request was made in error. The grace period applies only to the full deletion path; the EQUIRE-only deletion is immediate.

Removing a Member

Organization admins can remove members from their organization at any time. Removing a member does not delete the organization's records.