Schemas#
Three JSON Schemas, served at the exact URLs their $id values name. A $id is
a promise — validators fetch it — so these paths are permanent. When a later
version ships it is served alongside this one, never in place of it, and the
version segment is the standard's, not the rubric arithmetic's, so a
recalibration cannot orphan every validator that already trusts a URL.
| Schema | What it describes |
|---|---|
assessment-input.schema.json |
What goes in: per-face centering measurements and an enumerated list of defects. |
score-result.schema.json |
What comes out: the grade, the points, the binding face and region, and a line item for every penalty applied. |
rubric-config.schema.json |
The shape of a rubric itself — the penalty tables the scorer reads. This is what makes a per-set or experimental rubric possible without forking the scorer. |
Each file declares the address it is served from. If you fetch one and its $id
disagrees with where you got it, something is wrong and you should not trust it —
that check is run against these files before every deploy.
A limit worth knowing before you build#
All three schemas set additionalProperties: false at their root. Unknown fields
are rejected rather than ignored, so a document carrying an extension the
standard does not define will fail validation.
That is deliberate for now and it means Touchstone is not extensible today. Loosening it later is a backward-compatible change — everything valid now stays valid — so this can be revisited. It is stated here rather than discovered, because a standard that lets you infer extensibility it does not have has mis-sold itself.
Validating against them#
The schemas are ordinary JSON Schema (draft 2020-12) and work in any validator
that resolves $ref by URL. They are also published in the repository, so a
build that must not reach the network can vendor them and check them against
these URLs.