Catalogue › Design Authority › architecture-conformance

Architecture conformance

Reviews, as a reviewer, whether an AI solution's design conforms to the organisation's reference architectures, mandatory tier controls and architecture standards, records approved deviations with owners and expiry, and classifies each finding as blocking or advisory with the fix. Use when a design claims to follow a reference pattern, when a solution deviates from standards, or when deviations across solutions suggest a reference needs changing.

Department

Design Authority

Lifecycle

Deliver, Assure, Improve

Maturity

builder, scaler, ai-enterprise

Risk tiers

1, 2, 3, 4

Platforms

m365-agents, copilot-studio, ai-foundry, power-platform, entra, azure

Editions

scale, enterprise

Reviewers

design-authority

Status

draft

Copilot Cowork

Design Authority plugin for Copilot Cowork, or this skill on its own: Download SKILL.md

Licence

CC BY 4.0, by Simon Foote

Purpose

Reference architectures and standards only reduce risk if solutions follow them, and only stay useful if justified deviations are recorded and fed back. This reviewer skill checks a solution's design against the references and mandatory controls that apply to its pattern and risk tier, records approved deviations with owners and expiry dates, and classifies each finding as blocking or advisory. Conformance reviews go wrong when they become box-ticking against a long checklist, when every deviation is refused even where the reference is wrong, and when deviations are approved informally and forgotten.

When to use

• A tier 1 or higher design claims to follow a reference architecture.
• A design departs from a mandatory control or architecture standard.
• A deviation needs approval, with an owner and expiry.
• Several solutions are deviating in the same way, suggesting the reference needs to change.
• An audit asks whether solutions conform to the organisation's AI architecture standards.

When not to use

• Writing or changing the reference architectures - use ai-architecture:ai-reference-architecture.
• Code-level engineering standards for pro-code work - use ai-engineering:ai-engineering-standards.
• Reviewing AI-generated code - use copilot-code:generated-code-review.
• Reviewing the platform choice - use design-authority:platform-fit-review.
• Reviewing security controls in depth - use security-privacy:connector-review and security-privacy:data-exposure-review.

Questions to ask first

1. Which reference architecture does the design follow, and which version?
2. Which mandatory controls apply at this risk tier?
3. Where does the design deviate, and what reason is given for each deviation?
4. Has the same deviation been seen in other solutions?

Required inputs

• The solution design pack, with the reference pattern it claims.
• The current reference architectures and their mandatory controls by tier, from ai-architecture:ai-reference-architecture.
• The register of approved deviations.
• Standards the organisation has adopted, if any, for AI management systems or risk frameworks.

If no reference exists for the solution's pattern, conformance is checked against mandatory tier controls only, and the absence is reported to the AI architecture function.

Decision framework

Classify every gap between design and reference.

Approved deviations record: the reference and control, the reason, the compensating control, the owner, the approver and the expiry or review date. Below tier 2, findings are advisory except where a mandatory tier 1 control is absent. Disagreement escalates to the accountable executive for written risk acceptance.

Practitioner approach

Identify the claimed reference and version, then read the design against it section by section. Start with the fixed decisions - identity pattern, data boundaries, environment zone, logging - because deviations there carry the most risk. Then check the mandatory controls for the tier, then the variation points.

For each gap, find out whether it is a deviation or a misunderstanding. Teams often believe they conform when they have misread the reference; a short conversation can resolve these without a formal finding, but record the clarification so the reference can be improved.

Treat justified deviations seriously. A reference cannot foresee every case, and a team that has thought carefully about why it must deviate is doing good architecture. Ask for the reason, the compensating control and the owner, and approve with an expiry date so the deviation is revisited. Record it in the deviations register.

Refuse unjustified deviations at the fixed decisions. A design that uses a shared service identity for writes where the reference requires user identity, without a compensating entitlement check, is blocking at tier 2 regardless of how convenient it is.

Look across solutions. When the same deviation recurs, the reference is probably wrong or out of date. Report the pattern to ai-architecture:ai-reference-architecture with the evidence, rather than continuing to approve deviations one by one.

Use standards proportionately. Where the organisation has adopted a management-system standard or a risk framework, check the controls it has chosen to apply, by reference to the organisation's own implementation, not by reproducing licensed text.

Record findings with the reference, control, gap, risk, fix and owner, and pass them to the consolidated design review.

Outputs

• A conformance section in the design-review-record: reference and version, controls checked, findings classified as blocking or advisory with fix and owner.
• Deviation register entries with reason, compensating control, owner, approver and expiry.
• A deviation pattern report to the AI architecture function when the same gap recurs.

Microsoft platform considerations

References depend on platform capabilities that change. When a gap arises because a reference relies on a capability that has changed, check the current source records (ms-copilot-studio-guidance, ms-copilot-studio-security-governance, ms-agents-extensibility) and treat it as a reference problem, not a team problem.

Adoption considerations

Teams follow references they understand. Use clarifications found in reviews to improve reference guidance, and offer pre-review conformance checks for teams new to a pattern.

Knowledge considerations

Check that the grounding design follows the reference's knowledge pattern and the grounding standards, linking to knowledge-management:knowledge-grounding-standards rather than re-assessing content.

Security and privacy considerations

Many mandatory controls are security controls. Share relevant findings with the security-privacy reviewers and record whether security has already assessed them, to avoid conflicting verdicts.

Responsible AI considerations

Where references include oversight and logging controls for uses affecting people, absence is blocking from tier 3 and shared with the responsible-ai reviewers.

Evaluation requirements

Check that evaluation follows the approach the reference sets for the tier, with evidence stored where the reference requires.

Value measures

At portfolio level, track the share of solutions conforming at first review, open deviations and those past expiry, and references changed as a result of deviation patterns. The design authority chair owns these, with a baseline from the first round of reviews.

Scale notes

Starter

Conformance is usually checked informally against one or two simple patterns, often a partner's. Record deviations even so.

Scale

Check every tier 2 design against the references, keep a deviations register with expiry, and report patterns quarterly.

Enterprise

Federate conformance checks for standard patterns, automate checks where designs are expressed as code or configuration, and report conformance and deviations across the estate.

Hand-offs

• To ai-architecture:ai-reference-architecture with deviation patterns and reference problems.
• Back to the delivery team with findings and approved deviations.
• To design-authority:ai-design-review for the consolidated verdict.

Reviewer gates

This skill is part of the design-authority gate, blocking from risk tier 2 for fixed decisions and mandatory controls, and advisory below. Security-related findings are shared with security-privacy. Disagreement escalates to the accountable executive for written risk acceptance.

Failure modes

• Conformance becomes a long checklist, and teams tick boxes without understanding the reference.
• Every deviation is refused, so teams hide them or build outside the gate.
• Deviations are approved informally, never expire and are forgotten.
• The same deviation is approved repeatedly, and the reference is never fixed.

Sources

references/sources.md in this skill lists the source records behind this skill, what each is authoritative for, how volatile it is and what you may do with it. Product availability, licensing, limits and preview status change often, so check the current source before stating them, and cite what you used.

Never

• Approve a deviation without a reason, compensating control, owner and expiry.
• Pass an unjustified change to a fixed decision such as identity or data boundary at tier 2 or above.
• Reproduce licensed standard text; refer to the organisation's own implementation.
• Keep approving the same deviation without reporting it to the reference owner.