Skip to main content
Every request that flows through Wardin passes through the same six stops, in the same order, every time. This is the Request Path — the rail you see across the top of the dashboard (INGRESS → POLICY → ROUTE → LEDGER → EVIDENCE → OUTCOMES). It isn’t a metaphor for the product; it’s a literal description of what the gateway does to a request before an answer comes back, and it’s the mechanism behind the evidence layer — the six stages are where enforce, meter, sign, and attribute actually happen.
This page teaches the same six stages shown in the in-product commissioning flow — the first-run experience that walks a new tenant through connecting a provider and sending a first governed request across this same rail.

​
The six stages

​
01 — INGRESS

Every request enters here — identified, keyed, and streamed live. This is where the gateway authenticates the caller’s virtual key and the request becomes visible in the live stream, before anything else happens to it.

​
02 — POLICY

Allow, redact, or block — enforced in-path before the provider is called. Budget checks, model allowlists, PII redaction, and prompt-injection guardrails all run here, synchronously, ahead of the upstream call. A blocked request never reaches a provider and never gets billed.

​
03 — ROUTE

Which provider and model actually served the request. Wardin resolves the model name to a provider, applies fallback/retry/load-balancing across your connected providers, and checks the semantic cache before spending a token.

​
04 — LEDGER

Finance-grade debits, posted per team and per task. Every completed request commits an exact-cost debit — split by regular, cache-write, and cache-read tokens — against the caller’s budget and rolls up into team/organization spend.

​
05 — EVIDENCE

Every model-inference request gets a signed, hash-chained, tamper-evident receipt. Chaining and signing happen asynchronously, off the response path, so evidence generation never adds latency — see Signed Receipts for how the chain works.

​
06 — OUTCOMES

Accepted work per dollar — quality-gated, never raw volume. Spend is only meaningful next to a quality signal; Outcomes pairs cost with acceptance/rework data so cost reduction can’t be gamed by producing less or worse work.

​
The square node: Console isn’t a seventh stage

You’ll also see a square node next to the six diamonds, labeled CONSOLE. It is deliberately not part of the rail sequence, because it answers a different question:
  • The rail (diamonds) observes — it shows you what already happened to a request.
  • The Console (square) configures — it’s where you change how the next request will be handled: connecting a provider, editing a policy, minting a key, setting the cache threshold.
If a screen describes something that happened to a request, it belongs on the rail. If it changes how requests get handled, it belongs in the Console. See The Console for how Console sections are organized.

​
One signed receipt, three readers

The six stages aren’t six separate products regrouped — they’re the mechanism behind the evidence layer: every stage writes into the same signed, hash-chained receipt, and that one receipt is what three different readers each come to the rail for: One gateway sitting in the request path produces the whole receipt; you don’t stitch together a separate guardrail tool, FinOps tool, audit tool, and productivity tool to get the three views on it.