Platform

Resolve every AI call to the owner and budget responsible.

Your AI bill shows spend. It does not show ownership. Venturi builds an attribution graph inside the customer environment, resolving every model invocation to its service, code owner, identity, org, and budget.

No tags. No code-ownership spreadsheet. No gateway-only blind spot.

Review an Attribution Path

Illustrative example

Decision record

support-router-prod

Chargeback-ready

Confidence

0.91

Winning owner: Customer Ops Platform
Budget: CX Automation
Action: Shape recommendation

Computed inside the customer environment. Raw telemetry never leaves.

What the platform resolves

Six attribution layers turn usage telemetry into accountable decisions.

Token and cost totals show that spend moved. Venturi resolves why: which service produced it, which code owner is accountable, which identity triggered it, and which org and budget should absorb it.

Illustrative example

Six-layer chain

Invocation to budget attribution

confidence cap 0.95

Model invocation

model usage telemetry

anthropic.claude-sonnet

0.95 Resolved
Service attribution

route, trace, vendor project

support-router

0.94 Resolved
Code ownership

CODEOWNERS, deploy SHA

Customer Ops Platform

0.91 Chargeback-ready
Identity resolution

Okta group, service account trace

svc-support-router

0.86 Plausible
Org hierarchy

SSO group and budget hierarchy

CX Operations

0.89 Resolved
Budget attribution

finance budget path

CX Automation

0.91 Chargeback-ready

Decision-time path

Shape is the default advisory path. Gate is separate and explicit.

The decision-time interceptor reads from the attribution index and adds context when it is available. Fail-open is absolute: when enrichment cannot finish within budget, the request proceeds unmodified. Optimizer, never enforcer.

01

Observe-only

Unknown

Unknown or incomplete records stay visible, but they are not ready for chargeback or enforcement.

02

Shape recommendation

The default path enriches approvals, review queues, and budget conversations with advisory recommendations.

03

Chargeback-ready

Evidence is strong enough across model, service, code owner, identity, org path, and budget to support finance review.

04

Gate opt-in

Gate requires explicit customer configuration for a workload and policy class. It is never enabled by default.

How attribution is computed

Immutable events first, graph second, decision-time index third.

The graph is derived state. Corrections create new events, never overwrites. The interceptor reads a precomputed attribution index rather than traversing the graph at decision time.

Illustrative example

Evidence stack

Fragmented signals become auditable confidence.

Direct match

vendor project, route, service ID

Strong evidence

Resolved

Temporal correlation

deploy window and usage spike

Supporting evidence

Plausible

Naming convention

service account and budget prefix

Weak supporting evidence

Plausible

Historical pattern

prior owner and workload cadence

Supporting evidence

Contested

Service account tracing

shared key fanout

Contested evidence

Contested

Proportional allocation

usage share across owners

Allocation prior

Shape recommendation

Operational confidence

0.91

HRE preserves unresolved and contested evidence. Corrections create new events, and the attribution graph remains derived state. Confidence is calibrated, capped at 0.95, and not additive: stronger and weaker evidence are reconciled, never summed.

Decision records

Resolved, contested, and unresolved records stay inspectable.

A decision record is useful only when reviewers can inspect why an owner won, which candidates lost, which evidence was used, and what action class follows from the confidence score.

Illustrative example

Decision record

agent-eval-runner

req_c448af · openai.gpt-4.1

Operational confidence

0.68

Contested Gate-ineligible

Winning owner

AI Platform

Budget

Model Quality Programs

Service

quality-evals

Request class

evaluation batch

Time basis

deployment window

Illustrative example

Decision record

shared-notebook-key

req_unknown · gemini.1.5-pro

Operational confidence

0.31

Unknown Gate-ineligible

Winning owner

Unknown

Budget

Unassigned AI spend

Service

unknown service

Request class

ad hoc analysis

Time basis

month-to-date

Why Venturi

Every inference request is a decision problem.

Venturi asks a simple question in the decision path: which advisory action minimizes total risk-adjusted cost given the available evidence?

Plain English

Venturi places attributed context in the decision path. Shape mode recommends and enriches by default. Gate mode is available only when a customer explicitly opts in for a workload.

Show formal decision rule

