Skip to content

Enterprise readiness checklist

Venturi correlates model, service, code, identity, organization, and budget signals into 1 attribution graph without relying on manual tags. Manual tags may be optional evidence but are never the sole required mechanism; unsupported ownership remains unknown. 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, Product, Security, Finance, 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. The authority hierarchy for customer-visible behavior is Docs authority & product state.

How to use this checklist

  • Every persona path is executable with in-product guidance and these mirrored docs; human guidance can accelerate recovery but is never a dependency.
  • Work the tracks in parallel: Admin and Security can proceed while Legal and Data Protection clear the privacy gates.
  • The engineering active-use milestone is the 1st AttributionRecord on the /invocations surface, verified through the quality feed, from a connected source or accepted provider export file within ≤30 minutes.
  • Persona-complete production onboarding requires Product, Security, Engineering, and Finance to advance through real in-product actions. Finance must record an accepted chargeback-eligible export. There is no admin override and no support override.
  • Each control below is a customer-onboarding acceptance criterion. Record its tenant-specific state in the implementation checklist as verified, pending, not enabled, or not applicable.

Readiness at a glance

Primary readiness gates and their owners:

Track Owner Gate
Admin Tenant administrator Tenant created; roles assigned; recertification scheduled
Product Product owner Product tour complete; output states, confidence bands and default filters confirmed
Security Security / IAM Enabled SSO/SCIM/MFA federation configured and verified; read-only trust boundary verified
Finance Finance / FinOps Chargeback-eligible export reviewed and accepted in-product
Engineering Platform / SRE Source or file accepted; first attribution visible and chargeback export manifest verified
Workforce-Data CTO / CHRO / CPO Cohort-only adoption views confirmed; k=5 and the legal gate understood
Auditor Internal audit / GRC Auditor scoped grant issued; audit log reachable and its Object Lock mode confirmed
Support IT / service desk Break-glass governance understood; no standing Venturi access
Procurement Sourcing / vendor mgmt Plan entitlements, residency lane, and subprocessor list confirmed
Legal Legal / contracts Data Processing Agreement (DPA) and Workforce-Data legal sign-off executed
Data Protection DPO / privacy office DPIA run, lawful basis mapped, erasure and data-return paths confirmed

Target status for each readiness track:

Track Target status
Admin Configured
Product Acknowledged
Security Verified or explicitly not enabled
Finance Accepted
Engineering Live
Workforce-Data Cohort-only
Auditor Evidenced
Support Governed
Procurement Contracted
Legal Signed
Data Protection 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 is not 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 contract entitlement 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.

Product track: confirm attribution states

Product completes its path in-product, not through an acknowledgment outside the tenant.

  • Complete the product tour. Confirm all 6 output states: deterministically_resolved, strongly_inferred, bounded, ambiguous, unknown, and not_identifiable. Review the 3 confidence bands: Chargeback-ready, Provisional, and Estimated. Save the default dashboard filters. See Product tour.
  • Open an evidence card. Confirm confidence and freshness are visible for the selected attribution.

Security track: federate identity and verify the boundary

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

Identity controls: onboarding baseline and roadmap

