Project Definition Template

The 17 sections are grouped by the five-part model: Intent, Shape, Rules, Delivery, and Verification. Fill in each section, or jump to the full blank template at the bottom.

Intent

Sections 01–05 — what the product must achieve, for whom, and what success looks like.

01 Purpose

Define why this project exists.

Include:

problem being solved
desired outcome
business or user value
definition of success

## 01 Purpose

Project name:
Problem:
Desired outcome:
Business or user value:
Definition of success:

02 Users

Define who uses the system.

Include:

user types
responsibilities
permissions
goals

## 02 Users

### User type

Name:
Description:
Goals:
Responsibilities:
Permissions:

03 Behaviours

Define what users and the system do. Use clear behaviour statements.

Example:

A user can create or paste a text document.
The system validates the document content and size.
The system stores the document record.
The system shows save success or failure.

## 03 Behaviours

### Behaviour ID

Name:
User:
Trigger:
System behaviour:
Expected result:

04 Features

Define the features that support the behaviours. Each feature should map to one or more behaviours.

## 04 Features

### Feature ID

Name:
Description:
Linked behaviours:
Included:
Not included:

05 Success Criteria

Define what must be true for the project to be successful. Use measurable criteria where possible.

## 05 Success Criteria

### Criterion ID

Statement:
Measurement:
Target:
Linked behaviours or features:

Shape

Sections 06–12 — how the system is structured: constraints, context, building blocks, data, runtime, deployment.

06 Constraints

Define fixed limits.

Include:

technology constraints
regulatory constraints
budget constraints
delivery constraints
security constraints

## 06 Constraints

### Constraint ID

Type:
Statement:
Reason:
Impact:

07 System Context

Define the system boundary.

Include:

users
external systems
data sources
APIs
trust boundaries

## 07 System Context

System boundary:

Users:
External systems:
Data sources:
APIs:
Trust boundaries:

08 Solution Strategy

Define the chosen technical approach. Do not list every option — record the selected approach.

## 08 Solution Strategy

Selected approach:
Reason:
Main technical choices:
Trade-offs:
Rejected approaches:

09 Building Blocks

Define the major components of the system. Each building block should have one clear responsibility.

## 09 Building Blocks

### Building Block ID

Name:
Responsibility:
Inputs:
Outputs:
Depends on:
Used by:

10 Data and Interfaces

Define data structures, APIs, events, files, messages, and integration contracts.

## 10 Data and Interfaces

### Data object / Interface ID

Name:
Type:
Description:
Fields or contract:
Producer:
Consumer:
Validation rules:

11 Runtime Behaviour

Define important runtime flows step by step.

Example:

user submits request
frontend calls backend
backend validates request
backend updates database
response is returned

## 11 Runtime Behaviour

### Flow ID

Name:
Trigger:
Steps:

1.
2.
3.

Success result:
Failure result:

12 Deployment and Operations

Define where the system runs and how it is operated.

Include:

hosting
environments
configuration
secrets
monitoring
logging
support

## 12 Deployment and Operations

Environments:
Hosting:
Configuration:
Secrets management:
Monitoring:
Logging:
Support model:

Rules

Sections 13–15 — the control layer: standards, decisions, and delivery rules AI must follow.

13 Cross-Cutting Rules

Define rules that apply across the system.

Include:

authentication
authorization
validation
error handling
observability
security
privacy
performance
coding standards

## 13 Cross-Cutting Rules

### Rule ID

Area:
Rule:
Applies to:
Reason:
Verification:

14 Decisions

Record important decisions using decision records.

Include:

decision
status
reason
consequences

## 14 Decisions

### Decision ID

Title:
Status:
Decision:
Reason:
Consequences:
Date:

15 Delivery Rules

Define how this project delivers work.

Include:

delivery model
refinement rules
approval rules
AI usage rules
review rules
when AI must stop

## 15 Delivery Rules

Delivery model:
Refinement rules:
Approval rules:
AI usage rules:
Review rules:
AI must stop when:

Delivery

Section 16 — what will be implemented, in what order, and how each slice traces back.

16 Implementation Plan

Define what will be built and in what order.

Include:

milestones
implementation slices
dependencies
current priority
next slice

## 16 Implementation Plan

### Milestone ID

Name:
Goal:
Included slices:
Dependencies:
Status:

### Implementation Slice ID

Name:
Purpose:
Linked behaviours:
Linked features:
Linked building blocks:
Linked data and interfaces:
Linked rules:
Verification:
Status:

Verification

Section 17 — how work is accepted.

17 Verification

Define how work is accepted.

Include:

acceptance criteria
test strategy
review checklist
definition of done
manual checks
automated checks

## 17 Verification

Acceptance criteria:
Test strategy:
Manual checks:
Automated checks:
Review checklist:
Definition of done:

Copyable blank template

Copy the block below to start a new project definition. Fill each section in place.

# AIDD-17 Project Definition

## 01 Purpose

Project name:
Problem:
Desired outcome:
Business or user value:
Definition of success:

## 02 Users

### User type

Name:
Description:
Goals:
Responsibilities:
Permissions:

## 03 Behaviours

### Behaviour ID

Name:
User:
Trigger:
System behaviour:
Expected result:
Failure behaviour:

## 04 Features

### Feature ID

Name:
Description:
Linked behaviours:
Included:
Not included:

## 05 Success Criteria

### Criterion ID

Statement:
Measurement:
Target:
Linked behaviours or features:

## 06 Constraints

### Constraint ID

Type:
Statement:
Reason:
Impact:

## 07 System Context

System boundary:
Users:
External systems:
Data sources:
APIs:
Trust boundaries:

## 08 Solution Strategy

Selected approach:
Reason:
Main technical choices:
Trade-offs:
Rejected approaches:

## 09 Building Blocks

### Building Block ID

Name:
Responsibility:
Inputs:
Outputs:
Depends on:
Used by:

## 10 Data and Interfaces

### Data object / Interface ID

Name:
Type:
Description:
Fields or contract:
Producer:
Consumer:
Validation rules:

## 11 Runtime Behaviour

### Flow ID

Name:
Trigger:
Steps:

1.
2.
3.

Success result:
Failure result:

## 12 Deployment and Operations

Environments:
Hosting:
Configuration:
Secrets management:
Monitoring:
Logging:
Support model:

## 13 Cross-Cutting Rules

### Rule ID

Area:
Rule:
Applies to:
Reason:
Verification:

## 14 Decisions

### Decision ID

Title:
Status:
Decision:
Reason:
Consequences:
Date:

## 15 Delivery Rules

Delivery model:
Refinement rules:
Approval rules:
AI usage rules:
Review rules:
AI must stop when:

## 16 Implementation Plan

### Milestone ID

Name:
Goal:
Included slices:
Dependencies:
Status:

### Implementation Slice ID

Name:
Purpose:
Linked behaviours:
Linked features:
Linked building blocks:
Linked data and interfaces:
Linked rules:
Verification:
Status:

## 17 Verification

Acceptance criteria:
Test strategy:
Manual checks:
Automated checks:
Review checklist:
Definition of done: