The AIDD-17 Process

Core idea

AIDD-17 brings together product intent, software architecture, delivery rules, implementation planning, and verification. The process connects those parts into a loop:

Define → Design → Slice → Implement → Verify → Update → Repeat

This loop is what prevents AI-assisted development from drifting.

1. Define

The project begins with intent. Define:

purpose
users
behaviours
features
success criteria
constraints

This gives the project direction. AI cannot safely build the right thing if the intent is undefined.

2. Design

The architecture defines the shape of the system. Define:

system context
solution strategy
building blocks
data and interfaces
runtime behaviour
deployment and operations
cross-cutting rules
decisions

This gives the project structure. AI cannot safely change a system without understanding its shape.

3. Slice

Implementation work is split into slices. A slice is a small unit of work that maps back to the project definition. Each slice should define:

what it delivers
which behaviours it supports
which features it contributes to
which modules it touches
which interfaces it depends on
what is in scope
what is out of scope
how it will be verified

This gives the project control. AI should not be asked to build vague work.

4. Implement

AI, engineers, or both implement the approved slice. Implementation is constrained by the project definition, the architecture, the delivery rules, the implementation slice, and the verification criteria.

AI may assist with coding, tests, documentation, analysis, and review. AI must not invent product direction, architecture, scope, or process.

5. Verify

The implementation is reviewed against the project definition. Verification checks:

product behaviour
architecture fit
scope control
rules and decisions
tests
security
data handling
documentation updates

6. Update

Accepted changes may update the project definition. Update the relevant sections when implementation changes behaviour, architecture, interfaces, data, decisions, delivery rules, verification criteria, or the implementation plan.

The document is not a static artefact — it is the current definition of the project.

The full delivery loop

The six steps above are the day-to-day rhythm of the process. The Delivery Loop page shows how those steps connect into a single repeating cycle from project definition through to accepted change and back again.

Structure and process

The structure provides visibility. The process provides movement. AIDD-17 needs both — without structure, the process becomes guesswork; without process, the structure becomes documentation that nobody uses.

Process is project-specific

AIDD-17 does not prescribe Scrum, Kanban, Shape Up, one-day cycles, stage gates, or any other delivery method. Each project defines its own delivery process. Once defined, the process must be explicit enough for AI to follow without guessing.