Revise the architecture plan to reflect an input -> chunk -> process -> merge -> normalize -> output workflow

docs/roadmap/documentation.md

@@ -10,8 +10,8 @@ not describe implemented behavior.
 
 Notarius documentation should make three boundaries obvious:
 
-- source-format support belongs to input adapters;
-- extraction-domain behavior belongs to extractor packages;
+- source-format support belongs to input-stage modules;
+- extraction-domain behavior belongs to process-stage modules;
 - core framework behavior is source-agnostic and domain-agnostic.
 
 Documentation should avoid making the MVP look more transcript-specific or
@@ -35,6 +35,10 @@ Core architecture docs should prefer:
 - source reference;
 - input adapter;
 - extractor;
+- chunker;
+- merger;
+- normalizer;
+- output encoder;
 - artifact;
 - validator;
 - run manifest.
@@ -43,11 +47,12 @@ Core docs should avoid transcript-specific terms such as segment, speaker,
 timestamp, and transcript range unless discussing an input adapter or an example.
 
 Core docs should avoid D&D-specific terms such as spell, NPC, item, combat, and
-encounter unless discussing extractor packages or examples.
+encounter unless discussing process modules, artifact docs, or examples.
 
-### Adapter Docs Own Source Formats
+### Input Module Docs Own Source Formats
 
-Each implemented input adapter should have a canonical integration document.
+Each implemented input-stage module should have a canonical integration
+document.
 
 Likely future files:
 
@@ -56,32 +61,33 @@ docs/integrations/seriatim-transcript.md
 docs/integrations/markdown-source.md
 ```
 
-Adapter docs should cover:
+Input module docs should cover:
 
 - accepted external schema or file shape;
 - mapping into `SourceDocument` and `SourceUnit`;
-- metadata preserved by the adapter;
+- metadata preserved by the module;
 - validation rules and failure behavior;
 - examples.
 
-The Seriatim adapter doc should reference the Seriatim schema it supports and
+The Seriatim input module doc should reference the Seriatim schema it supports and
 explain how transcript segment IDs become source-unit IDs.
 
-### Extractor Docs Own Domains
+### Stage Module Docs Own Business Logic
 
-Each implemented extractor family should have canonical internal or integration
-docs.
+Each implemented stage-module family should have canonical internal or
+integration docs.
 
 Likely future files:
 
 ```text
-docs/internal/extractors.md
+docs/internal/stage-modules.md
 docs/integrations/artifacts-dnd.md
 ```
 
-Extractor docs should cover:
+Stage module docs should cover:
 
-- extractor key;
+- module key;
+- stage;
 - artifact type;
 - schema version;
 - required source-reference behavior;
@@ -89,13 +95,14 @@ Extractor docs should cover:
 - prompt and response-schema ownership;
 - examples.
 
-D&D concepts should be documented in D&D extractor docs, not in generic runner
-or framework docs.
+D&D concepts should be documented in D&D process-module or artifact docs, not in
+generic runner or framework docs.
 
 ### CLI Docs Should Reflect Extensibility
 
-The CLI reference should present input adapters and extractors as selectable
-components.
+The CLI reference should present input modules, chunk modules, process modules,
+merge modules, normalize modules, and output modules as selectable or
+configurable components as they become user-facing.
 
 Provisional command shape:
 
@@ -106,8 +113,9 @@ notarius extract ./source.json --input seriatim --extractors dnd.spells --output
 Once implemented, `docs/cli.md` should document:
 
 - positional source input path;
-- input adapter selection;
-- extractor selection;
+- input module selection;
+- process module selection;
+- chunk/merge/normalize/output selection when configurable;
 - config path behavior;
 - output path behavior;
 - diagnostics and report behavior;
@@ -117,15 +125,17 @@ Once implemented, `docs/cli.md` should document:
 
 `docs/config.md` should group fields by responsibility:
 
-- input adapter selection and adapter-specific options;
-- extractor selection and extractor-specific options;
+- input module selection and module-specific options;
+- chunk module selection and module-specific options;
+- process module selection and module-specific options;
+- merge module selection and module-specific options;
+- normalize module selection and module-specific options;
+- output module selection and module-specific options;
 - LLM runtime;
 - validation runtime;
-- source chunking;
-- output and diagnostics.
+- diagnostics.
 
-Adapter-specific and extractor-specific config should not leak into unrelated
-core config sections.
+Module-specific config should not leak into unrelated core config sections.
 
 ### Examples Should Stay Real
 
@@ -154,8 +164,8 @@ When the first vertical slice is implemented, add or update:
 - `docs/troubleshooting.md`: common failures.
 - `docs/internal/overview.md`: implemented package map.
 - `docs/internal/pipeline.md`: implemented extraction flow.
-- `docs/internal/adapters.md`: adapter contract and implemented adapters.
-- `docs/internal/extractors.md`: extractor contract and built-ins.
+- `docs/internal/stage-modules.md`: stage contracts and implemented modules.
+- `docs/internal/input-modules.md`: input adapter contract and implemented input modules.
 - `docs/internal/validators.md`: validator contract and built-ins.
 - `docs/integrations/seriatim-transcript.md`: Seriatim input contract.
 - `docs/integrations/artifacts.md`: output artifact envelope.
@@ -165,10 +175,10 @@ When the first vertical slice is implemented, add or update:
 Before merging docs, check:
 
 - Does the document describe implemented behavior outside `docs/roadmap/`?
-- Are source-format details isolated to adapter docs?
-- Are D&D details isolated to extractor or artifact docs?
+- Are source-format details isolated to input module or integration docs?
+- Are D&D details isolated to process module or artifact docs?
 - Is there one canonical home for the topic?
 - Do command examples match implemented CLI syntax?
 - Are examples valid, maintained, and free of secrets?
-- Did any architecture, config, CLI, adapter, extractor, validator, or artifact
+- Did any architecture, config, CLI, stage module, validator, or artifact
   contract change require a docs update?