audita/docs/roadmap/glossary-stages.md

Stage-Specific Glossary Inputs

Updated: 2026-11-07

Status: Accepted scope for the next Audita major release. Initial outline; detailed design and implementation remain pending. The master roadmap owns sequencing and release completion.

Baseline and Target

The current CLI accepts one glossary input for a processing run. The pipeline configuration supports repeated glossary stages, but does not select a different glossary input for each occurrence.

Allow operators to run ordered glossary stages against different glossary inputs within one processing run. For a D&D transcript, the first glossary stage can use party.yml and the second can use spells.yml. Each stage uses its selected glossary and processes the transcript resulting from earlier stages. Operators need not combine those inputs into one glossary or run Audita separately for each pass.

This example describes the intended behavior, not a selected configuration syntax. The major-release policy permits a hard cutover; the current single-glossary CLI and pipeline representation do not constrain the target design.

Sequencing and Work Outline

Implement after ConfigKit, PromptKit, CommandKit, and ReleaseKit adoption, and before final release validation and preparation. This lets the feature use the adopted configuration and CLI conventions and avoids adapting it twice. Keep the requirement visible during library design without expanding those migrations into feature implementation.

1. Define how a stage selects its glossary, how input paths resolve, and how defaults and CLI selection interact with stage configuration.
2. Carry the selected glossary through loading, stage execution, proposal generation, and validation. Review glossary consumers outside the glossary module so their input semantics are deliberate.
3. Make repeated stages and their selected inputs understandable in inspection, diagnostics, and reports. Account for all consumed glossary files in input handling and output-collision protection.
4. Verify the selected behavior and update configuration, CLI, input contracts, pipeline documentation, maintained examples, and hard-cutover guidance as the implementation lands.

Acceptance Direction

Use distinct party and spell fixtures with controlled model responses to show that each stage receives the intended glossary, that one stage's input does not leak into another, and that the second stage sees the first stage's accepted transcript changes. Verify meaningful errors for invalid selections or inputs, and retain the selected domain validation and partial-success behavior. Exact test cases follow the design; live provider calls are unnecessary.

Open Decisions

Detailed choices are deliberately deferred to the feature-design discussion:

• Stage representation, glossary references versus inline file paths, and defaults or CLI overrides.
• Which glossary is used by other modules and validators, including protected term checks and overlapping terms across inputs.
• Stage identity and input attribution in inspection, errors, and reports.

The capability and its inclusion in the next major release are settled. These questions refine the design; they do not reopen whether to deliver the feature.