Skip to content

Dashboard overview

This page is the tour of app.venturi.systems: how the screens are laid out, how to move around, how to read any table on the platform, and how the time-basis and freshness model keeps every number honest. Once you understand these patterns, every surface in the app works the same way.

The screen layout

Every page shares one frame:

  • A persistent left navigation grouped by job-to-be-done — Monitor, Resolve, Optimize, Operate, Admin — showing only the destinations your role entitles you to.
  • A page header with the page title, the active scope (organization, workspace, team, or project), the time view control, the freshness stamp, and the surface-level actions (filter, save view, export).
  • A main content area — almost always a table or a set of metric tiles over a table.
  • A command palette and global search, reachable from anywhere by keyboard.

Within an object page (a single team, service, or model), local tabs expose that object's facets — for a team: Overview · Spend · Models · Coverage · Disputes — without losing your place. Switching a tab never drops your filters or your selected time view.

The table is the product

Venturi's core surfaces are tables, not charts. The Invocation feed, the team and model rollups on Overview, the Coverage gap list, the Unknown Spend Analyzer, and the Exports queue are all first-class tables — because a number your finance team can sort, filter, and trace is a number they can defend. Tiles and charts summarize; the table is where you stand behind a figure.

The Overview screen

Overview (Monitor → Overview) is the home of the app and the first thing most users open. It answers, at your current scope: how much AI am I spending, who owns it, and how much of it can I trust?

It surfaces:

  • Total AI spend for the period, with its method label (estimated or reconciled) and freshness.
  • Attribution coverage — the share of spend that resolves to an owner, and the share that is an honest unknown.
  • The confidence distribution — how your attributed spend splits across the Chargeback-ready, Provisional, and Estimated bands, so you can see how much is billable before you export anything.
  • Spend by team and spend by model rollups, each drillable down to the invocation and its evidence.
  • Energy and carbon for the same scope, drawn from the covered-model catalog.

Every tile names its metric, time basis, method, and confidence semantics, and any two tiles that report the same metric for the same scope reconcile to the same figure. Click any aggregate to drill straight down to its constituents.

Reading a table

All analytic tables behave identically, so the patterns transfer everywhere.

Faceted filters

Every table supports the same facet set. Filter by:

  • Time range and basis (see below)
  • Team, service, model, provider
  • Output state — one of the six states (deterministically_resolved, strongly_inferred, bounded, ambiguous, unknown, not_identifiable)
  • Confidence bandChargeback-ready, Provisional, Estimated
  • Pathway category — one of the 20 classes describing how an invocation reached its owner
  • Capture-feasibility class and anomaly category
  • Degradation state

Facet counts always reconcile to the result total, and you can sort by multiple keys (for example, cost descending, then confidence ascending). Filtering the Invocation feed by output_state = ambiguous and a confidence band and a pathway category returns exactly the rows that match all three.

Interpretation metadata on every row

Each row carries its full interpretation metadata: stage origin, output state, coper and its band, evidence basis, model version where inference was involved, degradation state, and freshness. You never have to leave the table to know how a number was produced — and you can always open its evidence drawer to see the full basis.

Large tables stay fast and complete

Tables are server-paged and virtualized, so a million-row Invocation feed scrolls smoothly and exports completely. Counts and totals always reflect the full filtered set, not just the visible page.

Time views and freshness

A monetary figure is meaningless without knowing as of when and measured how. Venturi makes both explicit on every screen.

The time-view control

The page header time view selects how the period is interpreted:

Time view Shows you Use it to
Event time Spend as it occurred, by the timestamp of each invocation Reconcile to a billing period
Current state The latest resolved attribution for each invocation See where ownership stands now
Comparative One period against another Spot trends and regressions

Your selected time view persists as you navigate and is preserved in any saved view and export.

Method labels: estimated vs reconciled

Every cost figure is labeled with how it was measured:

  • estimated — computed from observed usage before the cloud bill finalizes.
  • reconciled — confirmed against the finalized, reconciled-actual cloud bill.

Cost is always computed on the model actually served, with measured tokens — never on the model requested, and never from a list price. This is why a "cheaper" reasoning model that expands its thinking tokens is shown at its true, higher cost rather than its sticker price.

Freshness, and the live indicator

The dashboard reads the materialized attribution index, which refreshes on a short cycle, so every surface stamps the time its data was current as of. A recalculation indicator appears within a moment of any change so you always know whether you're looking at settled or still-moving numbers. Index freshness targets P99 within about 90 seconds for the live index, with fully reconciled figures settling within a day.

Why dashboards are fast

The app reads a pre-computed index, not the live inference path. Cold authenticated load is under three seconds and in-app navigation between loaded pages is under a second. These read-path targets are entirely separate from — and never block — your AI gateway traffic.

Saved views

Any filter, sort, column, and time-basis configuration can be saved as a named saved view. Saved views are first-class objects: set one as your personal default, share or publish it to your team, schedule a report from it, or drive an alert off it.

A shared view always renders under each recipient's own access — individual-level workforce data stays hidden for non-workforce roles, EU rows respect residency, and small cohorts stay suppressed. Sharing a view never grants anyone data they couldn't otherwise see.

Saved view: "Payments — chargeback-ready, this month"
  scope:        Team:Payments
  time basis:   Event time · 2026-05
  filters:      output_state ∈ {deterministically_resolved, strongly_inferred}
                confidence band = Chargeback-ready
  columns:      Team · Model · Provider · EffectiveCost · coper · Output state
  sort:         EffectiveCost desc, coper asc

Exporting what you see

Any table or saved view exports to CSV, Excel, or JSON, carrying the interpretation metadata as columns — output state, coper, method label, and freshness — so the exported file is self-describing and reconciles to the on-screen totals. For the auditable FOCUS chargeback file and scheduled delivery, see governance & exports.

Honest states you'll see

The app surfaces the truth instead of papering over it:

  • Unknown spend renders as an em-dash, never a fabricated $0.00.
  • Empty and partial states are explicit — a partial-residency result tells you some rows are withheld by residency rules rather than silently dropping them.
  • A degraded-data banner appears if any underlying attribution was produced by a fail-open fallback, and the degradation state travels with the data into exports. A degradation banner is never used to mask an access denial.
  • Access denials are shown as a permission message that names the determining factor — not a generic error.

Accessibility

The whole app meets WCAG 2.2 AA: full keyboard operation including the command palette, semantic landmarks and a skip-to-content link on every route, consistent navigation and control identity across pages, live-region announcements for long-running jobs, and no change of context on focus or input without an explicit action.

Next steps