> For the complete documentation index, see [llms.txt](https://docs.optivalux.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.optivalux.com/trust/recovery-and-continuity.md).

# Recovery & Continuity

**Design principle:** no restrictive authority should be able to permanently trap a legitimate owner without a defined safe recovery path.

The architecture is designed to reduce the risk that an owner becomes indefinitely dependent on one failed or restrictive path. Failure of an authenticator, a verification service, a brand or a software version can reduce what is possible for a while, but does not change who owns the product, and bounded recovery and protection paths exist. This risk is reduced, not eliminated: the remaining availability assumptions are listed under [Operated-service caveats](#operated-service-caveats).

For the product-level description, see [Recovery & Protection](/product/recovery-and-protection.md).

## Principles

* **Recovery never changes ownership.**
* **Recovery never bypasses a restriction.** A suspended certificate stays suspended, and any pending notice before voiding continues unchanged.
* **Voided is terminal.** No recovery or protection path leaves Voided.
* **Recovery never allows an arbitrary tag.** Only a brand-authorized replacement or the product's own pre-registered Recovery Authenticator can be bound.
* **Recovery does not need the component that failed.**
* **Temporary restrictions are bounded.** Temporary protocol safety restrictions last at most 14 days and cannot be extended or immediately renewed. Only protocol governance, acting through its time delay, can restrict indefinitely.

## Recovery paths

| Failure                                                              | Path                                                                          | Needs                                         | Does not need                                    |
| -------------------------------------------------------------------- | ----------------------------------------------------------------------------- | --------------------------------------------- | ------------------------------------------------ |
| Authenticator lost or damaged                                        | **Brand-assisted recovery**                                                   | Owner, brand security role, new authenticator | Protocol governance                              |
| Authenticator lost or damaged; brand unavailable                     | **Recovery Authenticator recovery** (14-day maturation period, challengeable) | Owner, Recovery Authenticator                 | Brand, protocol governance, verification service |
| A software version is frozen or no longer matches its approved build | **Protection Mode**, without the protection period (see below)                | Owner                                         | Brand, protocol governance                       |
| Owner no longer trusts a software version                            | **Protection Mode** (minimum 14-day protection period, challengeable)         | Owner                                         | Brand, protocol governance                       |
| A verification service or authenticator type is withdrawn            | Recovery to a different, trusted authenticator                                | Owner and one of the recovery paths above     | The withdrawn service                            |

When a software version has been frozen or no longer matches its approved build, the protocol allows the owner to move the certificate to the protected state **without** the 14-day period, because the version itself can no longer be relied on. When the version is healthy, the 14-day period applies.

## Why these paths take 14 days

Recovery Authenticator recovery and Protection Mode can be started by the owner alone. If someone gained access to the owner's account, they could try to misuse these paths. The maturation period (recovery) and protection period (Protection Mode) give the real holder of the product time to respond:

* the **owner can cancel** during the period;
* a **fresh, trusted check of the product's current authenticator** can stop it;
* for symmetric authenticators, such a stop is limited to **once per product every 30 days**, so that a compromised verification service can delay, but never permanently block, an owner.

Even if misused, neither path changes ownership or enables a transfer.

## Continuity if a brand becomes unavailable

A brand may cease operating or stop responding. The protocol provides:

* **Recovery Authenticator recovery**, which needs no brand involvement;
* **Protection Mode**, which needs no brand involvement;
* a **brand continuity role**, registered in advance by the brand's security role, which becomes active only after an objective period of brand inactivity and ends as soon as the brand acts again. It has narrow powers (keeping software-version consent and verification-service continuity available) and **cannot** change ownership, authorize recovery, lift suspensions or void certificates.

## Operated-service caveats

Continuity of the **core record** does not mean continuity of every service:

* If the **verification service** for symmetric authenticators is unavailable, those authenticators cannot be verified until it returns or the product is recovered to a different authenticator. Ownership and standing are unaffected.
* If the **applications** or the **request submission service** are unavailable, owners may be unable to act conveniently. Anyone can submit a valid, owner-signed request to the network, so a single submission service cannot censor owners permanently, but doing so without an application requires technical effort.
* **Product details**, images and service notes are held by operated services and can be lost if those services end.
* If **both** the primary authenticator and the Recovery Authenticator are unavailable and brand-assisted recovery is not possible, the product cannot be re-bound. Ownership is still preserved.
* If **protocol governance itself** stops functioning, some availability can be lost (for example, approving new software). This is an accepted residual risk; it cannot change ownership.

These are part of the disclosed residual risks in [Claims & Limitations](/trust/claims-and-limitations.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.optivalux.com/trust/recovery-and-continuity.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.