# status values and exit codes

## envelope status

| status | process exit code | meaning |
| --- | --- | --- |
| `ok` | `0` | request succeeded |
| `failed` | `1` | execution or internal failure |
| `invalid` | `2` | invalid arguments or configuration |
| `conflict` | `3` | required permission is not held |
| `blocked` | `4` | a valid request cannot proceed under current conditions |
| `waiting` | `5` | accepted Operation has not resolved within the wait |

`waiting` is not evidence of failure. Follow the returned Operation. Envelope status describes the command result; it is separate from lifecycle and observation fields.

## session state

| value | meaning |
| --- | --- |
| `provisioning` | start or resume is preparing resources / Services |
| `active` | Session started |
| `suspending` | stop work is proceeding toward suspend |
| `suspended` | Services stopped, ports / Claims retained |
| `ending` | stop work is proceeding toward end |
| `ended` | lifecycle finished; retained data may remain |
| `failed` | Session start could not complete |

## service state

`pending`, `starting`, `ready`, `failed`, `stopped`, `unknown` describe the ServiceAllocation. `unknown` preserves missing evidence rather than declaring a process stopped. Run evidence can also be `succeeded` for a completed named command; named command terminal outcomes are `succeeded`, `failed`, `unknown`.

## operation state

`accepted`, `running`, `succeeded`, `failed`, `outcome_unknown`, `cancelled` describe the durable request. `outcome_unknown` does not authorize automatic replay. A cancelled request does not erase the target Run's execution history.

## other observations

Rule match results are `match`, `no_match`, `unknown`; unknown conservatively activates the Rule. `liveness.stale` is a boolean independent of lifecycle and ownership. Resource `applied_schema: unknown` and `seed_baseline: false` prevent interpreting unverified data as a reusable seed baseline.