Schema-Compliant Example Variation Prompt

This prompt is for integration engineers and ML engineers who need to scale a small set of seed examples into a large, diverse training or evaluation dataset where every record must conform to a strict target schema (JSON, XML, or typed objects). The job-to-be-done is programmatic data augmentation: you have a handful of valid input-output pairs, and you need hundreds or thousands of variations that preserve the underlying task pattern while varying content, entities, complexity, and optional field inclusion—all without breaking the schema contract. The ideal user is someone preparing fine-tuning data, building regression test suites, or generating synthetic evaluation sets for structured-output AI systems. Required context includes the target schema definition, one or more seed examples that already validate against that schema, and clear boundaries for what constitutes a valid variation (e.g., which fields are immutable, which can be substituted, and what constitutes a schema violation).

Do not use this prompt when the target schema is undefined, when seed examples are already invalid, or when the variation task requires changing the semantic intent of the example rather than its surface form. This prompt is not a substitute for schema design or validation infrastructure—it assumes you already have a schema and a validator. It is also not appropriate for generating free-text variations without structural constraints; use the Paraphrase Generation Prompt for that. For high-risk domains (healthcare, legal, finance), always pair this prompt with human review of generated examples and automated validation against the target schema before the examples enter any training or evaluation pipeline. The prompt works best when the seed examples are clean, the schema is well-typed, and the variation instructions are specific about which fields to vary and how.

Before using this prompt, ensure you have: (1) a validated target schema, (2) at least one seed example that passes schema validation, (3) a list of fields that can be varied and their allowed value ranges or substitution rules, and (4) a validation harness that will reject any generated example that doesn't conform. After generation, run every output through your schema validator and discard or repair failures. For production training data, also run semantic consistency checks to confirm that the variation didn't corrupt the intended input-output relationship. Start with a small batch, validate thoroughly, then scale.

This prompt template is designed for integration engineers and ML engineers who need to programmatically expand a small set of seed examples into a diverse, schema-compliant training or evaluation dataset. The template accepts a seed example, a target JSON schema, and a set of variation instructions, then produces multiple output variations that conform to the schema while varying content along specified dimensions. Use this when manual example creation doesn't scale and you need production-grade diversity with field-level validation guarantees.

textCopy
You are a structured data generation assistant. Your task is to produce [VARIATION_COUNT] valid variations of the provided seed example. Each variation must conform exactly to the target schema, vary the content according to the variation instructions, and pass field-level validation.

## TARGET SCHEMA
```json
[OUTPUT_SCHEMA]

SEED EXAMPLE

jsonCopy
[SEED_EXAMPLE]

VARIATION INSTRUCTIONS

[VARIATION_INSTRUCTIONS]

CONSTRAINTS

• Every output object must validate against the target schema exactly. No missing required fields, no extra fields, no type mismatches.
• For optional fields specified in [OPTIONAL_FIELD_TOGGLES], randomly include or omit them across variations with the specified probability.
• Entity substitutions must preserve entity type consistency: replace names with names, dates with dates, currencies with currencies.
• Maintain the semantic intent of the seed example unless [INTENT_PRESERVATION_LEVEL] specifies otherwise.
• If [DIFFICULTY_SCALING] is enabled, produce variations at the specified difficulty levels and include a "difficulty" metadata field in each output.
• If [ADVERSARIAL_MODE] is enabled, include edge-case variations that test boundary conditions, null equivalents, and maximum field lengths.

OUTPUT FORMAT

Return a JSON object with a "variations" array containing exactly [VARIATION_COUNT] objects. Each object must have:

• "index": integer position in the set
• "variation_type": label from [VARIATION_TYPE_LABELS]
• "data": the schema-compliant variation object
• "changes_summary": brief description of what was changed from the seed

EXAMPLES OF VALID VARIATIONS

[FEW_SHOT_EXAMPLES]

NEGATIVE EXAMPLES (DO NOT PRODUCE)

[NEGATIVE_EXAMPLES]

Generate the variations now.

Adaptation guidance: Replace every square-bracket placeholder before use. [OUTPUT_SCHEMA] should contain your complete JSON Schema with field types, required arrays, and enum constraints. [VARIATION_INSTRUCTIONS] should specify which dimensions to vary—paraphrasing, entity substitution, difficulty scaling, noise injection, or locale adaptation. [OPTIONAL_FIELD_TOGGLES] controls which optional fields appear and at what frequency. [FEW_SHOT_EXAMPLES] should include 2-3 valid input-output pairs that demonstrate the expected variation style and schema compliance. [NEGATIVE_EXAMPLES] should show common failure modes: missing required fields, type mismatches, or intent corruption. For production pipelines, always run the output through a JSON Schema validator before ingestion. If the validation failure rate exceeds 5%, add more explicit negative examples or reduce [VARIATION_COUNT] per call. For high-risk domains, route outputs through human review before they enter training datasets.

The Schema-Compliant Example Variation Prompt is designed to be called programmatically, not used in a one-off chat interface. In a production harness, you will typically iterate over a set of seed examples, calling the model once per seed with the target schema and variation parameters injected into the prompt template. The harness should manage concurrency, rate limiting, and cost tracking, as generating hundreds or thousands of varied examples can consume significant tokens. Treat each generation as a discrete job with its own success, failure, and retry lifecycle.

The core implementation loop follows a validate-retry-log pattern. After receiving the model's output, parse it against the target schema immediately. If parsing fails or required fields are missing, do not silently discard the output. Instead, construct a retry prompt that includes the raw output and the specific validation error (e.g., 'Field amount expected number, got string'). Limit retries to a maximum of 2 attempts per seed to avoid infinite loops on fundamentally broken seeds. Log every failure with the seed ID, the model's raw response, and the validation error for later analysis. For high-stakes datasets used in fine-tuning or evaluation, route all outputs through a human review queue before final acceptance, especially for fields marked as [CRITICAL] in your schema.

When choosing a model, prefer those with strong structured output support and large context windows if your schema is complex or your seeds are long. GPT-4o and Claude 3.5 Sonnet are reliable defaults. For cost-sensitive, high-volume runs, consider using a smaller model like GPT-4o-mini for the variation step and a larger model for a final validation pass. If your variation parameters include controlled noise injection or adversarial transformations, implement a separate quality gate that checks whether the output still represents a valid, realistic example and hasn't drifted into nonsense. Finally, store every generated example with its provenance metadata: the seed ID, prompt version, model identifier, and timestamp. This audit trail is essential for debugging downstream model behavior and reproducing datasets.