Skip to content

atlas: provenance registry (chunk occurrences), content-addressed extracts, multi-DB vector resolution #3125

Open

Description

@dezren39

Direction (Drew, 2026-10-31)

Atlas moves from a single canonical DB + one Turso publish to provenance-first, scalable infrastructure. Design doc: hatch-personal workspace/turso-atlas/docs/atlas-provenance-and-scale-design-2026-10-31.md.

Rules:

  1. Keep ALL data — nothing stripped from atlas.db or publishes to save space; only byte-identical dupes are cleaned, backups kept.
  2. Backups AND plain extracts for every corpus.
  3. Every chunk records EVERY place it was found: chunk_occurrences (chunk → array of source locators with spans, observed_at). Today dedup silently drops occurrences (~127K at first ingest); 6,344 canonical sessions own zero chunks for exactly this reason and their occurrences are unrecorded.
  4. Every import is interned content-addressed (laptop extracts CAS / R2, registry maps CA hash → normal paths) or pinned as repo@commit:path. Registry also holds line numbers / dates / spans for extracts.
  5. Retrieval: vector/FTS search across multiple Turso shard DBs (collection × month) returns IDs; a catalog/registry resolves an ID to a file, a chunk, or a start–end section — including a member of a tar in R2 (sidecar index, range fetch) or a local file.

Verified state feeding this (2026-10-31): canonical 18,325 sessions / 122,124 messages / 107,639 chunks; local-only = 6,941 chunks of personal-client TEXT held back from Turso by policy (not missing embeddings); Turso atlas 1.0 GB / 100,698 chunks; laptop ~/atlas 12 GB contains NO consequential byte-identical duplicates (hash-verified) — it is distinct versions/working sets, so no cleanup windfall exists.

Phases

  1. Add chunk_occurrences + cas_registry to canonical atlas.db; ingest writes occurrences from now on (no re-embed, no republish).
  2. Laptop extracts dir + CAS; atlas-backup covers it; backfill extracts for sources still on disk.
  3. Occurrence backfill from CAS extracts; document the local-only publish predicate in the publish script.
  4. Catalog DB + shard layout at next publish growth (or full message-archive ingest); resolution as MCP tools (search → ids → resolve → fetch span).

Acceptance criteria

  • A chunk_occurrences provenance registry exists: every chunk records every source locator it was found at (with spans and observed_at), including occurrences previously dropped by dedup.
  • Backups AND plain extracts exist for every corpus; imports are interned content-addressed (CAS hash → path registry) or pinned as repo@commit:path, with line numbers / dates / spans recorded for extracts.
  • Retrieval works across multiple Turso shard DBs (collection × month): vector/FTS search returns IDs and the catalog/registry resolves an ID to a file, chunk, or start–end section (including a tar member in R2 via sidecar index + range fetch, or a local file).
  • No data is stripped to save space; only byte-identical duplicates are cleaned, with backups kept.

