Docs authority & product state¶
This page is the release-state contract for the rest of this documentation set. It tells you two things a careful reviewer needs before relying on anything else here: which source documents these pages are derived from, and which release-state label applies to every major enterprise control Venturi describes. Venturi is the attribution layer for enterprise AI, and these docs are held to the same honesty standard as the product — a control is described in plain present tense only when it is implemented and evidenced; everything else carries a visible label.
How to read every control claim on this site
- GA — implemented today, in the standard product, and evidenced. Stated in present tense without a label.
- Private preview — built and available to named customers under a feature flag or design-partner agreement, not yet general. Carries a label.
- Milestone-scoped — committed to a specific operational milestone (for example, the first dedicated on-call coverage window). Stated as forward, never implied as already in force.
- Target-state — on the roadmap with an explicit phase gate; not yet built. Always labeled, never written in bare present tense.
When a page describes a not-yet-GA control, you will see a matching MkDocs admonition (!!! info "Target-state", !!! note "Milestone-scoped", and so on) at the point of the claim. The summary table below is the authoritative index of those labels.
What "authority" means here¶
Venturi maintains a small set of binding internal documents — the product requirements and engineering specifications — and the public docs are downstream of them. When a control's behavior is described on this site, the wording is traceable to a numbered requirement in one of those documents and, where the control is GA, to a control-design gate that confirms it is implemented. This is what lets a procurement or security reviewer treat these pages as evidence rather than marketing: each claim has a source, and each not-yet-shipped claim has a label that says so.
This page does not restate the controls themselves. It points to the page that owns each one, states the release-state label, and names the gate the claim has to pass. For the controls' full behavior, follow the cross-links.
Source document versions¶
The control claims across this site are aligned to the following internal source documents. These versions are the authority; if a page on this site ever appears to contradict the behavior these documents bind, the documents win and the page is the defect.
| Source document | Version |
|---|---|
| Master PRD | v8.28 |
| Engineering Specification | v2.21 |
| RAIL PRD & Methodology (decision-time adapter) | v3.1 |
| RAIL Engineering Specification | v1.12 |
| Canonical Reference | v1.7 |
The Master PRD and Engineering Specification govern the platform: attribution graph, ingestion, the serving plane, administration, and the security and operational controls. The RAIL PRD & Methodology and the RAIL Engineering Specification govern the decision-time adapter — the trained-model inference call inside the fail-open gateway that carries the 20 ms wall-clock timeout described in SLAs & SLOs. The Canonical Reference is the cross-document spine: it binds the document set together and is the index through which requirement and control identifiers resolve.
Claim-to-gate-to-evidence: enterprise controls¶
The table below is the master index of release-state labels for Venturi's major enterprise controls. For each control it states the claim as customers may rely on it, the gate the claim must satisfy before it is allowed to appear in present tense, the evidence a reviewer can examine, and the release state. Controls marked GA are described in present tense across the site; controls marked Private preview, Milestone-scoped, or Target-state carry a visible label everywhere they appear.
| Control | Customer-facing claim | Gate | Evidence | Release state |
|---|---|---|---|---|
| Read-only access | Every connector carries read-only scopes; IAM policies attached to Venturi's workloads contain an explicit Deny on all write actions, and write permissions cannot be added. |
Frozen-invariant check; the deployed IAM policy is inspected. | The connector IAM policy and the explicit write-deny are customer-inspectable in your own account. See Security architecture. | GA |
| No content capture | Venturi processes invocation metadata — identity, service, project, cost, tokens, timing — never prompt or completion bodies. Provider keys are stored only as a truncated, non-reversible prefix. | Content inspection is off by default and enforced as a frozen invariant. | Field-level data classification showing no content fields are persisted. | GA |
| Fail-open gateway | No code path may block or degrade a live AI request. The gateway works to a 50 ms P99 end-to-end budget and forwards traffic unmodified on any failure; fail-open is not configurable. | Latency-budget SLI plus the fail-open invariant; the 20 ms RAIL adapter timeout is its share of the budget. | Measured gateway-latency SLI and the conservative-attribution record written on breach. See the fail-open guarantee. | GA |
| WORM audit trail | Administrative, access, and policy actions are written to an immutable, append-only audit log that survives recovery and is attributable to the actor. | Append-only writer; restore validation preserves the trail across recovery. | The customer-readable audit log and the append-only audit trail design. | GA |
| Support break-glass | Venturi support has no standing access. Investigation runs under a customer-approved, time-boxed, MFA-gated, least-privilege, read-only-default, tenant- and residency-bound grant that is fully audited and fails closed — it never inherits the gateway's fail-open allowance. | Fail-closed on every isolation, residency, and authorization check; default onboarding grants no standing access. | Each break-glass action is recorded in your immutable audit log. See Support → how access is governed and Tenant isolation. | Target-state — the no-standing-access model and audit are in place; the runtime enforcement gate (customer-approved, MFA-gated, fail-closed) is being wired against the canonical identity model. |
| SSO / SCIM / MFA | Authentication federates to your IdP over SAML 2.0 or OIDC and fails closed; SCIM provisions joiners, movers, and leavers; MFA is IdP-enforced with step-up on sensitive operations. | Verification gates activation — domain verification plus a successful test assertion; the connection is never shown live until both pass. | The verification flow and step-up evidence in Single sign-on and SCIM provisioning. | Target-state — federation/provisioning surfaces and verification gating are in place; full runtime enforcement (SSO-only, SCIM deprovision SLA, step-up freshness) is being wired against the canonical identity model. |
| RBAC / ABAC enforcement | Access is granted through four canonical roles — Admin, FinOps, Engineer, Workforce-Data — plus scoped-grant templates (Viewer, Auditor) and attribute-bounded custom roles, all bounded by plan, the Admin ceiling, the Workforce-Data legal gate, k=5 cohort suppression, residency, and separation of duties. | Authorization fails closed; no mapping can resolve past Admin or weaken the Workforce-Data gate or k=5. | The role model and access-explain surface in Roles & access control. | Target-state — the canonical four-role model + scoped grants + ABAC are defined; uniform fail-closed runtime enforcement across every route/worker/export is being wired to the central authorization engine. |
| Tenant isolation | A cross-tenant request is rejected, not filtered, regardless of role; per-tenant stores and keys; restores re-verify the boundary before a recovered plane returns to service. | Isolation fails closed in normal operation and during recovery. | The rejection model in Tenant isolation and the isolation check inside disaster-recovery restore. | Target-state — per-tenant stores/keys are in place; record-level 403 TENANT_MISMATCH enforcement is being hardened and proven by the adversarial isolation suite. |
| DR / SLO | A single propagated recovery pair — RPO ≤ 15 min, RTO ≤ 1 h — underwritten by event sourcing; the serving plane targets 99.9% availability while your AI traffic stays effectively 100% via fail-open. | Each number maps to a named SLI; recovery is rehearsed and evidenced. | The objectives in SLAs & SLOs and the rehearsal evidence in Disaster recovery. | GA |
| 99.95% availability step-up | A 99.95% serving-plane step-up and a 15-minute Sev-1 MTTA target are available at Premium/Regulated tiers. | Scoped to Venturi's first dedicated on-call coverage milestone; not advertised before it is staffed. | Labeled forward in Support → tiers. | Milestone-scoped |
| Data residency | Per-tenant data lives in your VPC; the control plane and cross-tenant Aggregation VPC are region-pinned from day one; EU-origin data is processed in-region or under SCCs (single region plus SCCs). | Region-pinning enforced; residency checks fail closed. | The region model in Residency & subprocessors. | GA |
inference_geo residency control |
A customer-facing residency-control surface that lets you pin where inference-time decisions are made, atop the existing region-aware fields and per-jurisdiction filters. | Roadmap item with an explicit phase gate; built on shipped region-aware fields. | Labeled as roadmap in the Compliance → forward GDPR program. | Target-state |
| Erasure (crypto-shred) | Subject erasure within a 30-day SLA via per-subject crypto-shred, reconciled with the append-only architecture and surviving recovery; a deletion certificate is issued. | Key destruction makes content cryptographically unrecoverable, including from backups. | The mechanism and 30-day SLA in Crypto-shred erasure and Data-subject rights → erasure. | GA |
| SOC 2 readiness | Venturi does not yet hold SOC 2. Type I readiness is a target on the security roadmap, built on the audit-trail subsystem; Type II is targeted within 12 months of Type I. | Attestation gate; the control foundation (immutable audit trail) is in place, the attestation is not. | The honest roadmap and Trust Services Criteria scope in Compliance → SOC 2. | Target-state |
Target-state and Milestone-scoped controls are not GA
The identity-enforcement layer is Target-state: RBAC/ABAC runtime enforcement, SSO/SCIM/MFA enforcement, record-level tenant isolation, and support break-glass enforcement are defined against the canonical identity model but their uniform fail-closed runtime is still being wired — they must not be read as GA. inference_geo residency control and the SOC 2 attestation are also Target-state (roadmap with explicit phase gates, not yet built or held). The 99.95% availability step-up and the 15-minute Sev-1 MTTA target are Milestone-scoped to Venturi's first dedicated on-call coverage window. Venturi never describes any of these in bare present tense, and never implies it holds an attestation it does not hold. The GA controls above (read-only access, no content capture, fail-open gateway, immutable audit, crypto-shred erasure) are frozen invariants in place today.
Where these controls operate
Every GA control above applies to the serving plane — the in-VPC query and dashboard surface running inside your own cloud account — and to the data plane it protects. The Venturi-operated control plane is outbound-only and initiates nothing inbound. See Operations & reliability and Security architecture for the full trust boundary.
How to challenge a claim¶
If a control on this site reads as present-tense GA but you cannot find it in this table, treat that as a documentation defect and raise it through security support. The release-state labels here are binding on the rest of the site: a page may not quietly upgrade a Target-state or Milestone-scoped control to GA without it changing in this table first. Diligence artifacts and the control-framework crosswalk that back the GA rows are available through the Trust center.
Related pages¶
- Operations & reliability — the reliability invariants and section map.
- Known limitations — the honest register of uncapturable pathways, fallback behavior, and not-yet-GA controls.
- SLAs & SLOs — the measured objectives behind the DR/SLO row.
- Support — the milestone-scoped tiers and break-glass governance.
- Compliance — the honest SOC 2, GDPR, and EU AI Act roadmap.
- Security architecture — read-only access, fail-open, and the trust boundary.
- Trust center — diligence artifacts and the control-framework crosswalk.