## Problem The config schema describes the module's configuration but does not gate it. Across six schema files there are 156 keys and 15 top-level types, and `FullyValidatable` appears zero times. Without it, data that is **missing** a declared key validates silently, so configuration arriving incomplete is accepted without a word. Corrected while implementing this: an **undeclared** key is refused either way, because core adds a `ValidKeys` constraint to a mapping on its own. This issue first said such a key "produces no violation at all", and that is not true on this core version. The MR pins core's behaviour in a test so the claim does not come back. The gap is observable. A test that validates a contributor's `depth_cap` through `config.typed` passes unchanged when the schema file declaring `depth_cap` is removed entirely: with no declaration, and no type marked `FullyValidatable`, there is nothing for the validator to object to. Constraints that are declared are also only enforced where config validation runs. Nothing in the module calls it, so today a `Range` in the schema is a statement of intent rather than a limit. ## What happens Configuration that the forms would refuse is accepted when it arrives by any other route: a config import, a recipe, a programmatic save. The schema is the only thing standing in those paths, and it is not standing. Three smaller problems in the same files: - Twelve `label:` values are written as descriptions, some ending in a full stop and some a whole sentence long. A label is a short noun phrase; the sentence belongs in `description:`. - Keys holding machine names or plugin ids carry no `machine_name` constraint. - Required keys are not marked required, which only starts to matter once the types are `FullyValidatable`. ## The fix The order mattered, because the last step is what turns the rest into enforcement, and marking the types before the keys were right would have made saves fail on configuration that is actually valid. That happened twice, and the marking found it: 1. **Two pairs of keys are absent by design, not by age.** A `types` entry in `audit_trail_entity.settings` carries `bundle_default` in shared-rule mode and `bundles` in per-bundle mode, and the form writes one or the other, never both, so with every declared key required, every configuration that form can save was a violation. The per-chain TSA settings are the same shape: the chain form unsets `enabled` when the answer is the default and unsets `interval_seconds` when the field is empty. Both pairs are `requiredKey: false`. 2. **A plugin id is constrained by existence, not shape.** `machine_name` says nothing about whether an id names a plugin, and `no_such_contributor` is a perfect machine name that a chain then skips in silence. Core constrains a plugin id in configuration with `PluginExists`, naming the manager and the interface, so both `plugin_id` keys do that. 3. **Values the forms refuse were accepted by the schema.** Four keys carry a floor or a ceiling in their form and had nothing in their schema, the TSA `timeout_seconds` among them, which the timestamper floors at 1 and caps at nothing: an imported value there can hold a cron run open for as long as it likes. 4. **Two closed sets, an entity id and a verb list were not closed.** `auth_type` and `provider_status` each listed their values in a label and constrained nothing, and both matter: the timestamper's auth switch has no default arm, so an unrecognized mode sends the request with no credentials, and only `active` is stamped against, so an unrecognized status reads as retired. `ops` is the same class: the hooks dispatch `create`, `update` and `delete`, the test is strict, and `created` is the plausible mistake because that is the form the audit rows carry. 5. **Ten keys documented an ISO 8601 duration and nothing read it.** They share one type now, `audit_trail.iso_duration`, whose pattern was checked against `\DateInterval` itself across the shapes these keys use, `PT0S` included, since the lifecycle reads that as an off-switch. 6. The twelve label/description mix-ups, and the 15 top-level types marked. None of this needed a deprecation path. Retyping a key, tightening a constraint and marking a type `FullyValidatable` are all free before 1.0, where reinstall is the upgrade path. ## The runtime question, answered This issue asked whether the module should validate its own configuration at runtime, or leave enforcement to config import and recipes. It should, and it now does: every settings form field declares its `#config_target`, so `ConfigFormBase` writes the value, saves the object, validates the result against the schema, and reports each violation on the field that caused it. The hole that closes is worth naming. `AuditTrailSettingsForm` validates the lifecycle durations only when the lifecycle is enabled, which is right for the ordering rules, since they say nothing about a stage that does not run. With the lifecycle off, an unparseable duration was stored exactly as typed, and whoever switched the lifecycle on months later got a chain dropped out of the cron run with one log line, nowhere near the form that accepted it. `EntityAuditSettingsForm` keeps its own submit handler and says why: there is no field per stored key there, because the `types` map is derived from a form whose shape depends on which entity types exist and which mode each is in. The chain and secret forms are entity forms, which `#config_target` does not cover; those stay gated by the schema wherever validation runs. Where the constraints bite is worth being exact about, because it is not `$config->save()`: that validates the name and the value types and no constraint. They bite wherever something calls `validate()`, which is a recipe, a `#config_target` form, tooling that inspects configuration, and the test class this adds. --- Split out of #3620317, where this was item 4 of the proposed fix. The other three items are done. AI-Generated: Yes (Claude Code was used to help draft this issue summary. I reviewed it before posting.)