### Problem/Motivation Tool API publishes JSON Schema for every input and output, but validates maps by a different rule than the schema it publishes. In JSON Schema, `required` is a list on the parent object naming keys that must be present; it says nothing about the value, and `{}` is a valid `object` unless `minProperties` says otherwise. In Tool API, "required" is a flag on the value and becomes typed data's NotNull, and core's `NotNullConstraintValidator` treats an empty `Map` as NULL. So a required map means non-empty: * The advertised schema for a required map is `object`, which accepts `{}`. * Validation rejects `[]` for it ("This value should not be null"). A client that trusts the schema gets a failure the schema allowed. With output validation in 1.0.0-beta10 (#3583029), this surfaces as tool failures in consuming modules whenever a map is legitimately empty: * canvas_tools: `canvas_get_component_schema` fails for every component without slots or props, 24 of 41 on a byte_theme site (https://git.drupalcode.org/project/canvas_tools/-/work_items/26). * tool_belt: several free-form map outputs had to be declared optional (https://git.drupalcode.org/project/tool_belt/-/work_items/3616175). Lists had the same mismatch and were aligned in #3583040: a required list is present, may be empty, and a minimum comes only from a declared `Count`. Maps were deliberately left out (commit bca6986): a map's NotNull is what rejects `[]` for a map with required properties, because core skips the properties of an empty map (https://www.drupal.org/project/drupal/issues/3256536). That protection appears to be covered already on Tool API's own validation paths: * `TypedInputsTrait::validateInputValue()` (src/TypedInputsTrait.php:650-668) walks a `MapDataDefinition` with declared properties itself, reports each missing required property ("The @label property is required."), and returns before typed-data validation. * `TypedOutputsTrait::validateOutputValue()` does the same for a `MapOutputDefinition` with declared properties. * Typed-data NotNull is therefore only reached for maps without declared properties: a plain `data_type: 'map'` definition, or a map definition with no properties. Those are free-form maps, where the rejection protects no required property. Not traced: whether form adapters or other callers of `EffectiveDataDefinition::createFrom()` validate typed data on their own. `ExecuteToolPluginForm` and `ConfigureToolPluginForm` do not call `validate()`; submitted values reach validation through `execute()`. A related gap: "always present, may be null", which JSON Schema expresses with `required` plus `type: [T, "null"]`, cannot be declared (#3583043). ### Proposed resolution Treat "required" the way the published schema does, for maps as it already is for lists: 1. A required map is present and not NULL, and may be empty. Keep rejecting NULL for a required map (as `validateListNotNull()` does for lists), but not `[]`. 2. Keep required properties enforced by the input and output walkers, which already check them directly, so dropping the empty-map NotNull does not reopen the core #3256536 gap on those paths. Where typed data is validated outside the walkers, check required properties there too, or keep NotNull only for maps that declare required properties. 3. If a map must hold at least one entry, express it with an explicit constraint that normalizes to `minProperties`, mirroring `Count` for lists. ### Remaining tasks * Confirm the form adapters and any other typed-data validation paths. * Implement for inputs and outputs, and extend `RequiredEmptyListTest` (or a sibling) with map cases: required empty free-form map valid, required NULL map invalid, required map missing a required property invalid. * Once released, the optional declarations in consuming modules (canvas_tools #26, tool_belt #3616175) can go back to required where the value is always present. * Change record if the validation behaviour of existing tools changes. ### AI usage (if applicable) * [x] AI Assisted Issue: This issue was generated with AI assistance, but was reviewed and refined by the creator. * [ ] AI Assisted Code: This code was mainly generated by a human, with AI autocompleting or parts AI generated, but under full human supervision. * [ ] AI Generated Code: This code was mainly generated by an AI with human guidance, and reviewed, tested, and refined by a human. * [ ] Vibe Coded: This code was generated by an AI and has only been functionally tested.