Repository navigation
Open
Labels
area/infraInfrastructure, deployment, and operationsInfrastructure, deployment, and operationskind/designA design proposal (design-architect): multi-step, phased, decision-bearingA design proposal (design-architect): multi-step, phased, decision-bearingtask/triageQueue packet kind: verify, reproduce, and route this itemQueue packet kind: verify, reproduce, and route this item
Description
Parent: #6018 (Atlas ingestion program). Statements S21–S27 of the 2026-11-04 brief.
Requirement (Drew, in substance)
Atlas search must become measurable and judgeable, end to end:
Retrieval statistics
- Per file/embed: stats on what comes in from a shard on a query and makes it into the top K — shard-stage survival counts.
- After shard results are merged and rescored: stats on which results make the top 1, 2, 3, and the top 1–5 — final-rank distribution per file/embed. (Builds on #5774's full-vector logging per run and the #5733/#5741 rescore work.)
Feedback
- Simple feedback on results: "this was exactly what I needed" / "this was terrible" / everything in between.
- Bare minimum: thumbs up / thumbs down on all searches — every user knows how to do this with zero instruction; it must be addable from whatever surface returned the result.
- An optional comment may ride along; long-form feedback — up to an essay on why a result was terrible for a query — is explicitly welcomed and thanked. We normalize comments ourselves afterwards, based on context and increased detail (normalization is our job, not the user's).
Query trace
- Every result is associable to its query with a full trace: results carry IDs (assumed to exist — verify, and design the ID if not); for any result we can recover the scores it got at each stage (per-shard rank/score, merge, rescore stages), which shard it was in, the exact state of the embed content that was scored, and its metadata (provenance mark, version per the sibling versioning design, tier).
Uses (why this exists)
- Beyond performance and benchmarks, the stats + feedback guide evolutions of Atlas: what files are kept and what files aren't (feeds the versioning/retention deletion triggers), changes to our search patterns (weights, signals, expansion), and system evolution generally. Feedback data that cannot change a decision is decoration — the design names the decisions each signal feeds.
Design must answer
- Storage shape for traces (per-query record: query id, stage scores per result id, shard, embed content hash/state, parameters used) and its own retention — traces are themselves corpus (they belong in the ingestion source set as "statistics and reports").
- Feedback identity/weighting: whose thumbs count (Drew vs agents vs other users), per-result vs per-query feedback, and how essay comments get normalized (human pass? agent pass with the query context?) into structured signal.
- The feedback surface per client (CLI flag, service API field, UI affordance) with the thumbs path never more than one action away.
- Anti-gaming/quality: feedback on results the user never opened, duplicate feedback, agent self-feedback loops (agents judging their own retrievals) — named and handled.
Done looks like
A design doc: trace schema, stats aggregation model (per-embed survival + final-rank distributions), feedback capture + normalization pipeline, and the decision map (signal → retention/ranking/product decision), with implementation split into follow-ons.
Metadata
Metadata
Assignees
Labels
area/infraInfrastructure, deployment, and operationsInfrastructure, deployment, and operationskind/designA design proposal (design-architect): multi-step, phased, decision-bearingA design proposal (design-architect): multi-step, phased, decision-bearingtask/triageQueue packet kind: verify, reproduce, and route this itemQueue packet kind: verify, reproduce, and route this item
Activity
developing-today commentedon Nov 5, 2026
CODE-1693
dezren39 commentedon Nov 5, 2026
Research hard constraint: traces are logged AT QUERY TIME, or they don't exist
Cluster 4's one hard constraint, which this design must treat as load-bearing:
query_id, timestamp, querier context, raw query + rewritten query (the dual-submission rewriter makes these differ), corpus snapshot ids (per-shard head markers), and per candidate: embed id + embed version id, shard, per-stage (score, rank) at fan-out/merge/rescore, final rank, and which K cutoffs it survived. Ranks must be logged for the full candidate list at each stage, not just final top-K — survival at K=3 is only computable if stage outputs were recorded deeper than 3. Top-K survival stats (K=1/2/3/5 by shard, tier, source type) are then funnel aggregation over this log, not a separate system.(query_id, result_id, embed_version_id)— feedback against a version, or retention/versioning changes make old feedback uninterpretable.Wave-2 children filed under this issue
— Wave-2 research fold-in, 2026-11-04 (prior-art doc:
~/workspace/scratch/atlas-ingestion-brief-2026-11-04/prior-art-research.md)dezren39 commentedon Nov 5, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 5, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 5, 2026
Agent note - handed off
ses_e5e5390ebb4ffeBNW4a72aN77sdezren39 commentedon Nov 5, 2026
🤖 Agent note · handed off
opencode; handed off to the opencode claimant, which launches the bound session.48 remaining items
dezren39 commentedon Nov 6, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 6, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 6, 2026
🤖 Agent note · handed off
opencodedezren39 commentedon Nov 6, 2026
🤖 Agent note · picked up
repo-worker-code), OpenChamber scheduled lane7b47536b-c162-444c-be8a-3a9538cc4cb5repo-health-code-pilotdezren39 commentedon Nov 6, 2026
🤖 Agent note · triaged
repo-worker-code), OpenChamber scheduled lane7b47536b-c162-444c-be8a-3a9538cc4cb5origin/mainat32ec450e749cc40b2904682ffd6fd968e6081d38. The existingpkgs/atlas-search/crates/atlas-core/src/eval.rs/eval/README.mdharness evaluates saved rankings offline; its run contract is query ID → ranked document IDs and says raw scores are not required.search.rs/fusion.rshold branch ranks and fused scores in the live search path, but the inspected path has no durable per-query trace or feedback capture. This is not already implemented or superseded.Triage / route
No follow-up queue task was added because the parent design and the two relevant children already exist.