notarius/docs/roadmap/future.md

Future Work

Current Notarius behavior is documented in the canonical README, CLI, configuration, operations, internal, and integration docs. This roadmap records future work only. Items are ordered roughly by current value and specificity, not as committed release dates.

Near-Term D&D Pipeline

Evaluate Spell Extraction And Normalization

• Evaluate ordinary extraction retries and the completed normalization path against a human-reviewed transcript set before adding repair-aware retries or an LLM-backed semantic validator.
• Maintain a small set of human-reviewed transcripts and outputs for prompt, validator, and normalizer development. Treat model-quality review as an iterative human evaluation aid, not a deterministic correctness gate.

Evaluate The Shared D&D Scene Plan

• Reassess whether one shared scene plan provides enough context for NPC, spell, combat, interaction, and scene-description lanes after real-world use. Add more complex chunking only in response to demonstrated failures.

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.

Shared Normalization And Quality Work

Generic LLM-Assisted Deduplication

• Add a reusable normalizer that asks an LLM to identify duplicate sets in a list and propose one replacement element for each set.
• Define the minimum domain-neutral input contract, initially an ordered list whose elements have stable unique IDs. Artifact-kind registrations or adapters may expose that structure without moving domain rules into the generic package.
• Keep mutation deterministic: parse and validate the model's duplicate groups, require every referenced ID to exist, reject overlapping or malformed groups, prevent unrelated insertion or deletion, and apply only approved replacement operations in code.
• Preserve provenance needed for audit and downstream validation, and emit warnings describing every collapsed group.
• Evaluate batching and context-window limits before applying the normalizer to large artifact collections.

The model may use its own domain knowledge to judge semantic duplication; the generic implementation is responsible only for the common proposal contract, safety checks, and deterministic application of accepted changes.

Validation And Review

• Add domain validators and production default chains alongside each new D&D artifact.
• Add production LLM-backed validators only when a concrete review policy benefits from model judgment and deterministic checks are insufficient.
• Add validator diagnostics and timing summaries if operators need more detail than the current durable output bundle provides.
• Add validator compatibility metadata if deployments need config-time proof that a validator is suitable for a particular stage, module, or artifact kind.
• Add media-type validators when non-JSON artifact representations are introduced.

Further Reference Evolution

• Make prior-run artifacts easier to bind as references without changing the existing module-facing reference-item contract.
• Add structured or parsed references, such as typed NPC registries, rosters, or spell catalogs, when opaque UTF-8 prompt material is no longer sufficient.
• Add per-slot or per-chunk inclusion policies so large references are not repeated in every prompt unnecessarily.
• Add token budgeting and model context-window management for reference content.
• Add reference caching, preprocessing, summarization, embedding, or retrieval only when reference size and observed model behavior justify them.
• Extend generated references to prior-run artifacts or derived summaries only after same-run ordered handoffs establish the required provenance and lifecycle semantics.

Design Considerations To Revisit

These concerns are relevant to ordered artifact dependencies but are not committed near-term features.

Cross-artifact identity links

Evaluate whether downstream D&D artifacts should retain canonical NPC IDs from the generated NPC reference in addition to normalized display names. Any such contract must define player-character, unknown-actor, missing-NPC, and superseded-identity behavior before implementation. Deterministic validation may confirm that a linked ID exists in the consumed NPC artifact, but the link must never substitute for transcript evidence that the downstream event occurred.

Artifact contract evolution

Define compatibility and migration policy before generated-reference chains must span multiple schema versions or long-lived historical artifacts. The policy should address stable identifier semantics, which schema changes permit checkpoint reuse, when an older artifact may be decoded or adapted, and when a producer or all dependents must be recomputed. Do not add a general migration framework until an actual contract change requires one.

Blue-Sky Platform And Operations

These ideas are intentionally less specified. Promote one into an earlier section only after a concrete workflow, contract, and priority emerge.

Platform Extensions

• Additional input adapters, such as Markdown or note-export formats.
• Additional output encoders.
• Concurrent cross-lane entity normalization or broader workflow composition.
• Batching or specialized context-window controls for LLM-backed validators.

Distribution And Operations

• Packaged release artifacts for alpha distribution.
• A documented versioning and release process.
• Optional generated example-output fixtures with a regeneration procedure.
• Additional diagnostics or reporting views.

Workspace And Storage

• Default-idempotent run behavior with an explicit force override.
• Remote workspace storage.
• Workspace garbage collection and archival policies.
• Cross-machine checkpoint reuse.