Document the new configuration and processing workflow
This commit is contained in:
42
docs/adr/0002-glossary-configuration-and-preflight.md
Normal file
42
docs/adr/0002-glossary-configuration-and-preflight.md
Normal file
@@ -0,0 +1,42 @@
|
||||
# ADR 0002: Glossary configuration and processing readiness
|
||||
|
||||
**Status:** Accepted
|
||||
|
||||
**Date:** 2026-11-10
|
||||
|
||||
## Context
|
||||
|
||||
Operators need to reuse glossary collections across campaigns and select different
|
||||
context and protected terms for each ordered correction. Configuration inspection
|
||||
must remain useful without a transcript, model credentials, or a populated glossary.
|
||||
A processing run must reject an unusable later correction before publishing outputs
|
||||
or spending resources on earlier corrections.
|
||||
|
||||
## Decision
|
||||
|
||||
ConfigKit composes typed, named glossary collections with the application
|
||||
configuration. Each pipeline entry selects context and protection independently;
|
||||
Audita derives consumer views without changing the resolved configuration. For a
|
||||
glossary correction, active recognized spellings are exempt from that entry's
|
||||
protection view. Other protected spellings and validators remain effective.
|
||||
|
||||
After configuration resolution, Audita preflight checks the whole pipeline and
|
||||
coordinates output preparation. It consumes the typed configuration and acquired
|
||||
inputs, without reloading configuration or calling a provider. The output session
|
||||
owns preparation, cleanup, and publication. See the [configuration](../config.md)
|
||||
and [operations](../operations.md) contracts for current behavior.
|
||||
|
||||
## Alternatives considered
|
||||
|
||||
A separately parsed glossary per invocation would duplicate composition and make
|
||||
per-entry selection and provenance harder to express. Requiring nonempty
|
||||
collections in configuration validation would prevent inspection and reuse of
|
||||
valid empty definitions. Preparing outputs or checking each entry only when it
|
||||
runs could leave artifacts or incur model work before finding a later error.
|
||||
|
||||
## Consequences
|
||||
|
||||
Configuration and runtime views have distinct responsibilities. Inspection can
|
||||
show configured selections and origins without presenting derived vocabulary as
|
||||
configuration. Preflight and the output session need a clear handoff, and the
|
||||
processing pipeline must carry each entry's own effective settings and identity.
|
||||
@@ -4,6 +4,8 @@
|
||||
|
||||
- [ADR 0001: Adopt ReleaseKit for release management](0001-releasekit.md) —
|
||||
accepted 2026-10-07.
|
||||
- [ADR 0002: Glossary configuration and processing readiness](0002-glossary-configuration-and-preflight.md) —
|
||||
accepted 2026-11-10.
|
||||
|
||||
Use the
|
||||
[documentation policy's ADR lifecycle](../policy/documentation.md#architecture-decision-records)
|
||||
|
||||
Reference in New Issue
Block a user