Skip to content

Enterprise readiness checklist

Venturi is the attribution layer for enterprise AI: it links AI inference across providers, services, owners, identities, and budgets into one attribution graph without manual tags. This checklist is the cross-functional path a Fortune-500 program follows to take Venturi from a signed contract to a fully governed deployment. It is organized by the people who own each decision — Admin, Security, FinOps, Engineering, Workforce-Data, Auditor, Support, Procurement, Legal, and Data Protection — so every reviewer can find their own gate, complete it, and hand off cleanly.

Each persona track lists what that role does, the controls it depends on, and where the authoritative page lives. Where a control is not yet generally available, its row carries an honest release-state label; the binding index of those labels is Docs authority & product state.

How to use this checklist

  • Work the tracks in parallel — Admin and Security can proceed while Legal and Data Protection clear the privacy gates.
  • Two things must be true before Venturi returns any request-level attribution: a read-only cloud connector is live, and you have either enabled InvocationEvent emission or stood up the fail-open proxy (see Send events). The connector itself sets up in ~15–30 minutes; request-level attribution is the additional step.
  • Anywhere this page describes a control in plain present tense, it is GA. Anywhere a control is Private preview, Milestone-scoped, or Target-state, you will see a visible label at the claim.

Readiness at a glance

Track Owner Primary gate Status to reach
Admin Tenant administrator Tenant created, roles assigned, recertification scheduled Configured
Security Security / IAM SSO/SCIM/MFA federation surfaces + verification gating configured; full runtime enforcement is Target-state; read-only trust boundary verified (GA) In progress (enforcement: Target-state)
FinOps Finance / FinOps Budgets, chargeback exports, and FOCUS export wired Operating
Engineering Platform / SRE Connector live; request-level emission decided; observability green Live
Workforce-Data CTO / CHRO / CPO Cohort-only adoption views confirmed; k=5 and legal gate understood Cohort-only
Auditor Internal audit / GRC Auditor scoped-grant issued; WORM audit log reachable Evidenced
Support IT / service desk Break-glass governance understood; no standing Venturi access Governed
Procurement Sourcing / vendor mgmt Plan, residency lane, and subprocessor list confirmed Contracted
Legal Legal / contracts DPA and Workforce-Data legal sign-off executed Signed
Data Protection DPO / privacy office DPIA run, lawful basis mapped, erasure and data-return paths confirmed Cleared

Admin track — own the tenant

The Tenant Admin establishes the account, assigns the canonical roles, and keeps access right over time. Venturi's roles are least privilege, separation of duties, fail-closed by default, and every access decision is explainable on demand.

  • [ ] Create the tenant and claim your domains. The tenant is the isolation boundary — its own data store, encryption key, and audit trail. Verify the email domains your IdP will assert. See Single sign-on → claim your email domains.
  • [ ] Assign the four canonical roles — Admin, FinOps, Engineer, Workforce-Data — at the right scope node (Organization → Tenant → Workspace → Team → Project → Object). Grants inherit downward. See Roles & access control.
  • [ ] Use scoped-grant templates where standing access isn't warranted — Viewer for lowest-privilege read-only access and Auditor for a time-boxed, evidence-and-audit grant. See the role & permission matrix.
  • [ ] Bound any custom role. A custom role can never exceed the plan ceiling or the Admin ceiling, and can never weaken the Workforce-Data legal gate or k=5 suppression. See Custom roles.
  • [ ] Confirm step-up and separation of duties. Sensitive operations require a fresh WebAuthn/TOTP assertion; a proposer can never be the sole approver. See Step-up and separation of duties.
  • [ ] Schedule a recertification campaign. Standing access drifts; a grant not attested by its due date defaults to read-only pending review. See Keep access right.

Security track — federate identity and verify the boundary

Security owns the identity gates and proves the read-only trust boundary holds.

Identity controls — release state

SSO / SCIM / MFA federation surfaces are defined, with verification gating in place (Venturi will not show an IdP connection live until domain verification and a successful test assertion both pass — it fails closed until then). Full runtime enforcement (SSO-only, SCIM deprovision SLA, step-up freshness) is Target-state, being wired against the canonical identity model — see Docs authority & product state.

  • [ ] Federate SSO to your IdP over SAML 2.0 or OIDC. Authentication fails closed; a failed assertion denies access rather than degrading to a local login. See Single sign-on.
  • [ ] Map IdP groups to roles so role assignment is driven from your directory, not maintained by hand. See Map IdP groups to roles.
  • [ ] Enable SCIM for joiners, movers, and leavers, and confirm the deprovisioning guarantee — a deprovisioned user loses access promptly and completely. See SCIM provisioning.
  • [ ] Enforce SSO-only and MFA. MFA is IdP-enforced, with step-up on sensitive operations. See Enforce SSO-only and MFA and step-up.
  • [ ] Verify the read-only trust boundary. Every connector carries read-only scopes and an explicit write-Deny you can inspect in your own account; run the module's verify.sh to prove read works and write fails. See Security architecture → read-only integrations and Verify & confirm.
  • [ ] Confirm tenant isolation. A cross-tenant request is rejected, not filtered, regardless of role, and the boundary is re-verified on recovery. See Tenant isolation.
  • [ ] Confirm no content capture. Venturi processes invocation metadata — identity, service, project, cost, tokens, timing — and never prompt or completion bodies. See Data privacy & retention → what Venturi does not collect.
  • [ ] Understand the governance modes. Shape is the default. Gate is unavailable unless you explicitly enable it for a named workload, after trust readiness reaches OPERATIONALLY_TRUSTED; platform failure still fails open. Gate is never enabled during default onboarding. The allowed modes are PASSIVE, SHAPE, GATE. See Optimization & governance.

