Domain Example Augmentation Prompt Template

This prompt is for ML engineers and domain data curators who need to scale a small set of validated seed examples into a larger, diverse library without sacrificing domain correctness. The job-to-be-done is programmatic variation: taking a single high-quality input-output pair and producing multiple augmented versions that vary entities, terminology, difficulty, and phrasing while preserving the original's factual accuracy and constraint adherence. The ideal user already has a small library of golden examples vetted by domain experts and needs to expand coverage for fine-tuning, few-shot prompting, or evaluation datasets.

Use this prompt when you have a stable seed example that represents a correct pattern and you need to generate 5–50 variations that stress-test different surface forms. It is appropriate for domains like legal, medical, finance, or technical documentation where terminology precision and constraint boundaries are non-negotiable. The prompt expects you to supply the original example, a list of substitutable entities, domain terminology constraints, and a difficulty scaling target. It is not a replacement for expert review of the augmented outputs—every generated variation should pass through a validation checkpoint before entering your example library.

Do not use this prompt when the seed example itself is unvalidated, when the domain rules are too ambiguous to encode as constraints, or when the augmentation requires generating novel factual claims rather than varying surface form. It is also unsuitable for generating counterexamples or negative examples—those require a separate prompt designed to teach boundary violations. If your goal is to create entirely new example patterns rather than vary existing ones, start with a domain-specific few-shot example generator instead. After running this augmentation, always apply the companion example validation checklist to catch factual drift, entity hallucination, and constraint violations before the augmented examples touch any production system.

This prompt template is designed to be integrated into an automated example augmentation pipeline. It takes a seed example from your domain-specific library—such as a medical coding pair, a legal clause extraction, or a financial compliance check—and produces a set of valid variations. The template uses square-bracket placeholders that your application must populate before sending the request to the model. Each placeholder represents a critical input that controls the augmentation behavior, from the original example to the domain constraints that must never be violated.

textCopy
You are an expert in [DOMAIN] tasked with augmenting a library of few-shot examples.
Your goal is to generate [VARIATION_COUNT] new input-output pairs based on the provided seed example.

## Seed Example
[SEED_EXAMPLE]

## Augmentation Instructions
Apply the following variations while preserving domain correctness:
- Entity Substitution: Replace [ENTITY_TYPES_TO_SUBSTITUTE] with plausible alternatives from the [DOMAIN_TERMINOLOGY_REFERENCE].
- Paraphrasing: Rewrite the input using different sentence structures without changing the semantic meaning.
- Difficulty Scaling: Create variations at [DIFFICULTY_LEVELS] difficulty by [DIFFICULTY_SCALING_METHOD].
- Terminology Variation: Use synonyms or alternative domain-accepted terms for [TERMS_TO_VARY].

## Domain Constraints (DO NOT VIOLATE)
[DOMAIN_CONSTRAINTS]

## Output Schema
Return a JSON array of objects. Each object must have the keys "input" and "output".
[OUTPUT_SCHEMA]

## Validation Checks
Before outputting each example, internally verify:
1. The augmented example does not introduce factual errors.
2. All domain constraints are satisfied.
3. The output for the augmented input is correct according to [DOMAIN_RULES].
If a variation would violate any check, discard it and generate a new one.

## Examples of Valid Augmentations
[VALID_AUGMENTATION_EXAMPLES]

## Examples of Invalid Augmentations (to avoid)
[INVALID_AUGMENTATION_EXAMPLES]

To adapt this template for your pipeline, start by defining the [DOMAIN] and [DOMAIN_CONSTRAINTS] with precision. These are not optional; they are the guardrails that prevent the model from introducing subtle but critical errors, such as changing a drug dosage in a clinical example or altering a compliance clause in a legal one. The [OUTPUT_SCHEMA] should be a strict JSON Schema definition that your application can validate programmatically. For high-risk domains like healthcare or finance, always route the augmented examples through a human review queue before they enter your production example library. A secondary LLM-as-judge evaluation, using a rubric defined in your [DOMAIN_RULES], can act as a pre-filter to catch obvious constraint violations and reduce the review burden.

This prompt template is designed to be a single step within a larger programmatic augmentation pipeline, not a standalone chat interaction. The primary integration point is a script or microservice that takes a seed example and a set of augmentation parameters, formats the prompt, calls the model API, and then rigorously validates the output before accepting it into your domain example library. The harness must treat the model's output as a candidate that requires verification, especially because the prompt's goal is to introduce variation without breaking domain-specific factual, terminological, or constraint-based rules.

The core implementation loop should follow a strict generate → validate → retry or reject pattern. After receiving the model's response, parse the JSON output and run a series of automated checks. These must include: (1) a schema validation check to ensure the output matches the expected [OUTPUT_SCHEMA]; (2) a domain terminology check, using a pre-defined glossary or entity list, to confirm that any substituted terms (e.g., a medical procedure code or a financial instrument type) are valid and used correctly in context; (3) a constraint violation check, which programmatically verifies that none of the explicit [CONSTRAINTS] (like 'do not change the diagnosis' or 'preserve the regulatory citation') are broken by comparing the augmented output to the original seed; and (4) a semantic similarity check to ensure the augmented example hasn't drifted so far from the seed that it represents a completely different task. If any check fails, log the failure with the specific validator that tripped, increment a retry counter, and re-submit the prompt with the validation error message appended as feedback. If the prompt fails more than a set number of retries (e.g., 3), the seed example should be quarantined for human review rather than silently discarded.

For model choice, a model with strong instruction-following and JSON mode capabilities is essential. The prompt's complexity and the need for precise constraint adherence mean that smaller, less capable models will likely introduce subtle factual errors during augmentation. Log every successful and failed augmentation attempt, capturing the seed example, the augmentation parameters, the raw model output, the validation results, and the final accepted example. This audit trail is critical for debugging drift in your example library and for providing evidence during governance reviews. The next step after building this harness is to run a bulk backfill against your existing seed library, carefully monitoring the validation failure rate to identify which types of domain examples are most resistant to reliable augmentation.