SSO, SCIM, and MFA federation are part of the onboarding baseline, with verification gating: Venturi does not show an IdP connection as live until domain verification and a successful test assertion both pass, and it fails closed until then. The tenant implementation checklist records whether SSO-only enforcement, SCIM lifecycle enforcement, and step-up authentication are verified for your tenant. Uniform identity enforcement across every route, worker, and export is on the post-onboarding roadmap. 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: within the SCIM sync SLA (accepted changes target completion within 60 seconds, with a hard maximum of 300 seconds for session revocation), a deprovisioned user’s sessions are revoked server-side and every grant resolves to deny. See SCIM provisioning → the deprovisioning guarantee.
  • 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 cloud connector grants only allowlisted read actions and no write permission, which you can inspect in the role policy or role assignments in your own account. Automated credential validation runs as Venturi’s identity and proves that the expected reads succeed and the probed writes are denied; any successful write response is a security finding. See Deploy, Security architecture, and Verify & confirm. The local check for each cloud proves a narrower result:
    • AWS: listing every managed and inline policy on the role is the complete check: no attached policy, and inline policies (3 with Bedrock access enabled, 2 without) that allow only the access-boundary read actions. The IAM policy simulator spot-checks the 6 write actions the module’s verify.sh probes. The module’s verify.sh cannot run with your credentials, because the role trusts only Venturi’s principal.
    • Google Cloud: verify.sh confirms the service account has no user-managed keys, and its project-scope role lines must be exactly role: roles/monitoring.viewer, role: roles/logging.viewer, and role: roles/serviceusage.serviceUsageConsumer. Any other role: line, including roles/bigquery.dataViewer, roles/iam.serviceAccountTokenCreator, or roles/iam.workloadIdentityUser, is a security finding even when the script prints it as OK. The script runs no positive read, and its write probe runs only when your identity can impersonate the service account (otherwise it reports SKIP).
    • Azure: az role assignment list --assignee "$OBJECT_ID" --all must show only Reader, Cost Management Reader, and Monitoring Reader on the subscription, plus the scoped Log Analytics Reader and Azure Event Hubs Data Receiver grants when enabled. verify.sh, run as an identity that holds only Reader, confirms the service principal and its credentials, but its allowlist also accepts write-capable roles such as Reader and Data Access, and its write probes test the calling identity, not the service principal.
  • 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 the content boundary. Venturi materializes invocation metadata (identity, service, project, cost, tokens, timing) and never persists prompt or completion bodies. Read access to a log source is not storage of its content: where a granted source can carry content, such as Amazon Bedrock model-invocation logs, scope the grant to the named log group, log view, BigQuery dataset, Log Analytics workspace, or Event Hubs namespace that supplies metadata. For any record that still contains content, the collector applies a field allowlist in memory, discards prompt and completion fields before a record is materialized, and never persists, logs, retries, or exports them. The normalized InvocationEvent schema has no field for prompt or completion text. See Data privacy & retention → what Venturi does not collect.
  • Understand the governance modes. The modes are Passive, Advisory (Shape), and Active (Gate). Advisory (Shape) is the default, and default onboarding never enables Active (Gate). You can enable Active (Gate) only for a named workload whose trust readiness has reached OPERATIONALLY_TRUSTED. In Active (Gate), 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. See Optimization & governance.

