intake-backfill-routing

name	intake-backfill-routing
description	Class-level workflow for turning grouped vadimgest / intake batches into durable Obsidian writebacks, with compact thread-level triage, deduping, and checkpoint-safe commits.

Intake Backfill Routing

Use this skill when processing grouped edge/intake records from vadimgest, especially mixed-source batches that need to become durable Obsidian notes, entity updates, or inbox summaries.

Trigger conditions

• A batch arrives grouped by source, channel, thread, or conversation window.
• Multiple raw rows belong to one real conversation and should be compacted together.
• Routing is uncertain and the safest output is an Inbox note.
• The batch includes repeated asks, resend-like duplicates, or underspecified requests.

Core workflow

1. Compact by group first. Treat a channel/thread window as one unit before deciding where it belongs.
2. Dedupe aggressively. Merge repeated facts, repeated requests, and repeated sentiment signals within the same group.
3. Answer the four intake questions for each group:
   • What needs to be done?
   • How can I help now?
   • What facts changed?
   • What patterns/signals changed?
4. Route by confidence:
   • Clear person/org/deal/project fact → update the matching Obsidian State + Log note with provenance.
   • Ambiguous or cross-entity backfill → write one sourced Inbox note for the batch.
   • Noise / synthetic / empty headers / stale pings with no new fact → skip and record why.
5. Preserve provenance. Include source line ranges or representative vadimgest://... URIs in every durable note.
6. Use compact summaries. Do not create one note entry per raw row when several rows are one conversation.
7. Commit only after writeback. If a batch has a checkpoint step, run it only after triage/writeback for that exact batch and only for the listed source lines.

Inbox note pattern

When routing is unclear, prefer one sourced Inbox note with:

• batch title and date
• one subsection per high-signal group
• src: with line ranges or representative URIs
• concise Q1–Q4 bullets
• clear note of what was skipped, if any

Pitfalls

• Do not over-split one conversation into many notes.
• Do not promote an underspecified research ask into an entity note too early.
• Do not invent run IDs, project names, or recipients that were not present.
• Do not commit checkpoint lines before the writeback is complete.
• Do not treat repeated asks as new facts unless the resend changes the request.

Verification

• The batch is fully represented in either an entity note, an Inbox note, or an explicit skip summary.
• Provenance is present for each group.
• The checkpoint line matches the processed source line(s) if a checkpoint is part of the batch.

References

• See references/codex-edge-backfill-2026-07-02.md for a compact example of the routing pattern, dedupe behavior, and checkpoint-safe commit sequence.