the four-layer evidence stack.

The "AI-agent observability" category, as marketed since 2024, collapses four distinct concerns into one. Telemetry. Policy. Records. Attestation. Each maps to a different obligation in a different statute, with a different reader on the other side. Warrant separates them on purpose, because the regulator asks for the layers individually.

The four layers, defined.

Each layer answers a different question, in a different timeframe, for a different reader.

Most products live in L1 with a thin shim into L2 and call the bundle "AI compliance". The bundle is fine for engineering. It is not what a regulator asks for. Warrant lives in L3 and L4.

Layer 1 · observability.

Observability is the layer in every modern stack. Logs, traces, metrics, dashboards, alerts. The W3C Trace Context recommendation defines propagation primitives, OpenTelemetry standardises the wire format, vendor agents emit OTLP without thinking. Your platform team has owned this layer for a decade.

Layer 1 is good for debugging a latency spike at 03:14 last Tuesday, counting error-budget burn, watching p99 inference latency by model variant, paging the on-call engineer before the customer notices.

Layer 1 is not good for post-incident forensics under adversarial conditions or regulator submission. Not a feature gap, a structural property: observability platforms are built for live systems, not for posterity.

The mismatch shows up in retention. Default observability tier rotates at 7 to 30 days. The cold tier extends to 12 to 15 months. Both miss the regulator's clock. Article 12 is not itself a retention rule; it is a design duty on the logging capability:

Article 12(2) extends the same idea into specific use cases:

Article 12 is a capability test: the system must technically allow the automatic recording of events over its lifetime. Retention is a separate limb, and it splits by role. Article 19(1) binds providers to keep the Article 12(1) logs that are under their control for a period appropriate to the intended purpose of the system, and in any event at least six months. Article 26(6) puts deployers under the same six-month floor for the logs under theirs. A 30-day-rotation telemetry stack fails that floor before the capability question is even reached. The fix is not a longer retention plan. The fix is to recognise the layer as Layer 1 and put a Layer 3 system downstream of it.

Layer 2 · runtime guards.

Runtime guards are the policy layer. Input classifiers reject injection-shaped prompts. Output classifiers strip personally identifiable text. Tool whitelists prevent the agent from calling unauthorised endpoints. Authorisation gates require a human signature for trades above a threshold, wire transfers, any irreversible action.

Concrete shape, no vendor names. An order-routing agent gets a request to liquidate a position. The Layer 2 policy reads: order.notional > 50_000_USD ⟹ require_HITL_approval. The agent halts, surfaces the action to a human reviewer, waits for the reviewer's approval, then proceeds. NIST AI RMF describes the pattern under Measure and Manage; the OWASP LLM Top 10 catalogues the failure modes runtime guards address (LLM01, LLM06, LLM08).

Runtime guards prevent harm. That is the entire point. They tell the agent what not to do, in the millisecond before it would have done it. The decision becomes a log entry, hits Layer 1, and the on-call engineer sees a count of blocked attempts.

Runtime guards do not tell the regulator what happened in production six months ago. A "blocked: prompt-injection-pattern-04" entry is not the artefact an auditor reads. The auditor reads the trace, the prompt, the retrieved context, the rationale, the disposition. That artefact lives at Layer 3.

Layer 3 · evidence.

Evidence is the layer most products skip. Evidence is expensive and invisible until the moment it is needed. By that moment the cost of not having it is many multiples of the cost of having had it.

An auditor in 2027 investigates a customer complaint about a credit decision from March 2026. The question is not "show me uptime that day". The question is: show me the trace, the prompt version that was live, the retrieved policy clauses the model used, the customer-supplied inputs, the intermediate outputs, the final disposition, the rationale paragraph, and the named human who reviewed the action.

That bundle is the reconstruction surface. Annex IV of the EU AI Act calls it "technical documentation". NYDFS Part 500 calls it "audit trails". The NYDFS clause, verbatim:

