2026-09-21 · 6 min read · Rahul Chitturi
- json-schema
- validation
- api
JSON Schema can require other properties when a trigger property exists, or apply an entire subschema to the containing object. These are different jobs: dependentRequired lists required peer names, while dependentSchemas evaluates a schema.
A schema can appear correct but do nothing when the runtime uses an older dialect, the trigger property's spelling drifts, or the dependency was attached at the wrong object level.
Identify the trigger and consequence
For each rule, write a plain-language statement: if this exact property is present, these peer names become required or this subschema must validate the whole object. Presence is not the same as a truthy or non-null value.
- Declare the intended dialect with $schema.
- Keep property names case-sensitive and exact.
- Use required for presence, not value quality.
- Place dependencies beside the object properties they govern.
Trace composition deliberately
A dependent schema can contain properties, required, references, conditionals, and composition keywords. Isolate that schema first, then test it in the complete allOf or anyOf structure used by production.
If unevaluatedProperties participates, verify how successful dependent schemas contribute annotations in the chosen dialect and validator. Do not copy older dependencies syntax without checking migration semantics.
Create a trigger matrix
Use Flashman's JSON formatter for schemas and instances, diff for one-property fixture changes, case converter for naming drift, and regex tester for string constraints.
Test absent triggers, present null and false values, each missing peer, all peers, unexpected properties, nested objects, multiple simultaneous triggers, references, dialect changes, and validator upgrades.