0.37 µs
Triage check speed (simple rule path)
2 rules · p50
Half of Fair Housing Listing Guard checks finish faster than this — on the hot path.
Benchmarks
Performance you can publish
Your AI system gets a safety layer that costs less than 2 ms — even under load.
Real measurements from our validation engine and OpenAI-compatible layer — no LLM-as-judge latency, no hand-wavy slides.
Live Metrics: Refreshed on schedule every ~48 hours. Last run: Oct 14, 2026.
Benchmark environment: AMD EPYC-Milan Processor | 2 vCPUs | 8 GB RAM | Ubuntu 26.04.1 LTS | go1.25.0 linux/amd64
Headline comparison: 820 ms typical LLM completion vs 0.38 ms measured validation layer path (median of 5 runs; up to 2,426× faster integrity layer).
Validation engine
Deterministic rule checks on model output — measured with go test -benchmem on every template.
Updated Oct 14, 2026
1.3 µs
Heavy rule packs stay fast
Evidence Coverage Guard
8 rules on a real template — still microsecond-scale.
0.51 µs
RAG source matching
Typical check speed
4 rules on a real workload — measured on the validation hot path.
1.9M RPS
Engine RPS
3 rules
Sustained validation engine throughput for Collections Dunning Guard.
Validation layer path
Updated Oct 14, 2026
377.1 µs
Proxy return path
179.5 µs
Validation engine call
+0.06 ms
Output validation overhead
4.0k RPS
Sustained throughput
Full HTTP round trip — auth, rules, persist queue. Zero-latency mocked upstream (httptest); concurrency 1.
Playbook orchestration
Multi-agent workflows via X-VG-Flow — measured end-to-end with mocked agent upstreams (make bench-orchestration).
Updated Aug 31, 2026 · commit d4922ecd
2.14 ms
3-step linear handoff
p50
Path: triage,compliance,reply,end_success · 3 validations
1.23 ms
Branch on validation pass
happy
Path: classify,draft_reply,end_success · 2 validations
2.39 ms
Branch on validation block
block
Path: classify,draft_reply,human_handoff,end_handoff · 3 validations
2.21 ms
JSON field route A + merge + finalize
route_a
Path: classify,path_a,merge_finalize,finalize,end_done · 3 validations
Live numbers from orchestration-bench at concurrency 1 — linear, branch, and fan-out + merge scenarios.
Marketing playbook overhead
Per-template orchestration path — X-VG-Flow HTTP round trip with zero-latency mocked upstream at concurrency 1. Refresh with make bench-playbook-overhead-save every 1–2 days.
| Playbook | p50 overhead | Steps | vs model |
|---|---|---|---|
| Support Automation | 1.95 ms p50 | 3 | ~421× faster |
| Invoice Processing | 1.41 ms p50 | 5 | ~582× faster |
| Policy Answer Guarded | 1.15 ms p50 | 3 | ~715× faster |
| Lead Qualification | 1.72 ms p50 | 4 | ~475× faster |
| Parallel Extract Repair Fallback | 1.41 ms p50 | 6 | ~582× faster |
Typical LLM completion820 ms
ValGuard guarded validation path0.38 ms
Up to ~2,426×
lower validation layer overhead vs model latency
Full playbook p50 2.14 ms — ~383× lower than model
Same scale, one glance. ValGuard guarded validation path measured on a zero-latency mocked upstream (chat upstream guarded; median of 5 runs, headline uses best run).
LLM baseline is an industry median for GPT-4 class chat completions. Proxy latency is the median of 5 measured runs at concurrency 1 on the guarded single-agent path (input prompt guard + customer_support_reply output pack, no agent budget cap, no per-agent token cap, zero-latency mocked upstream). "Up to" uses the best run in that set.
What this means for your team
You do not need to read microbenchmarks to get the point. Here is the practical takeaway for product, ops, and engineering leads.
Your app stays fast
Validation adds roughly a millisecond of infrastructure overhead — not hundreds of milliseconds like asking a second AI model to grade every reply.
Rules behave predictably
The same bad output is blocked every time. No “sometimes it passes” drift from prompt tweaks or model updates.
Costs stay flat as you scale
You are not paying for an extra LLM call on every completion. Validation runs as code on your layer path.
You can skip guardrail architecture science projects
Attach validator packs from the dashboard, run in shadow mode first, then enforce — without slowing down releases.
Multi-agent playbooks stay fast
Chain agents with X-VG-Flow — linear, branch, and merge paths measured in single-digit to low tens of milliseconds per run, not another LLM judge per step.
ValGuard vs LLM-as-judge
Many teams validate output by asking another model to score it. Here is how that approach compares to deterministic rules on the numbers above.
| Method | Latency | Determinism | Cost | Throughput |
|---|---|---|---|---|
| LLM judge | 5–50 ms | probabilistic | high | low |
| ValGuard | Validation engine: 0.5–3 µs Layer path: 1–2 ms | deterministic | near-zero | very high |
How we measure
Benchmark environment
- Instance
- AMD EPYC-Milan Processor
- vCPUs
- 2
- Memory
- 8 GB RAM
- OS / runtime
- Ubuntu 26.04.1 LTS · go1.25.0 linux/amd64
- Validation engine: go test -benchmem on every production template — p50 latency, allocations, and throughput on the deterministic hot path.
- Layer path: End-to-end HTTP benchmarks through the live validation stack (Postgres, auth, persist queue) at concurrency 1 on the guarded single-agent path — input prompt guard plus the customer_support_reply output pack (7 rules). No agent monthly budget cap and no per-agent token cap (token-cap DB checks are skipped when caps are unset). Upstream LLM is mocked with a zero-latency HTTP server (local httptest) — reported layer latencies are ValGuard infrastructure only, not GPT-4 inference time.
- Playbook orchestration: orchestration-bench walks published 3–5 step graphs (linear, branch, fan-out + merge) via X-VG-Flow with per-agent mocks — concurrency sweep at 1, 10, 50, 100, 500, and 1000 on the 3-step linear path (make bench-orchestration-save).
- What we compare: Industry-median LLM completion time (~820 ms) vs measured ValGuard guarded validation path (input guard + production validator pack) on the mocked upstream. The bare upstream-json scenario (json_validity warn only) is reported separately in API highlights.
Full write-up: Benchmark methodology · Streaming disclosure
Validator spotlight
Four workloads teams deploy first — numbers pulled from the latest benchmark run.
Hot-path rule check
Typical p50 on a four-rule pack — faster than most JSON parsers, with 0.51 µs · 4 rules · 16 B · 1 alloc
Fastest pathInvoice extraction pack
Twelve business rules — schema, totals, currency, required fields. Heavy pack, still 21 µs · 12 rules · 16 B · 1 alloc
Production-readyRAG citation validation
Grounding and citation checks against retrieved sources in 0.89 µs · 4 rules · 1096 B · 10 allocs
Ultra-fastPII detection
Pattern scan for sensitive data across five compliance rules in 4.6 µs · 5 rules · 16 B · 1 alloc
Compliance-readyWhy teams choose ValGuard over classifier guardrails
- Invisible on the critical path: sub-millisecond rule checks — your users never wait for a second model call
- Deterministic, not probabilistic: same input, same verdict every time — no judge temperature or prompt drift
- Zero-allocation hot paths: predictable GC behavior under high RPS — measured, not assumed
- Full-stack coverage: input guard before the model, output validation after. One validation layer, one integration.
- Production throughput: thousands of validated RPS on commodity hardware
ValGuard is built for teams that need compliance-grade guardrails without turning reliability into a latency tax.