> 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/trust-model.md). # Trust Model Optivalux is designed to earn trust through **evidence** and **separation**, and to be explicit about where trust in an operated service or an organisation is still required. It does **not** remove the need for trust, and these docs never claim that it does. ## Evidence-based trust Every statement Optivalux makes about a product is a statement about evidence: * a registered authenticator answered with fresh, valid evidence, at a stated time; * a certificate has a stated standing, set by the issuing brand; * ownership is recorded, and changed only through defined processes. Optivalux does not ask anyone to trust a conclusion ("this is genuine") without showing what it rests on. ## Separation of facts Ownership, certificate standing and authentication availability are **independent facts**: * A verification service outage does not invalidate a certificate or affect ownership. * A suspended certificate keeps its owner. * A successful verification does not reinstate a suspended certificate. This separation limits the damage any single failure can cause and prevents one kind of problem from being mistaken for another. See [Product Identity](/product/product-identity.md). ## Separation of roles Each party can do only what its role requires: | Party | Can | Cannot | | ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | | **Owner** | Transfer (with recipient acceptance and fresh evidence), request recovery, start Protection Mode, report lost or stolen | Change certificate standing | | **Brand operator** | Register products within brand-set batch limits | Suspend, void, change ownership, authorize claims or recovery | | **Brand administration** | Manage batches and operators; suspend (provisionally, for owned products) | Void owned certificates, lift suspensions, authorize recovery, change ownership | | **Brand security role** | Lift suspensions, void (after notice), authorize brand-assisted recovery, enable claim authorization | Change ownership or transfer an owned product | | **Protocol governance** | Approve new protocol software versions; freeze versions; manage which authenticator types and verification services are trusted. A separate safety role can apply temporary restrictions of at most 14 days, which cannot be extended. | Change ownership; move an owned product to new software | | **Request submission service** | Submit signed requests to the network | Alter or forge any request | Brand and protocol roles with sensitive powers are designed to be controlled by multiple people (multi-signature), and protocol governance acts through a time delay. The exact thresholds and delays are set before any public deployment and are not yet decided. ## Authoritative record vs operated services Optivalux has two kinds of components, and they are trusted differently. **The authoritative record.** Core certificate state (ownership, standing, authenticator binding) and recorded provenance are held on blockchain infrastructure by the Optivalux protocol. This record does not rely solely on an Optivalux database remaining online, and it enforces its own rules, for example that ownership changes only through claim or owner-authorized transfer. **Operated services.** Other parts are services that someone runs: * the **verification service** that checks symmetric authenticators; * the brand's **claim service** that authorizes first ownership; * the **request submission service** that submits signed requests to the network; * **indexes and databases** that make the record fast to read; * **product details** and the **applications** themselves. Databases and indexes are **projections** of the authoritative record. Where they disagree, the record wins, and ownership-critical decisions read the record or confirm the projection is current. ## Where trust is still required Optivalux discloses these dependencies rather than hiding them: * **Symmetric authentication relies on the verification service.** If that service were compromised, it could report false verifications. It still could not transfer an owned product, because transfers also need the owner's authorization. * **First ownership relies on the brand's claim authorization.** Before a product is claimed, the brand together with protocol governance is part of the trust model for that unclaimed stock. * **The owner's account is a trust surface.** Owner sovereignty assumes that neither Optivalux nor the brand controls the owner's signing credentials. The account provider and application are part of what owners rely on. * **Operated services affect availability.** If a service is down, some actions may be unavailable. Recovery and Protection Mode provide bounded continuity paths when normal infrastructure is unavailable, while preserving ownership. They reduce, but do not eliminate, the risk that an owner depends on one failed or restrictive path. * **Deployment and software approval rely on verifiable process.** New protocol software is checked against published, audited builds before approval. Parts of that check are process-enforced rather than enforced by the record itself. ## What the architecture is designed to prevent * **Administrative reassignment.** For certificates owned under a conformant protocol version, no ordinary administrative role (brand, Optivalux or protocol governance) can silently reassign ownership. * **Silent takeover by later software.** A certificate stays with the software version it was issued under unless its owner chooses to move it. * **Burning or seizure.** There is no function to burn or seize a certificate. Voiding preserves ownership and history. The protocol is designed to preserve owner control through failures and version changes, but continuity depends on the accepted recovery and governance assumptions described in [Ownership & Control](/trust/ownership-and-control.md), [Recovery & Continuity](/trust/recovery-and-continuity.md) and the [Architecture Overview](/technical/architecture-overview.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/trust-model.md?ask=&goal= ``` `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.