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

Interpretation Is Derived

~11 min · interpretation, derived-state, rebuildable, four-layers

Level 0Cold Iron
0 XP0/36 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"You can throw the entire typed layer away and rebuild it from the crumbs. That is exactly why it is safe to keep improving."

Layer Two of Four

Recall the four-layer model: raw crumbs, then interpretations, then deterministic aggregates, then narration. Interpretation is layer two, and its defining property is that it is derived. Pippa reads a raw crumb and writes a typed annotation beside it — never inside it. The raw prose is untouched truth; the interpretation is a rebuildable reading that sits on top. If every interpretation in the database vanished tomorrow, a re-run over the crumbs would reproduce the layer. That single fact is what lets the reading get smarter over time without ever putting the truth at risk.

What an Interpretation Records

An interpretation is a small, honest record. It names the crumb it read, the types it found, the fields it could extract per type, the evidence span it rested on, and — crucially — who read it and under which rubric: the interpreter vessel and the interpreted_at generation. That provenance is what makes the layer comparable across time. When you look at a reading, you can always tell which model produced it and which rubric version it followed, so a smarter later pass never silently overwrites an earlier judgment; it stands beside it.

Interpretation is derived: rebuildable, versioned, never a mutation of the source. The raw crumb is the truth; the reading is a projection of it. Improving the rubric is safe because the worst case is a re-run — you can never corrupt what you can always regenerate.

When the Reading Runs

The interpretation worker is event-driven, with no schedule of its own (Forge runs no cron). It sweeps once at startup and is kicked after every crumb add or revise. The pending predicate is a single query: a crumb needs reading if it has no reading yet, if its reading is behind the crumb's current revision, or if its reading is behind the current RUBRIC_VERSION. That one condition captures both new crumbs and rubric evolution. A per-crumb attempt cap keeps an unreachable brain from spinning the worker forever — care includes not melting the machine at 3 a.m. over a crumb that will not type.

Code

An interpretation record — derived, with full provenance·json
{
  "crumb_id": "01J8Z...",           // what it read (never edited)
  "types": ["symptom"],
  "site": "knee",
  "severity": "mild",
  "trend": "improving",
  "evidence": "a little stiff after the ride",  // verbatim span
  "interpreter": "claude",           // which vessel read it
  "interpreted_at": "2026-07-24T...",
  "rubric_version": 2                 // which generation
}
// Delete this and the crumb still exists.
// Re-run interpretation and this comes back. Derived, not owned.

External links

Exercise

Suppose you stored the type directly ON the crumb at capture instead of in a derived layer. Six months later you improve how you read a word like 'stiff'. What must you now do to every old crumb, and what have you lost that Forge's derived layer would have kept?
Hint
Stored-on-the-crumb means improving the rubric forces you to edit history in place — losing the original judgment and the provenance of which generation read what. Derived means you just re-run; both the old and new readings survive.

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.