Refresh documentation and policies and simplify releases

docs/internal/pipeline.md

@@ -2,7 +2,10 @@
 
 ## Scope
 
-This document describes the implemented `audita process` pipeline.
+This document describes processing collaborators and state transitions. External
+input definitions belong to the [input-file contract](../integrations/transcript-glossary-files.md),
+settings to [configuration](../config.md), and serialized results to the
+[output-file contract](../integrations/output-files.md).
 
 ## Inputs
 
@@ -13,35 +16,23 @@ Pipeline inputs are:
 
 ## Pipeline Phases
 
-1. Input loading and schema validation
-- transcript and glossary files are read and parsed.
-- schema failures stop the run with `transcript_schema` or `glossary_schema`.
-
-2. Normalization
-- canonical transcript segments are normalized by configured gap/duration/token settings.
-- normalization summary artifacts are written.
-
-3. Chunking
-- normalized transcript is chunked with configured max/min tokens and target sections.
-
-4. Module proposal generation
-- runner executes configured module instances in sequence.
-- each module proposes corrections per section.
-- per-section proposal generation can run concurrently.
-
-5. Validator filtering
-- validators run on candidate proposals before apply.
-- deterministic validators run before LLM-backed validators.
-- LLM validator inputs are batched by max prompt token limit.
-
-6. Deterministic apply
-- approved proposals are applied via replacement policy.
-- applied/skipped/rejected outcomes are recorded.
-
-7. Output and reporting
-- final transcript is serialized with selected output schema.
-- report, utilization diagnostics, and correction ledger are written.
-- retention policy is applied to run directory.
+1. **Input loading:** CLI filesystem adapters read inputs; schema parsing produces
+   source transcript and glossary objects. Source segments are converted to the
+   canonical transcript shape before normalization.
+2. **Normalization:** the normalizer sorts and merges segments using its configured
+   time/token rules, reassigns IDs, and produces summary counters.
+3. **Chunking:** the chunker partitions the normalized transcript and returns
+   sections and token estimates, or fails when constraints are impossible.
+4. **Proposal generation:** the runner executes configured module instances in
+   sequence. Sections can generate proposals concurrently; results are collected
+   for deterministic indexing.
+5. **Validation:** deterministic validators run before LLM-backed validators.
+   LLM validation is batched by prompt budget; candidate decisions feed application.
+6. **Application:** `internal/framework/proposals` clones transcript state and
+   applies approved proposals in index order through replacement-policy checks.
+7. **Serialization and reporting:** the CLI encodes the final transcript, maps
+   runner output into reports, writes artifacts, and delegates retention to
+   diagnostics. See [report assembly](diagnostics-reporting.md).
 
 ## Runner Outputs
 
@@ -54,22 +45,18 @@ CLI/reporting then map this into process report and diagnostics artifacts.
 
 ## Failure Behavior
 
-Representative failure phases include:
-- `run_dir_creation`
-- `transcript_read`, `glossary_read`
-- `transcript_schema`, `glossary_schema`
-- `chunking`
-- `runner_setup`, `runner_execution`
-- `output_schema`, `serialization`, `output_write`, `stdout_write`
+CLI orchestration labels failures at the phase boundary. Runner execution failures
+can return completed or partial module results, which report assembly preserves.
+[Report fields](../integrations/output-files.md#process-report) define how consumers
+see these outcomes; [CLI semantics](../cli.md#process-output-and-exit-behavior)
+define streams and exits. Diagnostic write failures do not always abort processing.
 
-When diagnostics are available, failure stderr includes diagnostics path.
+## Ordering and State
 
-## Invariants
-
-- module execution order follows configured module sequence;
-- proposal/validator nondeterminism is isolated before deterministic apply;
-- proposal indices are assigned deterministically by section order;
-- output/report artifacts are generated from run results, not speculative state.
+The runner mutates its working transcript between module instances, after collecting
+section results and validating proposals. Proposal indexes follow section order;
+reports are derived from actual run results. Global requirements are owned by the
+[architecture policy](../policy/architecture.md#correction-and-concurrency-invariants).
 
 ## Key Tests