A new test-software release may add a field, rename a status, or change how measurements are represented. If downstream importers continue to assume the old structure, records can be accepted with missing identities or incorrect meaning. Give the result format its own explicit version and compatibility policy.
The JSON Schema object documentation distinguishes property definitions, required properties, and additional-property handling. In particular, defining a property does not itself make that property mandatory. A schema must express the requirements the receiving system actually depends on.
Define the minimum interpretable record
Identify required board, attempt, step, recipe, and measurement fields. State which fields may be absent and which may explicitly contain no value. Missing, null, empty text, and zero should not become interchangeable representations unless the format deliberately defines them that way.
Separate structural validation from engineering validation. A number can satisfy a numeric type while carrying the wrong unit. A status string can be syntactically valid while conflicting with an absent measurement or an incomplete test step.
Classify format changes
| Change | Review question |
|---|---|
| New optional field | Can older consumers ignore it safely? |
| Renamed required field | How will consumers find the same identity? |
| Changed unit or status meaning | Does the semantic version need to change? |
| New nested structure | Can existing parsers still locate the data? |
Keep examples for each supported version. Include valid records and deliberately invalid cases such as missing attempt identity, unknown status, and a measurement whose required unit is absent. The validation should fail for the intended reason, not merely because the file contains an unrelated syntax error. Include an unexpected field spelling to check whether a typo could bypass the intended required data path.
Release producer and consumer changes together
- Document the proposed schema and meaning changes.
- Test the producer against the new schema.
- Test each consumer with old and new examples.
- Define migration or rejection behavior for unsupported versions.
- Retain the original record alongside any converted representation.
Do not silently assign the newest schema version to historical files. A migration must explain how old fields map to new ones and which information cannot be recovered. Preserve the distinction between observed data and values introduced by conversion.
The final compatibility policy should make failures visible before records enter quality summaries. A file that opens successfully is not necessarily a complete or meaningful test record. Explicit format versions make long-term comparison possible without relying on undocumented assumptions hidden inside a parser.
Move from reading to a build-ready project
Use the fabrication and assembly checklists to prepare drawings, production files and test requirements.
Open the DFM checklist