50 lines
2.3 KiB
Markdown
50 lines
2.3 KiB
Markdown
# Future Work
|
|
|
|
Current Notarius behavior is documented in the canonical README, CLI,
|
|
configuration, operations, internal, and integration docs. This roadmap records
|
|
future work only.
|
|
|
|
## Candidate Product Work
|
|
|
|
- Additional input adapters, such as Markdown or note-export formats.
|
|
- Additional D&D extractors beyond spell casts.
|
|
- Add non-file reference producers, such as prior-run artifacts, derived
|
|
summaries, or entity registries, without changing module-facing reference
|
|
item contracts.
|
|
- Add token budgeting and model context-window management for reference content.
|
|
- Add per-slot or per-chunk inclusion policies so modules can avoid repeating
|
|
large reference content in every prompt when that becomes important.
|
|
- Add structured or parsed references, such as typed roster schemas, when a
|
|
module has a clear need for more than opaque UTF-8 text.
|
|
- Add reference caching, preprocessing, summarization, embedding, or retrieval
|
|
if references become large enough to require preprocessing.
|
|
- Cross-lane entity normalization.
|
|
- Cross-chunk semantic deduplication.
|
|
- Additional validator packages and production default chains for future
|
|
modules.
|
|
- Production LLM-backed validators when there is a concrete review policy that
|
|
benefits from model judgment.
|
|
- Validator diagnostics and timing summaries if operators need more detail than
|
|
`manifest.json`, `rejected.json`, and `warnings.json` provide.
|
|
- Media-type validators for non-JSON module outputs when such modules are
|
|
introduced.
|
|
- Validator compatibility metadata if real deployments need config-time
|
|
enforcement that a validator is suitable for a specific stage or module.
|
|
- Batching or context-window controls for LLM-backed validators if validator
|
|
inputs become large enough to require them.
|
|
- Parallel execution where it preserves deterministic manifests and diagnostics.
|
|
- Additional output encoders.
|
|
|
|
## Candidate Operational Work
|
|
|
|
- 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 if operator workflows need them.
|
|
|
|
## Non-Goals To Revisit Deliberately
|
|
|
|
- A general workflow language.
|
|
- Structural module selection through ad hoc run flags.
|
|
- Storing secrets in config files, diagnostics, manifests, or examples.
|