TrigGuard
TRIGGUARD BENCHMARKS
Request a demo

[ PERFORMANCE_BENCHMARKS ]

Measured latency and throughput

Reproducible runs against the TrigGuard execution authorization stack. Raw JSON artifacts, harness scripts, and environment metadata are published for independent verification.

Kernel FSM p99
0.018 ms
in-process · 100k iter
Decision core p99
0.474 ms
Swift /decide · 20k iter
Pipeline p99 (seq)
1.28 ms
/v1/evaluate · 5k iter
Pipeline p99 (10 VU)
4.59 ms
k6 · 30 s · 4,024 RPS
Sustained throughput
~4,200 RPS
single Node instance
Error rate
0.00%
10 / 50 / 100 VU runs
Run date: 2026-04-18 · Engine commit: 979d622 (TrigGuard/main)
Environment
Hardware: Apple M4 Pro · 24 GB RAM · arm64
OS: macOS 26.4.1 (Darwin 25.4.0)
Runtimes: Swift 6.3 · Node 22.22 · Python 3.14 · k6 (latest)
Network: Single-host localhost loopback. Zero WAN. No Cloud Run. No TLS.
Workload
Payload: POST /v1/evaluate with a representative spend request frame (tier-1 irreversible surface, two signals).
Iterations: 100,000 (kernel) · 20,000 (decision core HTTP) · 5,000 (sequential pipeline) · sustained k6 at 10 / 50 / 100 VU.
Warmup: 1,000 - 5,000 iterations discarded per harness before measurement.
Concurrency: sequential (1 client) for hot-path numbers; concurrent (10 / 50 / 100 VU) for tail-under-load numbers.
Methodology
Percentiles computed from raw client-side samples (no server-side bucketing).
Client wall-clock: process.hrtime.bigint() (ns precision, Node) or time.perf_counter() (Python).
Server-reported integer-ms timings are not used for percentile reporting.
All raw samples and per-run summaries are published as JSON; index at /data/benchmarks/benchmark_summary.json.

Kernel FSM, in-process decision (no HTTP, no crypto)

trigguard.sdk.gate.check() · trigguard-system/trigguard-kernel

VariantIterationsp50p95p99p99.9maxThroughput
Default request 100,000 0.011 ms 0.013 ms 0.018 ms 0.049 ms 0.214 ms 85,343 / s
Tier-1 irreversible + 2 signals (spend) 100,000 0.007 ms 0.008 ms 0.011 ms 0.038 ms 0.141 ms 139,716 / s

Single-threaded, after 1,000-iteration warmup. The DecisionEngine path is exercised (telemetry confirms 101,000 / 101,000 gates evaluated).

Decision core over HTTP (Swift canonical core)

POST /decide · TrigGuard/remote-eval-core

VariantIterationsp50p95p99p99.9maxThroughput
Client wall-clock (hrtime) 20,000 0.168 ms 0.260 ms 0.474 ms 1.328 ms 8.710 ms 5,285 / s

Isolates the Swift FSM + HTTP framing; no Node evaluator in the hot path.

End-to-end evaluator pipeline

POST /v1/evaluate · Node evaluator → Swift canonical core → signed receipt

ScenarioIterationsp50p95p99p99.9maxThroughput
Sequential (1 client, no concurrency) 5,000 0.485 ms 0.786 ms 1.279 ms 1.973 ms 3.460 ms 1,868 / s

Full production path: canonicalization, idempotency, auth check, protocol fingerprint, receipt hashing.

Concurrent load test (k6)

VU-based sustained concurrency · error rate = 0%

Virtual usersDurationTotal requestsRPSp50p95p99p99.9Errors
10 VUs 30 s 120,734 4,024 / s 2.26 ms 3.60 ms 4.59 ms 13.63 ms 0.00%
50 VUs 60 s 249,407 4,156 / s 11.65 ms 14.78 ms 21.33 ms 28.77 ms 0.00%
100 VUs 30 s 127,889 4,261 / s 22.71 ms 28.63 ms 35.12 ms 42.46 ms 0.00%

Single-instance Node evaluator + Swift core on one machine; saturation around ~4,200 RPS. Production deployment uses horizontal autoscaling to keep per-instance concurrency well below saturation.

Site-claim reconciliation

How measured reality compares with the published headline numbers

Claim
Kernel hot path p99 < 5 ms
Kernel FSM in-process p99 = 0.018 ms
Kernel FSM signals-heavy p99 = 0.011 ms
Decision core over HTTP p99 = 0.474 ms
Supported · ~10-280× headroom
Claim
End-to-end evaluation p99 < 15 ms
Sequential pipeline p99 = 1.28 ms
10 VU concurrent p99 = 4.59 ms
50 VU concurrent p99 = 21.33 ms (per-instance saturation)
Supported at production concurrency
Scope. These runs are on a single workstation with localhost loopback; they isolate stack-internal latency from Cloud Run, TLS, and WAN hops. Production numbers for the public Cloud Run decision path are additionally bounded by ingress routing and instance cold starts; those budgets are governed separately under the SLA.

Reproduce these runs

Every number on this page comes from a committed artifact; no hand-edited values.

The full harness lives in the TrigGuard repository. After cloning, on any machine with Node 20+, Python 3.11+, Swift 5.9+ and k6 installed:

# 1. In-process kernel FSM
cd trigguard-system/trigguard-kernel
PYTHONPATH=. python3 ../../TrigGuard/scripts/bench/kernel_latency_bench.py \
 --count 100000 --warmup 1000 \
 --output ../../TrigGuard/evidence/artifacts/benchmarks/kernel_fsm_latency.json

# 2. Start Swift canonical decision core
cd ../../TrigGuard
TG_DECIDE_PORT=9090 ./scripts/start_canonical_core.sh &

# 3. Measure /decide directly
BASE_URL=http://127.0.0.1:9090 ITERATIONS=20000 WARMUP=1000 \
 OUTPUT=evidence/artifacts/benchmarks/decision_core_http_latency.json \
 node scripts/bench/pipeline_latency_bench.js # (endpoint switched to /decide)

# 4. Start Node evaluator stub with canonical core URL wired in
cd remote-eval-stub && NODE_ENV=test \
 TRIGGUARD_UNSAFE_LOCAL_AUTH_BYPASS=true PORT=8080 \
 TG_CANONICAL_CORE_URL=http://127.0.0.1:9090/decide \
 BULKHEAD_TENANT_MAX_IN_FLIGHT=2000 BULKHEAD_GLOBAL_MAX_IN_FLIGHT=5000 \
 RATE_LIMIT_PER_TENANT=10000000 RATE_LIMIT_GLOBAL=50000000 \
 node server.js &

# 5. End-to-end sequential pipeline
cd .. && BASE_URL=http://127.0.0.1:8080 TOKEN=test-token \
 ITERATIONS=5000 WARMUP=500 \
 OUTPUT=evidence/artifacts/benchmarks/eval_pipeline_latency.json \
 node scripts/bench/pipeline_latency_bench.js

# 6. Concurrent k6 load test
k6 run --env BASE_URL=http://127.0.0.1:8080 --env VUS=50 --env DURATION=60s \
 --env TOKEN=test-token \
 --summary-export evidence/artifacts/benchmarks/k6_summary_50vu_60s.json \
 load-tests/evaluate_bench.js

# 7. Aggregate
node scripts/aggregate_benchmarks.js

Raw artifacts

Documentation

[ LAST_RUN: 2026-04-18T15:43Z · COMMIT: 979d622 ]