Core Principles

1. One project definition

Product intent, architecture, delivery rules, implementation planning, and verification should not live in disconnected places. AIDD-17 brings them into one coherent structure so the project definition becomes the common reference point for humans and AI.

2. Explicit over assumed

AI cannot safely follow rules that are only implied. If something matters, write it down:

if a project has a delivery process, define it
if a component has a responsibility, define it
if something is out of scope, define it
if a decision has been made, record it

3. Traceability over disconnected tickets

Implementation work should map back to the project definition. A slice of work should be traceable to product purpose, users, behaviours, features, architecture, data and interfaces, rules, and verification.

This prevents implementation from becoming detached from intent.

4. AI assists, humans own

AI can assist with analysis, planning, coding, testing, documentation, and review. Humans remain responsible for product direction, architecture, delivery choices, quality, and acceptance.

AI should work inside defined boundaries — it should not invent product direction, architecture, scope, process, or the meaning of done.

5. Delivery rules are 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 rules. Once defined, those rules must be clear enough for AI to follow without guessing.

6. Verification defines done

Verification connects implementation back to the project definition. It should include acceptance criteria, tests, review checks, and any project-specific definition of done.

Summary

AIDD-17 exists to provide control, agility, and visibility:

Control comes from explicit boundaries.
Agility comes from clear implementation slices.
Visibility comes from connecting product, architecture, delivery, and verification in one structure.