Skip to content

The HRE pipeline

The HRE is Venturi's three-stage attribution pipeline — the runtime that turns a raw AI invocation event into a resolved AttributionRecord. Every signal Venturi sees runs through the same three stages, in order, each with a single responsibility:

graph LR
  E[InvocationEvent] --> A["Stage A<br/>deterministic resolution<br/>(R1–R5)"]
  A -->|resolved edges| C
  A -->|unresolved edges| B["Stage B<br/>RAIL edge inference"]
  B --> C["Stage C<br/>fractional allocation"]
  C --> R[AttributionRecord]

A core principle runs through the whole pipeline: deterministic evidence always outranks inference, and inference always outranks allocation. Stage A overrides Stage B for any edge it can resolve; Stage C distributes cost but never changes who the candidate owners are. Precision degrades gracefully — it never collapses into a falsely confident guess.

Stage A — deterministic resolution

Stage A builds the attribution graph from facts. It populates all five node types from your source data and resolves every edge it can using exact join keys and rule-based matching. No machine learning is involved — Stage A is pure, repeatable logic over your own data.

Stage A applies five reconciliation methods:

Method How it resolves an edge
R1 · Direct key match An exact join — e.g. an account ID maps directly to an identity, or an API key to a service. The strongest evidence; can reach maximum posterior confidence.
R2 · Temporal proximity Events that line up in time are linked — e.g. a deployment immediately followed by invocations from that service.
R3 · Naming correlation Consistent naming across systems links records — e.g. a service name matching a repository name.
R4 · Historical patterns Prior resolved attributions inform new ones where the pattern is stable.
R5 · Service-account trace Following a service account or principal through the call chain to its owner.

Stage A also handles conflict honestly. Deterministic does not mean unambiguous: if two equally authoritative sources disagree — CODEOWNERS says Team A, deployment metadata says Team B — Stage A records a conflict state and preserves it for review rather than silently picking a winner. High-cost conflicts are surfaced for manual review.

Whatever Stage A resolves with certainty is marked deterministically_resolved and bypasses inference entirely. Only the genuinely ambiguous residual — the edges Stage A cannot resolve from facts — flows to Stage B.

Stage B — RAIL inference

For the edges deterministic rules cannot resolve, Stage B infers the most likely relationship and attaches a calibrated confidence. This is where Venturi's trained attribution-intelligence model, RAIL, does its work.

RAIL is an edge-existence model: for an unresolved edge, it scores how likely each candidate relationship is, given the available evidence, and returns the best candidate with a posterior confidence. That confidence is calibrated — when RAIL reports 0.85, attributions at that level are right about 85% of the time — and is materialized into the customer-facing operational score coper, capped at 0.95. Stage B always preserves the full set of ranked candidates alongside the selected answer, so a result can be inspected and challenged.

RAIL is the intelligence; HRE is the runtime

RAIL is Venturi's attribution-intelligence producer, deployed as a tenant-scoped sidecar inside your trust boundary. It supplies evidence-backed edge predictions to the HRE through a stable contract. It does not own your dashboards, billing, or controls — it answers one question well: for this ambiguous edge, which relationship is most likely, and how sure are we?

Fail-open is absolute

Stage B never blocks your AI traffic. If the trained model is slow, unavailable, missing its artifact, or returns an invalid result, the engine fails open to the HeuristicBaseline — a permanent, conservative fallback that resolves the edge with a transparent, lower-confidence heuristic instead of waiting on the model.

The latency budgets that guarantee fail-open

  • The synchronous interceptor on your live AI hot path works to a 50 ms P99 end-to-end budget and fails open on breach. It does a fast index lookup, not inline model inference.
  • The RAIL inference call is bounded by a hard 20 ms wall-clock timeout. If inference does not complete in time, the baseline answers.
  • The asynchronous attribution processor — which handles the large majority of attribution volume off the hot path — works to a generous inference budget so the model can be applied without affecting your traffic.

Net effect: attribution can momentarily degrade, but your AI requests are never delayed or dropped because of it. A fail-open result is marked as degraded so you always know when it happened.

A Stage B result is marked strongly_inferred when the model resolves the edge with high confidence, or bounded when the answer is uncertain enough that Venturi reports a constrained range rather than a single owner.

Stage C — fractional allocation

Some costs are genuinely shared and have no single owner — a shared API key, a shared endpoint, a platform service used by many teams. Stage C handles exactly these cases. It does not decide who the candidates are (Stage A and Stage B already established that); it decides how the cost is split among them.

  • Conservation. Allocations always sum to 100% of the cost. Nothing is lost, double-counted, or invented.
  • Fractional splits. Stage C distributes the cost across candidate owners proportionally, based on the available allocation signals.
  • The allocation prior (R6). Stage C is the only stage that uses the sixth reconciliation method, R6 — an allocation prior used purely to split shared cost. R6 is never used as evidence for whether an edge exists; it carries a hard ceiling so that allocated attributions are always clearly distinguished from directly resolved ones. Allocation-derived confidence is capped well below the chargeback floor, so shared-cost splits are transparently provisional rather than presented as certain ownership.

What comes out

Each stage stamps its result with a stage origin (stage_a, stage_b, or stage_c) and an output state, so you can always see how an attribution was reached. The combined output is materialized into an AttributionRecord and indexed for your dashboards, exports, budgets, and the API.

Stage Job Resolves Typical output state
A Deterministic resolution (R1–R5) Facts and exact matches deterministically_resolved
B RAIL edge inference (fail-open to HeuristicBaseline) Ambiguous residual strongly_inferred, bounded
C Fractional allocation (R6 prior) Shared cost allocated splits, conservation enforced

Where to go next