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 operate Venturi alongside 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 part of the customer-onboarding baseline and is traceable to an instrumented signal. Venturi never publishes a commitment it does not measure.

The operational posture in one page

  1. A degraded Venturi dependency never blocks your AI traffic. The decision-time interceptor is fail-open within a 50 ms P99 end-to-end budget, bounded by a cooperative timeout against a cumulative deadline. If the index lookup, the event stream, or any other Venturi dependency behind it is slow, degraded, or unavailable, your AI request is forwarded unmodified. Fail-open is not configurable. When your requests route through a Venturi endpoint, such as the drop-in proxy, that endpoint’s own reachability is on your request path; see Proxy endpoint reachability.
  2. The serving plane targets 99.9% availability over a rolling 28-day window, stepping up to 99.95% under the Premium and Regulated support tiers. This governs Venturi’s dashboard, query API, and exports, not the forwarding of your AI traffic.
  3. Recovery objectives are 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.

Pages in this section

Page What it answers
SLAs & SLOs The published availability, latency, freshness, coverage, and recovery objectives, the commitments each support tier carries, and the signals behind them.
Status & incidents The tenant-isolated in-product status surface, the severity model, the customer notification and update cadence, and how incidents close.
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 contact channels, support tiers, acknowledgment targets, business hours, 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 on your AI traffic

No failure of a Venturi dependency behind the interceptor 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 edge-existence inference) runs later in the asynchronous processor with a 20 ms timeout inside the processor’s 100 ms P99 budget. On an interceptor breach, traffic is forwarded unmodified; on a Stage B breach, the conservative heuristic baseline keeps attribution processing flowing. The one deliberate rejection on the request path is tenant admission: a provider key that is not registered to your tenant is rejected before anything is forwarded. 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, coverage, and recovery objective on these pages maps to a named service-level indicator, and each contracted commitment maps to a named support tier (Standard, Premium, or Regulated). Venturi does not advertise a target it cannot measure. See Commitments by support tier.

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

Give feedback on this page

Sign in to send feedback. Opens in a new tab.

Copy page details 
Docs feedback: Operations & reliability
Page: https://docs.venturi.systems/operations/