The controls in place, and where this product fits today.

Regulated Access runs as a separate Next.js app with its own regulated_access Postgres schema and product storage paths. Authentication, users, organizations, and the product entitlement flag live in the dedicated Regulated Access production project today; future provisioning handoffs do not grant this app a runtime write path into SPUSA. Product writes remain scoped to the Regulated Access schema.

Every Regulated Access table runs with row-level security enforced at the database, scoped to the requesting tenant. Cross-tenant queries are designed to return zero rows — never a 403, never an error message that leaks existence. Production separate-org validation is recorded as launch evidence before a pilot starts. Composite tenant constraints block cross-tenant UUID guessing at the database level.

Every privileged action writes one row to the append-only audit log. The table is append-only by design — updates and deletes raise an exception even from elevated service contexts. Each row carries a SHA-256 hash linking it to the previous row in the same tenant. A per-tenant transaction lock prevents concurrent inserts from forking the chain.

Audit details are validated by a strict per-action Zod schema and a separate runtime banned-PII detector. Names, emails, phone numbers, passport fields, citizenship text, document filenames, storage paths, content hashes, IP addresses, and user-agent strings are rejected at parse time AND at runtime — even if wrapped in nested objects or arrays.

Uploaded supporting documents live in private, tenant-scoped document storage. Access is gated by tenant-scoped path and short-lived, server-issued signed URLs. The URL itself is never persisted, never returned to the audit log, and never echoed back to the client beyond the immediate response.

The evidence pack (JSON manifest, ZIP, PDF) is rendered through a single PII-scrubbed view. The manifest carries IDs, status codes, counts, timestamps, and audit row hashes — not document bytes, not raw subject identifiers, not screening provider payloads.

Eight canonical roles cover the workflow: organization admin, compliance manager, compliance staff, site manager, front desk, read-only auditor, support triage, and a global super-admin. The global super-admin is provisioned only through controlled infrastructure operations — never grantable from the product UI. The last active organization admin in a tenant cannot be demoted or deactivated.

MFA enforcement is configurable per tenant: required factor, assurance level (AAL1 / AAL2), session freshness, and whether to enforce before dashboard access. No identity provider is hard-coded to bypass the policy. SSO satisfies the gate only when the session claims meet the configured assurance.

The screening pipeline is built around a provider-agnostic integration layer. SPUSA adapter path tested in controlled synthetic/mocked flows. Production provider calls remain inactive unless activation is enabled for a configured organization. The dev-only synthetic match harness is unavailable in production and is not represented as a substitute for real screening.