Skip to content

The attribution engine

The attribution engine turns raw, fragmented AI signals (gateway logs, provider usage records, cloud billing, identity directories, code ownership) into a single, queryable answer to the question every finance and engineering leader asks:

Which team, which service, which identity, and which budget is responsible for this AI spend?

The engine answers that question without relying on manual tags, attaches a calibrated confidence score to every answer, and shows its work. This section explains how it does that, in enough depth to trust the numbers on your dashboard and act on them.

What the engine produces

IDD classifies source evidence before attribution. Invocation-grade evidence uses the canonical InvocationEvent contract; discovery observations remain observations and do not create Invocation nodes. Aggregate usage and entitlement evidence retain their source scope and permitted uses.

Platform materialization publishes each eligible invocation result as a versioned AttributionRecord. A record preserves resolved, inferred, and unresolved relationships in the attribution graph and carries, for every attributed edge:

  • Who and what: the service, identity, project, organization, and budget responsible.
  • How much: billed cost, token counts, and (where the model is in the catalog) energy and carbon.
  • How sure: an operational confidence score, coper, and a confidence band.
  • How it was decided: the output state, the stage that produced it, and the evidence behind it.

You consume these records through dashboards, the FOCUS chargeback export, budgets and alerts, and the REST API. The engine is the source; every surface downstream is a view onto the same records.

How it works, end to end

Canonical invocation events enter platform Stage A for deterministic resolution first. Only eligible unresolved ownership relationships reach RAIL (Resource Attribution & Inference Layer) in Stage B. RAIL also owns the research and training machinery that supplies its verified models. Shared costs may enter the separate Stage C allocation subsystem; allocation preserves ownership and conserves the invoice total. The stages follow these conditional paths:

Condition Path
Stage A resolves an ownership edge. Platform materialization applies the 0.95 coper cap and publishes the AttributionRecord.
An unresolved edge is eligible for inference. Stage B returns cpost, evidence, and alternatives to platform materialization.
Cost from Stage A or Stage B is genuinely shared. The separate Stage C allocation subsystem splits the cost before materialization.

The materialized record feeds the index and API, then dashboards, exports, and alerts. The ownership paths show where inference is optional and where the separate allocation path applies.

  1. Stage A: deterministic resolution. Venturi builds the attribution graph from facts. Join keys and rule-based matching resolve every edge that can be resolved with certainty (account-to-identity, service-to-project, identity-to-organization) using your existing source data. No machine learning is involved.

  2. Stage B: trained edge-existence inference. For the genuinely ambiguous residual that deterministic rules cannot resolve, RAIL’s trained attribution model infers the most likely edge and attaches a calibrated confidence. Stage B runs in the asynchronous processor under a 20 ms timeout inside the processor’s 100 ms P99 budget. The processor falls back to a conservative heuristic baseline, so attribution processing keeps flowing, when any of the seven Stage B fallback conditions occurs:

    • the call reaches its 20 ms timeout;
    • the model artifact is missing;
    • the model returns an invalid output;
    • Stage B is disabled for that edge by flag;
    • the call is shed because 8 calls are already in flight on that processor instance;
    • the circuit breaker is open because the timeout rate exceeds its configured threshold (default: 5% over a 100-call rolling window);
    • the edge’s readiness gate vetoes serving the trained model for that edge (a fail-closed, per-edge veto).

    Customer traffic fail-open is enforced separately by the decision-time interceptor.

  3. Stage C: fractional allocation. When a cost is genuinely shared across multiple owners (a shared API key, a shared endpoint, a shared service), Stage C’s allocation subsystem splits it fractionally across the candidates so that allocations always sum to 100% of the cost.

The result is a single record that distinguishes what Venturi resolves with high confidence, what it has inferred, and what it cannot resolve, without ever collapsing those distinctions into a falsely precise number.

The principles the engine never breaks

These invariants hold on every deployment and shape everything else in this section.

Fail-open on your AI traffic

The engine never sits in the way of a live AI request. The decision-time interceptor on the synchronous hot path performs a fast index lookup, works to a 50 ms P99 end-to-end budget with a cooperative timeout against a cumulative deadline, and forwards the request unmodified on breach; your traffic flows even if attribution is momentarily degraded. Attribution catches up asynchronously.

Calibrated confidence, never false certainty

Operational confidence (coper) is capped at 0.95: a deliberate, conservative policy ceiling. Venturi never asserts that an attribution is certain. Chargeback-eligible attributions must clear a confidence floor of 0.80. See confidence and evidence.

No prompt or completion content

The engine attributes consumption from metadata: tokens, cost, model identity, timestamps, identity and ownership signals. It never stores the content of prompts or completions. The default cloud read grants can reach content-bearing logs, such as provider content logging you enable and Vertex AI container logs, which are on by default. Content fields from those logs are discarded in memory before a record is materialized; see Trust & security. Integrations are read-only.

Unknown is a first-class answer

When the evidence genuinely does not support an attribution, the engine says so explicitly rather than guessing. Unattributed and shared spend is surfaced and exportable, never hidden inside an aggregate.

Where to go next

If you want to understand… Read
The layers Venturi links signals across The attribution graph
The three stages, in detail The attribution pipeline
What confidence means and how to act on it Confidence and evidence
How Venturi estimates energy and carbon Energy and carbon attribution
How to connect your environment Onboarding
Give feedback on this page

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

Copy page details 
Docs feedback: The attribution engine
Page: https://docs.venturi.systems/engine/