Skip to content
Venturi
Contact

Platform / Deployment

Establish coverage before enabling decisions.

A design-partner deployment begins by mapping known pathways, capture feasibility, source health, and unresolved states. Observation and advisory use begin only after the evidence boundary is understood.

Inspect trust model

Evaluation sequence

Coverage is measured before a decision surface is promoted.

Each step produces an inspectable artifact and a narrower question for the next step.

Planned . Planned work that is not current capability. Validation pending . Customer evidence is still required to validate actionability.
  1. 01Inventory known AI pathways

    Map product categories and provider-neutral technical topologies in scope.

  2. 02Classify capture feasibility

    State the required granularity and whether each path is fully, partially, indirectly, or not capturable.

  3. 03Activate the minimum read-only sources

    Connect only the evidence required for the approved workload and relationship set.

  4. 04Validate governed records and relationships

    Exercise exact joins, eligible residual inference, abstention, corrections, and allocation separation.

  5. 05Report attribution coverage

    Publish numerator, denominator, exclusions, source health, time basis, and unresolved states.

  6. 06Enable decisions progressively

    Begin with observation and decision support. Keep Shape advisory and Gate explicitly configured.

Pathway and topology crosswalk

Product semantics and technical transport are separate dimensions.

The current product canon defines 20 product pathway classes. The separate provider-neutral topology catalog contains six families and 26 technical paths. Deployment maps both to capture layer, capture feasibility, and attribution state.

Pathway and topology crosswalk Product category, technical topology, capture layer, feasibility, and attribution state are related but non-equivalent.
Mechanism . Describes how the product is designed to work. Current topology reference as of 2026-06-23
Distinct governed dimensions
DimensionQuestion answeredCurrent governed model
Product pathway categoryWhat kind of product or usage context is present20 governed product pathway classes
Provider-neutral technical topologyHow the request or workload reaches inferenceSix topology families and 26 paths in the current technical catalog
Capture layerWhere evidence can be observedProvider, gateway, runtime, network, platform, or indirect source
Capture feasibilityWhether the required granularity can be observedFully, partially, indirectly, or uncapturable
Attribution stateWhether available evidence resolves an eligible relationshipCanonical output state, confidence, source health, and time basis
Show the 20 product pathway classes
  1. 01Direct API
  2. 02AI gateway
  3. 03Model router
  4. 04AWS Bedrock
  5. 05Azure OpenAI
  6. 06Vertex AI
  7. 07Other managed provider
  8. 08Orchestration framework
  9. 09Agentic AI
  10. 10Embedded SaaS per seat
  11. 11Embedded SaaS consumption
  12. 12Developer tool
  13. 13Self-hosted
  14. 14Edge or on-device
  15. 15Data-platform AI
  16. 16Fine-tuning or training
  17. 17Batch API
  18. 18RPA workflow
  19. 19Shadow AI
  20. 20Client-side AI

In summary: Venturi classifies each deployment two ways. The product lens has 20 governed pathway classes. The technical lens is provider-neutral: 26 paths in six families. Both map to a capture layer, capture feasibility, and an attribution state. This crosswalk supersedes the earlier 18-category revision.

Evidence-source activation

Activate the minimum evidence needed for the decision.

Source activation is based on the missing governed relationships, not on a generic connector checklist. Permissions and exclusions per source are enumerated in the trust-model matrix.

  1. BillingUsage, provider identifiers, and reconciled charges
  2. TelemetryService, route, workload, and runtime context
  3. CI/CD and source controlDeployment and governed project ownership
  4. Identity and organizationIdentity, team, and effective-dated hierarchy
  5. Finance hierarchyBudget and cost-center relationship

Coverage receipt

Report the denominator, exclusions, and next evidence gap.

Attribution coverage is meaningful only when the capturable denominator, time window, enabled sources, and exclusions are explicit.

Illustrative synthetic example

Coverage receipt

Synthetic evaluation scope

Validation pending . Customer evidence is still required to validate actionability.
Scope
One synthetic support-routing workload and its known inference paths
Time window
Synthetic evaluation window T0 to T1
Enabled sources
Billing, telemetry, deployment, identity, organization hierarchy
Healthy sources
Billing, telemetry, identity, organization hierarchy
Degraded sources
Deployment metadata for one synthetic event interval
Capturable denominator
C = governed records classified as capturable at the requested granularity
Attributed numerator
A = records with a supported owner path within C
Exclusions
Aggregate-only seat activity and out-of-scope environments
Unknown state
Detected records with insufficient eligible evidence
Not-identifiable state
Records whose pathway cannot expose the required identity field
Next evidence source
Complete event-time deployment metadata for the degraded interval

Attribution coverage = A divided by C. No customer percentage is asserted in this synthetic receipt.

Validation criteria

A decision surface needs more than a successful connector.

Promotion criteria combine capture feasibility, governed-record conformance, attribution coverage, source health, correction behavior, and buyer actionability.

Coverage
The attributed numerator and capturable denominator are versioned and explainable.
Unresolved states
Ambiguous, unknown, and not-identifiable records remain visible.
Source health
Degraded and stale evidence changes the record and its action class.
Corrections
Human corrections append history and re-materialize derived state.
Fail-open path
Venturi failure forwards customer traffic unmodified.
Actionability
The intended buyer can make a useful bounded decision from the output.

Progressive decision enablement

Move from observation to action only as evidence supports it.

Action class is promoted separately for each workload and decision. Output state alone does not activate a workflow.

  1. 01Observe only

    Collect records and expose gaps without operational use.

  2. 02Decision support

    Use the record in human review with alternatives and explanation visible.

  3. 03Eligible for finance review

    Apply the customer’s finance policy and threshold separately.

  4. 04Shape advisory

    Provide model, routing, or review recommendations without blocking traffic.

  5. 05Customer-controlled Gate path

    Require explicit workload and policy configuration. Venturi failure remains fail-open.

Evaluation deliverables

Leave an evidence package, not a deployment-duration promise.

The evaluation concludes with the artifacts needed to decide what can be observed, attributed, and validated next.

  • 01Source and permission map
  • 02Pathway and feasibility inventory
  • 03Trust-boundary review
  • 04Initial coverage baseline
  • 05Unresolved-state analysis
  • 06Decision-surface recommendation
  • 07Validation plan