The properties you didn't list still need a policy
additionalProperties
By default, properties not listed in properties are allowed. To forbid them, set additionalProperties: false — the schema becomes 'closed'. To validate them against a sub-schema instead, set additionalProperties to a schema (e.g. { "type": "string" }: 'every other key must be a string').
patternProperties
Sometimes property names follow a pattern. patternProperties maps regex-on-key to a schema. "^env_": {"type": "string"} means 'every key starting with env_ must be a string'. The classic use: env-var maps, locale maps ("^[a-z]{2}(-[A-Z]{2})?$").
propertyNames
Constrain the key strings themselves: "propertyNames": {"pattern": "^[a-zA-Z_][a-zA-Z0-9_]*$"} means 'all keys must be valid identifiers'. Useful when JSON keys become variable names downstream.
'closed by default' costs you forwards-compatibility. A schema with
additionalProperties: false rejects valid v2 documents in a v1 validator. Public APIs usually leave it open (or document the policy explicitly); private internal schemas often close it. Pick consciously, not by reflex.