Make a contract change reviewable
Use the workbench to investigate a concrete change, then export a record of what you checked.
1. Begin with a controlled example
Load Structure changes. Run checks: the new producer deletes context, changes amount to string and changes the kind enum. Read each consumer’s old and new inclusion result. Open the generated witness; it is validated against both contracts.
Use the semantic scenario to keep structure unchanged while declaring seconds → milliseconds and cents → dollars. With a 2020–2030 time window, the same numeric timestamp can pass one semantic contract and fail the other. Amount magnitude alone cannot reveal its unit. The unit change requires review even when sample values pass both.
Use the replay scenario for nullable versus absent nested fields, enum tightening and extension, a bad JSONL line, and a numeric identifier that fails the declared string contract. Compare row statuses and individual introduced/resolved/unchanged error counts.
2. Import your own inputs
Each editor accepts a local file: producer-old.json, producer-new.json, consumers.json, events.jsonl. Or download and reimport a synthetic input bundle with exactly old, new, consumers and events (events is a JSONL string). You can also expand Paste an input bundle and paste the same JSON bundle. Files are read locally. This tab does not send your inputs anywhere.
Producer files use {"dialect":"dcl/1","schema":{...},"semantics":{...}}. Consumers are an array of {"name":"reader","contract":{...}}; declare only dependencies and choose additionalProperties explicitly. Every JSONL line contains one event. A bad line stays in the error report; it is never counted as a successful validation. Empty input blocks the run.
3. Change a rule and rerun
Edit the new contract, then Run checks again. Edits disable stale exports. Restore the consumer’s required field, or add purchase to the consumer enum, and observe the directional result change. Expanding a producer enum may break an old consumer; tightening that same producer enum may instead reject old samples. Read both producer-contract directions.
4. Save evidence
Export contract-report.json, errors.csv and a readable HTML report. JSON includes contracts, consumer names, direction results, validated structural witnesses and every row diagnostic. It excludes original event values. The readable report is standalone and includes the full machine report. CSV has UTF-8 BOM, CRLF rows, quoted cells and formula prefixes. Review all exports before sharing.
Local data and practical limits
No backend, account, analytics, remote validation, localStorage or paid model is involved. Reloading clears edits; Clear workspace erases editor contents. Contract names and enum values may still be sensitive and appear in exports. Limits protect a browser tab, not a production system: 2 MB per input, 500 physical JSONL lines, 12 consumers, 160 schema nodes and depth 8; JSON nesting is at most 24. JSON parsing and a full replay each allow 50,000 value nodes; each validation allows 20,000 value visits, and a replay allows 20,000 diagnostics. Exceeding a budget is an input error, not a partial success. At most 100 scalar enum values; bounded lengths/items at most 10,000.
Keep long IDs as strings. Numeric magnitude above JavaScript’s safe integer limit is rejected before parsing; strings preserve all digits. Duplicate JSON keys are rejected. Null is a present value, while required checks absence. Optional absent/null fields skip semantic value checks; structural rules control whether they are permitted.