Entity Resolution Schema Validation Prompt

This playbook is for data engineers and pipeline operators who need to guarantee that the output of a cross-document entity resolution step conforms to a strict downstream ingestion contract. Use this prompt after an entity resolution process has produced merged records, but before those records are written to a master data store, search index, or analytics database. The prompt acts as a final validation gate, checking for schema compliance, type enforcement, required field presence, and early signs of schema drift. It does not perform the resolution itself; it validates the output of a resolution step.

The ideal user has a batch of resolved entity records—likely JSON—and a known target schema that downstream systems expect. You should have already completed deduplication, merging, and conflict resolution. This prompt is not a substitute for those steps. It is a contract enforcement layer. Provide the resolved records as [INPUT], the target schema as [OUTPUT_SCHEMA], and any additional constraints such as enum lists, date format rules, or null-handling policies as [CONSTRAINTS]. The prompt will return a structured validation report flagging missing required fields, type mismatches, unexpected keys, and records that deviate from the majority schema pattern—an early indicator of drift in the upstream resolution logic.

Do not use this prompt when you need to perform entity resolution itself, when you are still experimenting with merge logic, or when your downstream systems lack a formal schema. It is also inappropriate for validating unstructured narrative summaries or free-text fields where schema enforcement is not meaningful. For high-risk domains such as healthcare, finance, or legal compliance, always route validation failures to a human review queue before ingestion. After running this prompt, take the validation report and either block the batch, quarantine non-conforming records, or trigger a repair workflow before writing to your target system.

This prompt template validates that entity resolution output conforms to a target ingestion contract before data flows into downstream systems. It checks required fields, enforces types, detects schema drift, and flags records that would break database inserts or API consumers. Use this when you have a resolution pipeline producing merged entity profiles and need a gate before those profiles land in a data warehouse, search index, or operational system.

codeCopy
You are a schema validation engine for entity resolution output. Your job is to check every resolved entity record against the target ingestion schema and report violations, warnings, and drift signals.

## INPUT
- Resolved entity records: [RESOLUTION_OUTPUT]
- Target ingestion schema: [INGESTION_SCHEMA]
- Schema version: [SCHEMA_VERSION]
- Strict mode: [STRICT_MODE] (true = reject unknown fields; false = warn only)

## TASKS
1. For each record in [RESOLUTION_OUTPUT], check that every required field in [INGESTION_SCHEMA] is present and non-null.
2. Validate the type of every field against the schema (string, integer, float, boolean, array, object, enum, date, datetime).
3. Check that enum fields contain only allowed values defined in the schema.
4. If [STRICT_MODE] is true, flag any field present in the record but absent from the schema as a schema drift violation.
5. For nested objects and arrays, recurse into the structure and validate at every level.
6. For fields marked as nullable in the schema, distinguish between explicit null (allowed) and missing keys (violation unless optional).
7. Check that array fields contain elements of the declared item type.
8. Validate date and datetime fields against ISO 8601 format.
9. For fields with min/max constraints, length limits, or regex patterns defined in the schema, apply those validations.
10. For entity resolution-specific checks: verify that each record has a canonical_id field, that source_ids is a non-empty array, and that confidence scores are floats between 0.0 and 1.0.

## OUTPUT SCHEMA
Return a JSON object with this structure:
{
  "validation_summary": {
    "total_records": integer,
    "valid_records": integer,
    "invalid_records": integer,
    "warnings_count": integer,
    "schema_drift_detected": boolean,
    "schema_version_checked": string
  },
  "record_results": [
    {
      "record_index": integer,
      "canonical_id": string,
      "status": "valid" | "invalid" | "warning",
      "violations": [
        {
          "field_path": string,
          "violation_type": "missing_required" | "type_mismatch" | "invalid_enum" | "schema_drift" | "constraint_violation" | "null_violation" | "format_error" | "resolution_contract_violation",
          "expected": string,
          "actual": string,
          "severity": "error" | "warning"
        }
      ]
    }
  ],
  "schema_drift_fields": [string],
  "recommended_actions": [string]
}

## CONSTRAINTS
- Do not modify or repair any record data. Only validate and report.
- If a record has both errors and warnings, classify status as "invalid".
- Report violations at the most specific field path (e.g., "addresses[0].postal_code" not just "addresses").
- If the entire [RESOLUTION_OUTPUT] is empty or unparseable, return a single violation at the root level.
- Never guess field types. Compare only against the declared schema.
- For confidence fields, flag values outside 0.0-1.0 but do not round them.

To adapt this template, replace [RESOLUTION_OUTPUT] with your merged entity records in JSON format, [INGESTION_SCHEMA] with your target schema definition (JSON Schema, a field-to-type map, or a structured specification), [SCHEMA_VERSION] with a version string for audit trails, and [STRICT_MODE] with a boolean controlling unknown-field behavior. Wire this prompt into a post-resolution validation step that runs before any database write or API publish. For high-stakes ingestion pipelines, add a human review gate when invalid_records exceeds a threshold or when schema_drift_detected is true. Test this prompt against known-valid and intentionally-broken resolution outputs to confirm it catches missing required fields, type mismatches, enum violations, and unexpected fields before you rely on it in production.

The Entity Resolution Schema Validation Prompt is designed to sit at the boundary between your resolution engine and downstream ingestion. It should be called after entity records are produced but before they are written to a database, event stream, or API. The prompt acts as a schema gate: it receives a batch of resolved entity records and a target schema contract, then returns a validated payload with compliance checks, type enforcement, required field verification, and schema drift warnings. This is not a prompt you fire once and forget—it is a repeatable validation step that should be integrated into your data pipeline's processing loop, typically as a post-resolution transformation stage.

Wire the prompt into your application by constructing a request that includes the resolved entity payload under [RESOLVED_ENTITIES] and the target schema definition under [TARGET_SCHEMA]. The schema definition should be a JSON Schema or equivalent contract that specifies required fields, allowed types, enum values, and format constraints. On the application side, implement a validation wrapper that: (1) sends the prompt request with a strict JSON mode or function-calling output format to enforce structured returns; (2) parses the model's response into a typed validation result object containing valid_records, invalid_records, schema_drift_flags, and repair_suggestions; (3) applies a post-processing check that verifies every record in the input batch appears in either the valid or invalid output list—missing records indicate a model hallucination or truncation error. For high-throughput pipelines, batch records in groups of 10–50 to stay within context limits while maintaining reasonable latency. Use a model with strong JSON adherence, such as gpt-4o with response_format: { type: "json_object" } or Claude with structured output tool use, and set a low temperature (0.0–0.2) to maximize deterministic validation behavior.

Build a retry and escalation layer around the prompt. If the model returns malformed JSON, a partial record list, or schema drift warnings that indicate the resolution output has structurally changed, do not silently pass the data downstream. Implement a retry loop with up to 3 attempts, appending the previous error or drift warning to the prompt context on each retry. If validation still fails after retries, route the batch to a human review queue with the full validation output, the original resolved entities, and the target schema for manual inspection. Log every validation run—including input batch hash, output validation result, retry count, and escalation decision—to an audit table so you can trace schema compliance over time and detect when resolution quality degrades. Avoid the temptation to auto-repair records based on model suggestions without human approval when the target system is a production database or compliance-critical store; instead, treat repair suggestions as triage hints for the review queue.