Email and Phone Format Variant Generation Prompt Template

This prompt is designed for QA engineers and developers who need to validate contact field normalization and input validation logic. The core job is to generate a comprehensive set of email addresses and phone numbers that span valid RFC formats, common user typos, international variants, and deliberately invalid patterns. Each generated variant must be labeled with its expected validation outcome, making it immediately useful for automated test suites that verify whether a system correctly accepts, rejects, or normalizes contact data.

Use this prompt when you are building or maintaining a test suite for user registration forms, profile update endpoints, CRM data ingestion pipelines, or any system that stores and processes contact information. It is particularly valuable before a release that touches validation rules, when onboarding a new international market that introduces unfamiliar phone formats, or when hardening a system against malformed input that could cause downstream processing errors. The prompt requires you to provide the target validation rules, accepted formats, and any locale-specific constraints so the generated variants are relevant to your system under test.

Do not use this prompt for generating production contact data, sending actual emails, or making real phone calls. It is not a data cleaning tool for existing databases, nor is it a substitute for a proper email verification service. If your goal is to test email deliverability or phone number reachability, you need a different workflow that involves actual sending infrastructure and bounce handling. For performance testing that requires millions of records, pair this prompt with the Large Volume Database Seeding Prompt Template rather than relying on a single generation run. Always review the generated variants before feeding them into automated test pipelines, especially when the prompt produces edge cases for international formats you may not fully understand—a quick human sanity check prevents false positives in your validation tests.

This prompt template produces a structured dataset of email addresses and phone numbers designed to exercise your application's contact field normalization and validation rules. Each generated variant is labeled with its expected validation outcome (valid, invalid, or ambiguous), the format category it belongs to, and a brief rationale. Use this template when you need to verify that your validation logic correctly handles RFC-compliant formats, common user typos, international numbering plans, and deliberately malformed inputs. Do not use this prompt for generating production contact data or for testing systems where the validation rules are unknown to you—the prompt assumes you understand your own acceptance criteria.

textCopy
You are a test data generator for contact field validation. Your task is to produce a structured list of email addresses and phone numbers that exercise validation logic for normalization and format checking.

Generate variants for the following contact type: [CONTACT_TYPE]

Include variants from these categories: [VARIANT_CATEGORIES]

For each variant, provide:
- The raw input string
- The expected validation outcome: valid | invalid | ambiguous
- The format category label (e.g., RFC 5322 compliant, common typo, international E.164, local format, deliberately malformed)
- A one-sentence rationale explaining why this variant is interesting for testing

Apply these constraints:
- [CONSTRAINTS]

Output format: Return a JSON array of objects with keys: "input", "expected_outcome", "category", "rationale".

Example output structure:
[
  {
    "input": "user@example.com",
    "expected_outcome": "valid",
    "category": "RFC 5322 compliant",
    "rationale": "Standard email format that any validator should accept."
  }
]

Risk level for this generation: [RISK_LEVEL]

To adapt this template, replace each square-bracket placeholder with concrete values. Set [CONTACT_TYPE] to email, phone, or both. Define [VARIANT_CATEGORIES] as a comma-separated list drawn from categories such as RFC-compliant formats, common typos (missing @, double dots, transposed characters), international variants (country-specific prefixes, local formatting conventions), edge cases (maximum length, unusual TLDs, quoted local parts), and deliberately invalid patterns (null bytes, script injection attempts, empty strings). Use [CONSTRAINTS] to specify domain-specific rules like "exclude addresses from disposable domains" or "only generate NANP phone numbers." Set [RISK_LEVEL] to low, medium, or high to control whether the prompt should avoid generating patterns that could resemble real contact data. After generating variants, validate the output against your expected schema before feeding it into your test harness.

This prompt is designed to be called programmatically as part of a test data synthesis pipeline, not as a one-off chat interaction. The typical integration pattern is a script or test harness that reads a configuration specifying the number of variants per category (valid RFC emails, common typos, international phone numbers, deliberately invalid patterns), calls the LLM with the prompt template, parses the structured output, and writes the labeled records into a test data store or CSV file for consumption by contact field validation tests. The prompt expects a [VARIANT_COUNT] and optional [LOCALE] parameter to control output volume and regional phone format preferences. Because the output must be machine-readable, the prompt template includes a strict [OUTPUT_SCHEMA] requiring a JSON array of objects with value, type (email/phone), format_category (e.g., rfc5322-valid, common-typo, e164-international, deliberately-invalid), and expected_validation_result (pass/fail) fields. This schema contract is what makes the prompt usable in automated pipelines—downstream test runners can filter by expected_validation_result to build positive and negative test suites without manual inspection.

Validation and retry logic should be built into the harness, not trusted to the prompt alone. After receiving the LLM response, validate that every record contains all required fields, that type is exactly email or phone, that expected_validation_result is exactly pass or fail, and that the total record count matches the requested [VARIANT_COUNT]. For email variants, run a secondary format check: records labeled expected_validation_result: pass should conform to a basic RFC 5322 pattern (the harness can use a library like email-validator in Python), while records labeled fail should deliberately violate it. For phone variants, verify that pass records match E.164 format when format_category indicates international format. If validation fails, implement a retry loop with a maximum of 2 additional attempts, appending the validation errors to the prompt as [PREVIOUS_ERRORS] so the model can correct specific malformed records. Log every validation failure and retry attempt with the record index and error details for debugging prompt drift over time.

Model choice and temperature matter for this use case. The prompt benefits from a model with strong instruction-following and format discipline—GPT-4o, Claude 3.5 Sonnet, or equivalent—because the output must be syntactically valid JSON with precise category labels. Set temperature to 0.2 or lower to reduce creative variation that could produce ambiguous format categories. If using a local or open-weight model, test extensively for JSON compliance and category label consistency before integrating into CI. For high-volume generation (thousands of variants), consider batching requests with a larger [VARIANT_COUNT] per call (50-100 records) to reduce API overhead, but monitor for output truncation at the model's maximum token limit. Do not use this prompt for generating actual contact data that will be sent to real email addresses or phone numbers—the harness should include a safety check that prevents generated values from being used outside the test environment. Wire the output into your test database seeder or parameterized test framework (pytest, JUnit, etc.) so that each variant becomes a test case with the expected_validation_result field driving the assertion. For teams with compliance requirements, log the prompt version, model, timestamp, and generated record count as audit evidence that test data was synthetically generated and never derived from production.