# 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?


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://framework.aic.io/agile-delivery-playbook/operating-controls/commercial-ip-and-statement-of-work-alignment.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
