Two Axes of Checking

The Story

A European neobank's fraud AI flagged the right transfers at 7:14 AM. The money had left at 1:47 AM. €380,000 — gone, unrecoverable. The model scored the credential-stuffing burst at 94% confidence. The scoring was perfect. The architecture ran the check every six hours, in batch, after the fact.

A single synchronous rule — block any account attempting more than five outbound transfers in ten minutes — would have frozen the accounts mid-burst. The team had a quality check on the right type axis (AI judgment for pattern detection). They put it on the wrong timing axis (async, when it needed to be sync).

The post-incident review found what the engineers already knew: the batch architecture was chosen for cost and simplicity. Nobody asked the timing question. That is the gap this chapter closes.

The Core Idea

Quality checks in AI products are not one decision. They're two independent decisions that most teams collapse into one.

Decision 1 — Type: What does the checking? Some quality concerns have clear, codifiable rules. Is the response valid JSON? Does it contain a Social Security number pattern? These checks are deterministic — code that answers with 100% accuracy, in milliseconds, for free. Other quality concerns require judgment. Did the response follow the company's refund policy? Was the tone appropriate? These checks need an LLM-as-judge — semantically rich, expensive, and fallible.

Decision 2 — Timing: When does the checking happen? Some checks must block the response before the user sees it — synchronous guardrails. Others can run after the response is delivered — asynchronous evaluators analyzing sampled production traffic in the background.

For agentic systems, the timing axis changes fundamentally. The dangerous thing often happens BEFORE the final response. An agent that cancels an order, runs a shell command, or leaks credentials through a tool call creates the damage mid-workflow. A single output guardrail at the end misses everything that happened in the middle.

The three-layer architecture mature teams deploy: Layer 1 — behavior shaping upstream (safe-completion training, Constitutional AI). Layer 2 — inline runtime controls (input guardrails, output guardrails, tool guardrails, human approvals). Layer 3 — async monitoring and evaluation on sampled production traces.

Where This Hits in Production

The latency vs compliance negotiation. Regulations like HIPAA and FINRA force certain checks into the synchronous path — you must prevent the violation, not just detect it afterward. The PM's job becomes negotiating: fast deterministic checks synchronously, nuanced AI checks asynchronously.

Multi-tenant systems need policy packs, not one global guardrail. The same user action can belong in different quadrants for different customers. Enterprise reality: not one global guardrail, but tenant-specific, environment-specific, workflow-specific policy configurations.

At 10M queries/day, judgment checks must be sampled. At enterprise scale, you run deterministic checks on 100% and semantic judges on filtered or sampled subsets.

Connecting the Dots

On the autonomy spectrum, the 2x2 matrix doesn't just get more complex as autonomy increases — it changes shape. At Levels 1-3, you check one output. At Levels 5-7, every step in the workflow potentially needs its own guardrail assignment. The 2x2 isn't one matrix. It's one matrix per step.

In Practice: The Enterprise 2x2

Here's what a well-configured checking architecture looks like for an enterprise support agent — expressed as a YAML policy the infrastructure enforces.

Remember This

1. Every quality check sits in one quadrant of Type (code vs AI) × Timing (sync vs async). Wrong quadrant blocks real users or ships real violations. There is no neutral cell.

2. For agents, the guardrail belongs at the step that creates the side effect — not at the final response. An output check at step 10 cannot un-cancel the order at step 3.

3. The PM owns the quadrant assignment. It is a product decision priced in safety, latency, cost, and trust — not an engineering choice handed off after the spec.