IBEX Harness
DocsBenchmarksBlogChangelogRoadmap
GitHub
IBEX Harness

Documentation

Architecture Decision RecordsADR-0002: Repository foundation bootstrapADR-0003: Branch protection and merge policyADR-0004: Protobuf and code generation policyADR-0005: Postgres migration strategyADR-0006: Auth protobuf contract (`ibex.auth.v1`)ADR-0007: Auth token validation implementationADR-0008: Security scanning and CI quality gatesADR-0009: Permission bitmap layoutADR-0010: Cryptography policyADR-0011: Proxy auth gRPC client and middlewareADR-0012: Proxy request normalization (OpenAI chat)ADR-0013: Proxy input validation and stable error envelopeADR-0014: Core domain migration sequencingADR-0015: Proxy rate limit skeleton (Phase 1)ADR-0016: Proxy agent identity verification (Phase 1)ADR-0017: Request ID and trace context strategy (Phase 1)ADR-0018: Graceful shutdown contract (Phase 1)ADR-0019: OpenTelemetry provider configuration (Phase 1)ADR-0020: Shared package boundaries — `packages/config` and `packages/apierror`ADR-0021: Prometheus Metric Catalog (Phase 1)ADR-0022: Health check contract (Phase 1)ADR-0023: Docs site architecture (Phase 1.5)ADR-0024: Benchmark data publishing modelADR-0025: LLM provider abstractionADR-0026: OpenAI client designADR-0027: Streaming dual-write strategyADR-0028: Auth cache designADR-0029: Token revocation propagation via Redis pub/subADR-0030: Directive versioning strategyADR-0031: System prompt injection strategyADR-0032: Session data model and retentionADR-0033: ClickHouse llm_traces schema and retentionADR-0034: Proxy overhead performance measurement methodologyADR-0035: Chat Idempotency-Key Redis dedupeADR-0038: Context assembly service design and gRPC contractADR-0039: Proxy Postgres ownership for session and directive storesADR-0040: Anthropic provider adapterADR-0041: Model capability registryADR-0042: Self-hosted OpenAI-compatible LLM adapterADR-0043: Tokenizer registry architectureADR-0044: Non-streaming response pipelineADR-0045: Streaming response transformationADR-0046: Embedder interface and profile registryADR-0047: Memory temporal validity foundationADR-0048: Memory multi-label categoriesADR-0049: Memory relationship graph readinessADR-0050: MCP server skeleton (transport, auth, audit)ADR-0051: Local LGTM observability stack (Phase 2.5 exit pull-forward)ADR-0052: Memory schema v2 expand (HNSW, quality columns)ADR-0053: Vector store abstraction and composite scoring v2ADR-0054: In-process Presidio PII detection in memoryADR-0055: Memory write-path exact and near-duplicate dedupADR-0056: Temporal-interval-aware conflict detectionADR-0057: Memory write-path persistence and orchestrationADR-0058: Semantic search FTS fallback triggerADR-0059: Hot cache read pathADR-0060: Memory service tenant isolation architectureADR-0061: Retrieval-quality benchmark methodologyADR-0062: Worker task observability and dead-letter handlingADR-0063: Extraction output schema v2ADR-0064: Extraction provider registry and batch executionADR-0065: Extraction batch idempotency and turn pointer orderingADR-0066: Extraction quality evaluation harnessADR-0067: Context capability catalog generate-and-diff for token budgetsADR-0068: Composite scoring-time relevance gateADR-0069: Context packer bounded DP knapsackADR-0070: Context formatting locked ordering and session nonceADR-0071: Context assembly gRPC degradation ladder and retrieval deadlineADR-0072: Extraction enqueue via worker HTTP (not Celery Redis wire format)ADR-0073: Organization Lifecycle and Cascading SuspensionADR-0074 Provider Credential StorageADR-0075 Per-Org Model Routing PolicyADR-0076: Circuit Breaker per ProviderADR-0077: Provider Fallback RoutingADR-0078: Operator runtime topology & environment contract (4.P.0)ADR-0079: Operator session RS256 dual-verify and TOTP step-upIBEX Console service rename and boundaryADR-0081: Fail-closed Proxy runtime controlsD2 metadata-only trace read contractD2 publication, identity, query, and lifecycle contract
ADRs›ADR-0061: Retrieval-quality benchmark methodology
ADRs

ADR-0061: Retrieval-quality benchmark methodology

Architecture decision record 0061 — HNSW, ranking-quality gold set, and write-pipeline CI regression gates with committed baselines and published history.

ADR-0061: Retrieval-quality benchmark methodology

  • Status: Accepted
  • Date: 2026-08-31
  • Authors: IBEX Harness team
  • Milestone: 3.E.3 Retrieval-quality benchmark sign-off

Context

Phase 3 Track B ships HNSW recall/latency methodology in ADR-0053 §10 (strict corpus reset, production cells, ef_search=40). Milestone 3.E.3 adds permanent CI regression gates for:

  1. HNSW recall/latency — enforce persisted status on published runs
  2. Ranking quality — gold-set precision/recall/MRR vs committed baseline
  3. Write pipeline — wall-clock MemoryWriteOrchestrator.create() p95 vs SLA + baseline

