Status
Service status.
Operational status for public surfaces and customer rollout readiness. The public site is live; production customer tenants still require customer-specific configuration and external secret setup.
Service state
Public website
Marketing, trust, legal, pricing, implementation, and developer pages are served from the production domain.
App preview
The app preview uses fixture data and seeded credentials inside the authenticated product.
Health checks
Public liveness and sanitized readiness endpoints are available at /api/health and /api/ready for monitoring.
Production platform
Customer tenant rollout depends on order-form scope, billing route, access checks, and data setup.
Incident updates
Subscribers are recorded by scope, and a secret-protected operator route can dry-run or send incident, maintenance, security, and availability notices.
Security assurance
Procurement review bundles split live evidence from managed-beta, operator-required, and external-required proof.
Managed beta readiness
Invoice-led private or paid beta can be scoped with customer acceptance, operator proof, manual billing, and explicit self-serve/enterprise exclusions.
Vendor readiness
Support, billing, enterprise identity, HRIS, official issuer, and evidence-operation vendor boundaries are published without exposing secret values.
Launch gap register
Strict readiness blockers, production proof work, vendor dependencies, and customer acceptance gates are mapped to owners and launch-mode claims.
Operator launch console
Operator secret groups, mutating proof phases, command order, and launch evidence outputs are published without exposing secret values.
Launch claims guard
Buyer-safe wording, blocked wording, order-form treatment, and capability evidence are generated from live launch readiness.
Launch evidence ledger
Open launch blockers are mapped to proof artifacts, attachment targets, acceptance rules, and blocked claim boundaries.
Launch unblock plan
The current blockers are converted into ordered operator, vendor, customer, finance, and enterprise workstreams.
Managed beta readiness
10 managed launch gates define the invoice-led launch path, required customer/operator evidence, and self-serve or enterprise claims that remain gated.
Launch evidence
8 controls, 4 proof bundles define what must be captured before a customer tenant moves from setup into live private beta.
Security assurance
8 controls, 4 review bundles give procurement reviewers a bounded view of live controls, managed-beta controls, and external proof still required for enterprise rollout.
Operations evidence
6 controls, 5 SLO targets define how liveness, readiness, incident communications, rollback and restore proof are captured before paid production rollout.
Notifications
Subscribe to status updates.
Procurement, security, and tenant owners can opt into operational notices. Broadcast delivery is operator-controlled and requires the production email sender before live customer traffic.
Readiness gates
| Gate | State | Notes |
|---|---|---|
| Procurement documents | Live | DPA, SLA, subprocessors, privacy, terms, security, and trust pages are published. |
| Public API protection | Live | Mutating public routes are guarded by auth, secrets, or durable rate limiting. |
| Operational readiness API | Live | The running deployment reports liveness, dependency configuration, database connectivity, and strict launch readiness without exposing secret values. |
| Launch evidence pack | Live | Customer acceptance, operator run evidence, security/privacy evidence, and commercial proof bundles are published for tenant rollout records. |
| Security assurance pack | Live | Vendor risk, technical security, business-continuity, privacy, and AI-governance review bundles are published without claiming external certifications. |
| Operations evidence pack | Live | Health/readiness checks, SLO targets, incident dry-run requirements, rollback evidence, and restore rehearsal requirements are published. |
| Vendor readiness pack | Live | External dependency states are separated into ready, configured-unproven, manual-fallback, and blocked launch claims. |
| Launch gap register | Live | Open launch gaps are prioritized by severity, owner, blocked launch mode, proof command, and disallowed claim. |
| Operator launch console | Live | Operator execution phases, env groups, mutation boundaries, and evidence outputs are tied to the live launch gap register. |
| Launch claims guard | Live | Capability maturity, launch clearance, open gaps, and order-form defaults are converted into buyer-safe claim wording. |
| Launch evidence ledger | Live | Every open launch gap is mapped to the proof artifact, launch-room attachment target, acceptance rule, and blocked claim. |
| Launch unblock plan | Live | The live ledger and clearance state are aggregated into the next proof commands, owners, and claim locks. |
| Managed beta readiness | Live | The launchable-with-evidence path is published separately from strict self-serve paid readiness. |
| Evidence controls | Live | Uploaded evidence is hash-checked, screened for active content and EICAR signatures, quarantined on risk, and queued for retention cleanup. |
| Billing | External required | Stripe products, secret key, and webhook secret must be configured before self-serve paid checkout. |
| Production seed | External required | Privileged Supabase service-role access is required to apply production seed data. |
| Authenticated E2E | External required | Seeded owner, granted-employer, and denied-employer fixtures need production credentials for full smoke coverage. |
| Implementation runbook | Live | Rollout phases, order-form checklist, launch gates, and timeline are published. |
| Incident broadcasts | Managed beta | The status page records subscriber preferences and the operator broadcast route logs dry runs, delivery counts, and setup-required email state. |