Finance 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 (Google Cloud), Cost Management (Azure). See Guided onboarding.
  • Configure budgets and alerts at the scope nodes that own spend. See Budgets & alerts.
  • Set the chargeback floor. Chargeback is gated at the Chargeback-ready band (coper >= 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.
  • Accept the chargeback-eligible export in-product. Review the period, manifest checksum, policy version, provisional and unknown amounts, then record Finance acceptance. See Chargeback acceptance.

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, an authorized operator, customer-owned source details, and the setup permissions required for the selected path. See Before you begin.
  • Run the self-service setup sequence: tenant provisioning → IdP federation → entitlement → provider keys → identity and cost mapping → deploy → verify → 1st attribution → 1st export → Finance acceptance. Venturi tenant, connector, federation, and external-ID setup artifacts are generated in-product. Customer-provided provider-account credentials or provider exports are entered in-product. Credentials remain tenant-local and are validated for read-only access wherever the provider offers read-only credentials. See Guided onboarding.
  • Reach active use within ≤30 minutes. Connect at least 1 evidence source or accept a provider export file, then inspect the 1st AttributionRecord on the /invocations surface through the quality feed.
  • Decide request-level attribution. For request-level data, either emit InvocationEvent records through the Ingestion API or deploy the fail-open drop-in proxy. For admitted requests, attribution dependencies behind the proxy fail open; this behavior is not configurable. The proxy endpoint remains on the request path. Use the client-side failover or alternative capture paths described in the service-level guide when the workload cannot accept that dependency. The proxy’s one deliberate rejection is tenant admission: a call whose provider key is not registered to your tenant is rejected before anything is forwarded, so register each key before you send traffic with it.
  • 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 confidence it cannot evidence. See Confidence & evidence.
  • Set up API access for automation under step-up-gated key creation in Settings / Admin / Credentials. A Venturi API key stays valid until it expires or you rotate or revoke it, so give each key the narrowest scope set, set an expiry within your tenant’s policy, and rotate it on a schedule. See Developers → REST API and Webhooks.
  • Generate and verify the chargeback export manifest for Finance. See Chargeback export.

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 do not exist. Server-side k=5 minimum-cohort suppression applies on every cohort read path: UI views, dashboards, filters, drill-downs, shared views, API responses, exports, board packs, and webhooks. Cohorts below 5 are suppressed and rolled into the parent unit, and they cannot be reconstructed by differencing overlapping cohorts. An Admin can raise the threshold; no role can lower it below 5 or disable it.

  • 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.
  • Confirm cohort reporting meets the use case. Individual-level reporting is outside the product boundary.

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 the Auditor-grant template and Roles & access control.
  • Reach the audit log and confirm its storage mode. Administrative, access, and policy actions are written append-only, attributed to the actor, and preserved through recovery; no product surface or API edits or deletes an entry. The 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 bypass-governance-retention permission can shorten or remove a lock before it expires, that permission is withheld from routine roles, and its use is recorded. Compliance mode is configured at onboarding where your deployment requires root-resistant retention; only Compliance mode prevents every principal, including the account root user, from deleting an entry or shortening its retention before expiry. Confirm which mode your deployment uses. 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 tenant verification state before relying on it. The implementation checklist records each control as verified, pending, not enabled, or not applicable; Docs authority & product state separates the customer-onboarding baseline from the post-onboarding roadmap.

SOC 2 attestation status

SOC 2 Type I readiness/report target on our security roadmap with Type II targeted within 12 months; it is not yet held. 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 decision-time interceptor’s fail-open allowance.
  • Set your support tier and escalation path. See Support tiers.
  • Confirm the tier-scoped commitments. Every tier carries the 99.9% serving-plane objective over 28 days. The 15-minute Sev-1 case acknowledgment target (around the clock), the 99.95% availability step-up, and the 5-minute index-freshness SLA apply under the Premium and Regulated tiers. Your order form names the tier you hold. See Support → tiers at a glance and Commitments by support tier.

Procurement track: confirm plan, residency, and subprocessors

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

  • Confirm the plan entitlements on your order form, including the role and feature ceiling they grant and the default API rate limits, and check that Settings / Admin / Billing shows the same entitlements. Custom roles can never resolve past that ceiling. Your plan is separate from your support tier. See Your plan and Custom roles.
  • Confirm the deployment mode and residency lane. Per-tenant data lives in a dedicated single-tenant data plane. In self-hosted mode, that data plane runs inside your own cloud account and trust boundary. In SaaS mode, Venturi operates it for you, single-tenant and region-pinned to your contracted residency lane. Neither mode pools operational data with another tenant. The control plane and the cross-tenant Aggregation VPC are region-pinned, and EU-origin data is processed in-region or under Standard Contractual Clauses (SCCs). See Deployment modes and Residency & subprocessors.
  • Review the subprocessor list and the change-notification and objection workflow. The dated, versioned subprocessor list for your tenant is available in-product and in the onboarding diligence pack; new or replacement subprocessors get advance notice with an objection window under the DPA. See Residency & subprocessors.
  • Collect diligence artifacts for vendor onboarding. See Trust center.

inference_geo residency control: post-onboarding roadmap

A customer-facing surface to pin where inference-time decisions are made is on the post-onboarding roadmap. Onboarded deployments use the contracted residency lane and the region-aware fields in the event schema. See Compliance → GDPR data residency.

Legal owns the contractual privacy terms for cohort-level workforce processing.

  • Execute the DPA. Venturi acts as processor; your organization is the controller. The DPA commits the GDPR Article 28 processor obligations, including the Art. 28(3)(a) to (h) terms and the Art. 28(2) subprocessor change-notification and objection workflow. See Data-subject rights → processor, not controller.
  • Confirm the Workforce-Data purpose and lawful basis for cohort-level adoption reporting. Individual-level views are not available.
  • 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 → privacy-program artifacts in the onboarding diligence pack.

Privacy review precedes workforce-cohort processing

The legal classification of cross-tenant aggregation outputs and the precise erasure exemptions are documented in the privacy assessment for your deployment before workforce-cohort processing begins. The onboarding diligence pack includes the DPA, the lawful-basis mapping, the DPIA template (GDPR Art. 35), and the works-council pack for you to adapt. Venturi maintains a Record of Processing Activities (RoPA, GDPR Art. 30) for metadata processing in the dedicated tenant data plane (your cloud account when self-hosted, or the Venturi-operated single-tenant environment in SaaS mode) and cross-tenant aggregation.

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.

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. Venturi delivers it within 5 business days of the termination effective date, and a retrieval window (30 days by default, contract-configurable) runs before any key destruction. 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.
Give feedback on this page

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

Copy page details 
Docs feedback: Enterprise readiness checklist
Page: https://docs.venturi.systems/onboarding/enterprise-readiness-checklist/