The model risk guidance has carried the same idea since 2011 and continues under SR 26-2, the Fed / OCC / FDIC Revised Guidance on Model Risk Management issued 17 April 2026 (OCC Bulletin 2026-13), which supersedes and replaces SR 11-7 (4 April 2011) and SR 21-8 (9 April 2021). One scope limit is load-bearing for an agent: footnote 3 to its section II reads Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance, routing the agentic layer instead to the banking organization's own risk management and governance practices. So the reconstruction surface an examiner reads for an agent is the one the bank chose to keep, not one a model risk clause compelled.

L3, in record terms, holds:

• The trace. Span tree, timestamps, parent-child relationships, the OpenTelemetry payload L1 emitted, captured losslessly.
• Intermediate model outputs. Every model call, every response, including responses discarded in favour of a re-prompt.
• Prompt versions. The exact template live on the day, identified by version hash.
• Retrieved context. RAG citations, document IDs, chunk offsets, retrieval scores. What the model saw, not just what the model said.
• Decision rationale. The model's stated reasoning where requested, and the structured fields the rationale produced.
• Sub-clause citations. For each obligation triggered, the specific article, paragraph, sub-paragraph the system mapped against.

This is the evidence layer. It is mutable in the sense that storage is your storage; you can re-render the PDF, re-export the JSON. It is reconstructable in the sense that any honest re-render produces the same canonical bytes.

Layer 4 · attestation.

Attestation is the property that makes the Layer 3 evidence stand on its own: the record is independently verifiable by any auditor, without contacting Warrant. Verification resolves against an external, append-only public reference that Warrant does not operate. Any party recomputes the binding from the canonical bytes of the record and reaches the same yes-or-no result. That is a claim an architect can reason about and falsify: take the record, recompute, compare against the public reference, and the answer is binary.

Attestation is its own layer because of admissibility. Layer 3 evidence on its own is "the vendor's database, as the vendor presents it today". A regulator asking who attests to integrity over time gets one answer, the vendor, and that answer has a known failure mode: staff turnover, data migration, deliberate edit by an insider.

Layer 4 inverts the trust assumption. Verification runs against the record itself, not against Warrant's storage system, and it resolves against an external public reference rather than a Warrant service. An auditor checks the record on their own machine. None of it depends on Warrant being honest or even online.

Layer 3 says "here is the evidence". Layer 4 says "and here is why you can believe it without trusting us".

The layer-cake diagram.

Each layer runs on the layer beneath it; each carries its own job. The diagram, in mono:

                     ┌──────────────────────────┐
                     │  Layer 4 · Attestation    │  independently verifiable
                     ├──────────────────────────┤
                     │  Layer 3 · Evidence       │  trace · prompts · citations
                     ├──────────────────────────┤
                     │  Layer 2 · Runtime guards │  policy · tool whitelist
                     ├──────────────────────────┤
                     │  Layer 1 · Observability  │  metrics · logs · traces
                     └──────────────────────────┘

The same picture written as record types, which is the clearest way to see where one layer ends and the next begins. Read the block as a model of the four layers, not as Warrant's code: none of these four type names exists in the Warrant codebase. What Warrant ships at Layer 4 is the warrant-v1 evidence package, whose schema is nine root properties — classification, actions, authorizations, obligations, coverage_by_regime, deferred_regimes, risk_tier, refusal_reason, trace_metadata — with additionalProperties: false at the root. Layers 1 and 2 are the customer's own systems, not Warrant's.

# CONCEPTUAL. A model of the four layers, written as types to make the
# boundaries legible. These four names are not Warrant production code.
# ObligationRow below IS real: it is the signed obligation row defined in
# api/spec/warrant-v1-evidence.schema.json (id, compliance, confidence,
# evidence, unvalidated, applies_from).

from dataclasses import dataclass
from typing import List, Optional

@dataclass
class L1Telemetry:
    span_id: str
    parent_span_id: Optional[str]
    start_ns: int
    end_ns: int
    attributes: dict          # OpenTelemetry payload

