What RiskAlign does and does not do today

Row-level security (RLS) is configured across the schema. Configuration is not evidence of isolation.

Why: The current database has a single tenant. A genuine adversarial two-tenant test — creating a second tenant and attempting cross-tenant read/write from both an authenticated user and a service role — has not been run in a live pilot posture. Until it is, cross-tenant isolation is claimed on design and code review, not on adversarial evidence.

The console uses browser caching for responsiveness. Cached values are a view of the last authoritative response, not the record.

Why: Authoritative records are held server-side. Where the same value appears in the console after a sign-out or long idle, treat the server as the source of truth.

Application and database run in a single region and cluster.

Why: Pilot-appropriate. Cross-region replication and active/active are trigger-tied to procurement requiring them.

Email/password authentication with MFA enforcement and self-recovery grant lifecycle is implemented. SAML 2.0 is not yet wired. The live founder MFA / recovery rehearsal remains open, so MFA is verified by implementation and unit-level evidence rather than live rehearsal evidence.

Why: Pilot scope. SAML is sequenced for the first enterprise procurement requirement; the founder rehearsal is scheduled per the Wave 1 verification pack.

Public API documentation and a tenant-scoped route surface exist (see /docs/api), including inbound webhook slot. End-to-end operational and contract validation across all documented endpoints, scopes, rate-limit behaviour and webhook delivery has not been independently completed in this closure.

Why: Documentation and the route surface are published; independent end-to-end validation follows customer demand and pen-test scope.

In the meantime: CSV import/export covers reporting, bulk operations and the RegAlign bridge.

RiskAlign is cloud-only. No on-premise or private-cloud deployment is currently offered.

Why: Full on-premise is not on the roadmap.

No card processing. Invoiced and paid by bank transfer.

Why: Regulated buyers procure via Order Form + invoice + bank transfer.

Scoped SoW exists; no completed third-party test report yet.

Why: Test not yet contracted. Trust Centre will publish the executive summary when a report lands.

Not certified. SOC 2 Type I readiness is on the Security Roadmap, trigger-tied.

Why: Certification timing is driven by customer demand; controls are documented today and available for review on request.

DEV_OPEN was flipped to false on 2026-06-17 (ADR 0008). Real per-user auth (Supabase + RLS) is live. The DEV_OPEN constant and demo-passcode branch are retained in ~25 server-function files as a dormant rollback path.

Why: Dormant-branch removal remains open as a developer-pass item. Until a CI lint guard rejects DEV_OPEN=true in main, any PR touching src/lib/riskalign/dev-mode.ts is treated as security-sensitive.

MFA enforcement code and self-recovery grant lifecycle are implemented; live founder rehearsal is not yet complete.

Why: Rehearsal is scheduled per the Wave 1 verification pack. Until executed, MFA is verified by implementation and unit-level evidence only.

The /compass-methodology page documents the method but does not yet publish ratification rates.

Why: Aggregate figures will appear once the first paid pilot has decided enough suggestions for the numbers to be meaningful.

The group overview page shows per-entity KPIs across all entities in a tenant. Consolidated roll-up reports across every entity are not yet built.

Why: Lands after the first paid pilot tells us which consolidated views matter.

/status exists as a static published pilot-stage status record and incident log. It is not backed by real-time independent monitoring and does not evidence SLA or uptime performance.

Why: External independent monitoring is on the trigger-tied roadmap and remains open as a developer-handover ticket.

Inbound one-click, outbound CSV. The in-app import at /app/regalign-import lets a user parse and load a RegAlign obligations CSV and link obligations to risks. The reciprocal (risk-to-obligation lineage back to RegAlign) is via CSV export, not one-click.

Why: Outbound one-click UI lands once both products have signed pilots. The consoles remain separate; no live unified operator console is implied.

KRI and appetite breaches surface as visual signals on dashboard and register views. Email, in-app push and webhook notifications on breach are not yet built.

Why: Notification primitives are scoped in ADR-0015 and land alongside the workflow engine.

Designed support model; no externally published SLA.

Why: Will be published when the first paying tenant signs. Pilot agreements include explicit response commitments.

One person (the founder) is named operator and named technical contact.

Why: Continuity, liability, successor and exit arrangements are disclosed and agreed for each engagement rather than promised universally.

In the meantime: Selected CSV and PDF export surfaces and an audit trail exist for specified records. Comprehensive export, operator recovery and reversibility of every action have not been independently verified, and neither is a substitute for a second operator or tested continuity arrangements.

Backup configuration is in place; a documented restore rehearsal from a production snapshot is not yet complete.

Why: Scheduled per the Wave 1 verification pack.

RiskAlign is a tool. Suggestions and classifications are assistive only.

Why: Every output is reviewable by a named human before it becomes a governance record. See AI Use Disclosure. Compass is advisory only and must not ratify, approve or auto-close a governance record.

Jersey regulatory linkage via RegAlign is the deepest today. Other jurisdictions are shallower.

Why: Pilot-stage, Jersey-first by design. Depth follows each pilot signed in a new jurisdiction.