The Request Path

The six stages every LLM request passes through — and the one thing that isn’t a stage.

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.

This page teaches the same six captions shown in the in-product onboarding wizard’s orientation step — the wizard and this page are sourced from identical copy so they can never drift apart.

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 row 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.

The four pillars, regrouped

Wardin’s four-pillar model isn’t a separate concept from the six stages above — it’s the same six stops, regrouped:

Pillar	Stages
Gateway	Ingress · Policy · Route
Cost	Ledger
Evidence	Evidence
Productivity	Outcomes

One gateway sitting in the request path produces all four; you don’t stitch together a separate guardrail tool, FinOps tool, audit tool, and productivity tool to get them.