> For the complete documentation index, see [llms.txt](https://framework.aic.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://framework.aic.io/agile-delivery-playbook/operating-controls/commercial-ip-and-statement-of-work-alignment.md).

# Commercial, IP and Statement of Work Alignment

### Overview

Our agile process is designed to operate inside a controlled commercial model. Agile gives flexibility in how we solve problems. It does not remove the need for a clear Statement of Work, commercial authority, acceptance criteria or IP protection.

### Statement of Work Alignment

Every phase should be linked to a Statement of Work or other approved commercial authority.

The Statement of Work should define:

* phase
* objectives
* scope
* out of scope
* deliverables
* milestones
* acceptance criteria
* assumptions
* customer responsibilities
* dependencies
* team model
* governance cadence
* commercial model
* IP position
* security and data requirements

### Agile Scope Control

The backlog can change frequently. The authorised scope cannot change informally.

A backlog change may remain inside scope where it:

* supports the agreed objectives
* does not add material deliverables
* does not change acceptance criteria materially
* does not extend timeline or cost
* does not introduce new material risk
* does not change the IP or security position

A backlog change should go through change control where it affects:

* cost
* timeline
* deliverables
* acceptance
* security
* data
* IP
* supplier obligations
* material assumptions

### Milestone Alignment

Milestones should be connected to evidence.

A milestone should not simply say that a phase has progressed. It should identify what has been delivered, reviewed or accepted.

Examples:

* discovery findings accepted
* alpha prototype playback completed
* beta release deployed to private beta users
* live readiness evidence approved
* support model accepted

### Acceptance Criteria

Acceptance criteria should be agreed before delivery starts. They may be refined as learning emerges, but material changes must be approved.

Acceptance criteria should be:

* objective
* testable
* linked to deliverables
* capable of evidence
* commercially meaningful
* realistic for the phase

### IP Categories

We classify IP as:

* Background IP: pre-existing company assets, templates, methods, code, frameworks and know-how
* Foreground IP: IP created specifically during the project
* Customer IP: materials, data, documents and systems provided by the customer
* Third-party IP: externally owned components or services
* Open-source components: components governed by open-source licences

### IP Reuse Principles

* Reuse approved company assets before rebuilding.
* Do not transfer Background IP unless expressly agreed.
* Check licence terms before using third-party or open-source components.
* Do not contaminate reusable assets with customer confidential information.
* Record improvements that may be reusable.
* Confirm Foreground IP treatment in the contract or Statement of Work.

### Accelerator Use

Accelerators may include:

* discovery interview guides
* service blueprint templates
* backlog templates
* architecture patterns
* code scaffolds
* deployment pipelines
* test scripts
* security evidence packs
* acceptance criteria libraries
* governance templates

Accelerators should be used when they are relevant, current, secure, legally usable and appropriate to the customer environment.

### Commercial Health Checks

At each governance review, ask:

* Are we still inside the agreed Statement of Work?
* Are deliverables and acceptance criteria still valid?
* Are customer dependencies being met?
* Are changes being controlled?
* Are milestones and payment triggers supported by evidence?
* Is the IP position still clear?
* Are supplier outputs aligned to customer obligations?