Diagram-Claim-to-Specification Compliance Check Prompt

This prompt is designed for engineering leads, QA architects, and technical reviewers who need to verify that a system architecture diagram—whether a formal UML diagram, an informal whiteboard sketch, or a generated flowchart—faithfully represents a written specification. The core job is to detect missing components, incorrect connections, and label mismatches before a design review or implementation gate. It is not a general diagram-explanation tool, a code-generation prompt, or a replacement for human architectural judgment. Use it when you have a concrete specification document and a diagram artifact that must be reconciled.

The prompt expects two primary inputs: a [SPECIFICATION] containing the written description of the system architecture, and a [DIAGRAM_DESCRIPTION] that describes the visual artifact in structured text. If you are working with an image directly, you must first pass it through a vision-capable model to produce a textual description of components, connections, labels, and containment. The output is a structured compliance report with three sections: a component-presence check listing every specified component and whether it appears in the diagram, a connection-accuracy check comparing specified relationships against drawn edges, and a label-alignment score that flags terminology drift between the spec and the diagram. Each finding includes a severity level and a specific reference to the relevant spec section or diagram region.

Do not use this prompt when the specification is ambiguous, still in draft, or intentionally underspecified—the prompt will produce false positives by treating missing detail as non-compliance. It is also unsuitable for diagrams that use purely iconic or pictorial notation without textual labels, as the label-matching logic depends on extractable text. For regulated environments where a missed connection could have safety or compliance implications, always route the output through a human reviewer and maintain an audit trail of the prompt's findings alongside the reviewer's disposition. If the diagram format is informal—hand-drawn, photographed, or using non-standard notation—add a [NOTATION_GUIDE] input that maps visual conventions to spec terminology before running the check.

This prompt template is designed to be copied directly into your application or testing environment. It accepts a diagram description, a written specification, and a set of configurable constraints to produce a structured compliance report. The template uses square-bracket placeholders for all dynamic inputs, making it straightforward to wire into a prompt assembly pipeline or a manual review workflow. Before using it, ensure you have a reliable method for converting visual diagrams into a textual description—whether through a multimodal model, manual annotation, or a structured diagram-as-code format.

textCopy
You are a technical compliance analyst. Your task is to verify whether a described architecture diagram complies with a written specification.

## INPUT
### Diagram Description
[DIAGRAM_DESCRIPTION]

### Written Specification
[SPECIFICATION_TEXT]

## CONSTRAINTS
- [COMPLIANCE_RULES]
- Tolerance for informal notation: [NOTATION_TOLERANCE]
- Required confidence threshold for each finding: [CONFIDENCE_THRESHOLD]

## OUTPUT SCHEMA
Return a valid JSON object with the following structure:
{
  "components": [
    {
      "spec_component": "string (component name from specification)",
      "diagram_presence": "present | absent | implied",
      "diagram_label": "string or null",
      "label_alignment_score": 0.0-1.0,
      "notes": "string"
    }
  ],
  "connections": [
    {
      "spec_connection": "string (source -> target as described in spec)",
      "diagram_presence": "present | absent | implied | contradicted",
      "diagram_representation": "string or null",
      "accuracy_flag": "exact_match | direction_mismatch | protocol_mismatch | missing",
      "notes": "string"
    }
  ],
  "overall_compliance_score": 0.0-1.0,
  "critical_gaps": ["string"],
  "requires_human_review": true | false
}

## INSTRUCTIONS
1. Parse the specification to extract an exhaustive list of required components and their connections.
2. For each component, check if it appears in the diagram description. Account for synonyms, abbreviations, and informal labels. Do not penalize missing visual elements if the specification marks them as optional.
3. For each connection, verify the source, target, direction, and protocol or data type if specified. Flag any contradiction, even if a similar connection exists.
4. Score label alignment by comparing the diagram's label for a component against the specification's canonical term.
5. If the diagram uses informal notations (e.g., hand-drawn symbols, generic boxes), interpret them generously according to the tolerance level provided.
6. Set `requires_human_review` to `true` if any component is missing, any connection is contradicted, or the overall compliance score falls below the confidence threshold.
7. Do not invent components or connections not present in the specification.

