Catalogue › Design Authority › ai-design-review

AI design review

Runs the formal design authority gate for an AI solution - checking the design pack is complete, applying the necessity, platform fit, conformance and supportability lenses proportionately, and recording every finding as blocking or advisory with a fix and owner and a single verdict. Use when a tier 2 or higher solution finishes design and before build commits, when a partner's design needs independent review, or when a design changed materially.

Department

Design Authority

Lifecycle

Deliver, Assure

Maturity

builder, scaler, ai-enterprise

Risk tiers

2, 3, 4

Platforms

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

Editions

starter, 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

The design gate is the cheapest point to change an AI solution: the decisions are made but little has been built. This reviewer skill runs that gate. It checks that the design pack is complete, applies the design authority's lenses - necessity, platform fit, conformance and supportability - in proportion to the risk tier, and records every finding as blocking or advisory with a specific fix and owner. Design reviews go wrong when they become presentations rather than reviews of evidence, when every finding is treated as equally serious, and when a blocking issue is waved through to protect a date.

When to use

• A solution at risk tier 2 or above has finished design and is about to commit to build.
• A partner or supplier has delivered a design that the organisation must accept.
• A live solution's design has changed materially and needs a fresh gate.
• A pilot is about to become a supported service and was never formally reviewed.
• Programme stage gates require design authority sign-off.

When not to use

• Challenging whether AI is needed at all, in depth - use design-authority:ai-necessity-challenge.
• Reviewing the platform choice in depth - use design-authority:platform-fit-review.
• Checking conformance to reference architectures and standards in depth - use design-authority:architecture-conformance.
• Reviewing ownership and support in depth - use design-authority:supportability-review.
• Running the release gate for an agent - use m365-agents:agent-release-readiness.
• Reviewing security, identity and data exposure - use security-privacy:data-exposure-review and security-privacy:connector-review.

Questions to ask first

1. What is the solution's risk tier, and has it been confirmed since the design took shape?
2. Is the design pack complete enough to review, or does it need to go back before the review starts?
3. Which lenses does this tier and design need in depth, and which in summary?
4. Who is the accountable business owner, and who can accept residual risk if there is disagreement?

Required inputs

• The design pack: solution or agent brief, suitability decision, risk classification, architecture decision records, non-functional requirements, identity map, interface catalogue, grounding design, placement in the topology, evaluation approach and support model.
• The reference architectures and standards in force.
• Findings already raised by security-privacy and other reviewers, if available.

A missing input is itself a finding. From tier 2, a missing identity map, grounding design or evaluation approach is blocking until supplied; never infer the missing design from conversation.

Decision framework

Apply each lens and classify every finding. From tier 2 a blocking finding stops the gate; below tier 2 the review is advisory unless risk classification is wrong.

Verdicts: approved, approved with advisory findings, not approved - blocking findings, or returned - incomplete. Disagreement with a blocking finding escalates to the accountable executive for written risk acceptance.

Practitioner approach

Check completeness before scheduling the review. Ask for the design pack a few days ahead and read it. If core artefacts are missing, return the pack with a list rather than holding a meeting that can only discover the gaps. Reviewers' time is best spent on judgement, not on reconstructing a design.

Confirm the risk tier. Designs evolve, and a solution classified as tier 2 at intake may now act in systems or reach customers. If the tier has changed, the review depth and the other gates change with it; send the case back to opportunity-management:risk-classification first.

Decide the depth of each lens. A tier 2 knowledge agent built on a reference pattern may need only a summary check on platform fit and conformance, with depth on supportability. A tier 3 agent with write actions in a line-of-business system needs every lens in depth. Use the specialist design authority skills for the lenses that need depth, and record which were applied in summary.

Review evidence, not slides. Each finding cites the artefact and section it concerns, the risk or standard behind it, the specific fix and the owner. "Identity unclear" is not a finding; "The interface catalogue shows ticket creation through the maker's connection; switch to user authentication or a scoped service identity with an entitlement check" is.

