> ## Documentation Index
> Fetch the complete documentation index at: https://docs.solya.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Plan lifecycle & approvals

> The status lifecycle, business-rule gating, approval workflow, and audit trail shared by every plan type.

This page describes the mechanics common to **all** plan types. The per-type pages then
only cover what's specific to them.

## Plan and item statuses

A plan moves through a **status lifecycle**. The exact statuses depend on the type, but
most in-season plans follow:

```
Draft → Validated → (Sent → Received) → Closed
```

```mermaid theme={null}
stateDiagram-v2
  [*] --> Draft
  Draft --> Validated
  Validated --> Sent
  Sent --> Received
  Received --> Closed
  Closed --> [*]
```

Within a plan, each **item** carries its own status:

| Item status         | Meaning                                      |
| ------------------- | -------------------------------------------- |
| **To review**       | Newly added, awaiting validation.            |
| **Ready for order** | Validated and counted toward the plan total. |

A plan can be validated once its items are ready; the precise transitions (and which
are reversible) are listed on each plan-type page.

## Business-rule gating

When you **add an item** or **change a plan's status**, Solya evaluates the
[business rules](/en/intelligence-layer/business-center) from the plan's ruleset at
that moment. Each rule can:

<CardGroup cols={3}>
  <Card title="Block" icon="ban">
    Stops the action — the item can't be added or the plan can't be validated.
  </Card>

  <Card title="Warn" icon="triangle-exclamation">
    Lets the action proceed but surfaces a warning.
  </Card>

  <Card title="Log" icon="file-lines">
    Records that the rule fired, with no interruption.
  </Card>
</CardGroup>

Typical guards include budget (OTB) caps, plan-value limits, capacity per shop, size
curves, supplier constraints (MOQ / pack multiples), and markdown calendar windows.

## Approval workflow

Some plan types route through approval when a plan's value exceeds a configured
threshold (set via **approval policies** in the intelligence layer).

<Steps>
  <Step title="You try to validate / change status">
    If the plan value is over the threshold, validation is intercepted instead of
    proceeding.
  </Step>

  <Step title="An approval request is created">
    A **Pending** approval is recorded, snapshotting the plan value and the threshold.
    You can add a justification.
  </Step>

  <Step title="An approver decides">
    A user with the *Plan approver* permission **Approves** or **Rejects** the request
    (with a reason) from the approvals queue.
  </Step>

  <Step title="The plan proceeds or is sent back">
    On approval the status change goes through; on rejection you edit the plan and try
    again.
  </Step>
</Steps>

An approval can also become **Expired** automatically if the plan changes after the
request was made (so a stale approval never applies to a different plan).

Which types have an approval gate:

| Plan                                                    | Approval gate |
| ------------------------------------------------------- | ------------- |
| Restock, Pre-season, Supplier return, Supplier exchange | Yes           |
| Rebalance, Markdown                                     | No            |

## Activity & audit trail

Every plan records an immutable **activity log** — visible on the plan's *Activity* tab.
It captures plan lifecycle changes, item add/update/remove, item status changes, and the
full approval lifecycle. Each entry records **who** (a user, a workflow, an AI scenario
generator, or an API token), **when**, an optional **reason**, and the **rules** that
applied. Labels (names of variants, shops, users…) are resolved when you read the log so
they stay current.

<Note>
  Items added by AI recommendations or workflows are tagged with their **attribution**
  (manual vs decision-vector vs workflow), so you can always tell how a line got there.
</Note>