---
title: "Scope and feature creep — The Complete Flow Law"
source: "/reference/layr-002-complete-flow/scope"
description: "Completing a task is not the same as inventing product scope. Three levels separate the work that belongs to the request from the work that belongs to a product decision."
---
# Scope and feature creep

Part of [LAYR-002 — The Complete Flow Law](/__layr/pages/reference/layr-002-complete-flow.md). The complete rule and agent contract live in the full Markdown representation.

## Completeness is not feature creep

Completing a task is not the same as inventing product scope. Three levels separate the work that belongs to the request from the work that belongs to a product decision.

This distinction is foundational.

Layr separates three levels.

## Level A — Interaction completeness

Behavior required to make an already-supported action correct.

Example:

```text
Delete
→ safety strategy
→ pending
→ success
→ failure
→ recovery
```

Usually implement.

---

## Level B — Product inference

Capabilities already established elsewhere.

Example:

The existing invoice detail screen already supports:

```text
Edit
Download
Delete
```

A new card may need to preserve those capabilities.

Reuse established behavior.

---

## Level C — New product scope

New capability or business rule.

Examples:

```text
Refund
Duplicate
WhatsApp
Reminder automation
AI summary
Recurring invoice conversion
```

Do not implement without explicit product evidence or approval.

---

## The implied-completeness test

Before adding behavior, ask:

1. Is this required for an existing action to work correctly?
2. Does the product already contain this behavior?
3. Is it supported by routes, APIs, types, tests, or established patterns?
4. Would omitting it leave the task broken, ambiguous, unsafe, or unrecoverable?
5. Would adding it create a new capability or business rule?

If #5 is yes, it is probably new product scope.

---