> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://tieback.io/docs/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://tieback.io/docs/_mcp/server. # Lesson 2: Who Sees What > Academy Foundations Module 3 Lesson 2: why passport data is access controlled by user group, which audiences see which categories, and how to avoid the two failure modes of publishing too much or too little. **Module 3, Lesson 2 of 3. About 9 minutes.** ## Orientation Once you can name the categories of passport content, the next question a designer has to answer is who is allowed to see each one, and it is a question people reach for the wrong instinct on twice. The first instinct is to publish everything, because openness sounds like good practice. The second, once someone points out a competitor could read the composition data, is to lock everything down. Both instincts are wrong, and both are expensive to unwind once a system has been built around them. Access is not an afterthought bolted onto a finished passport. It is a property of the record from the first design decision, and it differs by category, not by product. Composition, sustainability, and supply chain information. Identity and compliance are usually assembly problems inside the organisation that carries the duty; those three are usually requests to someone else. ## Learning Objectives ## Reading Access as a Category Property The framework requires that access rights be differentiated by user group. Consumers, repairers, recyclers, notified bodies, customs authorities and market surveillance authorities are expected to see different subsets of the same record. That single requirement is what separates a passport from a product web page: a web page shows one view to everyone who arrives at it, and a passport cannot. Read the canonical article's treatment of supply chain information particularly closely: it is the clearest illustration of why access varies by category rather than by a blanket public or private setting. Facility level identification and detailed composition carry commercial sensitivity that a brand has a legitimate reason to restrict, while the same record may need to expose that information in full to a market surveillance authority carrying out an inspection. Identity data is generally the most open category, because a consumer needs it to confirm what they are holding. Composition and supply chain detail sit furthest toward restricted, for exactly the commercial sensitivity reason above. **The common misreading** is to assume that "digital" and "public" mean the same thing, or its mirror image, that restricting one category justifies restricting the whole record. Neither follows. A passport can, and generally must, show a consumer one subset, a repairer a wider subset including service information, and an authority the full record, from a single underlying data set. Designing for one undifferentiated audience is the same mistake as designing for no audience at all: it produces a record that satisfies nobody's actual need. #### [What Information Does a Digital Product Passport Contain?](/docs/knowledge-base/digital-product-passports/what-information-does-a-digital-product-passport-contain) Read the Supply Chain Information section for the clearest worked case of category level sensitivity, then the misconception on publishing everything, then the frequently asked question on public visibility. #### Designing access for the Aurelia S2 A consumer scanning the trimmer needs identity, headline sustainability claims, and enough lifecycle guidance to maintain and eventually dispose of it correctly. They do not need the battery cell supplier's identity or the exact mass fraction of each polymer additive. A repairer needs the consumer subset plus service information: which parts are replaceable, torque specifications, and the battery pack's safe handling data, because a lithium cell handled wrongly is a hazard, not a commercial curiosity. A market surveillance authority needs the full record on request, including composition, supplier identity and evidence for every published claim, because their role is to verify what a brand has asserted. Publishing the authority's view to consumers by default would expose supplier relationships the brand has a legitimate commercial reason to protect. Publishing only the consumer view to an inspecting authority would defeat the inspection. #### Draft an access table for your own product List the six categories down one side and three audiences across the top: your typical consumer, a repairer or recycler, and a regulator or authority. Mark each cell as full, partial or none. Where you cannot decide, that is the finding: it means the category has not yet been designed for more than one audience, which is the most common gap in early passport designs. ## Knowledge Check ## Takeaways * Differentiated access by user group is a framework requirement, not an optional design choice. * Identity data is generally the most open category; detailed composition and supply chain detail are generally the most restricted. * Access has to be designed per category and per audience from the start, not bolted on afterwards. * Publishing everything and restricting everything are both failures of the same design step. **If you remember one thing:** a passport is several views of one record, not one view of everything. ## Sources This lesson draws on [What Information Does a Digital Product Passport Contain?](/docs/knowledge-base/digital-product-passports/what-information-does-a-digital-product-passport-contain), sections Supply Chain Information, Common Misconceptions and Frequently Asked Questions. ## Related Docs * [Lesson 3: What You Already Hold, and What Has No Owner](/docs/academy/foundations/module-3/lesson-3) * [Lesson 1: The Categories of Passport Data](/docs/academy/foundations/module-3/lesson-1) * [What Information Does a Digital Product Passport Contain?](/docs/knowledge-base/digital-product-passports/what-information-does-a-digital-product-passport-contain) * [Glossary: Market Surveillance](/docs/knowledge-base/glossary/market-surveillance)