Case packet

Neutral case identifier: case-3cb813691b28b6

The possible directed relationship from Artifact A to Artifact B is under review.

Artifact A

Retaining the episode keeps a distilled rule re-derivable

A lesson learned in operation admits two explicit retention forms. The episode is the trace of the situation the lesson came from — a session transcript, an execution trace, a worked case. The rule is the distilled statement of the lesson, separated from its occasion. Memory designs tend to treat these as rivals — episodic stores versus extracted facts — but they are layers of one system, and the choice that matters is not which to keep but whether the pair stays linked.

Linked, the pair instantiates a [two-layer execution system] at artifact scale: the rule is the derived fast path — action-shaped, cheap to load, strictly narrower than what the episode contains — and the episode is the generator-side evidence a consumer drops back to when the rule's coverage fails or its scope is contested. That fallback is what the title names. A challenged rule with its episode retained and lineage recorded can be re-derived: read the episode again, judge whether the generalization survives, revise its scope from evidence. This is semantic re-derivation under the managed-staleness regime, not deterministic recomputation — but it is real recourse. A rule whose episode is gone has none: it can be trusted or discarded, never re-examined against what taught it. Discarding the episode converts the rule from an evidence-backed derivation into a bare commitment, and [an upstream change can then name no downstream worklist] because the dependency record died with the source.

Distillation is earned by recurrence

The timing of distillation is a lifecycle question, not a storage preference. A rule distilled from a single episode is a conjecture that has skipped its test: the [discovery lifecycle] places one surprising case at observation and the posited generalization at conjecture, with acceptance gated on accumulated cases. Retaining the episode first and distilling on recurrence respects those phases — the episode store is where candidate generalizations wait for their second and third occurrence, and recurrence is the same promotion signal the two-layer architecture uses to grow a fast path. Distill-on-first-occurrence fixes a generalization exactly when the evidence for its scope is thinnest.

What distillation sheds, and where each layer wins

Distillation keeps the articulable part of a lesson and sheds the rest. The residue — calibration, situational feel, what a counterpart means by their words — is competence the episode still carries latently, because replaying an episode into context partially re-induces the conditioned state that held the lesson, while no statement of the rule can. The episode is the explicit trace of a tacit state, and the loss direction follows from [only explicit retention being durable, writable, and addressable at once]: the rule is the more addressable object, the episode preserves more of what resisted articulation. The practical familiar form of this asymmetry is that worked examples routinely outperform stated instructions for style- and calibration-shaped competence.

Governability runs the other way. Rules collide detectably — two contradictory statements can be noticed at write time — and are individually citable, revisable, and retirable. Episodes teaching opposite lessons coexist silently, and no lesson inside an episode can be revised; it can only be annotated or re-distilled. So governance lives at the rule layer, evidence and residue at the episode layer — a division of labor, not a contest. Between the raw trace and the bare rule sits a spectrum of intermediate forms — the cleaned worked trace, the rule with its attached example — and the residue share of a lesson's value is a guide to where on that spectrum it should be retained.

Costs the pair must manage

  • Loading. Retaining episodes is a capture posture, not a context posture: [persistence and loading are separate decisions], and [evidence can be preserved without becoming the next context]. Rules load by default because [a fast path should carry answers, not work]; episodes load on demand — scope disputes, re-derivation, residue-heavy tasks.
  • Model relativity. An episode's lesson is a joint product of the trace and the model that reads it; replay under different weights re-conditions differently. Episode retention therefore carries a quiet selection-grade dependency on the parametric form — faithful replay pins the reader — while a rule is comparatively model-portable. The [operation-profile vocabulary] makes the dependency statable.

Scope

  • Which episodes to keep at all is the inclusion question, and it belongs to the [declared output spec]; this note owns the form question — given a lesson worth keeping, in which layer its value survives.
  • Nothing here claims raw transcripts are the right episode form; the claim is that some episode-grade record must survive distillation for the rule to remain re-derivable.

