Data Model Peer Review Facilitation Prompt

This prompt is for engineering leads, data architects, and senior backend engineers who need to facilitate a rigorous, structured peer review of a proposed data model. The job-to-be-done is not to generate a review, but to produce a facilitation artifact: a review agenda, a set of targeted probing questions organized by risk dimension, and a summary template that captures decisions, unresolved risks, and action items. The ideal user is someone who understands the domain and the proposed model well enough to provide it as input, but wants the AI to enforce review discipline and prevent the common failure mode of reviews that focus only on naming conventions while missing indexing gaps, evolvability traps, or security boundary violations.

Use this prompt when you have a concrete data model artifact to review—a DDL script, an ERD description, a set of table definitions, or a structured schema document. The prompt works best when you supply the model in a structured format (SQL DDL, JSON schema, or a detailed textual description of entities, attributes, relationships, and constraints) along with the intended access patterns, query profiles, and non-functional requirements. Do not use this prompt for reviewing code logic, API design, or infrastructure architecture; those require different review dimensions. Also avoid it when the model is too vague to evaluate—if you cannot describe the entities and their relationships, the review will produce generic advice rather than actionable findings.

The prompt is designed to be wired into a review workflow where a human facilitator runs it before the review meeting, distributes the agenda and questions to reviewers, and uses the summary template to capture outcomes. It is not a replacement for human judgment. The output includes risk areas that require human investigation (e.g., 'Verify whether this indexing strategy handles the pagination pattern on line 42'), not final verdicts. For high-stakes schema changes in production systems—especially those involving data migrations, PII, or financial records—always pair this prompt's output with a human approval gate and a rollback plan review before execution.

The prompt template below is designed to be dropped into an AI-assisted peer review harness. It takes a proposed data model, the team's review standards, and any known access patterns, then produces a structured review agenda, a set of probing questions organized by risk dimension, and a summary template for capturing decisions and action items. All placeholders use square brackets so you can safely substitute values in code without conflicting with JSON or template engines.

textCopy
You are facilitating a structured peer review of a proposed data model. Your role is to produce a review agenda, targeted probing questions, and a decision summary template. Do not approve or reject the model. Do not rewrite the schema. Your job is to help the review team examine the model thoroughly.

## INPUTS

### Proposed Data Model
[SCHEMA_DDL_OR_DESCRIPTION]

### Access Patterns and Query Profile
[ACCESS_PATTERNS]

### Review Standards and Policies
[REVIEW_STANDARDS]

### Known Constraints
[CONSTRAINTS]

### Risk Tolerance Level
[RISK_LEVEL: low | medium | high]

## OUTPUT SCHEMA

Return a JSON object with the following structure:

{
  "review_agenda": {
    "sections": [
      {
        "dimension": "performance | correctness | security | evolvability | operability",
        "priority": "high | medium | low",
        "focus_areas": ["string"],
        "time_allocation_minutes": number
      }
    ],
    "total_estimated_minutes": number
  },
  "probing_questions": [
    {
      "id": "string",
      "dimension": "performance | correctness | security | evolvability | operability",
      "question": "string",
      "context_why": "string explaining why this question matters",
      "expected_evidence": "what the team should point to when answering"
    }
  ],
  "risk_areas": [
    {
      "area": "string",
      "severity": "high | medium | low",
      "description": "string",
      "mitigation_discussion_points": ["string"]
    }
  ],
  "decision_summary_template": {
    "decisions_made": [
      {
        "topic": "string",
        "decision": "string placeholder",
        "rationale": "string placeholder",
        "alternatives_considered": ["string placeholder"],
        "action_items": ["string placeholder"]
      }
    ],
    "open_questions": ["string placeholder"],
    "follow_up_owner": "string placeholder",
    "next_review_date": "string placeholder"
  }
}

## CONSTRAINTS

- Cover all five dimensions: performance, correctness, security, evolvability, operability.
- Generate at least 3 probing questions per dimension.
- Flag at least 2 risk areas, even if the model appears sound.
- If [RISK_LEVEL] is "high," increase question depth and add rollback-planning questions.
- Do not invent access patterns. Use only what is provided in [ACCESS_PATTERNS].
- If [ACCESS_PATTERNS] is empty or insufficient, add a risk area noting "unknown access patterns" and generate questions that ask the team to provide them.
- The decision summary template must use placeholder strings, not pre-filled answers.

To adapt this template, replace each square-bracket placeholder with the actual input for your review session. The [SCHEMA_DDL_OR_DESCRIPTION] placeholder accepts raw DDL, an ERD description, or a structured schema document. The [ACCESS_PATTERNS] placeholder should include read and write patterns, expected query shapes, concurrency requirements, and any SLAs. If your organization has formal review standards, supply them in [REVIEW_STANDARDS]; otherwise, the prompt will still produce a useful review using its built-in dimension coverage. The [RISK_LEVEL] parameter controls review depth: set it to "high" for models backing financial, healthcare, or auth systems, and "low" for internal tools with limited blast radius.

Before wiring this into a production review pipeline, test the prompt against at least three known schemas with documented outcomes. Compare the generated probing questions against questions your senior reviewers would ask. If the prompt misses dimension coverage or generates questions that don't match your team's review culture, add a [EXAMPLES] placeholder containing one or two annotated review examples that demonstrate your expected depth and style. Avoid shipping this prompt without a human-in-the-loop step: the AI facilitates the review, but a senior engineer must still lead the session and capture the final decisions.

This prompt is designed to be the first step in a structured review pipeline, not a standalone chat interaction. The typical integration pattern is a webhook or API endpoint that receives a data model artifact (DDL, an ERD description, or a structured schema document) and returns a review agenda. The application layer should wrap the LLM call with pre-processing to validate the input artifact, post-processing to parse the structured output, and a persistence layer to store the review for later comparison against resolved action items.

Start by validating the input payload. The [DATA_MODEL_ARTIFACT] must be non-empty and should be checked for minimum complexity (e.g., at least one entity with attributes). If the input is raw DDL, run a lightweight SQL parser to confirm it is syntactically valid before sending it to the model. For the model call itself, use a model with strong structured output support and a low temperature setting (0.1–0.3) to ensure consistent JSON formatting. The prompt template expects a JSON output with review_agenda, probing_questions, risk_areas, and summary_template fields. Implement a JSON schema validator in your harness to confirm the response matches this contract. If validation fails, retry once with a repair prompt that includes the validation error; if it fails again, log the failure and escalate to a human reviewer rather than silently dropping the review.

Logging and traceability are critical because peer reviews feed into architecture decision records. Store the full prompt, the raw model response, the parsed output, and the validation result in an audit table. Attach a unique review_id and correlate it with the data model version or commit hash. For high-stakes schemas (production databases, PII-bearing tables, financial records), add a mandatory human approval step: the harness should publish the generated review to a review queue, require sign-off from at least one authorized reviewer, and only then mark the review as accepted. The summary_template field in the output is designed to be pre-populated into your team's decision log tool (e.g., a markdown file in a git repository or a Confluence page), so your harness should also handle that rendering step.

Avoid wiring this prompt directly into a CI/CD pipeline without a human-in-the-loop gate. A schema change PR can trigger the review generation automatically, but the output should be attached as a comment or checklist for the PR author and reviewers to work through, not used to auto-approve or auto-reject the change. The probing questions and risk areas are facilitation tools for human judgment, not pass/fail criteria. Finally, build an eval harness that periodically tests the prompt against a golden set of known data models with documented review expectations, checking that all four output sections are present, that risk areas cover performance, correctness, security, and evolvability dimensions, and that probing questions are specific to the model rather than generic.