Skip to content

The RAIL pipeline

RAIL (Reconciliation Attribution Intelligence Layer) is Venturi’s platform runtime and customer-facing attribution term. It turns a raw AI invocation event into a resolved AttributionRecord. RAIL is not Stage B only: its research and training machinery supplies verified models to Stage B, while the same RAIL contract spans Stage A resolution, Stage B inference, and Stage C allocation. Every signal Venturi sees runs through these 3 RAIL stages, in order, each with a single responsibility:

RAIL

unresolved edges

resolved edges

Stage A
deterministic resolution
(R1–R5)

Stage B
edge inference

Stage C
fractional allocation

InvocationEvent

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: trained edge 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 model does its work.

Stage B runs 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 designed to be calibrated (so that a reported confidence of 0.85 is intended to correspond to a roughly 85% chance the attribution is correct, and Venturi continuously checks whether emitted confidence still tracks real outcomes) 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.

Where the model runs

Stage B runs in-process inside the attribution processor, in your data plane. There is no separate inference service and no network hop: the processor loads a hash-verified model artifact into its own runtime and answers one question well: for this ambiguous edge, which relationship is most likely, and how sure are we? It does not own your dashboards, billing, or controls.

Stage B degrades without stopping attribution

Stage B is asynchronous and never enters your AI request path. If the trained model is slow, unavailable, missing its artifact, returns an invalid result, sheds under concurrency, or has its circuit breaker trip on sustained timeouts, the engine fails open to a deterministic heuristic baseline: a permanent, conservative fallback that resolves the edge with a transparent, lower-confidence heuristic instead of waiting on the model. Calibration drift beyond the published bound rolls a model back automatically, with no flag that can suppress it. Results answered by the fallback say so in their evidence metadata.

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 Stage B inference call is bounded by a hard 20 ms wall-clock call budget, the adapter’s share of that 50 ms interceptor budget. 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, runs independently of customer traffic to its own 100 ms P99 inference budget. That budget and the 20 ms call budget above are separate figures: neither sits inside the other.

Net effect: Stage B can momentarily degrade while attribution keeps flowing. Separately, the interceptor guarantees that AI requests are never delayed or dropped because of attribution. A fallback 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 refused outright as evidence for whether an edge exists, and it carries a hard 0.50 ceiling of its own, so allocated attributions are always clearly distinguished from directly resolved ones. An allocated line is ceilinged at 0.70 where proportional allocation signals are present and at 0.50 where the split rests on no such signal. Both sit below the 0.80 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 Stage B edge inference (fallback to the heuristic baseline) Ambiguous residual strongly_inferred, bounded
C Fractional allocation (R6 prior) Shared cost allocated splits, conservation enforced

Where to go next