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

# Contract lifecycle

> Handle proposal, approval, signing, failure, obsoletion, and deletion states

## States

| State         | Meaning                                                         | Normal next states            |
| ------------- | --------------------------------------------------------------- | ----------------------------- |
| `Proposed`    | Awaiting Trust Provider review                                  | Approved, Rejected            |
| `Rejected`    | Incomplete, inconsistent, or faulty                             | Proposed after creator update |
| `Approved`    | Reviewed; can act as a template or begin signing                | BeingSigned                   |
| `BeingSigned` | At least one signature exists but required roles are incomplete | Signed, Failed                |
| `Signed`      | All required role counts are satisfied; legally binding         | Failed, Obsoleted             |
| `Failed`      | Obligations failed or provider marked it failed                 | Terminal by policy            |
| `Obsoleted`   | Explicitly superseded/retired                                   | Terminal                      |
| `Deleted`     | Deleted by owner/provider under allowed rules                   | Terminal                      |

The server owns lifecycle enforcement. A client must treat a successful API response and the returned state as authoritative rather than updating local state optimistically.

## Typical flow

```mermaid theme={null}
stateDiagram-v2
  [*] --> Proposed
  Proposed --> Rejected: review fails
  Rejected --> Proposed: creator updates
  Proposed --> Approved: review succeeds
  Approved --> BeingSigned: first valid signature
  BeingSigned --> Signed: required roles complete
  BeingSigned --> Failed
  Signed --> Failed
  Approved --> Obsoleted
  Signed --> Obsoleted
  Proposed --> Deleted
  Rejected --> Deleted
```

## Event handling

Persist the contract ID, state, update timestamp, and last processed event ID. Notifications can be duplicated or arrive after a reconnect, so handlers must be idempotent and should re-fetch the contract before taking an irreversible action.

## Visibility

| Visibility         | Retrieval/search behavior                           |
| ------------------ | --------------------------------------------------- |
| `CreatorAndParts`  | Creator and named parts only                        |
| `DomainAndParts`   | Creator, parts, and accounts on the provider domain |
| `Public`           | Anyone with the ID can retrieve; not searchable     |
| `PublicSearchable` | Public retrieval and search                         |

Visibility is not a substitute for parameter protection. Do not put secrets in a public contract.