If I build my operating rhythm around this and it goes down the morning of my board meeting, what happens? What is your actual uptime commitment?

The full executive answer

Direct answer first: I will not quote you an uptime number, because we have no operating history that makes one honest. What I can show you is the resilience architecture and the honest state of its evidence. The AI layer is dual-provider — Anthropic primary, OpenAI secondary — so a model-provider outage degrades to the fallback engine rather than to silence. The application runs on Vercel’s multi-region edge with the database on managed Postgres with point-in-time recovery. We run a real incident-management module and a public status page — the same discipline we sell is the discipline we run — and generation requests queue through an asynchronous job system with idempotency keys, meaning a transient failure retries safely instead of losing or duplicating your work.

Now the gap, stated plainly because you will find it anyway: we measure and meet internal AI-latency service-level objectives today, but we have not yet run the full disaster-recovery drill — point-in-time restore plus second-region recovery — that would let me put availability and recovery-time numbers into a contract with evidence behind them. That drill is on the pre-general-availability roadmap, and enterprise agreements will carry an evidenced SLA once it has been executed, in line with ISO 22301, the business-continuity management standard. Until then I would rather you hear "designed for resilience, evidence pending" than a marketing nine.

For your board-morning scenario specifically, the practical mitigation is architectural: analyses are generated ahead of the meeting, not live in it, and every output exports to PowerPoint, Excel and PDF — plus the app itself works offline as a progressive web app. A platform outage on the day would be an inconvenience to regeneration, not a hole in your board pack.