FinOps track — wire budgets, chargeback, and exports

FinOps owns cost data, allocation, and the exports finance runs on. The FinOps role has full access to cost, chargeback, budgets, forecasting, and adoption reports, and read access to attribution; it cannot modify technical policies.

  • [ ] Confirm cost connectors are flowing — Cost Explorer / CUR (AWS), BigQuery billing export (GCP), Cost Management (Azure). See Connect your cloud.
  • [ ] Configure budgets and alerts at the scope nodes that own spend. See Budgets & alerts.
  • [ ] Set the chargeback floor. Chargeback is gated by a confidence floor of 0.80 so finance never bills on weakly-attributed spend; unresolved and unknown spend is surfaced rather than silently allocated. See Cost attribution & chargeback.
  • [ ] Stand up the FOCUS export and scheduled reports for your finance and BI stack. See Reporting & exports → the FOCUS export.
  • [ ] Review ownership-vs-allocation and unknown-spend reports so attribution gaps are visible before they reach a chargeback run. See Coverage & unknowns.

Engineering track — bring the deployment live

Engineering stands up the connector, decides on request-level emission, and confirms the deployment is observable. The Engineer role is read access to attribution and team-scoped dashboards, and can propose interventions and overrides that require separate approval.

  • [ ] Complete prerequisites — tooling, the access you'll grant, and the values Venturi provides. See Before you begin.
  • [ ] Run the cloud connector following the six-step shape (provided values → terraform.tfvars → apply → verify.sh → hand outputs back → rotation). The connector sets up in ~15–30 minutes. See Connect your cloud.
  • [ ] Decide request-level attribution. For request-level data, either emit InvocationEvents via the Ingestion API or deploy the fail-open drop-in proxy. No code path may block or degrade a live AI request — fail-open is not configurable.
  • [ ] Validate freshness and degradation. Confirm connector freshness and check the degradation surface so you know when a result came from the trained model versus a fallback. See Observability & diagnostics.
  • [ ] Confirm operational confidence. Operational confidence (coper) is capped at 0.95 — Venturi never reports certainty it cannot evidence. See Confidence & evidence.
  • [ ] Set up API access for automation under step-up-gated key creation. See Developers → REST API and Webhooks.

Workforce-Data track — confirm cohort-only adoption

The Workforce-Data role is the executive/people view (CTO / CHRO / Chief People Officer). It is cohort-level only and read-only with respect to attribution and policies.

Workforce-Data is cohort-only by design

Individual-level workforce views are never a UI toggle. They are gated per tenant behind written legal sign-off plus a DPA amendment, are off in the EU regardless of role, and are always subject to k=5 minimum-cohort suppression — any cohort smaller than five is rolled up to its parent, never shown. No custom role can weaken this.

  • [ ] Confirm cohort-level adoption-intelligence views by team, function, role, and tenure are sufficient for your program. See Adoption intelligence.
  • [ ] Acknowledge the k=5 suppression rule and that it cannot be disabled. See Cohort-only adoption intelligence.
  • [ ] Route any individual-level need through Legal and Data Protection — it requires written legal sign-off and a DPA amendment, and is EU-hard-disabled. See the Legal and Data Protection tracks below.

Auditor track — make the deployment evidenced

Internal audit and GRC need a scoped, time-boxed grant and a reachable, tamper-evident record.

  • [ ] Issue an Auditor scoped grant — time-boxed, read-only, with evidence and audit-log access. See Roles & access control and the role & permission matrix.
  • [ ] Reach the WORM audit log. Administrative, access, and policy actions are written to an immutable, append-only log that survives recovery and is attributable to the actor. See Audit logs.
  • [ ] Use "explain access" to confirm that every grant resolves the way your controls expect, with the deciding factor named on a denial. See Explain access.
  • [ ] Pull diligence artifacts and the control-framework crosswalk for your working papers. See Trust center.
  • [ ] Map each control to its release state before relying on it. The binding index is Docs authority & product state.

SOC 2 — release state

