Skip to content

PATTERN Cited by 1 source

Automated design-compliance review

Definition

Automated design-compliance review is a pattern where an LLM-backed agent automatically retrieves relevant design documents (threat models, API contracts, privacy specs) at code-review time and evaluates whether the proposed code change aligns with the requirements documented therein. The agent reasons across documents — comparing implementation against intent — rather than analyzing code in isolation.

Structure

  1. Trigger: a code change (PR) is opened for review.
  2. Retrieval: the agent uses semantic search (via MCP or equivalent) to find design documents relevant to the code being changed.
  3. Reasoning: a foundational model examines both the requirements and the code together, identifying gaps where documented requirements are not reflected in implementation.
  4. Surfacing: findings are presented inline in the code review workflow, traceable to the specific requirement and source document.
  5. Disposition: most findings are advisory; blocking is reserved for confirmed gaps.

Why it works

  • Static analysis can't do this. It inspects code for known patterns but cannot compare code against documented intent — it doesn't know what was agreed upon.
  • Human cross-referencing doesn't scale. Reviewers won't reliably find and re-read design docs that were written months earlier and live in a separate system.
  • Semantic retrieval recovers invisible links. At Dropbox, 69% of design-to-code connections are only recoverable through semantic search (Source: sources/2026-06-12-dropbox-mcp-dash-design-to-code-security).

Design principles (from the Dropbox realization)

  • Validate before surfacing. Every finding must be checked against actual code before reaching a developer — false positives destroy trust faster than true positives build it.
  • Traceable to source. Every finding links back to the specific requirement and document so reviewers can verify reasoning.
  • Advisory by default. Escalation to blocking only for confirmed gaps between approved designs and implementation (see patterns/advisory-over-blocking).
  • Account for staleness. Requirements evolve; the system must not blindly apply outdated guidance.

Applicability beyond security

Domain Design document Compliance check
Security Threat model Controls implemented per requirements
Privacy Data classification spec Field not logged/exposed per spec
Platform API contract Interface changes compatible with contract
Compliance Regulatory requirements Data handling meets jurisdiction rules

Seen in

Last updated · 542 distilled / 1,571 read