ValGuard.ai

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: Automatically benchmarked on VMware VM every 48 hours. Last run: Aug 31, 2026.

Benchmark environment: VMware VM · Intel Xeon CPU E5-1620 v4 @ 3.50GHz | 8 vCPUs | 16 GiB RAM | Ubuntu 20.04.6 LTS | go1.26.7 linux/amd64

Headline comparison: 820 ms typical LLM completion vs 5.01 ms measured validation layer path (median of 5 runs; up to 218× faster integrity layer).

Validation engine

Deterministic rule checks on model output — measured with go test -benchmem on every template.

Updated Aug 31, 2026 · commit 4d8fe82e

0.86 µ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.

3.6 µs

Heavy rule packs stay fast

Product Title Normalization

9 rules on a real template — still microsecond-scale.

1.0 µs

Employment Offer Language Guard

Typical check speed

4 rules on a real workload — measured on the validation hot path.

222k RPS

Engine RPS

4 rules

Sustained validation engine throughput for Calculation Validator.

Validation layer path

Updated Aug 31, 2026 · commit 4d8fe82e

375.7 µs

Proxy return path

195.3 µs

Validation engine call

+0.05 ms

Output validation overhead

4.4k RPS

Sustained throughput

Full HTTP round trip — auth, rules, persist queue. Zero-latency mocked upstream (httptest); concurrency 1.

See the full scenario library

Playbook orchestration

Multi-agent workflows via X-VG-Flow — measured end-to-end with mocked agent upstreams (make bench-orchestration).

Updated Jun 11, 2026 · commit 8998d7e

349.1 µs

3-step linear handoff

p50

Path: triage,compliance,reply,end_success · 3 validations

319.6 µs

Branch on validation pass

happy

Path: classify,draft_reply,end_success · 2 validations

238.4 µs

Branch on validation block

block

Path: classify,draft_reply,human_handoff,end_handoff · 3 validations

184.3 µs

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.

Playbooks documentation →

See the full scenario library

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.

Playbookp50 overheadStepsvs model
Support Automation1.82 ms p503~450× faster
Invoice Processing1.67 ms p504~491× faster
Policy Answer Guarded1.35 ms p502~609× faster
Lead Qualification1.38 ms p504~595× faster
Parallel Extract Repair Fallback1.67 ms p506~491× faster
Typical LLM completion820 ms
ValGuard guarded proxy path5.01 ms

Same scale as above — 0.61% of one model call. That thin sliver is the point.

Up to ~218×

lower validation layer overhead vs model latency

Full playbook p50 0.35 ms — ~2,349× lower than model

Same scale, one glance. ValGuard guarded proxy 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.

MethodLatencyDeterminismCostThroughput
LLM judge5–50 msprobabilistichighlow
ValGuardValidation engine: 0.5–3 µs Layer path: 1–2 msdeterministicnear-zerovery high

How we measure

Benchmark environment

Instance
VMware VM · Intel Xeon CPU E5-1620 v4 @ 3.50GHz
vCPUs
8
Memory
16 GiB RAM
OS / runtime
Ubuntu 20.04.6 LTS · go1.26.7 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, 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 proxy path (input guard + production validator pack) on the mocked upstream. The bare upstream-json scenario (json_validity warn only) is reported separately in proxy highlights.

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 1.2 µs · 4 rules · 16 B · 1 alloc

Fastest path

Invoice extraction pack

Twelve business rules — schema, totals, currency, required fields. Heavy pack, still 52 µs · 12 rules · 17 B · 1 alloc

Production-ready

RAG citation validation

Grounding and citation checks against retrieved sources in 2.4 µs · 4 rules · 1098 B · 10 allocs

Ultra-fast

PII detection

Pattern scan for sensitive data across five compliance rules in 16 µs · 5 rules · 21 B · 1 alloc

Compliance-ready

Why 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.

Start validatingBack to homepage chart