> ## Documentation Index
> Fetch the complete documentation index at: https://docs.wardin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

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

<Note>
  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.
</Note>

## 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](/concepts/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](/concepts/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.