Venturi does not yet hold SOC 2. Type I readiness is a Target-state item on the security roadmap, built on the immutable audit-trail subsystem; Type II is targeted within 12 months of Type I. See Compliance → SOC 2.

Support track — govern who can touch your tenant

Define how Venturi support reaches your environment when an investigation needs it — and confirm that, by default, it cannot.

  • [ ] Confirm Venturi support has no standing access to your tenant. Any investigation runs under a break-glass grant. See Support → how access is governed.
  • [ ] Acknowledge the break-glass guarantees. Support access is customer-approved, time-boxed, MFA-gated, least-privilege, tenant- and residency-bound, read-only by default, fully audited, and fails closed; it never inherits the gateway's fail-open allowance.
  • [ ] Set your support tier and escalation path. See Support tiers.
  • [ ] Note the milestone-scoped commitments. The 15-minute Sev-1 MTTA target and the 99.95% availability step-up are Milestone-scoped to Venturi's first dedicated on-call coverage window — labeled forward, not advertised as in force. See Support → the 15-minute Sev-1 target is milestone-scoped.

Procurement track — confirm plan, residency, and subprocessors

Procurement fixes the commercial and residency envelope the deployment runs in.

  • [ ] Confirm the plan tier and the role/feature ceiling it grants — custom roles can never resolve past the plan ceiling. See Roles & RBAC.
  • [ ] Confirm the residency lane. Per-tenant data lives in your VPC; the control plane and cross-tenant Aggregation VPC are region-pinned; EU-origin data is processed in-region or under SCCs. See Residency & subprocessors.
  • [ ] Review the subprocessor list and the change-notification/objection workflow. See Residency & subprocessors.
  • [ ] Collect diligence artifacts for vendor onboarding. See Trust center.

inference_geo residency control — release state

A customer-facing surface to pin where inference-time decisions are made is Target-state — a roadmap item with an explicit phase gate, built atop the shipped region-aware fields. Venturi does not describe it in present tense. See Compliance → GDPR.

Legal owns the contractual privacy terms and the gate that governs any individual-level workforce processing.

  • [ ] Execute the Data Processing Agreement. Venturi acts as processor; your organization is the controller. The DPA commits the GDPR Article 28 processor obligations, including the Art. 28(3)(a)–(h) terms and the Art. 28(2) subprocessor change-notification and objection workflow. See Data-subject rights → processor, not controller.
  • [ ] Sign off the Workforce-Data legal gate if — and only if — your program requires any individual-level workforce view. It needs written legal sign-off plus a DPA amendment, and is EU-hard-disabled regardless of that sign-off. Absent it, the deployment stays cohort-only with k=5 suppression. See Workforce-Data is cohort-only by design.
  • [ ] Confirm the lawful-basis mapping for each processing activity, including the named legal-claims / legitimate-interest basis for audit-log retention. See Data-subject rights → what ships to support your privacy program.

Legal sign-off precedes individual-level processing

The legal classification of cross-tenant aggregation outputs and the precise erasure exemptions are confirmed under EU counsel sign-off before external release. The mechanics are binding architecture; the executed DPA, RoPA, and DPIA template are produced as part of the enterprise-readiness program.

Data Protection track — clear the privacy gates

The DPO / privacy office runs the impact assessment and confirms the data-subject-rights and data-return paths before go-live.

  • [ ] Run the DPIA and works-council consultation. A DPIA template (GDPR Art. 35) and a works-council pack ship with the product. See Data-subject rights → what ships.
  • [ ] Confirm the erasure path. Subject erasure is fulfilled by crypto-shredding the per-subject key within a 30-day SLA, reconciled with the append-only architecture and surviving recovery, with a deletion certificate as evidence. See Data-subject rights → the 30-day erasure SLA.
  • [ ] Confirm access and portability. Access responses contain invocation metadata and derived attribution records — never message bodies; portability uses the machine-readable tenant-export format. See Right to data portability.
  • [ ] Maintain the RoPA for in-VPC metadata processing and cross-tenant aggregation. See Data-subject rights → what ships.

Offboarding and data return

Plan the exit before you go live, so a wind-down is a runbook rather than a scramble. Venturi fixes the export-then-delete order — export and retrieval window first, key destruction second, never the reverse.

  • [ ] Take the final tenant export in the machine-readable tenant-export format — your AttributionRecords, your customer-readable audit trail, and the reconciliation and billing artifacts you need to operate independently. See Reporting & exports → tenant data export.
  • [ ] Confirm certified deletion. On full offboarding, the same crypto-shred mechanism destroys the per-tenant key, rendering tenant data permanently unrecoverable, with a deletion certificate written to your audit trail. See Offboarding & data return.
  • [ ] Rotate or remove connector access in your own cloud account using the module's rotation path. See Rotate & offboard.
  • [ ] Retrieve the offboarding evidence artifacts — export manifest and checksums, the retrieval-window record, and the deletion certificate. See Offboarding & data return.