One physical garment has no more than one current owner.
Historical periods remain append-only. A valid transition closes the prior current period and creates the next atomically.
Foundation / Ownership
Possession alone cannot create Ownership.
A secure scan may verify a physical product. A successful authorized Claim, completed approved transfer, or another approved reason-coded event is what creates or changes zHezar’s platform Ownership record.
Reference only. No product, scan, Claim, owner, username, transfer, Collection, correction, evidence file, or Ownership record is represented here.
- 01Physical productStable Product Identity
- 02Secure verificationCurrent token and server result
- 03Authorized eventClaim, transfer, or approved process
- 04Ownership recordOne current authority
Identity / verification / event / authority
Current evidence
The authority model is defined. Ownership activation is not.
The repository specifies invariants, protected service boundaries, and public privacy constraints. It does not evidence an issued Product Identity, live token, completed Claim, current owner, approved transfer workflow, or public record activation.
No owner or garment is shown.
OD-016 remains Draft, so no username, history, optional Collection, public field, or ownership control is invented.
Six distinct layers
Related facts do not share the same authority.
Each layer answers a different question and must remain independently validated.
What official physical item is this?
Stable garment, Edition, unit, and lineage relationships survive token replacement and ownership change.
Did the current physical credential validate?
A live server result may establish token and product authenticity—not Ownership by itself.
Who physically holds the item now?
Possession may support a Claim, transfer, dispute, or service case, but cannot overwrite the record.
Did the authorized first-ownership process complete?
A validated operation may create the first Ownership record only when every required condition passes.
Which account holds current platform authority?
The current OwnershipRecord linked to the active physical identity and permanent account reference is authoritative.
What privacy-safe relationship may be shown?
A limited projection may explain approved history; it never becomes the source of Ownership authority.
Fourteen non-authority signals
Useful evidence is not current Ownership.
Any of these may support fulfillment, review, a dispute, or an approved workflow. None creates or changes platform Ownership alone.
- 01Username
- 02Email address
- 03Shipping address
- 04Receipt
- 05Order confirmation
- 06Delivery
- 07Physical possession
- 08Device
- 09Most recent scanner
- 10Public garment URL
- 11Static NFC identifier
- 12Support request
- 13Garment photograph
- 14Outside payment claim
Six historical roles
Owner is not one interchangeable label.
These relationships can belong to different accounts over a product’s life. Public presentation must label them accurately and reveal only the approved privacy-safe projection.
Completed the original approved purchase.
May differ from the first claimant when a separately approved gift workflow applies.
Completed the first authorized Claim.
The account that finished the protected first-Claim process.
Received the first completed Ownership record.
This role remains historical after a later valid transfer.
Completed the first authorized reveal, if applicable.
Discovery does not automatically mean purchaser or current owner.
Holds the one current authoritative Ownership record.
Profile visibility or scanning activity does not add or remove this authority.
Previously held completed Ownership.
The historical relationship remains, but owner-only authority has ended.
Authorized first Claim
Every required condition must still be true at completion.
The server revalidates current authority at the mutation boundary. Prior evidence or a successful screen is not enough.
- 01
Eligible purchasing account
The authorized account and any approved gift relationship are resolved.
- 02
Delivered and claimable state
Order, return, cancellation, payment, fraud, legal, security, and ownership holds permit the operation.
- 03
Secure physical verification
The current active token and Product Identity validate through the authoritative backend.
- 04
No current Ownership record
The operation fails closed if ownership exists or concurrent authority cannot be resolved.
- 05
Server-side revalidation
Authentication, authorization, expiry, operation identity, and current facts are checked at mutation.
- 06
Atomic record and history
The first Ownership record and required provenance are created together or not at all.
Completed transfer
Invitation or acceptance alone does not change Ownership.
A transfer remains pending until current-owner authority, the intended receiver, physical verification, eligibility, terms, holds, and final server mutation all complete.
The existing owner remains current.
Invitation, acceptance, payment arrangement, meeting, delivery, or a scan attempt is not a completed transition.
The transition changes authority atomically.
The prior period closes, the receiver’s current period opens, the product reference updates, and provenance records the event.
Former and current authority separate.
The former owner loses owner-only controls, the new owner gains them, and configured holds begin without deleting history.
Public and protected
The record can be authoritative without exposing the case file.
OD-016 remains Draft. Optional public Collection and historical-owner modules stay disabled, and the public projection uses the most privacy-preserving presentation.
Privacy-safe username-based relationships and required product history.
Only approved fields, time precision, owner labels, profile references, and required provenance may appear.
Legal identity, contact, address, payment, location, security, and evidence.
Orders, devices, network signals, disputes, fraud review, case files, and private ownership history remain access-controlled.
Corrections, holds, and continuity
A complaint is not a reversal.
Ownership changes, revocations, restorations, and corrections require a documented approved process, evidence, authority, reason, audit history, and any required notice or appeal.
- Legal process
- Fraud decision
- Payment decision
- Return
- Exchange
- Replacement or reissue
- Account-deletion process
- Ownership dispute
- Security correction
- Administrative correction
Valid Ownership does not expire through inactivity.
Stopping scans, leaving the platform, account inactivity, or the product leaving sale does not silently remove a completed record. Required provenance survives ordinary profile changes and deletion according to approved policy.
Public promise limits
This explainer is not Ownership evidence.
- 01
This page creates, verifies, displays, changes, revokes, restores, or corrects an Ownership record.
- 02
A scan, static URL, screenshot, receipt, delivery, possession, or support statement establishes Ownership.
- 03
Product authenticity and physical possession automatically resolve legal title or every dispute.
- 04
A public username or profile presentation is the authoritative account or Ownership identifier.
- 05
An invitation, acceptance, payment, handoff, or scan attempt means a transfer completed.
- 06
A complaint, profile preference, inactivity, or stopped scanning silently reverses valid Ownership.
- 07
Public provenance exposes private identity, contact, address, payment, security, or evidence records.
- 08
This reference activates a Claim, transfer, Collection, marketplace, inheritance, correction, case, support, or legal process.
Readiness / July 2026
The ownership model is reviewable. Ownership is not active here.
These labels describe repository readiness only and do not represent a Claim, current owner, transfer, public record, or production service.
CapabilityStateRequired before activation
Public ownership educationPublic reference
Product, privacy, legal, security, accessibility, and content approval remain required.
Claim and Ownership TermsLegal review required
Final definitions, terms, versions, acceptance, and records are required.
Secure first ClaimFuture gate
Issued products, approved NFC, account/order authority, holds, APIs, and support are required.
Current Ownership authorityFuture gate
Authoritative records, concurrency, audit, reconciliation, recovery, and monitoring are required.
Public owner projectionOD-016 Draft
Approved fields, labels, privacy, retention, deletion, anonymization, and holds are required.
Ownership transferFuture gate
OD-017, recipient, physical verification, fees, disputes, holds, and operations are required.
Corrections and disputesWorkflow required
Cases, evidence, authority, notices, appeals, audit, and safe operations are required.
Related public boundaries
Verify the product. Authorize the event. Preserve the history.
Authenticity explains secure scans, Provenance explains append-only history, and Edition Integrity keeps release identity distinct.