Continuous
Design Audit

Every software organization has architectural intent. The team has made decisions, written principles, established boundaries, published ADRs. The question is whether those principles are enforced — or whether they are Confluence pages that everybody vaguely respects and nobody specifically checks.

A Continuous Design Audit is the enforcement mechanism. It runs at every PR, checks the code change against the approved architectural intent captured in the Architecture Ledger and Steering artifacts, and produces a result: the change is conformant, the change has pre-approved deviation, or the change needs architect review.

“Continuous” is the critical word. Not periodic. Not quarterly architecture reviews. Not when an architect happens to be on the PR. Continuous — every PR, every time, without an architect having to be present for every review to have teeth.

The CDA pipeline starts when a PR is opened against a connected repository. The diff is analyzed against the Architecture Ledger — which entities are being touched, which boundaries are being crossed, which interfaces are changing. This mapping determines which Lenses are applicable.

A Lens is the operationalization of a Steering principle as a set of binary yes/no questions that can be applied to a code diff. Each applicable Lens is evaluated with a focused LLM call: the diff, the Lens prompts, and the relevant Steering context.

Path B1 is the primary value for AI-generated code. The agent writes code that crosses a service boundary without an approved Change Intention. The CDA detects it. The PR is blocked. An architect reviews the specific finding — not the entire codebase. The architectural change does not merge silently.

Existing tools — SonarQube, ArchUnit, Structurizr Fit — operate on code structure. They can detect whether a service imports a forbidden package. They cannot detect whether a design decision violates an architectural principle that was never expressed in a package dependency rule.

The difference is the source of truth. Static analysis tools are bounded by what can be expressed as code rules. CDA is bounded by what has been expressed as Steering intent — which includes principles, constraints, rationale, and the context that makes a rule meaningful.

A Lens can operationalize "services should not coordinate directly — use the event bus" in a way that a dependency graph check cannot, because the principle involves not just what the code does but what the design intent was when the boundary was established. CDA does not ask "does this code pass?" It asks "does this design decision conform?"

CDA is the Conformance layer of the Design Continuity system. It only produces value when the preceding layers are in place:

• —Steering is populated: principles exist, Lenses are authored, they are approved and published.
• —Architecture Ledger is populated: the system model exists, entities are current.
• —Change Control is active: Design Reviews are run, CHI records are maintained.

CDA without Steering is a gate with no rules. CDA without a current Ledger produces false positives. This is not a limitation — it is the architecture. The three layers are a system, not a feature menu.

A Continuous Design Audit is not a standalone tool. It is a CI/CD gate — specifically, the gate that every pipeline is missing. Every CI/CD pipeline checks code quality. None, by default, check design intent. The CDA is the gate that changes that.

When integrated into your CI/CD pipeline, the CDA runs on every PR open event — before code review, before merge. The result is one of three states: conformant (PR proceeds normally), approved deviation (PR has an approved Change Intention that covers the drift — proceeds with record), or unplanned drift (PR is blocked, a CHI is auto-drafted, and the architect is notified of the specific finding).

This is what makes an engineering organization AI-ready. Not prompt engineering, not AI code review tools, not additional test coverage. An AI agent generates code with no memory of architectural intent. The CDA gate is the enforcement layer that was missing before the code was reviewed by any human.