To adapt this template, replace each square-bracket placeholder with values from your application context. [DIAGRAM_DESCRIPTION] should be a structured text representation of the diagram, not a raw image file. If you are using a multimodal model to generate this description upstream, validate its output for hallucinated components before passing it here. [COMPLIANCE_RULES] can include domain-specific requirements such as 'all databases must be behind a firewall' or 'no single point of failure is permitted.' The [NOTATION_TOLERANCE] field accepts values like 'strict' (only formal UML), 'moderate' (accepts common informal symbols), or 'lenient' (any reasonable interpretation). Always set [CONFIDENCE_THRESHOLD] to a value between 0.0 and 1.0 to gate the requires_human_review flag.

This prompt is designed for a single-turn verification task. It does not maintain state across multiple diagrams. For batch processing, wrap this template in an orchestration layer that handles rate limiting, retries on malformed JSON, and result aggregation. The output schema is intentionally flat to simplify parsing and downstream logging. If your compliance workflow requires audit-ready evidence, store the full prompt, the raw model response, and the parsed JSON together. For high-risk systems, always route outputs with requires_human_review: true to a qualified reviewer before accepting the compliance verdict.

This prompt is designed to be called as a single step within a larger compliance verification pipeline. It expects a pre-extracted set of claims from a diagram (produced by an upstream multimodal extraction step) and a clean text copy of the specification. The harness must enforce this contract: the prompt does not perform OCR, image segmentation, or PDF parsing itself. Those responsibilities belong to dedicated upstream tools. The harness should validate that both [DIAGRAM_CLAIMS] and [SPECIFICATION_TEXT] are non-empty and properly structured before making the model call. For high-stakes engineering compliance, always route outputs to a human review queue rather than treating the model's verdict as final.

The implementation should wrap the prompt in a function that accepts a structured DiagramClaimSet (an array of objects with claim_id, claim_text, source_element like 'Box A' or 'Arrow B->C', and claim_type such as 'component_presence', 'connection', or 'label') and a SpecificationDocument (with sections containing section_id and text). The function constructs the prompt by serializing these inputs into the [DIAGRAM_CLAIMS] and [SPECIFICATION_TEXT] placeholders. After the model responds, the harness must parse the JSON output and run a validation suite: check that every input claim_id appears in the output, that compliance_status is one of the allowed enum values (compliant, non_compliant, ambiguous, not_specified), and that any specification_reference points to a valid section_id from the input. Failed validations should trigger a retry with the validation errors appended to the [CONSTRAINTS] block, up to a maximum of two retries before escalating to human review.

Model choice matters here. Use a model with strong structured output capabilities and a large context window, as specifications can be lengthy. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are suitable candidates. Enable structured output mode (JSON mode or tool calling with a strict schema) rather than relying on free-text parsing. For logging, capture the full prompt, the raw model response, the parsed output, and the validation results in an immutable audit record. This is critical for compliance workflows where you must prove what the model was shown and how it arrived at its verdict. The harness should also compute and log a simple alignment coverage metric: the percentage of input claims that received a non-null specification_reference. A low coverage score may indicate a poorly written specification or a diagram that has drifted significantly from the documented requirements. Do not silently accept low coverage; flag it for review.

Common failure modes to instrument for include: the model hallucinating specification sections that don't exist (caught by the section ID validator), the model misinterpreting informal diagram notations like dashed lines or color coding (mitigated by ensuring the upstream claim extractor explicitly describes these conventions in the claim text), and the model failing to distinguish between a component being explicitly absent from the spec versus the spec being silent on the matter (enforced by the not_specified vs non_compliant distinction in the output schema). Your eval set should include diagram-spec pairs with known discrepancies, including missing components, incorrect connections, and terminology mismatches where the diagram uses a synonym for a spec term. Measure precision and recall on non_compliant flag detection, and pay special attention to false negatives where a real discrepancy is missed. If the prompt is part of a CI/CD pipeline for architecture reviews, gate the pipeline on a clean compliance report with zero non_compliant flags, but allow a human override for ambiguous items with documented justification.