C.W.K.
Stream
Lesson 03 of 05 · published

Crumbs Are Never Consumed

~9 min · never-consumed, provenance, citation, exact-ids

Level 0Cold Hearth
0 XP0/34 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"A crumb that fed one draft remains fully available to another."

Reading Is Not Eating

Some systems consume their inputs: an inbox digest marks messages read and folds them away, a batch job drains a queue, a compaction merges records and drops the originals. Assembly does none of that. When Pippa reads a set of crumbs to build a draft, the crumbs are inputs to a projection — they are read, never eaten. After assembly, every crumb is exactly where it was, in the same state, fully available to the next draft, the next reading, the next year. Reading is not a state change on the thing read.

This is what makes two drafts over the same crumbs a normal, supported outcome instead of a conflict. Monday's reflective draft and a year-end retrospective can both draw on the same March crumbs, each reading them through a different lens, and neither reading diminishes the other or the crumbs. The raw material is inexhaustible; only the drafts are opinions, and opinions can coexist.

Derive without draining. A projection should read its source, never consume it. The moment building a derived artifact removes or mutates the source, you've made the derivation one-shot and destroyed your ability to re-derive differently. Keep the source whole after every read, and every future projection stays possible.

Provenance Is Exact, Not a Summary

When a draft records its source_crumb_ids, it stores the precise IDs of the crumbs it read — not a paraphrase, not a count, not a summary of them. That exactness is what makes provenance trustworthy. Months later you can open a paragraph, follow its source IDs, and land on the actual fragments it grew from, each still readable in its original words. A summary would rot: it would drift from the crumbs, and you could never be sure the draft's claim matched the evidence. Exact IDs never drift, because they point at identity, and identity is the one thing about a crumb that never changes.

Citations That Survive a Re-file

Because provenance points at the crumb's ULID, not its date or text, a citation keeps resolving even after the crumb has been re-filed to another day or moved to another journal. The draft said 'I was built from crumb 01J8Z…', and crumb 01J8Z… still exists, still readable, wherever it now lives. Consume-and-summarize would have severed that link the first time anything changed; reference-by-identity keeps the lineage intact for the life of the journal.

Code

One crumb, cited by two drafts, owned by neither·json
// the same crumb id appears in both drafts' provenance —
// it is referenced, never owned or consumed

{ "draft": "01D..reflective", "target_date": "2026-03-14",
  "source_crumb_ids": ["01J8Z...a", "01J8Z...b"] }

{ "draft": "01D..yearend",   "target_date": "2026-12-31",
  "source_crumb_ids": ["01J8Z...a", "01K..q", "01K..r"] }

// crumb 01J8Z...a fed both. After each assembly it is byte-for-byte
// unchanged, still available to a third draft that hasn't been written yet.

External links

Exercise

Think of a place where you 'process' items into a summary — cleared notifications, an archived inbox, a compacted log. Ask what you lose the moment the originals are consumed: could you re-derive a different summary later? Then redesign it so the summary references the originals by stable ID and leaves them intact. What new things become possible once reading stops destroying?
Hint
The capability you unlock is re-derivation: once the source survives every read, you can build a second, third, or completely different projection over it whenever you want. Consuming the source trades all of that away for a one-time convenience.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.