> 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.

# Break-Glass Amendments

> Correct published Digital Product Passport (DPP) data with break-glass governance: immutable passport snapshots, governed field eligibility, and a complete amendment audit trail.

A published Digital Product Passport (DPP) is an immutable snapshot: the data a consumer, retailer or regulator scans today is exactly the data that was frozen at issuance. That permanence is the point, and real operations still need a way to correct a mistyped figure or a superseded compliance value. **tie*back*** answers that with a single, governed mechanism: **break-glass amendments**.

Break-glass gives you passport data correction without ever rewriting history. The frozen snapshot stays untouched, the correction is layered on top, and every change is written to an append-only ledger. Data governance for product passports, designed to support ESPR-style and GS1 Digital Link expectations, comes from the architecture rather than from process discipline.

The former controlled-update mechanism has been retired and consolidated into break-glass. There is now one amendment path, one permission model, and one audit trail to review.

## How Break-Glass Works

#### Select the passport

Choose a published or revoked passport. Legacy passports minted before the governed freeze are
not amendable, and the interface says so up front.

#### Load eligible fields

The field picker is populated from governance data, so only genuinely amendable fields appear.

#### Enter the correction

Choose the field, supply the new value with a type-aware input, and select a governed reason.

#### Submit

The amendment is layered over the immutable snapshot, a break-glass ledger entry is written, and
the passport's **Last updated** value moves to the time of that amendment.

## What Can Be Amended

Field eligibility is governed data, never a hardcoded list. A field is amendable when all three conditions hold:

| Condition                 | Meaning                                                            |
| ------------------------- | ------------------------------------------------------------------ |
| **Live-applicable**       | The field applies to the product under the current field catalogue |
| **Frozen at mint**        | The field was captured in the passport's governed snapshot         |
| **Break-glass policy on** | The field definition enables break-glass amendment                 |

Corrections without chaos: the eligible-field picker reflects exactly this rule, so what you can change is always what governance says you may change.

* The **HS / commodity code** is amendable.
* **Economic-operator fields** are amended by selecting a different existing operator record, never by free-typing operator details, so the operator registry stays the single source of truth.

## What Cannot Be Amended

* **Unique product identifiers**: GTIN/UPC and SKU / unique product identifier are never amendable. Passport integrity by design: an incorrect identifier is not a typo but a different product, so the passport is **revoked and reissued** rather than edited.
* **Legacy passports**: passports minted before the governed freeze are not pointered to governed data and cannot be amended. The UI refuses up front, and the API refuses with `passport_not_pointered`.

> **Note**
>
> Whether product identity fields such as GTIN and SKU are *displayed* on the branded passport is
> template-governed: a brand shows or hides them by selecting them in its template.

## Bulk Amendments

Precision at scale: bulk break-glass is **single-product**. A selection spanning more than one product is refused with the single-product message, so one correction can never fan out across unrelated products by accident.

Legacy passports inside a selection are excluded automatically and reported with the "legacy passports were excluded" notice, so the scope you execute is always the scope you were shown.

## The Amendment Audit Trail

Amendments are stored as a separate **field amendments** layer on top of the frozen snapshot. The snapshot itself is never modified. Every amendment writes a **break-glass ledger** entry capturing:

* who applied the amendment
* when it was applied
* the governed reason
* the prior value, and the source that prior value came from

That ledger is the evidence pack an auditor asks for, produced as a by-product of doing the work.

### Ledger-Derived "Last Updated"

A passport's **Last updated** value is derived from the break-glass ledger (the time of the latest amendment) rather than stored on the record. Recency is therefore always backed by an audited event. A passport with no amendments shows none: **"No amendments recorded."**

The same value is exposed in the public passport payload as `last_updated_at`.

## Who Can Amend

The break-glass capability is held by the **owner**, **admin** and **compliance-approver** roles.

Product-data writes outside passports are governed separately by the `products.core_values.write` capability, held by the same three roles.

## Product Edits vs Passport Amendments

| Action                | Effect                                                                                                                                              |
| --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Editing a product** | Changes the product master record. Applies to **future mints only**. Existing passports are unaffected.                                             |
| **Break-glass**       | Corrects a specific published or revoked passport, with a governed reason and a ledger entry. The product master and other passports are untouched. |

Product edits and passport amendments are independent operations. Editing a product does not update existing passports, and amending a passport does not change the product master.

## Related Docs

* [Passport Operations](/passports/passport-operations)
* [Publication Lifecycle](/passports/publication-lifecycle)
* [Products](/product-module/products)
* [Minting Overview](/minting/overview)