Check the shape. Review the meaning.

Three separate questions

1. Is the response usable JSON? Syntax checks reject commentary or Markdown fences.
2. Does it have the required shape and expected facts? The structure checks required fields, types, lengths and closed objects. Expected-value checks independently verify the source ID, owner, deadline and array membership/order. Either can fail.
3. Does it mean the right thing? Manual criteria judge source grounding, useful task wording and retained dependencies. Structure does not assess truth or agreement.

The original action pack's subset checks can accept a response with the expected IDs/dates but no task description. The additional contract catches that omission and unexpected fields. It still permits different valid task wording. A structurally valid invented or whitespace-only task is not thereby accepted.

Apply it to your project

1. Download your current project before changing checks. Select a case, enable Require a JSON response, and paste a contract into JSON structure contract.
2. Read the validation message. Unsupported keywords or invalid contracts fail explicitly; they are never treated as passing checks. Blank means no structure check. The contract is inactive while JSON checks are disabled.
3. Optionally choose Copy structure to all cases. Confirmation copies only this contract and enables JSON checks for nonblank contracts, preserving each case's expected values, phrases, word limit and recorded evidence. Blank removes contracts but does not turn off other checks.
4. Inspect path-specific failures next to recorded outputs. New checks do not rerun a model. They make bound manual reviews out of date; restart review explicitly to retain the older context before judging again.
5. Keep the structure in your project export. Recorded-response rules, review snapshots, trial history, baseline comparisons and reports retain it. In a baseline comparison both outputs use the current candidate rules.

Checks are not inserted into prompts. If your model needs the output contract, put the relevant instructions in the prompt yourself. A CSV expected-value column replaces expected values/exactness but retains a copied structure when inheriting case checks. Generic CSV exports do not include structure contracts.

Supported contract language

This is an explicit JSON Schema-style subset, not a full JSON Schema validator or a declared draft implementation. Each node must be an object with a type. Unsupported keywords—including $ref, $schema, pattern, format, oneOf and conditionals—are errors. No remote documents are fetched, regular expressions run or schema code executed.

• type: object, array, string, number, integer, boolean or null. One type, or an array pairing one type with null. No other unions.
• Objects: properties maps names to nodes; required lists unique names defined in properties; additionalProperties is true or false (default true). These constraints apply only to object values.
• Arrays: items is one node applied to every item; optional minItems/maxItems. No tuples or uniqueItems. Structure alone does not set item order; expected-value checks do.
• Strings: minLength/maxLength count Unicode code points, including whitespace. Not bytes, grapheme clusters or meaningful words.
• Numbers/integers: minimum/maximum are inclusive finite bounds. Integer means a finite integer in JavaScript number semantics, not arbitrary-precision arithmetic.
• enum: 1–100 scalar JSON values (string, finite number, boolean or null). A value must satisfy both type and enum. No object/array enum entries.
• title and description are text annotations only; they do not validate meaning. Type-inapplicable validation keywords are rejected.

Bounds: 10,000 characters per contract, 200 schema nodes, 12 nested levels, length/item bounds from 0 to 100,000, up to 12 response differences shown. These are provisional implementation limits. Native JSON parsing applies: duplicate keys keep the last value and numbers have JavaScript precision. Schemas cannot prove semantic correctness, prompt-injection resistance or source authenticity.

Compatibility and evidence

Projects without structure or saved project decisions remain format 4. Adding structure upgrades to at least format 5; saving a project decision opts into format 6. Neither clearing structure nor deleting decisions downgrades the project. Version-5/6 projects export version-2 response worksheets. Older clients reject those versions rather than ignore the new checks. Projects 1–4 import without inventing structure contracts; existing reviews/history remain intact. A version-1 worksheet cannot supply a newly active structure contract: changed rules block it until you export a matching worksheet.

Do not attach the new contract to old review snapshots as if it had been used then. Recheck existing outputs under the new rules and explicitly review again. The earlier actual public-notes exercise remains a format-4 historical example without structure. Its source classifications and judgments are agent-authored; it is not an independent model benchmark. The new starter remains unrun.

No new content upload, telemetry event or model execution is introduced. Project JSON is the editable backup; the offline HTML handoff exposes the new current/saved checks for review without uploading the project.