Skip to main content
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 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. One record, four things done to it, four verbs: enforce, meter, sign, attribute.

​
Three readers, one receipt

ReaderQuestion they askWhat the receipt gives them
Security / complianceDid 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.
FinanceWhat 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.
EffectivenessDid 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.
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 for exactly what’s verifiable today.

​
Where this shows up in the product

  • The Request Path — the six-stage rail is the mechanism: where enforcement, metering, and evidence generation actually happen on every request.
  • Signed 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.