Skip to content

Coverage & unknowns

Venturi’s defining discipline is that it refuses to guess. When the evidence does not support an owner, the spend is shown as a reported unknown rather than silently assigned to the nearest team. The Coverage and Unknown spend surfaces are where you see exactly how much of your AI estate is attributed, what is not, and why; and where you turn unknowns into resolved ownership.

This is the surface you use to prove, on your own data, that Venturi attributes AI spend without relying on manual tags. It is also where your finance team sees how much spend is billable before anyone exports anything.

How much of your estate is attributed

Coverage (Quality / Coverage) answers one question at your current scope: what share of my AI spend resolves to a confident owner, and what does not?

It reports four coverage measures. Each one has its own denominator, so they are never interchangeable:

Measure What it measures Target or objective
Capture coverage Observed AI spend as a share of your independently anchored AI estate (cloud-billing AI line items, finance GL categories, provider invoices, or declared AI tooling). Without an anchor, it is labeled as measured against the instrumented estate only. No fixed target; the undetected residual is shown alongside it
Pathway coverage Ingested events assigned to one of the 20 named pathway categories as a share of all ingested events. Events held as Unclassified: pending rule count against it. It measures classification, not ownership. 100% pathway-coverage target
Attribution coverage Capturable usage that resolves through the attribution chain to an owner at or above the 0.80 confidence floor, as a share of all capturable usage. 0.95 attribution-coverage objective; contracted floors are 0.90 for Standard and 0.95 for Premium and Regulated (SLAs & SLOs)
Chargeback-ready coverage Spend, in dollars, whose attribution is Chargeback-ready (coper >= 0.80), as a share of captured spend. This is the pool a default chargeback export draws from; a heuristic-baseline or degraded result in it stays out of chargeback until the same edge is re-observed under trained-model attribution (what a chargeback includes). No fixed target; it rises as you resolve unknowns

The two targets answer different questions. A 100% pathway coverage means every event is classified into a named route, including routes that are detected-only or uncapturable; it says nothing about who owns the spend. The 0.95 attribution-coverage objective measures how much capturable usage resolves to an owner with enough confidence to act on. Complete pathway classification can therefore coexist with unresolved spend.

Alongside the four measures, Coverage shows:

  • The unknown and shared fraction: spend Venturi can see but cannot responsibly assign, broken out by why.
  • Completeness and freshness: every coverage figure carries a data-quality descriptor: completeness, freshness timestamp, dedup status, lineage depth, and confidence band.

Coverage also rolls these inputs into a composite coverage score that combines source freshness, pathway capture, identity resolution, billing reconciliation, and the confidence distribution. It is a readiness summary, not a fifth coverage ratio: a high coverage score means the estate is observable enough to make operational decisions, and it never implies certainty about every individual row.

Completeness is never imputed to zero

A rollup that sits below your configured completeness floor shows the coverage gap explicitly; it never quietly treats missing data as $0.00. You always know the difference between “this team spent nothing” and “we do not yet have complete data for this team.”

Coverage by source

Coverage improves as you connect more of your estate. The Coverage page attributes your completeness to its sources so you know exactly what to connect next:

Source What it adds How to improve it
Cloud connector Account- and team-level attribution from billing, usage, and identity data Connect your cloud
Request-level events Per-call resolution: tokens, served model, cost, and the identity behind each call Send InvocationEvents
Gateway coverage Identity binding for calls routed through your AI gateway Increase gateway routing
Identity / org data Resolution of identity → org → budget across trust boundaries Keep your IdP and HRIS current
Discovery sources (CASB, DNS/firewall logs, provider admin APIs) Detection of pathways, such as shadow AI, that no request-level source observes; entries go to the discovery ledger, not to attribution Connect the CASB and DNS/firewall connectors

Connector health feeds coverage directly. A connector that goes stale moves to a degraded state and raises a freshness alert, and the affected coverage is shown as a gap rather than as confident attribution, so a silent ingestion failure can never masquerade as resolved spend. Admins, and users granted connector settings access, see each connector’s health at Integrations in the admin console.

Coverage by pathway

Sources tell you what to connect; pathways tell you where the blind spot is. Every event Venturi ingests resolves to one of 20 named pathway categories: the distinct routes AI spend takes through your estate, from gateway-routed API calls to embedded SaaS features to client-side and shadow usage. Nothing collapses into an anonymous “other” bucket: an event that has no classification rule yet is held in a named Unclassified: pending rule state (UNCLASSIFIED_PENDING_RULE), carrying the ingestion layer and provider hint that produced it, and pathway coverage counts those unclassified events against its 100% target. You never see a green 100% while whole classes of spend sit quietly unclassified.

