What RegAlign does not yet do

SAML 2.0 single sign-on is configurable per customer via the operator console (Okta, Entra ID, OneLogin, any SAML 2.0 IdP). SCIM auto-provisioning is not built — seats are still created manually.

Why: SAML covers the buyer's actual blocker (one corporate identity, one MFA). SCIM is convenience tooling that only pays off above ~50 seats — past our pilot scope.

In the meantime: Seats are granted and revoked within the same business day during the pilot window.

There is no documented public REST API for customer integrations yet.

Why: The export surface today is CSV (the RegAlign ↔ RiskAlign bridge contract is v1, frozen) and PDF. A REST API will follow customer demand.

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

RegAlign is cloud-only. There is no on-premise or customer-managed deployment.

Why: A single-tenant managed deployment is possible on request; a true on-premise build is not on the roadmap.

No credit-card processing. RegAlign invoices customers and is paid by bank transfer.

Why: Regulated firms procure via Order Form + invoice + bank transfer (NET30). Card rails add fees and PCI scope without matching how buyers actually pay. Issue forms from /order-form in the operator console.

We have a scoped SoW and an RFP but no completed third-party pen test report yet.

Why: Test is being contracted. Trust Centre will publish the executive summary when the report lands.

Not certified. A SOC 2 Type I readiness path is in the Security Roadmap.

Why: Certification timing is driven by customer demand; controls are already documented and audit-walkable.

The 5 calls / hour / IP limit on Compass is enforced per edge-runtime worker, not globally.

Why: Acceptable for the pilot traffic profile. A durable per-IP counter is on the dev backlog.

Role-specific first-run checklists (CCO, MLRO, Board) ship in-product at /first-run-checklist. Progress is saved per-device.

Why: Live since System-Readiness Sprint. Replaces the founder-led walkthrough as the default onboarding path.

Notification digest cadence and working-hours are user-level, not tenant-level.

Why: Tenant-level overrides will land once we have feedback from two live pilots on what they actually want batched.

There is no in-product 'delete my pilot data' button.

Why: Deletion on pilot exit is run by us, documented in the Data Retention & Deletion policy, and evidenced in the audit trail. A self-serve button is on the backlog.

In the meantime: Email a deletion request to hello@regalignplatform.com; we action it within 5 business days and return a deletion certificate.

Ten registers (incidents, findings, breach register, internal SARs, whistleblowing reports, third parties, DP breaches, DSARs, conflicts, training) still allow free-text categorisation alongside the structured linkage spine.

Why: Phase 1 shipped the spine and a universal picker; per-form retrofits are mechanical and sequenced post pilot #1 to avoid concurrent UI churn.

Several internal diagnostic and aging-cohort routes exist as separate URLs rather than query parameters on a single route. The /diagnostics index page surfaces them centrally.

Why: Historical scaffolding. Bulk consolidation is a developer-handover ticket (~180 routes); the index page is the safe interim. They do not affect operator workflows.

Server-side error telemetry is wired to Sentry. Browser-side Sentry init reads the DSN from a server function — works on Lovable Cloud out of the box; self-hosters with a separate DSN should set SENTRY_DSN at runtime.

Why: Lovable Cloud disallows user-managed VITE_-prefixed build secrets, so we expose the public DSN via a server fn rather than at build time. Functionally equivalent.

The /status page reads from the status_probes table and is publicly viewable. Probe writes are still operator-run.

Why: Continuous external probing is a dev-handover ticket; until then operators (or a scheduled job once configured) write probe results. The page itself is live.

We have a designed support model but no externally published SLA.

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

Today, one person (the founder) is the named operator and the named technical contact.

Why: Successor role spec, second-operator brief and source-code escrow are in flight. We are explicit about this rather than hiding it.

In the meantime: All operator actions are reversible from the audit trail; all governance state is exportable as CSV and PDF at any time.

There is no third-party support partner today.

Why: Will be introduced after the first paying tenant signs (Phase 17 support-model design).

RegAlign 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.

The methodology library reflects our research and current professional practice; it has not yet been signed off by an external SME panel.

Why: SME review brief is issued. Sign-off will be published alongside any material methodology change.

Jersey (JFSC) regulatory content is the deepest. Guernsey, Isle of Man and UK content exists but is shallower.

Why: We are pilot-stage and Jersey-first by design. Other jurisdictions will deepen with each pilot signed there.

RegAlign is deployed on Lovable Cloud (Cloudflare Workers + Supabase Postgres). If the platform materially changes its commercial terms, deprecates a capability we rely on, or imposes a region we cannot accept, we have a documented migration path off it.

Why: Single-vendor hosting concentration is a real procurement question. Source code is in escrow; database export and infra-as-code redeploy to a vanilla Cloudflare + Supabase account is rehearsed quarterly. Switching cost is measured in days, not months.