[Aspiration] Cross-scenario knowledge persistence — domain-level compounding

[usathyan]

Aspiration

Today, when a contributor runs a new scenario in an existing domain (e.g., a 7th drug-discovery scenario after S6), the pipeline reads only the static domain config (domain.yaml, SKILL.md, epistemic.py, workbench/template.yaml). Prior scenario graphs are not consulted during ingest, extraction, build, or epistemic analysis. There's no automatic compounding of knowledge across runs in the same domain.

Refinements are human-mediated today: a contributor reads the narrator briefing, notices a missed pattern, manually edits the domain config, commits. That's real value but it's contributor maintenance, not framework learning.

This issue tracks a multi-phase aspiration: build mechanisms by which earlier scenario graphs in a domain enhance the brute-facts and epistemic layers of new scenarios in the same domain.

Why this matters

The framework's positioning rests on a domain getting better the more it's used. That's currently true only insofar as humans do the work of folding lessons back. A real compounding mechanism would:

• Make the "scenario count = maturity signal" claim automatically true, not contingent on contributor diligence
• Let users in the same domain inherit canonical entity forms, prior contested-claim resolutions, and persona-tested patterns without redundant work
• Give the narrator awareness of historical context ("S6 already flagged temporal stratification on semaglutide INDICATED_FOR obesity")
• Differentiate epistract from "extract once, throw away" pipelines

Candidate mechanisms (ordered by feasibility)

1. Cross-scenario entity canonicalization (most tractable)

Persist a per-domain canonical entity store: domains/<name>/canonical_entities.json (or sqlite/lancedb). When core/run_sift build runs a new scenario, it consults this store during entity resolution so that semaglutide (resolved in S6) is reused — not re-resolved from scratch — in S7+.

Roughly:

• New step at the end of cmd_build: append/merge new entities to the canonical store
• New step at the beginning of cmd_build: load the canonical store; pass it to sift-kg's resolver as a known-aliases dict
• Risk: stale canonical store as ontologies evolve; need a versioning / refresh story

2. Domain-level aggregate graph

Maintain domains/<name>/aggregate_graph.json — a master KG that accumulates all entities and relations seen across every scenario run on that domain. New scenarios start with this graph in scope; their extractions merge into it. Workbench can browse the aggregate.

Risks:

• Storage and load-time cost grows linearly with scenario count
• Cross-corpus relation merging needs careful attribution (which scenario produced this edge?)
• Aggregate graphs are easy to corrupt without test discipline

3. Persona few-shot from prior briefings

When the /epistract:epistemic narrator runs in domain X, the system prompt includes 1–2 prior epistemic_narrative.md excerpts from the same domain as exemplars. The narrator learns the domain's voice from its own past output.

Risks:

• Stylistic drift (narrator overfits to one prior briefing)
• Token-budget growth
• Hard to prevent the narrator from re-asserting old findings about a different corpus

4. Epistemic rule mining

When a contradiction or contested claim recurs across N scenarios in the same domain, auto-promote it to domains/<name>/epistemic.py:CUSTOM_RULES. Frequency-based learning of recurring patterns.

Risks:

• Rule-promotion needs human review (auto-merging into Python source is dangerous)
• "Recurrence" definition is fuzzy across heterogeneous corpora
• Might land as a CLI suggestion (/epistract:epistemic --suggest-rules) rather than auto-promotion

5. Cross-scenario claim arbitration

When S7's narrator finds semaglutide INDICATED_FOR obesity as contested, but S6's narrator already resolved that as a temporal-stratification issue, the new run should surface S6's resolution rather than re-deriving it. Requires the narrator to query an aggregate claims log.

Risks:

• Highly speculative; depends on (1) and (2) being in place

Concrete first step

If we want one milestone for v3.3.0:

Mechanism (1) — cross-scenario entity canonicalization — landing as domains/<name>/canonical_entities.json with core.entity_resolution.persist_canonical() and core.entity_resolution.load_canonical() helpers. Run during cmd_build. Most tractable. Highest immediate user-visible win — SURPASS-2 references the same tirzepatide node across every scenario.

What this is not

• Not "epistract becomes a vector database" — the persistence layer is a structured graph, not embeddings
• Not "the narrator becomes an autonomous agent" — narrator is still bounded by graph + persona
• Not "user data leaves the local repo" — all aggregate state lives under domains/<name>/, gitignored or committed at the domain author's choice

Status

Aspirational. Unassigned. No committed timeline. This issue exists to make the gap visible and capture design ideas. If it gets traction, the realistic path is mechanism (1) first as a v3.3.0 milestone, then evaluate whether the rest are worth building.

Cross-references

• Referenced from README.md "Reading the table" paragraph under Pre-built Domains
• Related GSD todo: TBD (Umesh to add)

---

If you have thoughts on which mechanism to prioritize, or alternative designs we haven't considered, comment here.