> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://tieback.io/docs/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://tieback.io/docs/_mcp/server.

# Lifecycle States

> The three lifecycle states of a Digital Product Passport in tieback, how transitions work, and what each state means for public visibility today.

Every Digital Product Passport in **tie*back*** has a lifecycle state that determines its visibility, editability, and available governance actions.

## States

| State         | Label in UI   | Visibility                | Governance actions available |
| ------------- | ------------- | ------------------------- | ---------------------------- |
| `unpublished` | **Draft**     | Brand team only           | Publish                      |
| `published`   | **Published** | Public (via scan or link) | Revoke, Break-Glass          |
| `revoked`     | **Revoked**   | No longer publicly served | Break-Glass only             |

## State Transitions

Passports follow a forward-only progression:

```
Draft → Published → Revoked
```

| Transition  | Description                                                                                                                                                                                                                                          |
| ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Publish** | Makes the passport publicly accessible. The resolver begins serving this passport when consumers scan the product. A publication audit stamp is recorded, linking the passport to the active publication/template version at the time of publishing. |
| **Revoke**  | Removes the passport from public access. The passport is no longer served by the resolver. Revocation applies to the digital passport object only; it does not cascade to physical carriers, unit identity, or token validity.                       |

Transitions are irreversible: a published passport cannot be returned to Draft, and a revoked passport cannot be republished.

### Who Can Transition

Lifecycle transitions require administrator-level permissions and are validated server-side via the `transition_passport_lifecycle` RPC, which enforces role checks and valid state progression.

## Initial State

A passport's initial state is determined at **mint time**. When a mint job completes, the resulting passport records are created in the `unpublished` (Draft) state.

## Publication Audit Stamp

When a passport is published, **tie*back*** resolves the currently active publication through the passport assignment hierarchy and stamps that publication ID into the passport record. This creates a permanent audit record of which template/content version was in effect at the moment of publication.

This audit stamp is separate from the live resolver routing, which continues to use the dynamic assignment hierarchy to determine which passport to serve.

## Revocation Scope

Revocation is strictly scoped to the digital passport object:

* the passport is no longer served by the resolver
* the passport record and its full history are retained
* physical carriers (QR codes, NFC tags, RFID) are unaffected
* mint unit identity and token validity are unaffected
* Break-Glass amendments can still be applied to revoked passports

## Related Docs

* [Passport Operations](/passports/passport-operations)
* [Break-Glass Amendments](/passports/controlled-update-break-glass)
* [Publication Lifecycle](/passports/publication-lifecycle)
* [Brand Setup & Readiness](/passports/brand-setup-readiness)