How Venturi works
From fragmented evidence to simple, actionable answers.
The seven chapters explain the mechanism end to end: which evidence is read, how ownership resolves when signals disagree, and what happens in the serving path at decision time.
End-to-end mechanism
Customer traffic and evidence processing stay in separate lanes.
The evidence plane materializes an attribution record and bounded index asynchronously. The serving path reads that index and never traverses the graph.
Existing customer request path
- 01Application request
Existing customer context enters the serving path.
- 02Bounded index lookup
Read the precomputed attribution index within the architecture budget.
- 03Forward request
Shape adds advisory context. Any Venturi failure forwards the request unmodified.
Asynchronous evidence and attribution plane
- 01Read-only connectors
Collect eligible billing, telemetry, deployment, identity, organization, and finance evidence outside the synchronous request path.
- 02Governed records and graph
Resolve deterministic relationships, infer eligible residuals, and preserve alternatives and unknown states.
- 03Materialize record and index
Create the inspectable decision record and bounded lookup used at decision time.
In summary: customer traffic follows application request, bounded index lookup, and forwarding. Separately, read-only evidence is processed into governed relationships, an attribution record, and a materialized index. Connectors and graph processing are not synchronous request dependencies.
Seven-chapter narrative
Follow the mechanism from structural gap to operating decision.
Each chapter answers one buyer question, shows the mechanism, states the evidence boundary, and ends with the decision the mechanism can support.
- 01 The structural gap
Why billing, telemetry, identity, deployment, finance, and tags cannot resolve ownership independently.
- 02 From evidence to attribution
How read-only evidence becomes a governed, confidence-scored record.
- 03 The attribution graph
How six product layers map to a compact five-node graph and eight relations.
- 04 The attribution engine
How deterministic resolution, calibrated inference, and separate allocation preserve uncertainty.
- 05 The serving path
How a precomputed index supports bounded-time decisions without becoming a production dependency.
- 06 The decision record
How evidence, truth domain, alternatives, time basis, and corrections remain inspectable.
- 07 Adoption and cost intelligence
How two buyer motions read the same attributed usage, with validation status made explicit.
Claim-state key
Mechanism and proof state are labeled separately.
The labels identify whether a section describes the governed mechanism, an architecture behavior, an initial projection, or a proof point that still requires deployment evidence.
- Mechanism . Describes how the product is designed to work.
- How the product is designed to produce an attributed record.
- Architecture commitment . A required system behavior that still needs deployment evidence.
- A required behavior such as fail-open forwarding or read-only access.
- Initial projection . An initial decision surface derived from the attribution graph.
- An adoption or cost decision surface derived from the graph.
- Validation pending . Customer evidence is still required to validate actionability.
- Customer evidence is still required to validate actionability.
Technical documentation
Implementation guidance lives in the documentation.
Connector setup, administration, troubleshooting, and schema-level detail belong in the technical documentation. This section explains the product mechanism and evidence boundary.
Use the documentation for implementation detail after the attribution boundary and evaluation scope are defined.
Open technical documentation on docs.venturi.systems