The neutral record layer that lets customers own their fit data across every brand they wear.
TL;DR — The Shared Ledger is not a brand database. It is a neutral persistence and permission layer where customers own their fit records, operators contribute under cryptographically scoped grants, every write carries provenance, and access can be revoked without destroying continuity. Getting governance right at this layer is what makes multi-brand fit infrastructure trustworthy at scale.
The word ledger often triggers the wrong mental model. It is not a blockchain pitch. It is not a brand story. The Shared Ledger is the neutral record and permission layer for fit data shared across multiple operators — the infrastructure substrate that makes a concept like Size Passport credible rather than cosmetic.
EU fashion returns cost an estimated €38 billion per year, according to McKinsey's State of Fashion 2024, with fit mismatch accounting for roughly 70 percent of that volume. Every major retailer has tried to solve this with their own measurement tools, recommendation engines, and size charts. None of those solutions transfer when the customer shops somewhere else. That is not a product problem. That is an infrastructure problem.
Definition
Shared Ledger
The neutral persistence and permission layer that coordinates customer-owned fit data and operator contributions across brands and ateliers. It is not controlled by any single operator. It enforces provenance on every write, scoped permissions on every read, and first-class portability and revocation for every customer.
A brand database stores data about customers. The Shared Ledger stores data for customers, under rules the customer controls. That distinction is the entire point. When a brand owns the fit record, they can withdraw it, sunset the product, or simply fail to integrate with the next brand the customer visits. When the customer owns the record, portability is structural — not a feature someone has to build later.
GDPR Article 20 establishes the legal foundation: data subjects have the right to receive personal data in a structured, commonly used, machine-readable format and to transmit that data to another controller. The Shared Ledger operationalises that right at the infrastructure layer rather than leaving it as a compliance afterthought. In practice, this means every fit record must be exportable as a standard payload — not a PDF, not a screenshot, but a structured data object a receiving operator can actually parse.
The Shared Ledger permission model has four independent layers: record ownership, contribution grants, read scopes, and revocation. Because each layer is independent, a brand's read access can be revoked without deleting its historical contribution, and a new operator can receive write access without gaining visibility into contributions from other operators. Granularity at this level prevents the system from collapsing into a surveillance layer controlled by whichever operator enrolled the most customers first.
Implementing this model requires a credential layer that can carry claims about both the data and the permission grants themselves. The W3C Verifiable Credentials Data Model provides the technical vocabulary: a fit measurement issued by an operator becomes a verifiable credential signed by that operator's decentralised identifier, and the customer's wallet holds the credential rather than the operator's server. This architecture means the operator cannot silently modify a historical measurement after it is issued — a property that matters enormously when the same measurement is being used by a downstream brand to cut a garment.
Provenance means every data point in the Shared Ledger carries a verifiable origin: who measured, when, with what method, and under which permission grant. This is not an audit log appended to a database row. It is a structural property of the data model itself, enforced at write time rather than reconstructed after the fact.
Consider what happens without provenance. A customer visits three brands over two years. Each records a slightly different chest measurement — 96 cm, 98 cm, 94 cm — because each used a different protocol, different measurer, or different garment fit philosophy. A downstream operator who sees only the average (96 cm) cannot determine whether the variance reflects measurement noise, body change, or protocol inconsistency. Provenance solves this: the downstream operator sees all three measurements, their origins, and the method metadata, and can weight or filter accordingly.
The W3C JSON-LD 1.1 specification provides the semantic layer for expressing this provenance in a format that is both human-readable and machine-parseable across different operator systems. When provenance is encoded in JSON-LD, any operator receiving the record can resolve the vocabulary terms to their canonical definitions — eliminating the translation layer that typically causes fit data to degrade when it crosses brand boundaries.
Revocation is the most technically delicate property. It must be complete — a revoked operator cannot retrieve data after the revocation event — but it must also be non-destructive. The customer's fit record should remain intact and usable by other permitted operators even after one operator's access is removed. Achieving this requires separating the data plane from the access plane.
In the Shared Ledger model, each contribution is stored once under the customer's ownership key, with the contributing operator's provenance metadata attached. Read access is controlled by the permission layer, not by data co-location. When a customer revokes Brand X's access, Brand X's historical contribution remains in the customer's record — because the customer owns it — but Brand X's credential to read that record is invalidated. Other operators with valid read grants are unaffected. The customer's continuity of service with those operators is preserved without any action on their part.
A trustworthy fit infrastructure cannot be designed brand-first and corrected later. Governance, data model, and permission posture have to be right before the product layer becomes persuasive.
The practical difference between a shared ledger model and conventional brand-siloed measurement data is clearest across four dimensions: ownership, portability, revocability, and governance resilience. Understanding each shows why incremental improvements to existing brand databases cannot produce the same outcome — and why the architecture must be neutral from inception.
Building the database is straightforward. Building durable rules that survive the incentives of the largest operator in the room is the genuinely hard part. Every multi-stakeholder data infrastructure eventually faces pressure to give preferential treatment to its highest-volume contributor — more lenient data retention policies, faster API rate limits, earlier access to new measurement schemas. The Shared Ledger's governance design must resist that pressure structurally, not just by policy.
The Ellen MacArthur Foundation's New Textiles Economy report identified interoperability as a foundational requirement for a circular fashion system, but noted that interoperability consistently fails when the coordinating entity is also a commercial competitor. The Shared Ledger addresses this by separating the infrastructure operator role from the brand operator role. The entity running the ledger cannot also be selling garments; the conflict of interest is architectural, not merely contractual.
ISO/IEC 27001 provides the information security management framework that governs how measurement data is stored, accessed, and transmitted within a compliant implementation. In practice, a Shared Ledger deployment requires an annual information security audit covering not only the ledger operator's own systems but also the API surface exposed to brand operators — because a permissioned data layer is only as secure as its weakest integration point.
The European Parliament's Sustainable and Circular Textiles Strategy, adopted in 2022, mandates digital product passports for textiles by 2030. Those passports will require structured, machine-readable data about garment construction, material provenance, and care instructions — but the regulatory framework is silent on how consumer body data should flow between the brand issuing the passport and the customer wearing the garment. The Shared Ledger fills that gap by providing a governed record layer for the person-side of the product-person relationship.
Research by Barclays UK (2023) found that 49 percent of online fashion shoppers deliberately over-order to try items at home, with fit uncertainty cited as the primary driver. This pattern produces not just returns cost but significant carbon emissions. The Ellen MacArthur Foundation estimates that extending the active life of garments by just nine months reduces carbon, water, and waste footprints by 20 to 30 percent each. A shared fit record that travels with the customer is the mechanism through which that extension becomes feasible at scale.
When measuring real-world deployments, the critical success metric is not the number of brands integrated but the number of customers who have exercised their portability and revocation rights — because those actions demonstrate that the governance model is functioning. A shared ledger that no customer ever exports from or revokes against is, functionally, just another brand database with a more elaborate technical story.
No. The Shared Ledger is an architectural pattern, not a specific technology. The core properties — customer record ownership, operator contribution grants, provenance, portability, and revocation — can be implemented on a conventional database with a cryptographic credential layer. Blockchain is one possible implementation substrate, but the governance and permission model are what matter, not the storage technology. Choosing a distributed ledger technology does not, by itself, produce the governance properties the Shared Ledger model requires.
The neutral infrastructure operator — the entity running the ledger — must be structurally separated from any brand or retailer that contributes to or reads from it. This separation is what makes neutrality credible. In the Size Passport implementation, the ledger operator role is held by a dedicated entity whose sole function is infrastructure governance, with no commercial relationship to any participating brand. Brand operators access the ledger via API under the same permission model that applies to all participants.
Yes. GDPR Article 17 (right to erasure) applies. A customer can request complete deletion of their Shared Ledger record, which removes both the measurement data and all associated permission grants. This is distinct from revocation (which removes a specific operator's access while preserving the record) and from portability export (which creates a copy without modifying the source record). The data model supports all three operations independently.
Direct integration is the most complete path, but not the only one. A customer can export their Size Passport as a structured portable credential and present it to any brand — even one that has not integrated with the ledger — using a standard data import flow. This fallback preserves customer agency during the transitional period when full multi-brand integration is still being built out across the fashion industry.
Sources
Related concepts