Activity

  1. dezren39 commented on Oct 31, 2026

    @dezren39
    MemberAuthor

    Update — privacy model changed (Drew, 2026-10-31)

    The local-only publish gate is lifted: everything in canonical publishes to Turso, including the six personal clients (6,941 chunks). Privacy moves to query-time classification filters: scheme-1.0 labels (already complete for all 18,325 sessions in classification-full-v1.json: personal 16,009 / local-only 2,226 / secret-bearing 90) ship inside the publish with a denormalized sensitivity column on chunks + sessions for pre-filtering, and Turso access stays restricted to trusted workers (per-DB tokens). secret-bearing is deny-by-default for any caller not explicitly granted that tier.

    Publish v2 build is in flight on the laptop: all 18,325 sessions / 122,124 messages / 107,639 chunks + labels + FTS + bge-small vectors for the previously held-back 6,941 chunks. It stops before the live Turso replacement, which waits on Drew's go with the v2 size + secret-bearing footprint reported. Design doc updated: hatch-personal workspace/turso-atlas/docs/atlas-provenance-and-scale-design-2026-10-31.md.

  2. added
    source/humanFiled directly by a human
    priority/highImportant and time-sensitive
    effort/lLarge: multi-day or open-ended; expect staged check-ins
    area/infraInfrastructure, deployment, and operations
    meta/enrichedIntake review done: acceptance criteria, links, and normalized labels added
    on Oct 31, 2026
  3. dezren39 commented on Oct 31, 2026

    @dezren39
    MemberAuthor

    Intake review

    Fleet monitor intake pass (2026-10-31).

    Related: design doc referenced in the body (hatch-personal workspace/turso-atlas/docs/atlas-provenance-and-scale-design-2026-10-31.md). No merged PR or commit found that implements this — verified live, not already solved.

    Notes: This is a Drew-directed design/epic, not a single fix: the five rules in the body are the spec. It arrived with no labels and no acceptance criteria; both are now set (criteria derived from the body's own rules).

    Risks: Scope is large (registry schema, CAS interning, multi-DB retrieval) — a single queue task should not try to land it whole. Backfill of ~127K dropped occurrences touches the canonical atlas data; rule 1 (keep all data, backups kept) must gate any migration.

    Suggested approach: Split into implementation phases under this issue (registry + occurrence backfill first, then CAS interning, then multi-shard retrieval), each routed as its own task; keep this issue as the tracking epic (consider meta/epic).

  4. dezren39 commented on Oct 31, 2026

    @dezren39
    MemberAuthor

    atlas-search CLI shipped (hatch-personal PR https://github.com/dezren39/hatch-personal/pull/9, merged 2026-10-31): hybrid FTS+vector search + get-chunk over the live v2 publish, turso and local backends, sensitivity ceiling default personal. Verified on both backends with programmatic asserts (gold-chunk paraphrase rank 1, filter correctness, sensitivity gate, provenance).

    Findings for the v3 (fused-rerank) publish, from building against the live DB:

    1. vector_top_k does not work on the current plain-BLOB vec table (no libsql vector index) — the CLI uses ORDER BY vector_distance_cos(vec, vector32(?)) (~4s unfiltered full scan). If v3 wants indexed search, publish the vec column with a libsql vector index (diskann) and the CLI can switch.
    2. The publish schema has NO secondary indexes: any chunk->message->session join chain costs 20-60s over Turso. The CLI works around it (denormalized chunks.sensitivity + IN-subquery, ~3-15s), but v3 should add an index on messages(session_id) and denormalize session_id onto chunks.
    3. The CLI is already stage-1-ready for fused rerank: --model/--vec-table/--embedder/--trunc configurable (Snowflake ST path with prompt_name='query' smoke-tested against vec-snowflake.db), results carry rank_sources + stage-1 scores for the future RRF rerank step.
  5. added
    queue/queuedHas a queued task in the Supabase agent queue
    task/triageQueue packet kind: verify, reproduce, and route this item
    on Nov 3, 2026
  6. developing-today commented on Nov 3, 2026

    @developing-today
    Contributor

    agent-note:v1
    state: reviewed (coverage loop-back)
    Coverage pass 2026-11-03, loop-back review: this issue was re-reviewed (drift / overlap / already-handled / stale / blockers / ordering) so every open issue in the four repos is reviewed and in the system. Verdict: still live; in the system as task 7378 (triage, queued, priority 50) in repo-health-code-pilot. Labels audited and synced. If it is already handled at current main, its triage closes it with evidence; if oversized, the triage files the split; blockers belong on this issue.
    Found via: coverage loop-back 2026-11-03

  7. 9 remaining items

  8. dezren39 commented on Nov 4, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · handed off

    • Agent: fleet monitor (repo-fleet-monitor)
    • Session / ID: task 7378
    • Found via: monitor reconciliation
    • Task: claim-evaporated repair — the queue claim on task 7378 ended without complete/park/block, its lease expired, and the task returned to queued unclaimed while this issue still carried claimed labels. Labels reset to the truth: queue/queued + status/needs-triage. Checkpoint stage at evaporation: handed_off.
    • Expectation: the next lane to claim task 7378 posts a fresh pickup note.
  9. added
    work/assignedQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    and removed
    queue/queuedHas a queued task in the Supabase agent queue
    on Nov 4, 2026
  10. dezren39 commented on Nov 4, 2026

    @dezren39
    MemberAuthor

    agent-note:v1
    event: picked up
    task: 7378 (triage; queue repo-health-code-pilot; worker repo-worker-code; lane c8b9355e-319a-4640-8096-7ad19480d151 — OpenChamber scheduled lane)
    by: repo-worker-code

    Fresh verification: issue #3125 is OPEN, assigned to Drew, and has no hard-stop labels. This is a multi-phase Atlas provenance/scaling epic, not a code-sized fix. Existing issue history says its requirements are sourced from the hatch-personal Atlas design; prior queue handoffs expired, so I am resuming from the issue/PR state rather than assuming work was done.
    next: check current repo PRs/queue ownership and the linked Atlas project state; identify what is in flight, what is landed, and the record semantics/blockers before routing.

  11. dezren39 commented on Nov 4, 2026

    @dezren39
    MemberAuthor

    agent-note:v1
    event: done — triaged
    task: 7378 (triage; queue repo-health-code-pilot; worker repo-worker-code; lane c8b9355e-319a-4640-8096-7ad19480d151 — OpenChamber scheduled lane)
    by: repo-worker-code

    Fresh state: #3125 remains OPEN; no matching implementation PR exists in developing-today/code. Atlas is still in dezren39/hatch-personal per hatch-personal#2 (no migration scheduled). Current Atlas activity there is search/production work: PRs #9, #17–#19, and #22 are merged; no Atlas PR is open; issues #20 (writer stall/index) and #21 (search improvements) remain open. None implements the provenance registry.

    The adopted design doc gives record semantics: stable source_roots; separate repo owner/name and commit SHA; virtual item_path; each chunk_occurrences row identifies (chunk_id, root_id, item_path, span_start) with spans/role/observed_at; duplicate hash hits add occurrences; CAS locators remain immutable; unrecoverable occurrences are recorded only when logs prove they existed.

    To keep implementation in the correct repo and make the oversized plan executable, created and verified these hatch-personal follow-ups:

    No code was changed and no implementation was claimed. Queue task 7378 completed as triaged; sandbox backlog/sweep bookkeeping is deferred to fleet reconciliation.

  12. dezren39 commented on Nov 5, 2026

    @dezren39
    MemberAuthor

    Extension from the 2026-11-04 Atlas ingestion brief — provenance standard, widened

    Drew's 2026-11-04 brief (program tracker: #6018) makes this issue's provenance registry the foundation and adds requirements that extend its scope. Recorded here rather than in a duplicate issue, per the brief's dedup discipline:

    1. One provenance standard for ALL sources (brief S28): "a standard way to understand a file's provenance: when and where it came from" — the registry's locator model is that standard; non-file sources (session stores, chat logs, GitHub comments, generated reports) get locators of the same dignity as files, not second-class free text.
    2. Source-system marks alongside repo@commit:path (S33): Drew's example — a chunk's origin mark may read "OpenCode DB @ AMD laptop on this day": the mark names system + machine + date when there is no repo. Concretely the locator grammar needs a source-system form (e.g. opencode-db@amd:2026-11-04 + session/message ids) next to the git form, so both are parseable by the same tooling.
    3. Past/future-self association (S29): occurrences say where a chunk was found; the brief also needs version lineage — a file associated with its past and future selves (edits and renames as lineage edges). That model is designed in the sibling versioning issue #6026; the two must share identity (a chunk's occurrences reference version ids from design(atlas): content versioning + retention — versions, rename lineage, newest-resolution, cold rollout, deletion triggers #6026's model, not bare paths).
    4. Segment search as the association mechanism of last resort (S31): where no lineage exists (loose files, legacy extracts), associations are MADE by searching segments of the file's content within Atlas and linking what matches — the registry should record how an occurrence was established (observed at ingest / derived by segment match / asserted by a human), since derived associations carry different confidence.
    5. Unassociated + duplicate are logged states (S32): sources must carry enough metadata from the start that a file which associates to nothing — and a duplicate that collapses into an existing chunk — is recorded as such, never silently dropped. (This extends this issue's rule 3: dedup already drops occurrences silently today, ~127K at first ingest; the brief generalizes the fix from chunks to files.)

    The existing-embed audit task (#6029) measures the current corpus against this widened standard and will size the backfill this registry needs.

  13. dezren39 commented on Nov 5, 2026

    @dezren39
    MemberAuthor

    Wave-2 research addition: the PROV-lite field set for the provenance record

    The Atlas prior-art pass (Cluster 3) grounds this registry's record design in W3C PROV — two of its relations are literally the version-lineage vocabulary: wasRevisionOf (new file version ↔ prior version) and specializationOf (a version ↔ the timeless logical file), alongside wasGeneratedBy, used, wasDerivedFrom, wasAttributedTo. The recommended record is PROV-lite — roughly eight fields, standard names and directions, no full PROV-O/RDF deployment (a named dead end: practitioners converge on "learn the vocabulary, skip the ontology"):

    entity id · derived-from ids · generated-by run id · attributed-to agent · timestamps · source mark · content hash · span offsets.

    Complementary shapes from the same cluster:

    • OpenLineage (Job/Run/Dataset + sourceCodeLocation/version/nominalTime/parent facets) is the model for the ingest-run record — the run-level companion to this per-chunk registry.
    • in-toto/SLSA attestation shape for per-batch statements (subject = written chunk hashes; materials = source hashes + marks; builder = ingester name/version/git hash) — filed as a design follow-up under the ingestion program (#6045, child of #6019).
    • The composite source-mark grammar (repo@commit:path; system@host@date; chat@session@timestamp; content hash riding in the mark) is filed as #6044 under the program tracker #6018 — this registry is its implementation home, and the existing-embed audit (#6029) is its consumer.

    Filed under: Atlas ingestion program #6018, wave-2 research fold-in (research item 15).

    — Wave-2 research fold-in, 2026-11-04 (prior-art doc: ~/workspace/scratch/atlas-ingestion-brief-2026-11-04/prior-art-research.md)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area/infraInfrastructure, deployment, and operationseffort/lLarge: multi-day or open-ended; expect staged check-inskind/enhancementmeta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedpriority/highImportant and time-sensitivesource/humanFiled directly by a humantask/triageQueue packet kind: verify, reproduce, and route this item

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions