USE CASES·ENTERPRISE

REPLACE THE
STACK.
KEEP THE DATA.

One binary. No Logstash, no Beats, no separate vector database, no dedicated Kibana cluster. The lead section is a real security audit — XERJ pointed at its own Rust engine and at WordPress core, finding (and fixing) real bugs, with every token cost measured. The rest are capability benchmarks against Elasticsearch 8.13, reproducible from demo/playbooks/SCORECARD.md. Every section's live chart says exactly what it measured — and we removed the demos that had no real scenario behind them.

GROUP·CYBERSECURITY

AUDIT REAL CODE. FIND REAL BUGS.

Two reproducible whitebox security audits with XERJ as the agent's retrieval substrate — one on a large third-party codebase, one on XERJ's own engine. Both real, both measured, each its own full case study.

01
WORDPRESS
SECURITY
AUDIT.

An AI agent security-audited real WordPress core — 1,492 PHP files, ~619k lines — using XERJ as its retrieval substrate: index once as security facts (11,990 functions, 1,343 hooks), query the bug shape, read only the survivors. It swept 226 handlers for missing-capability IDOR (0 found — core is hardened) and surfaced the real wp_http_validate_url SSRF gap (169.254 cloud-metadata) reachable unauthenticated. The point is the method and its economics: the whole audit cost ~26K tokens against ~5.2M just to load the tree.

~26K-TOKEN AUDIT vs ~5.2M TO LOAD · 199× FEWER
CISO · APPSEC ENGINEER · SECURITY RESEARCHER
FULL CASE STUDY →
MEASURED · WORDPRESS CORE · 1,492 FILES / ~619K LINES
XERJ-ASSISTED READ EVERY FILE
Tokens, entire audit ~26,000 ~5,200,000 199×
SQLi triage: must read after 4 functions 51 whole files

TOKEN COST TO THE ANSWER · NOT LATENCY · CORE IS HARDENED — 0 IDOR ACROSS 226 HANDLERS; THE ONE REAL WEAKNESS (SSRF) IS STATED PLAINLY · SOURCES IN docs/case-studies/wordpress-security-audit →

02
XERJ AUDITS
ITS OWN
RUST.

The stronger proof: XERJ turned the method on its own Rust engine (197 files) and found and fixed real vulnerabilities. A call-graph query grep cannot express surfaced an unauthenticated /_sql stack-overflow that aborts the process; a five-stage instruction/data pass added a search-template injection that leaks private documents and a snapshot path-traversal. The three application-layer highs are fixed on the branch, each proven by crashing — then not-crashing — a live server. Against six known-fixed bugs the substrate recalled 6/6 where grep managed 4/6, at 171× fewer tokens.

4 REAL HIGHS · 3 FIXED · 6/6 RECALL vs grep 4/6 · 171× FEWER TOKENS
APPSEC ENGINEER · SECURITY RESEARCHER · AI-AGENT BUILDER · RUST TEAM
FULL CASE STUDY →
MEASURED · tiktoken cl100k_base · TOKENS TO REACH THE /_sql FINDING
XERJ-ASSISTED READ EVERY FILE
Tokens to the finding 10,533 1,805,277 171×
Detection vs grep (known bugs) 6 / 6 4 / 6

