Coverage and unknowns¶
Venturi's defining discipline is that it refuses to guess. When the evidence doesn't support an owner, the spend is shown as an honest 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 isn't, and why — and where you turn unknowns into resolved ownership.
This is the surface a prospect uses to prove no-manual-tags attribution on their own data, and the surface a finance team uses to know how much spend is billable before they export anything.
Coverage: how much of your estate is attributed¶
Coverage (Resolve → Coverage) answers one question at your current scope:
what share of my AI spend resolves to a confident owner, and what doesn't?
It shows:
- Attribution coverage — the share of spend that resolves to an owner at all.
- Chargeback-ready coverage — the share that clears the
coper ≥ 0.80chargeback floor and is therefore billable. - 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.
The coverage score combines source freshness, pathway capture, identity resolution, billing reconciliation, and the confidence distribution. A high coverage score means the estate is observable enough to make operational decisions; 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 don't 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 |
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. See integration health 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, carrying the ingestion layer and provider hint that produced it, and the Pathway Coverage KPI counts those unclassified events against its 100% target. You never see a green 100% while whole classes of spend sit quietly unresolved.
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 (e.g. gateway API, SaaS-embedded, client-side, shadow AI) |
| Events seen | How much activity Venturi observes on this pathway |
| Not-identifiable share | The fraction of this pathway that resolves to an honest 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.
Detected, even when it can't be billed
Some pathways — shadow AI, client-side calls, opaque SaaS-embedded features — can be detected (via CASB, DNS, or admin-API signals) 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 precisely the spend a CISO most needs to see.
Capture coverage vs. your total AI spend¶
A coverage percentage is only honest if 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 doesn't 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.
We tell you what the coverage number is measured against
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 can't 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 |
Confident, attributed, chargeback-eligible |
strongly_inferred |
Confident, attributed, chargeback-eligible |
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 (Resolve → Unknowns) is the working surface for everything that
didn't 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's 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 isn't 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 doesn't yet observe | Extend connector or gateway coverage |
| Provider billing delay | The cost hasn't finalized on the provider's bill yet | Resolves on reconciliation |
| Below the chargeback floor | Evidence is too weak to bill on (coper < 0.80) |
Strengthen the signal, or keep as analysis-only |
| Not identifiable | The signal can't 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 honest 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'd work any work 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's metadata, it never changes attribution.
- Open a dispute on any row to investigate, and resolve it with an audited override when you've 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, 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 isn't attributable. See governance & exports.
Next steps¶
- Use Attribution detail to open the evidence drawer, dispute, and override the unknowns you triage here.
- Use Confidence and evidence to learn the output states and the honest-unknown discipline in full.
- Use Optimization & adoption once coverage is solid to turn attributed spend into savings.
- Use Send events — the fastest way to close telemetry-driven unknowns.
- Read the known-limitations register for the honest list of pathways that stay detected-only and the fallback behavior behind degraded results.