Show me your p95 latency and your performance benchmarks under realistic load?

The full executive answer

Here is exactly what is measured and what is not — and the distinction is built into the product itself. What is measured today: public API read latency and the server error rate, from a daily rollup of our own request logs, each against a stated objective — for example, 95% of API reads at or under 800 milliseconds. What is not yet measured: AI generation latency, which is the latency that dominates user experience in this product, and availability. The time each generation takes is not yet recorded, so we quote no AI-latency figure; availability needs an external probe, because nothing inside a system can observe its own downtime. Our reliability code flags both as targets, not measurements, and the product shows them that way.

Why this posture rather than a benchmark slide: we are pre-launch with no production traffic history, and synthetic benchmarks of an unloaded system are close to meaningless — Google's SRE discipline is that you set service-level objectives, instrument them, and manage to an error budget, rather than quoting lab numbers. The instrumentation groundwork is already in: OpenTelemetry spans around request handling and AI calls (exportable over OTLP once a collector is configured), Sentry for errors, and an SLO alerting job that runs on schedule.

The roadmap is: record the duration of every AI generation, add external synthetic probes on the critical user journeys, and turn the two remaining targets into measured SLOs with public error budgets — before we sign any latency or availability SLA. If a vendor ever shows you a clean p95 chart with no production traffic behind it, that is the number to distrust.