Add intra-module pipeline for LLM validation

docs/architecture.md

@@ -313,7 +313,13 @@ These primitives are wired into the production runner and report model. The gram
   - identical/no-effect rejection
   - conservative protected glossary-term guard for non-glossary modules
 
-`internal/framework/runner` executes validator chains in order for each module and applies only validator-approved proposals.
+`internal/framework/runner` executes module pipelines with deterministic boundaries:
+- modules still execute serially over the working transcript;
+- section proposal work is launched promptly and can run concurrently;
+- section-level validator-chain work starts as section proposals become available (deterministic validators before LLM-backed validators);
+- proposal-generation and LLM-validator calls can overlap under composed scheduler limits;
+- approved proposals are still applied once per module after section work settles.
+
 Validator rejections are reported distinctly from proposal-application skips.
 
 ## Implemented LLM-backed validator infrastructure

docs/intra-module-pipeline-audit.md

@@ -2,6 +2,15 @@
 
 Date: 2026-05-12
 
+## Implementation Status (2026-05-12 Update)
+
+The intra-module pipelining gap identified in this audit has now been addressed:
+- section proposal jobs are launched promptly for each module;
+- as section proposals become available in deterministic section order, section-local validator work starts without waiting for all section proposals to finish;
+- deterministic validators run before LLM-backed validators for each section;
+- proposal and validation LLM calls can overlap through the existing composed scheduler path;
+- module application remains a single deterministic apply barrier.
+
 ## Summary
 
 This audit checks whether Audita currently maximizes available LLM concurrency within each module by overlapping proposal and validation work.

docs/llm-concurrency-audit.md

@@ -27,7 +27,8 @@ The targeted concurrency gaps identified in this audit have now been addressed:
 - legacy `llm-concurrency` settings are preserved as compatibility aliases to total concurrency,
 - proposal and validation schedulers are composed with a global total-cap scheduler,
 - scheduler default behavior is FIFO with context-aware queued cancellation and reliable permit release,
-- runner proposal worker fan-out is aligned with effective proposal concurrency.
+- runner proposal worker fan-out is aligned with effective proposal concurrency,
+- intra-module execution now pipelines section validation so proposal and validation LLM work can overlap within a module while retaining deterministic module-level apply ordering.
 
 ## Audit Findings (Questions 1-14)