Proxy load benchmarks remain ADR-0034 / ADR-0024. This ADR covers the memory substrate suites only.

Options considered

1) Gate enforcement location

  1. Schema-validate published JSON only — gates could pass with status: fail in history.
  2. Dedicated enforce steps that exit non-zero before merge (chosen).

Decision: (2). HNSW: check_hnsw_gate_status.py reads top-level runs[].status from hnsw-benchmark-data.json. Ranking/write: regression_gate.py / write_pipeline/regression_gate.py return exit code 1 on policy failure.

2) Ranking gold set design

  1. Live embedder + human labels at CI time — non-deterministic, costly.
  2. Committed gold_set_v1.json with deterministic zero_embedding(hotspot) (chosen).

Decision: (2). Fifty memories, twenty queries, single-labeler v1 disclaimer (ranking_quality/README.md). validate_gold_set.py runs in CI before the bench; composite-ground-truth order is validated against production composite_score().

3) Regression tolerance policy

  1. Hard-fail only in bench (100% metrics) — regression gate never exercised on real variance.
  2. Committed baseline.json + max_regression_pct policy with synthetic gate tests (chosen).

Decision: (2). Ranking: max_regression_pct: 5.0 on precision@5, recall@10, MRR, top_category_accuracy. Write: max_latency_ms_p95: 200 absolute SLA plus max_regression_pct: 20.0 on p95 latency. Synthetic failure paths tested in test_regression_gate.py and write_pipeline/test_regression_gate.py.

4) Published history delivery

  1. Per-suite data PRs on contributor branches.
  2. Single bot PR on chore/bench-data-publish upserting all suite JSON files (chosen).

Decision: (2) per ADR-0024. Bot posts one sticky PR comment with per-suite matrix + deep dives.

Decision

HNSW suite (benchmarks/memory/)

ConstantValueSource
Published ef_search40publish_cells.py
Published min_similarity0.70same
Recall floor0.98_RECALL_SLA
1M p95 / p99 SLA< 30 ms / < 100 mswhen 1M cell present (full profile)
CI profilessmoke (PR), fast (main), full (weekly).github/workflows/memory-benchmark.yml

Enforcement: check_hnsw_gate_status.py after publish build; fails CI when status != pass.

Ranking-quality suite (benchmarks/memory/ranking_quality/)

ItemShipped value
Gold setgold_set_v1.json — 50 memories, 20 queries
Embeddingszero_embedding(hotspot) — deterministic cosine geometry
Metricsprecision@5, recall@10, MRR, expected_order_match, top_category_accuracy (metrics.py)
Baselineall metrics 1.0 (baseline.json)
Regression policymax_regression_pct: 5.0
Published pathweb/public/benchmarks/ranking-quality-benchmark-data.json

Bench hard-fails when any query misses perfect metrics; regression gate compares latest run to baseline for hardware variance tolerance.

Write-pipeline suite (benchmarks/memory/write_pipeline/)

ItemShipped value
MeasurementWall-clock orch.create() over 40 iterations
SLAp95 < 200 ms (max_latency_ms_p95: 200)
Baseline p95199 ms (baseline.json)
Regression policymax_regression_pct: 20.0 on p95
Published pathweb/public/benchmarks/write-pipeline-benchmark-data.json

CI wiring

  • Workflow: .github/workflows/memory-benchmark.yml
  • Jobs: collect-hnsw-benchmarks, collect-ranking-quality, collect-write-pipeline-bench
  • Publish on gate failure: build steps use if: always() so failed runs still record status: fail in published JSON
  • Bot: ranking/write/HNSW PR comments + combined data PR (#660 pattern)

Consequences

Positive

  • Three memory suites share one enforcement pattern: run bench → regression gate → publish → validate.
  • Synthetic gate tests prove failure paths without relying on live-data luck.
  • Dashboard history JSON is bot-published on main only — PR branches use artifacts + comments.

Negative

  • Gold set v1 is single-labeler, small-N — not a Phase 5 inter-rater gold standard.
  • Ranking bench always expects 100% metrics; the 5% regression band only helps CI hardware drift, not partial quality regressions caught solely by the bench script.
  • HNSW 1M cells run on full profile only; smoke/fast PR CI defers 1M (documented in bot comments as "1M deferred").
  • Stub published JSON on feature branches can conflict with bot chore/bench-data-publish until merged — resolve by keeping bot branch rebased on main.

References

  • 3.E.3 milestone
  • ADR-0053 §10 — HNSW bench methodology (Track B)
  • ADR-0024 — bot publish model
  • PR #654 — 3.E.3 implementation
  • benchmarks/memory/README.md — suite index

Was this page helpful?

Edit on GitHub

Last updated on

PreviousADR-0060: Memory service tenant isolation architectureNextADR-0062: Worker task observability and dead-letter handling

On this page

  • Context
  • Options considered
  • 1) Gate enforcement location
  • 2) Ranking gold set design
  • 3) Regression tolerance policy
  • 4) Published history delivery
  • Decision
  • HNSW suite (benchmarks/memory/)
  • Ranking-quality suite (benchmarks/memory/ranking_quality/)
  • Write-pipeline suite (benchmarks/memory/write_pipeline/)
  • CI wiring
  • Consequences
  • References
0%