TOKEN COST TO THE ANSWER · NOT LATENCY · RECALL MEASURED AGAINST 6 KNOWN-FIXED BUGS (grep CAN'T FIND MISSING CODE); 6/6 IS IN-SAMPLE — SEE THE CAVEAT · METHODOLOGY + ALL 8 FINDINGS IN docs/case-studies/xerj-self-audit →

GROUP·PERFORMANCE & SCALE

MEASURED vs ELASTICSEARCH 8.13.

Reproducible capability benchmarks from demo/playbooks/SCORECARD.md — measured numbers on a real query matrix, not user stories.

03
SECURITY
ANALYTICS
AT SCALE.

Your SOC team spends more time waiting for dashboards than investigating threats. The battery on the right is the reproducible XERJ-vs-Elasticsearch query matrix — bool filters, range scans, term lookups and aggregations — measured on a 1M-doc corpus. XERJ is the yellow bar; Elasticsearch 8.13 is the gray one.

11.5× FASTER BOOL QUERIES
CISO · SOC ANALYST · SECOPS
FULL USE CASE →
REPRODUCIBLE · ES 8.13 · demo/playbooks/SCORECARD.md
XERJ ES 8.13
Bool query 1.38 ms 15.90 ms 11.5×
Range filter 1.34 ms 4.66 ms 3.5×
Match query 0.57 ms 1.45 ms 2.5×
Terms + avg sub-agg 0.38 ms 1.16 ms 3.1×
Date-histogram agg 0.37 ms 0.88 ms 2.4×
Cardinality agg 1.15 ms 1.92 ms 1.7×
Term query 1.36 ms 2.15 ms 1.6×
Terms aggregation 1.34 ms 1.54 ms 1.15×

P50 · 1M-DOC LLM-TELEMETRY CORPUS · FULL 91-CELL MATRIX AT xerj.org/benchmarks →

04
OPERATIONAL
INTELLIGENCE.

Ship logs at line rate. Query hot data in milliseconds. No ILM policy puzzles, no shard tuning, no Logstash pipeline. The chart shows a 24-hour diurnal ingest pattern — XERJ sustains it with zero write-stalls, and ingests 1.5–1.7× faster than Elasticsearch in the reproducible benchmark.

1.7× FASTER INGEST
SRE · DEVOPS · PLATFORM ENGINEERING
FULL USE CASE →
INGEST THROUGHPUT · 24H · SINGLE CLIENT
00:00 · 20K docs/s min 20K docs/s · peak 82.51K docs/s 20K docs/s · 24:00
05
AI-NATIVE
SEARCH &
RETRIEVAL.

Hybrid semantic + keyword search in one query. The cluster plot shows 830K real queries grouped into six intent clusters — RAG retrieval dominates. Every cluster is one index query away, not a separate Pinecone call. The benchmark below is the reproducible XERJ-vs-Elasticsearch latency for kNN and text retrieval.

3.4× FASTER kNN · 100% RECALL
ML ENGINEER · DATA SCIENTIST · AI PLATFORM
FULL USE CASE →
REPRODUCIBLE · ES 8.13 · demo/playbooks/SCORECARD.md
XERJ ES 8.13
Query-string query 1.35 ms 9.35 ms 6.9×
Multi-match query 1.44 ms 5.89 ms 4.1×
kNN · k=10 · 100% recall 0.78 ms 2.64 ms 3.4×
Match query 0.57 ms 1.45 ms 2.5×

P50 · 1M-DOC LLM-TELEMETRY CORPUS · FULL 91-CELL MATRIX AT xerj.org/benchmarks →

06
ELASTICSEARCH
REPLACEMENT.

Same API on port 9200. Same query DSL. Same client libraries. The comparison on the right is the reproducible query-latency head-to-head. Yellow is XERJ; gray is Elasticsearch 8.13 on the identical workload.

1.20× SMALLER ON DISK
VP ENGINEERING · CTO · PLATFORM TEAM
FULL USE CASE →
REPRODUCIBLE · ES 8.13 · demo/playbooks/SCORECARD.md
XERJ ES 8.13
Bool query 1.38 ms 15.90 ms 11.5×
Query-string query 1.35 ms 9.35 ms 6.9×
Wildcard query 1.35 ms 9.10 ms 6.8×
Range filter 1.34 ms 4.66 ms 3.5×
Match query 0.57 ms 1.45 ms 2.5×
Term query 1.36 ms 2.15 ms 1.6×

P50 · 1M-DOC LLM-TELEMETRY CORPUS · FULL 91-CELL MATRIX AT xerj.org/benchmarks →

07
UNIFIED
OBSERVABILITY.

Logs, traces, and metrics in one store — one binary instead of a Grafana-Loki-Tempo-Mimir stack to babysit. OTLP in, Prometheus out. The chart on the right is the reproducible query-latency head-to-head vs Elasticsearch 8.13 on log-shaped data.

6 SYSTEMS → 1 BINARY
OBSERVABILITY LEAD · SRE · INFRA
FULL USE CASE →
REPRODUCIBLE · ES 8.13 · demo/playbooks/SCORECARD.md
XERJ ES 8.13
Range filter 1.34 ms 4.66 ms 3.5×
Terms + avg sub-agg 0.38 ms 1.16 ms 3.1×
Date-histogram agg 0.37 ms 0.88 ms 2.4×
Cardinality agg 1.15 ms 1.92 ms 1.7×
Avg aggregation 1.16 ms 2.23 ms 1.9×
Terms aggregation 1.34 ms 1.54 ms 1.15×

P50 · 1M-DOC LLM-TELEMETRY CORPUS · FULL 91-CELL MATRIX AT xerj.org/benchmarks →

READY?·REQUEST ACCESS

RUN IT ON
YOUR DATA.

Leave a work email and we'll reply within one business day with a private binary, the reproduction scripts, and a 45-minute walkthrough.

We keep your email to follow up about XERJ — nothing else. No spam, no reselling.