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.

Shared Normalization And Quality Work

The implemented source-backed core and initial D&D registry adoption are described by Module Internals and D&D Module Internals. The Semantic Reconciliation Roadmap retains the original feature scope; the sections below keep broader extensions deferred.

Large-Collection Semantic Reconciliation

• Evaluate deterministic candidate blocking only after representative registry inputs exceed the active roadmap's bounded single-request limits. Blocking should use cheap, explainable signals to form plausible comparison sets while preserving the possibility that a duplicate appears outside a lexical name match.
• Define correctness for candidates that appear in more than one block, conflicting canonical selections, transitive identity across blocks, retry isolation, and deterministic final ordering before implementation.
• Prefer a reconciliation graph or union plan with explicit conflict checks over arbitrary fixed-size slices. Never silently treat a batch boundary as evidence that two candidates are distinct.
• Record per-request bounds, block provenance, model calls, discarded proposals, and final group derivation well enough to audit a collapse.

Operator-Selected Semantic Policies

• Consider allowing an operator to select an approved semantic-policy prompt for a typed reconciliation module without replacing the shared protocol, response schema, or deterministic safety rules.
• Define the trusted asset source, configuration syntax, compatibility checks, startup validation, provenance, prompt fingerprinting, checkpoint effects, and support boundary before exposing the option.
• Prefer selection among registered, typed-policy-compatible prompt assets over arbitrary filesystem prompt paths. Do not add this flexibility until an operator workflow requires it; artifact-family-owned policy remains simpler and safer for the initial implementation.

Broader Reconciliation Inputs And Module Selection

• Revisit alternate context providers when a concrete non-source-backed entity collection needs semantic reconciliation. Any extension must preserve the same request-local identity, deterministic proposal validation, provenance, and typed application guarantees.
• Consider a selectable generic normalizer only if Notarius gains a real domain-neutral typed artifact contract that can safely support it. Do not weaken exact artifact registration or introduce reflection-based arbitrary JSON mutation merely to expose a universal module key.

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.

Artifact-family-oriented physical packaging

ADR-0004 currently groups production extensions by domain and then by pipeline stage. After artifact-family ownership terminology is established and more families span extraction, normalization, validation, codecs, references, and assets, reassess whether a feature-first physical layout would improve navigation and reduce scattered changes enough to justify a repository-wide package migration. Any change must address Go dependency cycles, registrar ownership, stable public module keys, and supersession of the affected ADR-0004 decision. Conceptual artifact-family ownership does not by itself require this move.

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.