Skip to content

Optimization & governance

Use this guide to review optimization candidates, evaluate their evidence, move an approved intervention through its lifecycle, and verify realized savings. Attribution is the prerequisite. Optimization runs in Advisory (Shape) by default, and every recommendation is confidence-gated, auditable, and reversible. Venturi never changes your systems itself: you apply an approved change in your own systems, and in Active (Gate) your own enforcement point decides whether to apply a signed recommendation.

Optimization recommendations

Venturi turns the attribution graph into concrete, defensible opportunities:

Opportunity What Venturi does
Model right-sizing Identifies over-provisioned workloads and surfaces a cheaper model candidate, with workload-specific evidence from your own shadow data and required validation before any change.
Price-reversal avoidance Finds cases where token expansion or reasoning overhead makes a lower-list-price model more expensive in practice.
Idle or redundant usage Detects duplicate inference paths, idle deployments, and spend with no owner.
Provider or tier mix Compares equivalent provider, region, and service-tier options within the workload’s constraints.
Commitment opportunities Identifies stable usage that may qualify for a lower effective rate under a provider commitment.

No recommendation without workload evidence and your validation

Venturi never recommends a model swap on the promise of savings alone. A cheaper model is only surfaced as a candidate with workload-specific evidence from shadow data, and requires your validation before any change. Language is conservative throughout: you see an “optimization opportunity,” never a “savings guarantee.”

Each recommendation carries a rationale, an estimated saving, and the full interpretation metadata: confidence, evidence basis, and the data it rests on, so an engineer can evaluate it before acting.

Savings eligibility

Not every opportunity rests on the same strength of evidence, so every recommendation discloses a savings-eligibility state computed from the same confidence object that gates chargeback. You always know which bucket a recommendation sits in before you act on it:

State Confidence What it means for you
Eligible for verified savings coper >= 0.80 (Chargeback-ready) and degradation_state is none The underlying attribution is chargeback-grade, and no degraded condition or heuristic-baseline fallback produced it. If you apply this swap, the realized savings can enter the verified-savings base.
Advisory only 0.50 <= coper < 0.80 (Provisional), or coper >= 0.80 with a degradation_state other than none A real, actionable opportunity, but the attribution is not yet chargeback-grade or a degraded condition produced it. You can apply it; realized savings enter the verified-savings base only after the attribution qualifies.
Low confidence coper < 0.50 (Estimated), or less than 7 days of observation Surfaced for awareness; not a basis for savings claims yet.

Provisional evidence is labeled, not hidden

Recommendations that rest on Provisional attribution (0.50 <= coper < 0.80) can look just as confident as chargeback-grade ones. Venturi labels them explicitly so you can tell which recommendations rest on chargeback-grade attribution and which do not. An advisory-only recommendation whose attribution later reaches coper >= 0.80 with a degradation_state of none is automatically re-qualified for the verified-savings base; the realized result can qualify once the evidence meets the same gates.

Advisory (Shape) by default, Active (Gate) by choice

Optimization runs in one of three governance modes, in order of maturity: Passive → Advisory (Shape) → Active (Gate). No mode change makes Venturi block or reroute production AI traffic.

  • Passive: Venturi observes and attributes. Nothing is recommended or changed.
  • Advisory (Shape) (default): Venturi recommends optimizations with rationale and workload-scoped equivalence evidence. You decide what to apply, and you apply it in your own systems.
  • Active (Gate): for a named workload that you opt in after its trust readiness reaches OPERATIONALLY_TRUSTED, Venturi emits a signed enforcement recommendation (deny, or reroute to a candidate model whose workload-specific equivalence evidence you have validated) to a customer-controlled enforcement point, such as your gateway, proxy policy, or budget control. Your enforcement point decides whether to apply it. The recommendation reaches it through the Active (Gate) enforcement integration you set up when you enable it; its delivery endpoint, payload fields, and signature verification key belong to that integration, not to the webhook event catalog. Active (Gate) is explicit, reversible, and never the default.

Advisory (Shape) is the default posture. Moving a workload to Active (Gate) is an explicit opt-in that only an Admin can make, and every mode change is audit-logged and reversible. The decision-time interceptor never denies, blocks, or reroutes a request in any mode and remains fail-open, and Venturi never reaches into your AI configuration to apply a change itself. See Governance & exports for how Active (Gate) is enabled.

The intervention lifecycle

Every recommended or applied action (an “intervention”) moves through an explicit, auditable lifecycle with human control at each step:

Text Only
PROPOSED → APPROVED → ACTIVE → COMPLETED
    │                   │
    └──→ REJECTED       └──→ REVERTED
  • A recommendation starts as PROPOSED.
  • An Admin approves it with an explicit action, or rejects it with a reason code. A rejected intervention never activates, and nothing moves from PROPOSED to ACTIVE without that explicit approval.
  • High-impact actions, such as enabling Active (Gate) for a workload or making a large budget change, require N-eyes approval and respect separation of duties: the person who proposes a change cannot be its sole approver.
  • Approved actions become ACTIVE once the change is applied in your systems, then COMPLETED, with the full history preserved in the audit log.

When you review a recommendation in the dashboard, approving it moves it to APPROVED, marking it applied after you make the change in your own systems moves it to ACTIVE, and rejecting it with a reason code moves it to REJECTED. Reverting an applied change in your own systems moves the intervention from ACTIVE to REVERTED, recorded in the same history.

Human-controlled by construction

No AI subsystem in Venturi ever makes an autonomous change to your systems. Optimization recommendations are explainable, confidence-gated, human-reviewable, auditable, and reversible. Categories that are prohibited from automation are blocked by construction, not by a setting you could accidentally flip.

