How Venturi works¶
You do not need this page to onboard. It explains what happens to your data after you connect, and why the integration is shaped the way it is. Each section summarizes one idea and links to the page that defines it.
Looking for the full architecture?
This page is the short conceptual overview. System architecture is the reference for exact values and boundaries: the three planes, the three-stage attribution pipeline with RAIL (Resource Attribution & Inference Layer) as Stage B, the in-process Stage B engine in the attribution processor, the control-versus-data-plane split, the fail-open boundary, and exactly where your data lives and where it does not.
The attribution graph¶
Venturi is the attribution layer for AI. It links AI inference across providers, services, owners, identities, and budgets into one attribution graph, without relying on manual tags. IDD classifies the source evidence first. Only invocation-grade evidence creates Invocation nodes; discovery observations and aggregate usage retain their declared granularity. For canonical invocations, the graph records supported relationships across six layers and keeps unresolved relationships explicit:
An invocation connects to its service and identity. A service connects to its
project and identity; projects and identities connect to their organizations.
Organizations carry the budgeted_under and billed_to relationships that
express budget responsibility.
The graph stores these six layers as five node types plus budget edges; see The attribution graph for the canonical definition of each layer and edge.
The result answers questions finance and engineering both ask: which team, which service, which person, which budget is responsible for a given slice of AI spend, with a confidence score on every attribution (capped at 0.95; Venturi never asserts certainty).
As teams operationalize chargebacks, governance, and adoption, the attribution graph provides a shared record of accepted allocations and decisions. Its system-of-record role develops through those established workflows.
Where the data comes from¶
| Source | Gives Venturi |
|---|---|
| Cloud connector (onboarding) | Billed cost (CUR / BigQuery billing export / Cost Management), provider-native usage logs (Bedrock, Vertex AI, Azure OpenAI), and identity inventory. |
| Ingestion API / proxy (optional) | Request-level events: per-call tokens, cost, latency, and the identity/service that made the call. |
The connector alone produces account/team-level attribution. Adding events gives you per-request resolution.
Deployment model¶
Venturi runs as a dedicated, single-tenant data plane: inside your cloud trust boundary in self-hosted mode, or inside a Venturi-operated tenant boundary pinned to your contracted residency lane in SaaS mode. See Deployment modes. Both modes hold the three product invariants defined in System architecture: your operational data stays in your tenant boundary, integrations are read-only, and the decision-time interceptor fails open.
Fail-open on your AI traffic¶
The single hardest rule in the platform: a slow, degraded, or unavailable Venturi dependency never blocks customer production traffic. The decision-time interceptor works to a 50 ms P99 end-to-end latency budget, with a cooperative timeout against a cumulative deadline. If a dependency behind it is slow or down, your request proceeds unmodified and attribution is reconciled later. The one deliberate rejection is the drop-in proxy’s tenant admission: a provider key that is not registered to your tenant is rejected before anything is forwarded (see Tenant admission). With the drop-in proxy, the proxy endpoint itself is on your request path; the Drop-in proxy page explains how to fail over when it cannot be reached. See the fail-open boundary.
No content capture¶
The core pipeline never stores prompt or completion text. Attribution is built from metadata (model, tokens, cost, identity, timing), and the ingestion schema has no content field at all. The default cloud read grants can reach content-bearing logs, such as provider content logging you enable and Vertex AI container logs, which are on by default; Venturi discards content fields in memory before a record is materialized and never persists them. See Trust & security.
Sign in to send feedback. Opens in a new tab.
Copy page details
Docs feedback: How Venturi works
Page: https://docs.venturi.systems/concepts/architecture/