Plan canonical D&D entity registries and occurrences

docs/roadmap/future.md

@@ -24,45 +24,11 @@ not as committed release dates.
 
 ### Canonical Entity Registries And Occurrences
 
-- Establish a consistent module and artifact naming convention that makes the
-  two entity-extraction roles explicit. Prefer `dnd/<entity>-registry` for a
-  module that identifies canonical nouns and `dnd/<entity>-occurrences` for a
-  downstream module that consumes that registry and extracts transcript-backed
-  evidence about those nouns. Apply the convention coherently to NPCs,
-  locations, and items rather than preserving the current mixture of bare
-  plurals, `interactions`, `occurrences`, and `events` names.
-- Treat this as a contract-level change rather than a prompt-asset rename. A
-  full feature roadmap should inventory and update module IDs, artifact kinds
-  and schema identities where applicable, pipeline dependencies, generated
-  references, checkpoints, configuration examples, tests, and documentation.
-  Because Notarius remains pre-release, prefer a clean migration over aliases
-  or compatibility shims unless the repository has acquired a concrete need
-  for them before implementation.
-- Define the registry contract around stable, canonicalizable entity names.
-  In particular, tighten location extraction to include explicitly named
-  in-world places, such as `Waterdeep` or `The Yawning Portal`, while excluding
-  generic, temporary, relative, or purely descriptive references such as `the
-  room`, `the bar`, `the hallway`, or `upstairs`. Determine eligibility by
-  whether the transcript establishes a stable name or unique designation, not
-  by capitalization alone, because transcript capitalization is unreliable.
-- Keep registry identification separate from occurrence evidence. A downstream
-  occurrence extractor may resolve a generic reference such as `the bar` to an
-  existing named registry entry when transcript context supports that
-  coreference, but it must not create a new canonical entity merely from the
-  generic reference. The occurrence itself must remain independently supported
-  by transcript ranges; registry membership is grounding, not event evidence.
-- Define equivalent eligibility and coreference rules for NPC and item
-  registries so future entity types follow one architectural pattern while
-  retaining their domain-specific occurrence kinds. The full roadmap should
-  decide how unnamed but uniquely identifiable NPCs and items are represented,
-  and whether an item registry is introduced before or alongside renaming the
-  existing item-event lane.
-- Evaluate the renamed and tightened contracts against representative
-  transcripts. Review false-positive registry entries, missed named entities,
-  coreference accuracy, unsupported occurrence links, and the behavior of
-  cost-effective smaller models. Keep these semantic changes separate from the
-  prompt-asset consolidation so regressions can be attributed to the correct
-  work set.
+This work has been promoted to the dedicated
+[Canonical D&D Entity Registries And Occurrences](entity-registries.md)
+roadmap. That document owns the proposed module and artifact vocabulary,
+registry eligibility, identity policies, occurrence contracts, ordered
+handoffs, migration policy, and target end state.
 
 ## Shared Normalization And Quality Work