Decision Rule

arg min

a ∈ Actions

TRAC(a)

Shape mode returns recommendations, enriched context, and review evidence. Gate mode can block only for workloads where the customer has explicitly enabled that workload and policy path.

Actions

The available moves.

Model choice, routing decision, region, and configuration. Venturi evaluates the viable options before the workload decision is made.

TRAC

Total Risk-Adjusted Cost.

Direct cost plus a confidence risk premium. Not just what the request costs, but how much uncertainty remains in the owner, budget, and service chain.

Deployment path

Start with read-only signals and one unclear workload.

The first deployment should prove attribution coverage before any advisory workflow turns on. Shape recommendations reach reviewers only after the customer trusts the evidence. Gate stays opt-in and workload-specific.

Connector inventory

Integration surface without a logo wall.

Read-only first

Cloud

AWS, Azure, GCP

Data used: billing, cost APIs, usage tags where present
Permission: read-only cost and monitor APIs
Excluded: resource modification, secrets, production writes
Contribution: hourly or daily export budget and vendor project confidence

CI/CD

GitHub Actions, GitLab CI, Jenkins, Buildkite

Data used: deployment metadata, service IDs, release timestamps
Permission: metadata read
Excluded: deployment mutation
Contribution: event or scheduled sync service and release attribution

Source control

GitHub, GitLab, Bitbucket

Data used: repository metadata, ownership, CODEOWNERS
Permission: metadata read
Excluded: source code content
Contribution: scheduled sync code ownership confidence

Show all 6 connector groups

Identity

Okta, Azure AD, Google Workspace

Data used: users, groups, service identities
Permission: directory read
Excluded: identity writes and password data
Contribution: scheduled sync identity and org path confidence

HCM and org

Workday, Oracle HCM, generic HCM

Data used: org hierarchy and team membership
Permission: limited org read
Excluded: salary, performance, sensitive HR data
Contribution: daily sync budget and adoption projection context

Telemetry

model usage, token usage, latency, cost signals

Data used: usage totals, routes, latency, request classes
Permission: read-only telemetry export
Excluded: prompt and output export
Contribution: stream or batch invocation and service attribution

Group	Data used	Permission	Excluded	Contribution
Cloud AWS, Azure, GCP	billing, cost APIs, usage tags where present	read-only cost and monitor APIs	resource modification, secrets, production writes	hourly or daily export budget and vendor project confidence
CI/CD GitHub Actions, GitLab CI, Jenkins, Buildkite	deployment metadata, service IDs, release timestamps	metadata read	deployment mutation	event or scheduled sync service and release attribution
Source control GitHub, GitLab, Bitbucket	repository metadata, ownership, CODEOWNERS	metadata read	source code content	scheduled sync code ownership confidence
Identity Okta, Azure AD, Google Workspace	users, groups, service identities	directory read	identity writes and password data	scheduled sync identity and org path confidence
HCM and org Workday, Oracle HCM, generic HCM	org hierarchy and team membership	limited org read	salary, performance, sensitive HR data	daily sync budget and adoption projection context
Telemetry model usage, token usage, latency, cost signals	usage totals, routes, latency, request classes	read-only telemetry export	prompt and output export	stream or batch invocation and service attribution

Projections, not modules

Decision-enabling intelligence, not another reporting layer.

Cost attribution and adoption intelligence are two projections of the same attribution graph, resolved to one confidence-scored decision record. They answer different operating questions without becoming separate product modules. Every component runs inside the customer environment behind a read-only boundary; the full trust boundary is detailed on Security.

Which service caused the spend?
Which team owns the usage?
Which budget absorbs the cost?
Which lower-cost model is acceptable?
Which workload is contested?
Which usage is ready for chargeback?
Which request should receive a Shape recommendation?

Design partner review

Bring one unclear workload.

No production data is required for the first conversation. Start with one workload, one unclear owner or budget path, and the decision your team cannot make confidently today.

Review an Attribution Path See the trust boundary

Useful starting points

Spend owner AI spend is rising but ownership is unclear
Shared identity a shared key or service account lacks an accountable owner
Model change a model migration has unresolved cost and quality tradeoffs
Budget path a budget review cannot tie AI spend to services or teams