@dataclass
class L2RuntimeDecision:
    policy_id: str
    decision: str             # allow | block | escalate
    triggered_rules: List[str]
    requires_hitl: bool

@dataclass
class L3Evidence:
    trace: List[L1Telemetry]
    runtime_decisions: List[L2RuntimeDecision]
    prompt_version: str
    model_rationale: str
    final_disposition: str
    obligation_rows: List[ObligationRow]   # real: keyed by action_id in warrant-v1

@dataclass
class L4Attestation:
    evidence_ref: str            # binds to one L3Evidence by content
    author: str                  # named author on the public record
    external_timestamp: str      # pinned to an external public timeline
    independently_verifiable: bool   # checkable by any auditor, no Warrant call

Read as a model, the block says the thing worth saying: an attestation binds to one evidence record by its content, an evidence record contains the layers beneath it, and a type that expects an attestation cannot be handed raw telemetry instead. Read as a claim about Warrant's implementation, it would be false, so state the implementation plainly. Warrant does not enforce the layer split in a type system. What it enforces is at the schema boundary: the warrant-v1 root is closed, so a package that tried to carry raw spans or runtime-policy decisions would fail validation rather than be accepted as evidence. That is a runtime check on one artefact, not a compile-time guarantee across four layers.

What breaks when a layer is missing.

The clearest argument for the split is the four failure cases, each a real outage shape:

The boundary between L3 and L4 is the regulator's friend.

The counter-intuitive choice in the Warrant stack is the split between L3 and L4. A simpler product fuses them: write the evidence into a write-once log, call the log an attestation. The fused design fails on a soft requirement that turns out to be hard.

The soft requirement is re-rendering. An evidence package as PDF has a cover page, header, footer, page-numbering, layout the auditor's preferences can change. Six months in, the regulator asks for the same evidence in a different language with annexes attached. The L3 record is the source of truth; the PDF is a render. A fused design that attests the rendered PDF cannot re-render without breaking the attestation.

Attesting the canonical L3 record rather than the PDF is the design target, and it is worth stating plainly that today it is the other way round: the attestation covers the rendered document, so a re-render does not carry it. That is the honest limit of the current build. The target property is the one described above — a canonical form reproducible enough that any honest re-render round-trips to the same bytes, so the attestation survives re-renders and languages, and any party recomputes the binding from those bytes and reaches the same yes-or-no with no Warrant call in the path. Read this paragraph as where the record layer is going, not as what it does now.

The hard requirement is integrity. The L3 record is mutable in the sense that it lives in storage your team operates. An insider with access could edit it. The L4 record makes the edit detectable. Change a byte of the canonical record and verification fails, while the external public reference still points at the original. The edit is loud.

Splitting evidence (mutable, your storage) from attestation (independently verifiable, externally referenced) gives both flexibility and integrity. A regulator gets the L3 evidence in whatever shape they need; the L4 attestation binds the shape to the original bytes.

A regulator query, four responses.

Put the same regulator question to each layer and read the four responses side by side:

L1 and L2 are honest answers to questions the regulator did not ask. L3 answers the question. L4 proves the answer has not been edited since the action. A submission with L3 and L4 closes the inquiry. A submission with only L1 and L2 invites a follow-up the team cannot answer.

Closing · what Warrant ships.

Warrant's product is L3 plus L4 with hooks into L1 and L2. We do not replace your observability platform. We do not replace your input filter or your policy engine. We sit downstream of both.

The integration shape is small. The platform accepts a trace payload in OpenTelemetry's wire format, accepts a runtime-decisions payload from your policy layer, and produces an L3 evidence package per attestable action. The package carries the L4 attestation and is independently verifiable from any laptop, with no Warrant API call.

Two-year regulator review is the test we hold the artefact to. The 2027 auditor reading the 2026 record reads the trace, follows the citations, verifies the record independently on their own machine, and closes the file in under twenty minutes.

Pick the layer your problem actually lives at. If the answer is "all four", the four-layer stack is what you build, and the two layers downstream are the layers most teams have skipped.

Questions an architect asks first.