> ## 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 Evidence Layer

> How enforce + meter + sign + attribute converge into one signed, hash-chained receipt — and why three different readers all trust the same record.

Wardin's organizing idea: every request in the request path produces exactly **one**
record — enforced, priced, signed, and attributed in the same pass — and that one
record is read by three different audiences for three different reasons.

Most teams stitch together four separate tools to get four separate views of the same
request: a guardrail service that blocks it, a FinOps tool that prices it later from a
lagging export, an audit tool that logs a summary of what allegedly happened, and a
productivity tool that tries to reconstruct value after the fact. Because those tools
sit outside the request path and don't share a data model, their outputs don't have to
agree with each other, and none of them can prove anything — they observed after the
fact, they didn't enforce in the moment.

Wardin sits **in** the request path. The [gateway](/concepts/request-path) enforces
policy and budget synchronously, meters the actual cost from the provider's own token
accounting, and emits it all — enforcement decisions, cost, actor — as one canonical
record that's then [signed and hash-chained](/concepts/receipts). One record, four
things done to it, four verbs: **enforce, meter, sign, attribute.**

## Three readers, one receipt

| Reader                    | Question they ask                                       | What the receipt gives them                                                                                                                                                                            |
| ------------------------- | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Security / compliance** | Did governance controls actually run on this request?   | The ordered `checks` list — budget, allowlist, guardrail, PII, upstream outcome — each a pass/fail, signed and chained so a check can't be edited or deleted after the fact.                           |
| **Finance**               | What did this request cost, and can I trust the number? | `cost_usd`, split by regular / cache-write / cache-read tokens, committed atomically against the same budget the request was checked against — not a reconciled export from a separate billing system. |
| **Effectiveness**         | Did this governed spend produce accepted work?          | The same request's `actor` and session tie it to **OUTCOMES** — quality-gated accepted-work-per-dollar, sourced from real GitHub PR results, not a raw tokens-saved counter.                           |

No reader gets a different record. A compliance reviewer and a finance analyst
disagreeing about what happened on a request is a data-integrity failure in the
stitched-together world; here it's structurally impossible, because they're reading
the same signed artifact.

## Why regulation makes this demanded, not optional

The EU AI Act's high-risk obligations (Art 12 — logging, Art 26 — deployer duties,
Art 73 — incident reporting) describe artifacts that look like a request-path
receipt: proof that a control ran, on a specific request, at a specific time, that
can't have been edited after the fact. A registry or catalog tool can only ask a
customer to attest that this happened; a gateway that sits in the path and signs what
it enforced already has the artifact as a byproduct of doing its job.

<Note>
  Wardin produces **audit-grade, Art-12-style runtime records** for gateway-routed
  traffic — not a compliance certification. No software makes an organization
  "compliant"; SOC 2, ISO 27001, and HIPAA are audits Wardin doesn't hold and can't
  confer on you. Framework-mapped control citations per check (e.g. `eu_ai_act:art_12`,
  `nist_ai_rmf`), long-term WORM retention beyond the hot analytics window, and a
  one-click auditor export are **in active development, not yet available**. See
  [Signed Receipts](/concepts/receipts) for exactly what's verifiable today.
</Note>

## Where this shows up in the product

* **[The Request Path](/concepts/request-path)** — the six-stage rail is the
  mechanism: where enforcement, metering, and evidence generation actually happen on
  every request.
* **[Signed Receipts](/concepts/receipts)** — the receipt format, the hash chain, and
  how to verify one yourself.
* **EVIDENCE** (rail stage) — chain statistics and a sample verified receipt.
* **OUTCOMES** (rail stage) — the effectiveness reader's view: accepted work per
  dollar.