Open Questions

  • Eviction: episodes accumulate linearly with operation; what retires one — the promotion of its lesson, a staleness horizon, or contradiction by later episodes?
  • Recall: the rule layer is findable by statement; what routing lets an agent find the episode it needs when the rule's scope fails?
  • How much residue actually survives replay, and how it degrades across model versions, is measurable and unmeasured.

Relevant Notes:

Artifact B

Source changes should surface downstream review targets, while reverse lineage can remain searchable

Use-shaping produces an artifact for a particular consumer: an instruction guides an agent, a skill body runs a workflow, a checklist enforces a policy, a paper presents an argument. What belongs in the shaped artifact depends on that consumer. When the consumer's task does not include inspecting provenance, source links can dilute focus, so placement policy may keep maintenance lineage out of consumer-visible content. In LLM instructions in particular, pointers the executor must resolve add [indirection cost]. Papers, legal analyses, audit records, and evidence-backed recommendations are boundary cases when citations are part of the consumer's warrant: use-shaping then preserves that provenance, while the artifact still needs maintenance lineage.

Whether or not provenance is visible to the consumer, the artifact stays dependent on its sources — whether its content is worked out from them or generalizes beyond them. A maintained source may be edited; an immutable or externally owned source may publish a successor that the workflow detects or adopts. Either event can put downstream artifacts at risk. Without a dependency record, an upstream change names no downstream worklist, making staleness review easier to miss.

The dependency record must therefore exist, but it need not be stored at the source or outside the artifact's hidden metadata. It only needs to stay out of consumer-visible content when the consumer does not need it. This note proposes an interruption-first criterion for workflows that cannot rely on maintainers to run a separate search: the lineage view should surface downstream targets when the workflow recognizes an upstream change. For locally controlled sources, that moment is edit time. For external or versioned sources, it is when a new version is detected or adopted.

The criterion follows from the asymmetry of two lineage queries. The forward query — what depends on what just changed? — should reach the maintainer as part of the change workflow because a separate lookup makes downstream review easier to miss. The reverse query — what informed this artifact? — is usually a deliberate investigation that can afford a search. A suitable design serves the path that should interrupt and may leave search to the path that can wait.

Where the record lives is a design choice

Under that criterion:

  • Source-side records
  • Benefit: For locally editable sources, a lineage pointer (Derived into: / Abstracted into:) is visible in the file the editor already has open, without a separate lookup integration.
  • Limitation: Lineage is scattered across sources and provides no global view by itself.
  • A dedicated lineage-link database
  • Capability: The whole graph can serve global queries (all downstream artifacts of a subtree, artifacts with no relevant lineage links, coverage) and scale past what footers can carry.
  • Requirement: A change-handling surface must consult it, such as a hook, validator, editor integration, or external-source update workflow. Without that surface, the record does not interrupt the maintainer.
  • Artifact-side records
  • Capability: Source metadata hidden from the consumer serves the reverse query cheaply and can be indexed into a forward view.
  • Requirement: Without a forward index and change-handling surface, the metadata does not produce the interruption-first signal.
  • Cost: Provenance maintenance remains attached to the artifact, even though the metadata stays outside consumer-visible content.

The designs compose: source-side pointers as the human-visible interrupt, derived into a database for global queries — at which point the database is itself a derived copy that must be [checked or absent].

Under the interruption-first model, the consumer-facing artifact carries the content needed for use while a lineage view gives maintainers downstream targets when the workflow recognizes an upstream change. What the subsequent review is depends on the lineage regime: a derived artifact (content worked out from the source) is stale until re-derived and compared; an abstracted rule (content exceeding its instances) is re-opened for support rather than invalidated. Where the derivation is mechanical, [the check is free and the regime flips to enforce-or-omit].

This KB's design choice is source-side records — the Derived into: / Abstracted into: footer sections with the ripgrep (rg) text-search command serving reverse queries — with the two labels' semantics documented in [link-vocabulary.md]. For this repository, source-side pointers avoid an additional change-time integration. A lineage database becomes worth integrating when global queries or cross-repo lineage justify that surface.

Relevant Notes:

Derived into:

  • [link-vocabulary.md] — the lineage-footer convention and its two-regime semantics

Under-review context phrase

the dependency record that keeps the pair a pair