Record intentional editorial acceptance across modules

docs/adr/0003-module-focus-and-editorial-acceptance.md

@@ -0,0 +1,59 @@
+# ADR 0003: Module focus and editorial acceptance
+
+**Status:** Accepted
+
+**Date:** 2026-11-11
+
+## Context
+
+Audita gives each correction module a focused task. A prompt review suggested
+making that task's scope an acceptance condition, because validators can accept
+minor editorial changes that the proposing module was not asked to make.
+
+The maintainer's practical testing established why this difference is deliberate.
+Models persistently propose minor editorial cleanup when it is clearly warranted
+in the supplied text. Instructions strict enough to suppress that cleanup also
+suppress desirable edits. Enforcing exclusive module scopes would therefore
+trade away useful corrections to achieve a separation that does not serve the
+application's editorial goals.
+
+## Decision
+
+Module scope guides the corrections Audita asks a model to propose. It is not an
+exhaustive boundary on acceptable edits. Minor editorial cleanup is permitted
+across modules and their validators even when the proposal prompt does not
+request it.
+
+Validators must not reject an otherwise acceptable minor editorial change solely
+because it falls outside the originating module's requested focus. Existing
+checks for applicability, protected terms, meaning, and other domain concerns
+continue to apply. This allowance does not guarantee that any particular edit
+passes validation or application, nor does it authorize arbitrary rewriting.
+
+Proposal, validation, and repair instructions may differ to serve their roles.
+Their consistency should be assessed against this distinction, rather than by
+requiring identical lists of allowed edits. Repair feedback should not turn
+module focus into an exclusive acceptance rule.
+
+## Alternatives considered
+
+**Strict module-aware acceptance**, whether implemented in shared validators,
+separate review definitions, or an additional scope check, would make stage
+boundaries easier to describe. It is rejected because the maintainer's testing
+shows that suppressing incidental cleanup also suppresses desirable work.
+
+**Request every kind of cleanup in every module** would align proposal requests
+with the broader acceptance policy, but would dilute the focused tasks. Permitting
+incidental cleanup does not require asking each stage to perform every task.
+
+## Consequences
+
+An edit accepted outside a module's requested focus is not, by itself, a design
+defect. Prompt maintenance and evaluation should preserve useful corrections
+while checking substantive editorial quality. They should not introduce strict
+scope enforcement as an apparent consistency fix.
+
+The [architecture policy](../policy/architecture.md#correction-and-concurrency-invariants)
+records the boundary. Reconsidering this accepted decision requires new evidence
+and explicit supersession under the ADR lifecycle, rather than rediscovering the
+same prompt/validator difference during each review.

docs/adr/README.md

@@ -6,6 +6,8 @@
   accepted 2026-10-07.
 - [ADR 0002: Glossary configuration and processing readiness](0002-glossary-configuration-and-preflight.md) —
   accepted 2026-11-10.
+- [ADR 0003: Module focus and editorial acceptance](0003-module-focus-and-editorial-acceptance.md) —
+  accepted 2026-11-11.
 
 Use the
 [documentation policy's ADR lifecycle](../policy/documentation.md#architecture-decision-records)