3.4 KiB
Audita Validators
Scope
This document describes internal validator composition, execution order, and decision handling. These registry keys identify implementation components; they are not independently selectable through configuration.
Ownership
Built-in validator keys and chains:
internal/validators
Shared validator runtime mechanics:
internal/framework/validators
Execution-class metadata:
internal/validators/metadata
Built-In Validator Keys
Deterministic:
proposal_shapeconfidence_thresholdoriginal_text_presencenon_empty_resulting_segment— rejects edits that would leave the segment blank, regardless of replacement-span length.no_effectprotected_terms
LLM-backed:
spoken_form_plausibilitymeaning_reversal_revieweditorial_review
Built-In Chains
Module chains are defined in internal/validators/chains.go.
Glossary, homophones, spoken_word, and grammar each resolve a fixed ordered chain.
Runtime Execution
For each module section:
- run deterministic validators;
- run LLM-backed validators;
- record decisions and compact operation outcomes;
- carry only approved proposals forward.
Decision cardinality is enforced: each candidate proposal must receive exactly one decision per validator.
LLM Validator Batching
LLM validators:
- build canonical validation request payloads;
- batch using
validation.max_prompt_tokensand the existing domain token estimator; - select an embedded prompt ID and pass payload/description variables to the role-bound structured client with the validator-decision schema.
Oversized single inputs are rejected with a consolidated
validation_input_too_large operation, without a provider call. Recoverable
model failures make only their batch candidates unavailable while other
batches continue. Missing, duplicate, or unknown decision indices invalidate
that batch as a whole. Fatal errors stop the chain without returning unchecked
candidates as approved. Domain acceptance has no semantic retry.
Decision and Rejection Reporting
Runner collects decisions, rejected candidates, and operation outcomes. Ledger assembly groups decisions by deterministic versus LLM-backed execution metadata. The serialized names and fields belong to the report and ledger contract; implementation mapping is covered by report assembly.
Changing Validators
- Implement validator behavior under
internal/validators/<validator_key>; update registry and chain wiring ininternal/validators. - Put shared runtime mechanics in
internal/framework/validatorsonly when needed. Keep deterministic versus LLM-backed execution metadata explicit. - Preserve exposed identities and decision semantics under the architecture policy.
- Review validator, registry, chain, batching, malformed-output, diagnostics, and decision-cardinality tests; update meaningful coverage under the testing policy.
- Update implementation guidance here and any affected external contract in its canonical owner.
Key Tests
internal/validators/*_test.gointernal/framework/validators/*_test.gointernal/framework/processreport/correction_ledger_test.gointernal/cli/run_test.go