---
title: "The nine flow stages — The Complete Flow Law"
source: "/reference/layr-002-complete-flow/flow-model"
description: "Nine stages carry a task from the moment the user arrives to the moment they move on."
---
# The nine flow stages

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.

## The Complete Flow Model

Nine stages carry a task from the moment the user arrives to the moment they move on. A feature is complete when every stage its path reaches has been designed.

Layr evaluates an interactive feature through nine dimensions:

```text
1. ENTRY
2. DISCOVERY
3. ACTION
4. INPUT
5. SYSTEM STATE
6. OUTCOME
7. FAILURE
8. RECOVERY
9. CONTINUATION
```

A context layer modifies them:

```text
permissions
responsive behavior
accessibility
empty state
first use
long content
large data
concurrency
offline/degraded network
destructive consequence
```

---

## 1. Entry

How does the user reach the feature?

Inspect:

- route,
- parent screen,
- deep link,
- list/card,
- search result,
- notification,
- command,
- contextual action.

Questions:

- Is the entry point discoverable?
- Does it match existing product patterns?
- Can the user return?
- Does a deep link work?
- What happens if the target no longer exists?

---

## 2. Discovery

Can the user understand what can be done?

Inspect:

- primary action,
- secondary actions,
- hierarchy,
- labels,
- disabled actions,
- destructive actions,
- menus,
- affordances.

The interface should expose behavior without overexplaining obvious controls.

A capability that technically exists but is practically undiscoverable is still an incomplete experience.

---

## 3. Action

What actions actually belong to this object or state?

The agent should derive them from:

1. explicit requirements,
2. existing routes,
3. existing APIs,
4. neighboring interfaces,
5. types/state machines,
6. tests,
7. established product conventions.

Do not create actions solely because they are common in the industry.

---

## 4. Input

What information must the user provide?

Inspect:

- required fields,
- optional fields,
- defaults,
- validation,
- server validation,
- formats,
- file limits,
- accessible labels,
- submit availability,
- draft preservation.

A failed request should not unnecessarily erase valid user work.

---

## 5. System State

What is the system doing after the action begins?

Common states:

- idle,
- loading,
- pending,
- uploading,
- processing,
- queued,
- retrying,
- synchronizing,
- completed.

The UI may need:

- duplicate-submit prevention,
- optimistic state,
- progress,
- cancellation,
- re-entry,
- stale-data handling.

The correct behavior depends on task duration and consequence.

---

## 6. Outcome

How does the user know the task worked?

Success might be communicated through:

- changed data,
- new object appearing,
- status update,
- route transition,
- inline feedback,
- persistent result,
- transient status.

Do not add a toast after every action by default.

The requirement is that the successful outcome is understandable.

---

## 7. Failure

What expected failures belong to the task?

Examples:

- validation,
- transport/network,
- permission,
- expired authentication,
- conflict,
- stale record,
- missing resource,
- rate limit,
- invalid file,
- external dependency,
- partial batch failure.

The UI should distinguish failures that require different user responses.

---

## 8. Recovery

What can the user do after failure or mistake?

Possible recovery:

- retry,
- edit,
- undo,
- restore,
- reconnect,
- refresh,
- request access,
- resolve conflict,
- retry failed subset,
- return safely.

An error message is not always a recovery path.

---

## 9. Continuation

What happens after completion?

Inspect:

- focus,
- route,
- selected item,
- scroll position,
- filters,
- refreshed data,
- next action,
- back navigation.

A mutation can succeed technically and still disorient the user.

---