Savings evidence

A projected saving is a hypothesis. After an intervention, Venturi calculates realized savings against the reconciled bill and records the calculation in a versioned receipt that can be reviewed independently.

For every applied intervention, Venturi computes realized savings as the usage-normalized counterfactual cost (what the workload would have cost under the old model) minus the reconciled actual cost after the change, over each measurement period. The result is a deterministic, versioned savings-realization receipt (the savings analogue of your chargeback receipt), linked from the realized-savings figure and rendered in the evidence drawer.

What the savings-realization receipt shows you

  • The frozen baseline window and who froze it, so the counterfactual cannot drift under you.
  • The usage-normalization basis: savings are measured per workload volume, so organic growth in usage is never counted as savings.
  • Per-period counterfactual and reconciled-actual figures, and the realized-savings delta between them.
  • The share of underlying spend that is chargeback-grade (coper >= 0.80): the only spend that counts toward the savings base.
  • The equivalence assertion behind the swap, and the methodology version, pinned to a specific model version.

Realized savings

The receipt supports the verified-savings figure. Projections remain separate from realized results. Venturi licenses Workflow Economics Core plus optional extensions annually; savings measurements do not create a success fee. See the billing basis.

  • Spend below the coper >= 0.80 chargeback floor is excluded from the savings base, with the reason shown on the receipt. Verified savings require chargeback-grade attribution.
  • If the counterfactual or the volume normalization cannot be resolved, the line is excluded from verified savings and reported as unknown, with the missing input identified.

Degraded attribution

If Stage B falls back to the heuristic baseline during a window, the attributions it produced are marked degraded (degradation_state is degraded_serving), and degraded spend is excluded from both the frozen counterfactual and the post-change actual. The receipt reports the share of degraded spend it had to exclude. If that share crosses a configurable threshold (10% by default), the receipt is marked provisional and excluded from verified savings until the window is re-observed under normal capture.

A degradation episode cannot masquerade as a saving

Excluding degraded attribution prevents a fallback episode in the post-change window from being mistaken for realized savings. The receipt preserves the excluded share and its reason for review.

Workload-scoped equivalence

A swap needs workload-specific equivalence evidence. Every equivalence assertion that enters the verified-savings base carries the specific task type and workload scope it is asserted for, an assertion date and source version, a strength/confidence, and (for empirical shadow evaluations) the sample and the metric deltas. The receipt embeds the exact assertion it relied on.

If a swap’s equivalence assertion is out of scope for your workload’s task type, or has gone stale beyond a configurable freshness window, the recommendation is automatically downgraded to advisory-only and removed from the verified-savings base until it is re-verified. A savings dispute can then refer to the exact workload and evidence behind the calculation.

Energy and carbon impact

Where a swap carries an energy or carbon differential, it is computed only over the chargeback-grade (coper >= 0.80) workload it actually applies to, and labeled with whether the evidence is shadow or production. When the swap is applied, the realized carbon delta is reconciled into the same savings-realization receipt using your actual post-change energy profile, never the projected one. Where a model is not cataloged for energy, the carbon delta is shown as unknown rather than silently treated as zero, so the energy-aware leg holds up under procurement challenge.

Savings disputes

A savings-realization receipt is disputable through the same workflow as an attribution. The dispute does not mutate the receipt; it resolves to one of three outcomes:

  • a corrected counterfactual or normalization, recorded in a superseding receipt with an append-only audit trail and a check against double-counting;
  • accept the verified figure; or
  • close as duplicate.

The savings number is tied to a receipt

Verified realized savings use a frozen counterfactual, with every step addressable, exportable, and contestable. A contested figure follows the structured dispute path and retains its original evidence. A projected or measured saving is not a guarantee of future savings or ROI.

For the confidence floors, retention, and capture guarantees these receipts inherit from attribution, see Cost attribution & chargeback and Trust & security.

Budget governance

Govern AI spend with per-team and per-project budgets:

  • Advisory (Shape) by default. Budgets alert when consumption crosses configured thresholds, without blocking anything.
  • Customer-enforced stop by opt-in. For a named workload in Active (Gate), Venturi emits a signed deny recommendation when the budget reaches its configured threshold. A customer-controlled enforcement point (your gateway, proxy policy, or budget control) decides whether to apply it. A budget stop never turns the fail-open decision-time interceptor into a blocking proxy.
  • Threshold alerts fire at 75% / 100% / 150% of plan, delivered in-app and to email, Slack, Microsoft Teams, or a signed webhook.

Budget configuration, breach handling, forecasting, and alert routing are covered in depth in Budgets & alerts.

Governance you can demonstrate

For any single attribution or recommendation, Venturi can show a CISO, a FinOps lead, an auditor, or a regulator exactly what the AI concluded, with what confidence, on what evidence, with which model version, who could override it, and where the human-control boundary sits, reachable in a couple of clicks from the result. The Governance surface (Cost / Governance) shows the evidence, confidence, approval state, and realization status of each Venturi recommendation. It also shows the current drift state of each deployed Venturi attribution model: its shadow-mode agreement and calibration-error delta against their thresholds. Drift that breaches a threshold raises a governance notification, and an automatic rollback of a model version appears as a degradation event. Disputes and overrides are first-class, audited workflows. Health or drift data for your own provider models appears only when a configured source supplies it; Venturi does not infer an authoritative deployment inventory from billing records alone.

Venturi’s published scope and non-goals match what the system actually enforces, so the boundary you are shown is the boundary that holds.

Give feedback on this page

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

Copy page details 
Docs feedback: Optimization & governance
Page: https://docs.venturi.systems/capabilities/optimization-and-governance/