JSON Schema Generator Prompt

You are a senior API and data-contract engineer. Generate a JSON Schema only from the representative data, requirements, and version information I provide. Ask about any ambiguity that changes validation behavior instead of inventing a rule.

Schema purpose and consumer: [API request, API response, event, config file, form, stored document]
Target JSON Schema draft or validator: [draft/version, library, platform, unknown]
Representative valid JSON instances: [paste several, with secrets removed]
Representative invalid instances: [paste if available]
Field-by-field business rules: [required, optional, nullable, conditional, deprecated]
Allowed types and coercion policy: [details]
String rules: [length, pattern, format, normalization]
Number rules: [integer or number, range, multiple]
Array rules: [item type, size, uniqueness, order significance]
Object rules: [required keys, additionalProperties policy, property-name rules]
Enums or controlled values: [verified list and case sensitivity]
Identifiers, dates, times, URLs, and units: [exact representation]
Cross-field conditions: [if/then/else, oneOf, anyOf, dependent requirements]
Reusable structures: [candidates for $defs and $ref]
Defaults and examples policy: [annotation only, applied by separate code, none]
Backward-compatibility requirements: [existing producers and consumers]
Security or privacy constraints: [secret fields, personal data, maximum payload size]
Output language or integration example: [JavaScript, TypeScript, Python, Java, CLI, none]

Provide:
1. A concise interpretation of the contract and a list of unresolved decisions.
2. One complete valid JSON Schema for the named draft, including $schema and $id only when supplied or safely parameterized.
3. Clear title and description annotations that do not change validation behavior.
4. Reusable $defs and $ref structures where they reduce duplication without hiding simple rules.
5. A property table showing type, required status, nullability, constraints, default behavior, and source evidence.
6. At least two minimal valid instances and targeted invalid instances for every meaningful constraint.
7. A validation matrix with expected pass or fail result and the keyword responsible.
8. A compatibility review covering stricter required fields, closed objects, enum changes, type narrowing, and consumer impact.
9. A short integration example for the specified validator, with version assumptions called out.
10. A final audit for unsupported format claims, unsafe regex, unbounded arrays or strings, duplicate logic, secrets in examples, and rules inferred from too few samples.

Do not infer that a field is required, nullable, unique, formatted, bounded, or enumerated merely because one sample suggests it. Do not treat default as automatic mutation unless the named validator does so. Never include real secrets or personal data in examples.