Each category has a default capture-feasibility class: fully capturable (first-party request telemetry), partially capturable (cost or telemetry is derived rather than invoiced per request), indirectly capturable (usage is inferred from billing records or seat counts), or uncapturable (no direct telemetry path; at most detected through discovery sources). An individual event carries its own capture-feasibility class, which can differ from the default depending on how it was captured.

The Capture column gives each category’s default capture feasibility.

Category Coverage Capture
DIRECT_API Calls from your code straight to a model provider’s API, such as OpenAI or Anthropic Fully capturable
AI_GATEWAY Calls routed through your AI gateway or network proxy Fully capturable
AWS_BEDROCK Amazon Bedrock managed inference Fully capturable
AZURE_OPENAI Azure OpenAI managed inference Fully capturable
VERTEX_AI Vertex AI managed inference Fully capturable
MANAGED_OTHER Other cloud-managed model services Fully capturable
BATCH_API Provider batch APIs Fully capturable
SELF_HOSTED Models you host on your own infrastructure Partially capturable
ORCHESTRATION_FRAMEWORK Calls made through an orchestration framework in your application Partially capturable
AGENTIC_AI Agentic workflows that chain model calls and tools Partially capturable
MODEL_ROUTER Calls dispatched through a model router Partially capturable
DEVELOPER_TOOL AI developer tools, such as coding assistants Partially capturable
FINE_TUNING_TRAINING Fine-tuning and training jobs Partially capturable
DATA_PLATFORM_AI AI functions inside data platforms, such as Snowflake, Databricks, or BigQuery Indirectly capturable
SAAS_EMBEDDED_PER_SEAT AI features embedded in SaaS products and licensed per seat Indirectly capturable
SAAS_EMBEDDED_CONSUMPTION AI features embedded in SaaS products and billed by consumption Indirectly capturable
RPA_WORKFLOW AI steps inside RPA and automation workflows Indirectly capturable
EDGE_ON_DEVICE Inference that runs on end-user devices or at the edge Uncapturable
CLIENT_SIDE_AI Browser or desktop calls that bypass your gateway Uncapturable
SHADOW_AI Unsanctioned AI tools and personal accounts Uncapturable

The coverage map turns that into a per-pathway picture, so you can see which route is degraded and exactly which integration would close it:

Column What it tells you
Pathway The named category from the table above (for example AI_GATEWAY, SAAS_EMBEDDED_CONSUMPTION, CLIENT_SIDE_AI, or SHADOW_AI)
Events seen How much activity Venturi observes on this pathway
Not-identifiable share The fraction of this pathway that resolves to a reported unknown
Dominant missing source The single connector or signal whose absence drives most of the gap
Would-close integration The named integration that upgrades this pathway’s coverage

When the engine returns not_identifiable for an event, that verdict carries the event’s pathway category with it, so a blind spot always arrives labeled with the pathway it belongs to and the source that would resolve it. The coverage map is how you prioritize connector work by impact: sort by not-identifiable spend, read the dominant missing source, connect it, and watch that pathway’s coverage rise on the next cycle. The same per-pathway coverage map is available through GET /api/v1/coverage.

Detected, even when it cannot be billed

Some pathways (shadow AI, client-side calls, opaque SaaS-embedded features) can be detected without being attributable at request granularity. Venturi keeps these as a standing, trended line in a discovery ledger: each entry names the detecting source, first- and last-seen dates, a best-effort activity magnitude (labeled an estimate, never an invented dollar figure), and the integration that would make the pathway capturable. These pathways stay out of the chargeback denominator (they are never billed as if they were attributed) but they remain counted in your completeness and adoption view. A discovered blind spot never silently disappears just because it carries no attributable spend; that is the spend your security team most needs to see.

CASB, DNS/firewall, and provider admin-API signals are discovery-only wherever they cannot supply request-level evidence. A CASB, DNS, firewall, or EDR observation shows that a user or device reached an AI provider (a CASB record can name the user), but it does not identify the individual request or its cost. A provider-domain or IP match therefore never becomes request-level attribution on its own. A provider admin API that reports only aggregate usage adds detection and an activity magnitude, not per-request ownership. A pathway moves from the discovery ledger into attribution only when a request-level source (a gateway, proxy, SDK, or InvocationEvent) independently supplies the invocation, identity, and cost evidence. The known-limitations register lists the pathways that stay detected-only.

Capture coverage vs. your total AI spend

A coverage percentage means little unless you know what it is a percentage of. Where an independent anchor for your total AI spend exists (cloud-billing AI-service line items, finance GL AI-vendor categories, provider-account invoice totals, or procurement-declared AI tooling), Venturi reconciles the sum of detected pathway spend against that anchor and surfaces the difference as an explicit undetected-spend estimate: a labeled lower bound on spend Venturi does not yet see. Your capture coverage is then measured against your real estate, not against itself, and the executive summary shows the undetected residual alongside it.

