Skip to content

AI transparency

This page consolidates transparency for the attribution pipeline: what the system decides, how confidence is represented, what happens when the trained model cannot answer, and how a human can review or override an attribution result.

Model documentation

This page, Confidence & evidence, and Known limitations document model behavior and review controls. The Model-card index records the separate publication status of the standalone public Stage B model card.

Decision flow

  1. Where the decision-time interceptor sits on the request path, it performs a fast index lookup, emits a metadata-only InvocationEvent, and forwards the request. It runs no trained inference, works to a 50 ms P99 end-to-end budget, and fails open.
  2. Events from the interceptor, the drop-in proxy, the ingestion API, and connectors reach the asynchronous attribution processor.
  3. Stage A attaches tenant, source-system, policy, and timing context and resolves every edge it can with deterministic methods.
  4. For the ambiguous residual only, RAIL’s Stage B scores the candidate edge with the trained attribution model under a 20 ms Stage B timeout inside the processor’s 100 ms P99 budget.

  5. The processor uses a deterministic heuristic-baseline result when any Stage B fallback condition occurs:

    • The call reaches its 20 ms timeout.
    • The model artifact is missing.
    • The model returns an invalid output.
    • A flag disables Stage B for that edge.
    • 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. The default is 5% over a 100-call rolling window.
    • The edge’s readiness gate vetoes serving the trained model for that edge. This is a fail-closed, per-edge veto.

  6. Stage C splits genuinely shared cost across candidate owners.

  7. The output carries an evidence trail, confidence value, result source, and output state. If calibration drift or model age has demoted an edge, its confidence is capped below the 0.80 chargeback floor and the evidence card records the demotion reason; see Confidence & evidence.

The request path never waits for trained attribution: every step after the first runs in the asynchronous processor. See System architecture.

Confidence semantics

Operational confidence (coper) is deliberately capped at 0.95. Venturi does not display certainty. Confidence places each edge in one of three bands: Chargeback-ready (coper >= 0.80), Provisional (0.50 <= coper < 0.80), or Estimated (coper < 0.50). It is not a claim that the system has perfect visibility into every pathway.

See Confidence & evidence for output states and evidence-card fields.

How to act on a result

The canonical vocabulary is the six output states plus the three confidence bands. In practice they reduce to these customer actions:

You see Which results
Chargeback-ready deterministically_resolved or strongly_inferred at coper >= 0.80
Provisional Any output state at 0.50 <= coper < 0.80, commonly strongly_inferred or ambiguous below the floor
Estimated Any output state at coper < 0.50
Bounded bounded
Unknown / not identifiable unknown, not_identifiable
Heuristic baseline marker Any result answered by the deterministic fallback

Actions for each displayed result or marker:

You see Customer action
Chargeback-ready Clears the 0.80 confidence floor, which is necessary but not sufficient for billing. Verify export_eligibility=eligible, current evidence, no open dispute or degradation, reconciliation, and finance acceptance.
Provisional Review the evidence card and accept, correct, or defer; never auto-billed.
Estimated Surface and investigate; never billed.
Bounded Use for planning and coverage work, not chargeback.
Unknown / not identifiable Connect the source that would close the gap, or leave out of chargeback; never zeroed or hidden.
Heuristic baseline marker Treat as visible but degraded; filter or exclude until re-observed.

Human controls

Reviewers can accept, correct, or reject attribution evidence according to their role and tenant policy. Review actions are written to the audit trail. Corrected edges keep the original evidence and the reviewer action so downstream reports can distinguish model output, heuristic fallback, and human review.

Data use and opt-out boundary

Venturi processes metadata needed for attribution: identity, service, project, cost, token counts, timing, policy context, and source-system evidence. Prompt and completion bodies are not requested for connector setup and are not needed for these transparency controls. 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 and are never persisted; see Trust & security.

If a pathway cannot be observed without content capture, Venturi treats that as a known limitation rather than silently expanding capture. See Known limitations.

Give feedback on this page

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

Copy page details 
Docs feedback: AI transparency
Page: https://docs.venturi.systems/engine/ai-transparency/