Choose an acquisition path¶
Start with the path that matches the evidence you can provide. These four paths are peers: use one, or combine them when you need broader coverage or finer attribution.
Observation is not invocation¶
A discovery signal is an observation, not an invocation. Discovery evidence, aggregate usage, entitlement inventories, and exclusion signals do not become invocations unless a governed promotion rule accepts the evidence and produces an invocation record. Until then, Venturi preserves the observation state and its provenance instead of treating detected activity as request-level usage.
This boundary also applies to connected sources. Billing totals and adoption inventories can improve attribution without proving that a specific model request occurred.
Source Evidence¶
Ingestion & Data Discovery (IDD) classifies evidence and preserves provenance.
- Usage and invoices
- Recorded consumption and billed amounts
- Identity and organization
- Candidate owners and team context
- Code and deployment
- Service and project relationships
- Network signals
- Observed activity with limited call semantics
Each record distinguishes supported fields from missing fields. Ownership resolution uses both the evidence and its limits. Unknown is not zero, and aggregate evidence does not establish request-level truth.
Business Outcome and ROI Evidence¶
Existing customer systems of record supply the acceptance, labor, financial and comparison evidence used by AI return measurement. Read-only histories and declared identifier mappings can connect a business work item across multiple systems. Existing native statuses define acceptance through a versioned semantic mapping.
This measurement does not require new employee timers, surveys or customer-written acceptance events. Unsupported inputs remain explicit; they withhold only dependent calculations. A supported team-period comparison can remain useful when individual requests cannot be joined to tasks.
Choose between paths¶
- Connect a source: find the provider in the connector catalog and connect it read-only from guided setup.
- Import a file: upload a supported provider export or gateway log, or register a recurring drop from your own storage. See File import.
- Instrument an app: use the Ingestion API when your code can emit an event, or the drop-in proxy when you can change the provider SDK base URL.
- Add discovery coverage: use CASB, DNS/firewall, or customer-authorized eBPF metadata to create detected-only observations.
Invariants across every path¶
- Fail open at the invocation boundary. Ingestion and proxy processing never block admitted production traffic. The one fail-closed step is the drop-in proxy’s tenant admission: a provider key that is not registered to your tenant is rejected before anything is forwarded.
- Do not capture content. Send or collect metadata, not prompt or completion text.
- Preserve evidence state. Keep observed, inferred, excluded, and promoted records distinguishable through attribution and review.
- Use read-only access. Source acquisition never grants Venturi permission to change customer systems.
Sign in to send feedback. Opens in a new tab.
Copy page details
Docs feedback: Choose an acquisition path
Page: https://docs.venturi.systems/ingestion/