Every coverage figure names its denominator

Where no independent spend anchor exists, the coverage report states plainly that the figure is “measured against the instrumented estate only; total-estate completeness is unverified.” Venturi never implies it sees all of your AI spend when it can only see the part it has been connected to. “Capture coverage 87%” always carries its denominator, so a finance leader reads it as coverage of a known total, never as a structurally optimistic number that cannot be checked from outside the product.

The six output states

Coverage is built on the six output states the engine emits. Every invocation lands in exactly one, and they never blur:

Output state Counts toward coverage as…
deterministically_resolved Attributed; chargeback-eligible when coper >= 0.80 and not degraded
strongly_inferred Attributed; chargeback-eligible when coper >= 0.80 and not degraded, so never while it rests on the heuristic-baseline fallback
bounded Attributed to a constrained range: visible, not yet billable
ambiguous Multiple plausible owners: a candidate set, not a single owner
unknown Seen, but unattributable on current evidence
not_identifiable Cannot be tied to a known node in your environment

The last two states are how Venturi tells you the truth instead of guessing. They are fully visible, fully exportable, and never coalesced into an aggregate or assigned to the nearest team.

The Unknown Spend Analyzer

Unknown spend (Quality / Coverage / Unknown spend) is the working surface for everything that did not confidently resolve. Instead of discovering coverage gaps mid-audit, you work them down here as a prioritized queue. Unknown spend is a first-class output, not a hidden remainder.

The Analyzer is a table (sortable, filterable, exportable) where each row is a slice of unattributed or shared spend, and every row tells you why it is unknown.

Why something is unknown

Open any row’s evidence drawer and the reason is named explicitly, which tells you what kind of fix it needs:

Reason What it means Typical fix
Stale org data The identity resolved, but the org/budget mapping is out of date Refresh your HRIS/IdP feed
Shared API key A key is used by multiple teams, so no single owner is justified Split the key, or accept a fair allocation
Unmapped identity The caller is not in your identity inventory Add the identity mapping
Conflicting metadata CI/CD or deployment signals disagree Resolve the source conflict
Uncaptured pathway The invocation reached a provider by a path Venturi does not yet observe Extend connector or gateway coverage
Provider billing delay The cost has not finalized on the provider’s bill yet Resolves on reconciliation
Below the chargeback floor Evidence is too weak to bill on: Provisional (0.50 <= coper < 0.80) or Estimated (coper < 0.50) Strengthen the signal, or keep as analysis-only
Not identifiable The signal cannot be tied to any known node Genuine limit, or a new connector is needed

This separation is the whole point: a data-quality unknown is something you fix at the source, a coverage unknown is something you fix by connecting more, and a genuine unknown is the correct answer. Each group names the next operational action and tells you whether resolving it affects chargeback, adoption, optimization, or reporting.

Triaging the queue

Work the Analyzer the way you would work any queue:

  • Sort by spend to attack the largest unattributed dollars first.
  • Filter by reason to batch the fixes, for example, every “stale org data” row at once.
  • Assign and comment on an unknown-spend item like any other workflow object; collaboration here obeys the same rule as everywhere: it is metadata, and it never changes attribution.
  • Open a dispute on any row to investigate, and resolve it with an audited override when you have established the true owner.

A gap is marked resolved only after the underlying source is fixed (or an override is committed); every resolution is auditable and visible in the record history.

From unknown to chargeback-ready

The most common workflow on this page: sort unknowns by spend, open the top row, read the named reason in its evidence drawer, fix the underlying source (or commit an override), and watch that spend move into chargeback-ready coverage on the next index cycle. Each fix raises your chargeback-ready coverage measurably.

Shared and allocated spend

Some spend is genuinely shared: a model serving many teams behind one key. Venturi never pretends a shared cost has a single owner. Instead, Stage C allocates a fair fractional share across the resolved owners, conserving 100% of the spend. These allocated splits are deliberately capped below the chargeback floor (at 0.70 where proportional allocation signals are present, and at 0.50 where the split rests on no such signal), so a shared-cost estimate is shown for context and analysis but never billed back as if it were direct ownership. See cost attribution & chargeback.

Exporting coverage

Coverage and unknown-spend tables export to CSV, Excel, or JSON with their interpretation metadata as columns: output state, coper, the unknown reason, method label, and freshness, so a coverage report is self-describing and reconciles to the screen. This is how you hand finance a defensible picture of exactly what is and is not attributable. See governance & exports.

Next steps

Give feedback on this page

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

Copy page details 
Docs feedback: Coverage & unknowns
Page: https://docs.venturi.systems/dashboard/coverage-and-unknowns/