Skip to content

design(atlas): delta-only ingestion + offset embeds — land only changes; span-anchored chunks with non-doubling joins #6028

Open

Description

@dezren39

Parent: #6018 (Atlas ingestion program). Statements S35–S38 of the 2026-11-04 brief.

Requirement (Drew, in substance)

Delta-only ingestion

Re-ingesting a largely unchanged corpus must land only the deltas. Drew's numbers: a 21 GB corpus of which 20.5 GB is already in Atlas — re-running ingestion over it must NOT update every file, retag everything, or edit all metadata to carry a new date. What lands is exactly:

  • all the new files, and
  • the edits to the old files — edits carry a new date and repeat some overlapping data, and that overlap repetition is accepted rather than engineered away.

Untouched content is not re-embedded, not re-tagged, not re-dated. (Content-addressed landing per #3125 is the natural mechanism; this design makes "we only take the deltas" a stated, testable guarantee of the ingest path, including metadata: no mass metadata edits for unchanged objects.)

Offset / overlap embeds

The chunker need not re-chunk a changed file along fresh boundary lines. The system may accept embeds with different overlaps that are not along boundary lines, recorded as spans into the current file version. Drew's example:

An embed is accepted whose content, joined to the file's most recent version, runs from index 17 to 241 — because indices 0–16 matched a prior embed. A different embed covers another end; everything after 241 matched a different embed. Only this one diff is new.

So an edit produces a small set of span-anchored embeds covering the changed region (with whatever overlap the matcher needed), anchored by offsets into the current version, each embed knowing which prior embeds its head and tail matched.

Search-time join

A search hit shows the full paragraph — and when results are joined together, lines that were merged do not double up. The join reconstructs source text exactly once: overlapped spans between sibling embeds (and between an embed and the file version it anchors to) are deduplicated at reconstruction, so a paragraph assembled from three overlapping embeds reads as the paragraph, not as three stuttering copies.

Design must answer

  • Change detection per source type: git (commit diff), plain trees (hash walk), databases/session stores (watermarks + row hashes) — and the cost ceiling for detection itself (a detection pass that reads 21 GB to save embedding 20.5 GB has only won if reads are much cheaper than embeds; say so with numbers).
  • Span anchoring: offsets in what unit (bytes/chars/lines), against which version id, and how anchors survive a subsequent edit (offset drift — when does an anchored embed detach, and how is detachment detected and logged?).
  • Overlap acceptance rules: minimum match run to anchor on (the 0–16 head match), maximum overlap fraction before an embed is just a duplicate (interacts with the #5733 ≥0.9 dedup edge), and occurrence recording for the matched spans (an embed's matched head is an occurrence of the prior embed's content — #3125 semantics).
  • Join/reconstruction: paragraph assembly from overlapping embeds + version text; the no-double-up guarantee stated as a testable invariant; behavior when the underlying version is cold or retired (sibling versioning design).

Done looks like

A design doc: delta-detection per source with cost model, the span-anchored embed format, acceptance thresholds, join semantics with the non-doubling invariant, and a worked example using Drew's 17–241 case end to end. Implementation split into follow-ons.

Activity

  1. added
    area/infraInfrastructure, deployment, and operations
    kind/designA design proposal (design-architect): multi-step, phased, decision-bearing
    on Nov 5, 2026
  2. developing-today commented on Nov 5, 2026

    @developing-today
    Contributor
  3. dezren39 commented on Nov 5, 2026

    @dezren39
    MemberAuthor

    Research verdict: the span model is the design — CDC is the wrong engine at embed scale

    The prior-art pass (Cluster 1) settles this design's central mechanism choice:

    • Content-defined chunking is refuted as the embed-layer engine. Backup CDC (LBFS Rabin; FastCDC, USENIX ATC '16) targets ~512 KiB–8 MiB chunks; embedding chunks are ~1–2 KB, where min/max constraints dominate and the dedup bought is small. Decisively: embeddings are not hashes — a restic chunk is identical bytes, but an embedding is a function of the chunk's exact text including its window neighbors. CDC can make bytes line up; it cannot make yesterday's vector the right vector for today's window. CDC also degrades under structural shift (a +15-byte insertion invalidated 57% of 64 KiB FastCDC chunks in a controlled test). A feasibility follow-up (#6040) will verify this verdict on our own corpus before it forecloses anything.
    • The design is the rsync/restic span model. (a) Matching: rsync's sliding-window matcher (rolling weak checksum, strong verify on hit — Tridgell & Mackerras 1996) aligns a new version against prior spans at arbitrary offsets — it is literally the mechanism that computes "0–16 matched span A, 17–241 is new, 242+ matched span B." (b) Storage: a file version is an ordered list of span references (embed_id, start, end) (restic/borg shape); the version costs only its new spans plus a manifest row; spans are reused only when byte-identical. (c) Reconstruction: results carry their own text (a hit reads correctly alone), and the join deduplicates by interval union per file version — sort spans by start, merge overlapping/adjacent intervals, emit each byte once. That is the testable form of this issue's non-doubling invariant.
    • Failure catalog the design must answer (from the research): vector drift on identical content under changed windows; top-K crowding by near-duplicate v1/v2 chunks; phantom diffs from pure re-wrapping; orphan spans whose surrounding context changed meaning (span context — heading path — must version with the reference, not the span).

    Wave-2 children filed under this issue

    • #6035 — spans as (file_version_id, start, end) + text snapshots; migration from the chunk store
    • #6036 — the rsync-style matcher design
    • #6037 — structural-first splitting per source type
    • #6038 — how much a vector/rank moves with different neighbors
    • #6039 — 0/10/20% overlap vs recall and index size
    • #6040 — verify the CDC verdict on the real corpus

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

  4. added
    queue/queuedHas a queued task in the Supabase agent queue
    task/triageQueue packet kind: verify, reproduce, and route this item
    work/assignedQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    and removed
    queue/queuedHas a queued task in the Supabase agent queue
    on Nov 5, 2026
  5. dezren39 commented on Nov 5, 2026

    @dezren39
    MemberAuthor

    Triage — task 10395 (lane code-e, 2026-11-05)

    Verdict: valid design parent, already decomposed — no implementation at current main, nothing to fix directly in this issue.

    Evidence checked fresh this pass:

    Routing / ordering (the follow-ons already exist — do not re-file):

    1. design(atlas): span-table schema — spans as (file_version_id, start, end) with embedded-text snapshots #6035 — span-table schema (file_version_id, start, end) + text snapshots; migration from the chunk store. Foundation; goes first.
    2. design(atlas): offset-matching algorithm — rsync-style sliding-window matcher for span alignment #6036 — rsync-style offset matcher design. Depends on the design(atlas): span-table schema — spans as (file_version_id, start, end) with embedded-text snapshots #6035 span shape.
    3. design(atlas): chunk-boundary policy v2 — structural-first splitting per source type #6037 — structural-first chunk-boundary policy per source type. Feeds both of the above.
    4. Research gates, in parallel with 1–3: research(atlas): boundary-drift measurement — how much a paragraph's vector/rank moves with different embedding neighbors #6038 (boundary drift), research(atlas): overlap budget experiment — 0% / 10% / 20% overlap vs golden-set recall and index size #6039 (0/10/20% overlap budget), research(atlas): CDC feasibility at embedding scale — FastCDC with ~512-token targets vs the span approach #6040 (verify the CDC verdict on the real corpus before it forecloses anything).
    5. Cross-issue dependencies the design doc must respect: design(atlas): content versioning + retention — versions, rename lineage, newest-resolution, cold rollout, deletion triggers #6026 (content versioning + retention — version ids and cold/retired behavior the anchors bind to), atlas: provenance registry (chunk occurrences), content-addressed extracts, multi-DB vector resolution #3125 (provenance registry / occurrence semantics for matched spans), Atlas search: Jaccard as a third signal (rescore + ingest dedup); SPLADE as a triggered follow-on #5733 (≥0.9 Jaccard dedup edge — the maximum-overlap acceptance threshold interacts directly), design(atlas): embedding cost ledger — per-batch token/$ accounting with a delta reuse-ratio alert #6058 (embedding cost ledger — the delta reuse-ratio is the cost-model proof for "reads are much cheaper than embeds").

    What remains for this issue itself: the consolidated design doc answering its four questions (per-source delta detection + cost ceiling, span anchoring + drift/detach, overlap acceptance thresholds, join semantics + the worked 17–241 example). That doc is the synthesis of #6035–#6040, so it is correctly sequenced after those children land their designs/measurements — writing it now would freeze thresholds the research gates are meant to set. No blocker from Drew; the ordering above is the record.

    Queue: task 10395 completes as triaged with this routing. The children carry their own queue tasks (all labelled queue/queued at check time).

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 operationskind/designA design proposal (design-architect): multi-step, phased, decision-bearingtask/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