> 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/getting-started/how-it-works.md). # How It Works This page explains Optivalux at product level. The mechanics behind each step are covered in the [Product](/product/product-identity.md), [Trust](/trust/trust-model.md) and [Technical](/technical/architecture-overview.md) sections. > **Current stage:** this describes the designed and implemented protocol behaviour. Owner and brand applications are not yet connected to it, and nothing is live on a public network. See [Current Stage](/getting-started/current-stage.md). ## From brand to owner, one chain of evidence ``` Brand │ registers each product and issues its certificate ▼ Product + secure authenticator │ the authenticator produces fresh cryptographic evidence, │ checked against the product's registered identity ▼ Optivalux certificate │ holds standing, ownership and provenance for that one product ▼ Owner verifies · keeps · transfers · recovers ``` ### 1. The brand registers the product The brand places a **secure authenticator** in the product: a small secure element, such as an NFC chip, integrated during manufacture or finishing. Optivalux is hardware-neutral; the authenticator type is chosen per product category. Registration requires fresh evidence from that authenticator, so an identifier alone cannot be registered. The brand's **product certificate** is created for that item, held by the brand until the product is sold, and starts in **Active** standing. For the pilot profile, each product also has a separate **Recovery Authenticator** registered at this stage. It is used only if the primary authenticator is ever lost or damaged. See [Recovery & Protection](/product/recovery-and-protection.md). ### 2. Anyone can verify it Anyone holding the product can tap its authenticator with a phone. The result states **what was verified and when**: whether the registered authenticator answered with fresh evidence that matches the registered identity, and what the certificate's standing is. A **QR code** only opens the product's record. It shows public status but is never evidence that someone is holding the product. See [Authenticity Evidence](/product/authenticity-evidence.md). ### 3. The first owner claims it After purchase, the buyer **claims** the product. A claim needs the buyer's own request, fresh evidence from the product's authenticator, and the brand's authorization that this product may be claimed (for example, after the purchase is confirmed). The certificate and its history then belong to the owner's account. ### 4. Ownership moves only with the owner's authorization When the product changes hands, **ownership changes only when all three conditions are met**: 1. the current owner authorizes the transfer to a named recipient; 2. the recipient accepts it; 3. the product is freshly verified in the recipient's possession. Holding the product alone never changes ownership. See [Ownership & Transfer](/product/ownership-and-transfer.md). ### 5. Recovery restores access, never ownership If the authenticator is lost or damaged, access can be restored through **brand-assisted recovery** or with the owner's own **Recovery Authenticator**. Recovery never changes who owns the product, and a suspended certificate stays suspended. If the software or verification a certificate depends on stops working, the owner can start **Protection Mode**, which moves the certificate to a protected, non-operational state after a minimum 14-day period. Ownership does not change. See [Recovery & Protection](/product/recovery-and-protection.md). ### 6. Provenance accumulates Registration, claim, transfers, changes in certificate standing and authenticator recovery are recorded on the same product record. The history stays with the product, not with a receipt or an account. See [Provenance](/product/provenance.md). ## What sits underneath Core certificate state, ownership and recorded provenance are kept on **blockchain infrastructure**, so they do not rely solely on an Optivalux database remaining online. Product details, verification services and applications are still operated services. Owners and brands never need to handle the underlying infrastructure directly: they see products, evidence and history, not technical records or fees. See [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/getting-started/how-it-works.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.