Skip to content

Docs authority and product state

This page separates the product contract a customer can rely on during onboarding from implementation evidence and the longer-term roadmap. It is the interpretation key for the rest of this site.

Present tense on this site describes Venturi’s product behavior and controls. Your implementation checklist records tenant-specific configuration, enabled integrations, and verification evidence. The control scopes and future capabilities listed below retain their stated availability.

Customer-onboarding baseline

The customer-onboarding baseline is the behavior Venturi commits to for an onboarded tenant. A capability belongs in this baseline only when its prerequisites, safe failure mode, and customer verification path are documented. The product contract defines the documented behavior. External attestations and tenant-specific configuration are documented separately.

The baseline invariants, their customer contracts, and how to verify them:

Invariant Contract Verification
Collection Provider access is least-privilege and write actions are excluded or explicitly denied. Inspect the deployed provider policy and run the connector verification.
Credential posture No long-lived cloud credentials by default: AWS access uses role assumption with an external ID, and Google Cloud and Azure access use workload identity federation. The exceptions are explicit: the Azure client-secret fallback (90-day TTL, stored in Terraform state), Venturi API keys (long-lived until rotated), and SaaS connector credentials (stored as encrypted credential references). Inspect the deployed trust policy or federated credential, then review Settings / Admin / Credentials. See Rotate & offboard.
Metadata Venturi materializes allowlisted metadata fields, never prompt or completion bodies. Review data classification and ingestion validation.
Traffic path The decision-time interceptor performs a fast index lookup within a 50 ms P99 end-to-end budget (15 ms internal). A cooperative timeout against a cumulative deadline forwards the request unmodified on any failure or timeout of a Venturi dependency behind the interceptor. With the drop-in proxy, the proxy endpoint’s own reachability stays on your request path; see Proxy endpoint reachability. Exercise the fail-open check and inspect the latency SLI.
Attribution Stage B (trained edge-existence inference) runs in the asynchronous processor with a 20 ms timeout inside the processor’s 100 ms P99 budget. When Stage B misses its timeout or is unavailable, the heuristic baseline keeps attribution processing flowing. Inspect result-source markers and the processor SLI.
Cohort privacy Every cohort read path (adoption views, dashboards, exports, API responses, board packs, and webhooks) enforces a server-side minimum cohort size of 5. A smaller cohort rolls into its parent unit and cannot be reconstructed by differencing overlapping cohorts. An Admin can raise the threshold but never lower it below 5. Attempt a sub-threshold query and an overlapping-cohort difference; confirm that both return the parent rollup.
Audit durability Audit entries are append-only: no product surface or API edits or deletes one. The audit stream is written to customer-controlled object storage under S3 Object Lock with a 5-year retention period. Governance mode is the default: only a principal holding the explicit s3:BypassGovernanceRetention permission can shorten or remove a lock before it expires. Venturi’s writer and audit-retrieval roles never hold that permission. The administrators of the account that holds the bucket withhold it from routine roles and record its use with AWS CloudTrail data events on the bucket (see Who holds the audit bucket). Compliance mode, in which no user (including the account root user) can shorten or remove a lock before it expires, is configured at onboarding for deployments that require it. Inspect the bucket’s Object Lock mode and retention period, then read back the audit stream. See Audit logs.
Enforcement Active (Gate) is enabled only for a named, operationally trusted workload. For that workload, Venturi emits a signed enforcement recommendation (deny or reroute), and your enforcement point (gateway, proxy policy, or budget control) decides whether to apply it. A budget hard stop uses the same mechanism. The decision-time interceptor never denies, blocks, or reroutes traffic and stays fail-open. Verify the recommendation signature and your enforcement policy independently.
Tenant isolation Each tenant has tenant-scoped stores and keys, and every request is bound to one tenant by its signed token. A cross-tenant request is rejected with 403 TENANT_MISMATCH regardless of role, and isolation fails closed. These controls pass onboarding verification before the deployment is handed over. Review the record-level tenant-isolation test result in your implementation checklist. See Tenant isolation.
Support access Venturi support holds no standing access. Tenant access exists only under a customer-approved, time-boxed, MFA-gated, audited break-glass grant that fails closed. Review grant requests and approvals in the audit log. See Support-access architecture.

Current implementation status by tenant

During onboarding, Venturi records each control as verified, pending, not enabled, or not applicable in your tenant’s implementation checklist. These records describe your tenant’s configuration and acceptance evidence.

The following items require explicit implementation evidence before they are represented as active for a tenant:

  • SSO-only enforcement, SCIM lifecycle enforcement, and step-up authentication.
  • Role and attribute authorization on the routes, workers, and exports your tenant uses.
  • Record-level tenant-isolation adversarial tests.
  • Customer-approved support-access runtime controls.
  • Compliance-mode object lock and its configured retention period.
  • Any optional provider surface, export, or enforcement integration.

Until a control is verified for your tenant, its fail-closed default applies. For example, support works only from customer-supplied diagnostics until the break-glass gate is verified.

SOC 2 Type I readiness/report target on our security roadmap with Type II targeted within 12 months; it is not yet held. Readiness work and audit evidence are distinct from an issued SOC 2 report.

Post-onboarding roadmap

Post-onboarding roadmap items describe intended future capabilities. They are not part of the customer-onboarding baseline unless a signed order or implementation plan explicitly adds them. Current roadmap items are:

  • Uniform identity enforcement across every route, worker, and export.
  • The customer-facing inference_geo inference-residency control.
  • Customer-facing EU AI Act compliance automation.
  • Sustainability resource and carbon estimates as an optional extension. The domain guide specifies the target workflow; compatible factor provenance and tenant verification remain prerequisites. Estimates are separate from an audited emissions inventory.
  • SOC 2 reports and ISO/IEC 27001 and 42001 certification. These attestations are not held today.

Roadmap language never overrides the baseline or tenant-specific implementation status. When a capability moves into the baseline, its verification procedure and evidence must land with the documentation change.

Authority hierarchy

For customer-visible behavior, the order of authority is:

  1. The signed customer agreement and implementation plan. The order form is the commercial authority for the support tier and any customer-specific commitment.
  2. The deployed provider policies, configuration, and verification evidence.
  3. The customer-onboarding baseline on this page and the detailed product docs, which are the technical authority for what each tier and control means.
  4. Internal requirements and engineering specifications.
  5. Post-onboarding roadmap material.

If a page conflicts with a deployed policy or tenant verification result, treat it as a documentation defect and contact Support.

Give feedback on this page

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

Copy page details 
Docs feedback: Docs authority and product state
Page: https://docs.venturi.systems/operations/release-state-and-authority/