Skip to content
AIDD-17

The AIDD-17 Structure

AIDD-17 is organised around five questions:

  1. What are we trying to achieve?
  2. What shape does the system take?
  3. What rules must be followed?
  4. What are we implementing next?
  5. How do we know it is correct?

These five questions form the high-level model. They expand into seventeen sections that describe a software project from idea to implementation.

The process can vary by project. The definitions must be explicit.

The five-part model

Section titled “The five-part model”

AIDD-17 brings together product thinking, software architecture, delivery rules, implementation planning, and verification into one coherent structure.

It exists to give software teams:

  • control — over scope, decisions, and AI behaviour
  • agility — to adapt without losing definition
  • visibility — into intent, structure, and progress

Each project can define its own way of working. Once defined, the rules must be explicit so AI does not drift, guess, or expand scope.

1. Intent

Section titled “1. Intent”

Intent defines what the product must achieve. It is the product-owner side of the document.

It answers:

  • why the project exists
  • who it is for
  • what users need to do
  • what behaviours the system must support
  • what success looks like

Intent prevents AI from treating the project as a vague coding task.

Sections:

  1. Purpose
  2. Users
  3. Behaviours
  4. Features
  5. Success Criteria

2. Shape

Section titled “2. Shape”

Shape defines how the system is structured. It is the architecture side of the document.

It answers:

  • what constraints apply
  • what systems are involved
  • what solution approach is being used
  • what building blocks make up the system
  • what data and interfaces exist
  • how the system behaves at runtime
  • where and how the system operates

Shape gives AI the system map before it changes the system.

Sections:

  1. Constraints
  2. System Context
  3. Solution Strategy
  4. Building Blocks
  5. Data and Interfaces
  6. Runtime Behaviour
  7. Deployment and Operations

3. Rules

Section titled “3. Rules”

Rules define what must be followed. This is the control layer of AIDD-17.

It answers:

  • what standards apply across the system
  • what decisions have already been made
  • how delivery works for this project
  • what AI is allowed to do
  • when AI must stop and ask for clarification
  • what must not be changed without human approval

AIDD-17 does not prescribe a universal process. It gives each project a place to define its own rules clearly.

Sections:

  1. Cross-Cutting Rules
  2. Decisions
  3. Delivery Rules

4. Delivery

Section titled “4. Delivery”

Delivery defines what will be implemented. It connects the implementation plan back to the product and architecture.

It answers:

  • what will be built
  • in what order
  • what each implementation slice delivers
  • which behaviours, features, architecture sections, and interfaces each slice maps to
  • what AI should work on next

Delivery is where AIDD-17 can reduce the need for disconnected tickets. Each implementation slice should be traceable back to the project definition.

Section:

  1. Implementation Plan

5. Verification

Section titled “5. Verification”

Verification defines how the work is accepted.

It answers:

  • what must be tested
  • what acceptance criteria apply
  • what review is required
  • what “done” means
  • how the team proves the work is correct

AI-generated output is not complete just because code has been produced. It is complete when it satisfies the verification rules.

Section:

  1. Verification

The 17 sections at a glance

Section titled “The 17 sections at a glance”
AIDD-17
├── Intent
│   ├── 01 Purpose
│   ├── 02 Users
│   ├── 03 Behaviours
│   ├── 04 Features
│   └── 05 Success Criteria
│
├── Shape
│   ├── 06 Constraints
│   ├── 07 System Context
│   ├── 08 Solution Strategy
│   ├── 09 Building Blocks
│   ├── 10 Data and Interfaces
│   ├── 11 Runtime Behaviour
│   └── 12 Deployment and Operations
│
├── Rules
│   ├── 13 Cross-Cutting Rules
│   ├── 14 Decisions
│   └── 15 Delivery Rules
│
├── Delivery
│   └── 16 Implementation Plan
│
└── Verification
    └── 17 Verification

Who uses each part

Section titled “Who uses each part”

Product owners

Use Intent to define what matters.

Architects

Use Shape and Rules to define how the system works and what constraints apply.

Engineers

Use Delivery and Verification to implement and prove the work.

AI

Uses the complete structure as context so it can assist without inventing missing information.

Summary

Section titled “Summary”

AIDD-17 brings the project into one visible structure:

  • Intent defines what should be built.
  • Shape defines how the system is organised.
  • Rules define what must be followed.
  • Delivery defines what will be implemented.
  • Verification defines how the work is accepted.

Together, these parts give product owners, architects, engineers, and AI a shared project definition for rapid software delivery without losing control.