Classify honestly. Blocking findings are those that would make the solution unsafe, unsupportable or non-conformant in a way the organisation has not accepted. Advisory findings improve the solution but do not stop it. Inflating advisory issues to blocking damages trust in the gate as much as waving blocking issues through.

Consolidate findings from other reviewers where they are available, so the delivery team sees one picture. Do not re-review security or evaluation; record their status and any dependencies.

Record the verdict on the design review record, agree fixes and dates, and close blocking findings only on evidence. Where the business owner disagrees with a blocking finding, escalate to the accountable executive; their written acceptance of the risk is recorded, and the finding stays on the record.

Outputs

• A design review record on the design-review-record template: scope, tier, lenses applied and depth, findings classified as blocking or advisory with risk, fix, owner and date, verdict and sign-off.
• A returned-pack note listing missing artefacts, where the pack is incomplete.
• Any written risk acceptance from the accountable executive.

Microsoft platform considerations

Platform capabilities that a design relies on, such as authentication options, evaluation tooling, ALM and channels, change often. Reviewers check that the design cites current source records (ms-agents-compare, ms-agents-extensibility, ms-copilot-studio-guidance, ms-foundry-models) for anything volatile, and raise a finding where it relies on memory.

Adoption considerations

The gate is part of the delivery experience. Publish what the pack must contain and how long review takes, and run pre-review clinics for first-time teams so the gate improves designs rather than surprising teams.

Knowledge considerations

Check that the grounding design names owned, ready sources and that knowledge readiness is evidenced through m365-agents:knowledge-source-readiness or equivalent. Missing knowledge owners for a tier 2 solution are blocking.

Security and privacy considerations

The security-privacy review is separate and blocking from tier 2. The design review records its status and any dependencies between security fixes and design changes, without repeating it.

Responsible AI considerations

From tier 3, the responsible-ai review applies. Record its status, and treat a design that lacks the oversight it requires as blocking at the design gate as well.

Evaluation requirements

Check that the evaluation approach and thresholds match the tier and the non-functional requirements, and that evaluation-quality has agreed them. An unevaluable design is blocking from tier 2.

Value measures

At portfolio level, track designs approved first time, blocking findings per review by lens, time from pack submission to verdict and incidents later traced to issues the review missed. The design authority chair owns these measures, with a baseline from the first quarter of reviews.

Scale notes

Starter

A design review can be a single session with the AI lead, a security contact and the business owner, recorded on the template. Use a partner's architect for tier 3 and 4 designs.

Scale

Run a regular design authority forum with published pack requirements, specialist lenses applied as needed and a findings log across reviews.

Enterprise

Federate tier 2 reviews against reference patterns to business-unit design authorities, with the central authority reviewing novel designs and tier 3 and 4 solutions, and analyse findings across the estate to improve references.

Hand-offs

• To design-authority:ai-necessity-challenge, design-authority:platform-fit-review, design-authority:architecture-conformance and design-authority:supportability-review for in-depth lenses.
• Back to ai-architecture:platform-selection and the build departments with findings to fix.
• To m365-agents:agent-release-readiness or the release policy with the verdict.

Reviewer gates

This skill is the design-authority gate. It is blocking from risk tier 2 and advisory below it. It runs alongside the security-privacy gate and, from tier 3, the responsible-ai gate. Blocking findings are not traded against dates; disagreement escalates to the accountable executive for written risk acceptance.

Failure modes

• The review is a presentation, and nobody reads the artefacts that would reveal the problems.
• Every finding is classified as blocking, teams learn to ignore the gate, and genuinely serious issues are lost.
• A launch date overrides a blocking finding without written risk acceptance.
• An incomplete pack is reviewed anyway, and the gaps are filled with assumptions.

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

• Trade a blocking finding against a release date.
• Approve a tier 2 or higher design with a missing identity map, grounding design or evaluation approach.
• Record a finding without the risk or standard behind it, the fix and an owner.
• Repeat another reviewer department's review instead of recording its status.