Skip to content

Operations & reliability

Use this section to validate how Venturi behaves under load, degradation, incidents, support access, and recovery. It documents the service-level objectives, health signals, incident process, access controls, and disaster-recovery posture that operators can test.

This section is written for the people who keep Venturi running well inside your environment (your platform, SRE, and FinOps-operations teams) and for the reviewers who need to see Venturi’s reliability commitments before they sign. Every number on these pages is grounded in Venturi’s binding specifications and is traceable to an instrumented signal. Venturi never publishes a commitment it does not measure.

The operational posture in one page

  1. Your AI traffic cannot be taken down by Venturi. The decision-time interceptor is fail-open with a hard 50 ms P99 end-to-end budget. Under any failure (including a full Venturi outage), your AI request is forwarded unmodified. Fail-open is absolute and not configurable.
  2. The serving plane targets 99.9% availability. This governs Venturi’s tenant query and dashboard surface, not your traffic, which stays effectively 100% available because of fail-open.
  3. Durability is one customer-facing pair: RPO ≤ 15 minutes, RTO ≤ 1 hour, propagated identically across every store. Event sourcing over the durable invocation log underwrites the recovery point.
  4. Venturi self-reports its own health. A live degradation state, freshness signals, and per-component status are exposed in-product and over the API, so you never have to guess whether attribution is current.
  5. Support is tiered, audited, and least-privilege. Venturi support has no standing access to your tenant. Any support investigation runs under a time-boxed, customer-approved, fully-audited break-glass grant that fails closed on tenant isolation and residency.

What’s in this section

Page What it answers
SLAs & SLOs The published availability, latency, freshness, and durability objectives, what each one governs, and the signals behind them.
Status & incidents How Venturi classifies, communicates, and closes out incidents, the severity model, and the in-product degradation surface.
Observability & diagnostics The health, freshness, and coverage signals you can read yourself: in-product, over the API, and through your own monitoring stack.
Support The support tiers, response targets, escalation paths, and how Venturi support access is governed.
Support-access architecture The customer-approved, time-boxed, fail-closed support grant and its audit evidence.
Disaster recovery Backup, restore, the RPO/RTO pair, the recovery design, and how recovery is rehearsed and evidenced.
Docs authority & product state The customer-onboarding baseline, current implementation evidence, and post-onboarding roadmap boundary.

The reliability invariants

A small set of frozen invariants shapes every operational control here. They hold on every deployment and cannot be configured away.

Fail-open is absolute on your AI traffic

No Venturi code path may block or degrade a live customer AI request. The synchronous decision-time interceptor performs a fast index lookup within a 50 ms P99 end-to-end budget. Stage B trained-model inference runs later in the asynchronous processor with a 20 ms call budget inside the processor’s 100 ms P99 objective. On an interceptor breach, traffic is forwarded unmodified; on a Stage B breach, attribution processing falls back to a conservative heuristic. See SLAs and SLOs.

Access-control surfaces fail closed

Authentication, authorization, tenant isolation, export, billing mutation, residency routing, and support break-glass fail closed: the decision-time interceptor’s fail-open allowance never extends to an access decision. A cross-tenant request is rejected regardless of role. See Support.

Every published number is instrumented

Each availability, latency, freshness, and durability objective on these pages maps to a named service-level indicator. Venturi does not advertise a target it cannot measure, and forward commitments scoped to a future operational milestone are labeled as such, never implied as already in force.

Where Venturi runs

These commitments apply to the serving plane inside the dedicated tenant data plane. That plane runs in your account in self-hosted mode or in the contracted single-tenant residency lane in SaaS mode. The separate control plane carries signed control traffic and no raw tenant data. See Deployment modes.

Where to start