Feature Drift Guardrails

The risk

AI can produce useful-looking work that goes beyond the defined project intent. In AIDD-17, this is treated as feature drift. Feature drift must be detected, reviewed, and either rejected or converted into an approved follow-up slice.

What feature drift means

Feature drift happens when implementation work creates behaviour, architecture, interfaces, data, process, or user experience that was not defined or approved.

Feature drift includes:

• adding product behaviour that is not linked to a defined behaviour or feature
• expanding a slice beyond its stated scope
• changing architecture without a decision record
• introducing new data structures or interfaces without definition
• adding automation, background work, notifications, permissions, or integrations that were not requested
• changing user-facing language or flows in a way that changes product intent
• implementing a future slice early

Feature drift can happen even when the code works and the tests pass.

Guardrail principle

AIDD-17 does not stop AI being useful. It makes AI operate inside defined boundaries.

The core rule is:

AI may propose additional work, but it must not silently implement additional work.

Required traceability

Every implementation slice should trace back to approved project definition items.

At minimum, a slice should link to:

• behaviours it implements
• features it supports
• relevant interfaces
• relevant data structures
• applicable rules
• verification criteria
• related decision records

If work cannot be traced back to the project definition, it is not automatically valid. It should be treated as one of the following:

• a missing definition
• a proposed follow-up slice
• an implementation mistake
• an unresolved question

Slice boundaries

Each implementation slice must define:

• what is in scope
• what is out of scope
• expected files or system areas
• assumptions
• stop conditions
• acceptance criteria

A slice should be small enough that reviewers can clearly identify whether AI stayed inside the boundary.

Good slice boundaries

A good slice does not only say what to build. It also says what not to build.

AI stop conditions

AI must stop and report when:

• required behaviour is undefined
• scope is ambiguous
• architecture conflicts with the requested implementation
• an interface or data structure is missing
• tests cannot be written from the available criteria
• out-of-scope files need to change
• security, privacy, or compliance impact is unclear
• the implementation would require inventing product behaviour

Stopping is the correct outcome when the definition is incomplete.

Review process

1. Confirm the implementation links back to the approved slice.
2. Check whether all changed files are expected.
3. Check whether new behaviour was added.
4. Check whether new architecture, data, or interfaces were introduced.
5. Check whether assumptions were reported.
6. Check whether unresolved questions were documented.
7. Decide whether any extra work should be rejected, removed, or turned into a follow-up slice.

Handling unexpected AI additions

Reject

Use this when the extra work is not wanted or conflicts with the project definition.

Remove the unapproved behaviour. Keep the implementation limited to the approved slice.

Defer

Use this when the extra work may be useful but is not part of the current slice.

Do not implement this now. Record it as a proposed follow-up slice.

Approve

Use this only when the extra work is intentionally accepted.

Update the project definition, decision records, implementation plan, and verification criteria before accepting the change.

Reviewer checklist

Use this checklist during AI output review:

• Does every change map to the assigned slice?
• Does every user-facing behaviour map to a defined behaviour or feature?
• Did AI add any extra routes, screens, fields, events, jobs, permissions, or integrations?
• Did AI change architecture without a decision record?
• Did AI introduce new data contracts without updating the project definition?
• Did AI modify unrelated files?
• Did AI report assumptions and unresolved questions?
• Did AI create or update tests only for approved behaviour?
• Are proposed future improvements separated from implemented work?

Output expected from AI

At the end of an implementation task, AI should return:

required-ai-output.txt

Summary of changes:

Files changed:

Tests added or changed:

Verification performed:

Assumptions made:

Unresolved questions:

Potential feature drift:

Suggested follow-up slices:

Acceptance rule

Accept only bounded work

A slice can be accepted when the implementation satisfies the defined behaviour, respects the defined architecture, stays inside scope, reports assumptions, passes verification, and avoids unapproved feature drift.