Roadmap: Retrieval Evaluation and Observability as a Product Surface

Gap statement: strong internal plumbing, no customer-visible surface

Wikantik has arguably more honest evaluation machinery than the LLM-judge frameworks the market standardized on — a retrieval experiment harness, retrieval-quality CI, a per-bundle coverage signal computed from true dense cosines, and a real-traffic query log. But all of it is internal plumbing. Competitors ship dashboards, traces, and built-in metrics that buyers can see. The gap is productization, not science — which makes it one of the cheapest credibility wins on the roadmap.

Market grounding

Current Wikantik state

Proposed direction

  1. Schedule the harness: nightly/weekly runs against the eval corpus with results persisted; alert on recall regression beyond a threshold. This is configuration plus a results table, not new code of substance.
  2. Retrieval-quality dashboard (admin UI): recall trend from harness runs, under-served-query burn-down from the query log, coverage-confidence distribution over live traffic, index freshness (embed-queue depth, last re-index).
  3. OpenTelemetry traces on the retrieval path: spans for candidate retrieval → fusion → rerank chain → bundle assembly, propagated through /api/bundle and both MCP servers — stage-wise timing and result counts per query, exportable to any OTel backend.
  4. Publish the methodology: a public page documenting the metric definitions, the harness, and the measured-dead-levers list — honesty as marketing, and a genuine differentiator against LLM-judge theater.

Phase 1 scope and acceptance criteria

First session scope: scheduled harness runs + a persisted results table (numbered migration) + a regression alert. No dashboard, no OTel.

Phase 1 is done when:

  1. A scheduled (nightly or weekly) run executes the harness against eval/bundle-corpus and persists per-run recall@12 (overall, and per retrieval stage where the harness supports it) with timestamp and build/config identity.
  2. An induced regression — temporarily enabling a known-bad configuration in a test environment — fires the alert; a normal run does not.
  3. A short runbook page documents how to read a result row and respond to an alert.
  4. The results table migration re-applies as a no-op.

Dashboard (step 2) and OTel (step 3) are separate phases with their own gates; do not bundle them into Phase 1.

Verify before designing on these

Non-goals

Investigation starting points

See Also