The Request Path

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.

​

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