> 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 3: What You Already Hold, and What Has No Owner > Academy Foundations Module 3 Lesson 3: the Passport Data Origin Model, how to audit where each passport attribute actually lives, and why an attribute with no named owner is the finding, not a detail. **Module 3, Lesson 3 of 3. About 9 minutes.** ## Orientation You now have two lenses: which category an attribute belongs to, and who is allowed to see it. The third question is the one that actually determines your programme's timeline, and it is the question most teams answer by assumption rather than by looking: do we hold this attribute, and if so, where. "We hold it" is a claim that needs testing, not a status someone remembers from a previous project. An attribute can exist in a system of record, exist only as a PDF nobody has indexed, exist in a colleague's head, or not exist inside the organisation at all. Those are four different problems with four different remedies, and none of them is fixed by writing a field name in a spreadsheet. Because access is a property of each category rather than a single public or private switch on the whole record. The same attributes can be governed and released differently to different audiences without duplicating the underlying data. ## Learning Objectives ## Reading Origin as Distinct from Existence The Passport Data Origin Model separates three questions that are usually collapsed into one: whether an attribute exists anywhere in the extended organisation, whether it exists in a form your own systems can query, and whether anyone has been named as responsible for keeping it correct. An attribute can pass the first test and fail the other two, and that gap is exactly where passport programmes lose months they did not budget for. Auditing origin means walking each attribute back to its actual location rather than its assumed location. A product data system entry looks authoritative because it is structured, but it may have been entered once, years ago, by someone no longer at the company, and never checked against the underlying test report. A PDF on a shared drive looks like a gap because it is unstructured, but the value inside it may be current and correct, just not queryable. Treat structured and unstructured the same way: ask when it was last verified and against what source, not merely where it sits. **The common misreading** is to treat "we can find a number" and "we hold this attribute" as the same statement. Finding a number in an old specification sheet is not the same as being able to produce it, on demand, in a structured form, with a defensible source. A programme that counts the first as success will discover the difference the first time an authority asks for evidence rather than a figure. The second failure of the same misreading is worse: assuming that because an attribute is not visible in any system, someone somewhere must be managing it informally. Usually no one is. The absence of a system entry is evidence of absence, not evidence of an invisible owner. A tieback framework that separates whether an attribute exists anywhere in the extended organisation, whether it exists in a queryable structured form, and whether it has a named owner responsible for its accuracy. Used to turn "do we have this data" from a guess into an audited answer. **Use it when** you are running a data readiness audit, being told a category is "basically done", or trying to work out why an attribute keeps arriving late from the same source every time. **Where it fails:** it tells you where an attribute sits today and whether anyone owns it. It does not tell you whether the attribute is correct, and it does not resolve a dispute between two systems that disagree, which needs governance, not an origin audit, to fix. Do not treat a completed origin audit as a data quality sign-off. #### [What Data Goes in a Digital Product Passport?](/docs/knowledge-base/digital-product-passports/what-data-goes-in-a-digital-product-passport) Read the section on where passport data actually comes from, then the audit section, which sets out the practical steps for walking an attribute back to its real source rather than its assumed one. #### Auditing origin for the Aurelia S2 Three internal systems each hold a different identifier for the trimmer, and none of the three teams that maintain them knows the other two exist. That is not a data quality issue to schedule for later. It is the finding: no one currently owns "what is this product's canonical identifier", and every attribute linked to the wrong one inherits the same confusion. Composition data for the housing and battery cell sits entirely with the contract manufacturer, who has never been asked for it in a specification or a contract clause. It fails the origin test at the first question: it may not exist anywhere in a form anyone can retrieve, structured or not. Of the remaining likely attributes, roughly a third live in the product data system, and a third exist only as PDFs on a shared drive, readable by a person but not queryable by anything else. A completed QR pilot resolves to the marketing page, which demonstrates that a carrier can be printed and scanned, and says nothing about whether any attribute behind it is owned. A different organisation, one selling a single product line through one channel with one supplier relationship, might find this entire audit takes an afternoon and turns up no gaps worth naming. For the S2, with three systems, a contract manufacturer never asked, and data split across a live system and a shared drive, the audit is the programme's real starting point. #### Run an origin audit on five attributes of your own product Pick five attributes you expect a passport to need. For each, write three answers: does it exist anywhere in the extended organisation, can it be produced today in a structured queryable form, and who is named as its owner. Do not accept "IT" or "product team" as an owner; write a person. Any attribute that fails the third question, even if it passes the first two, is your actual risk. A correct number with no owner will drift the first time the product changes. #### [Passport Data Origin Worksheet](/docs/knowledge-base/templates/passport-data-origin-worksheet) When you want to run this beyond five attributes, the worksheet is the working document for it. It takes each item of information through origin, authoritative source and evidence, and counts what is still unowned or unevidenced. It runs in your browser, saves nothing anywhere, and needs no tieback product. ## Knowledge Check ## Takeaways * "We hold it" and "we can produce it today, in a structured form, from a defensible source" are different claims. * Audit each attribute against three questions: does it exist anywhere, is it queryable, does it have a named owner. * An unstructured value is a smaller problem than a value that does not exist anywhere; do not confuse the two. * An attribute with no named owner is the finding itself, not a detail to fix once the data is collected. **If you remember one thing:** the absence of a system entry is evidence of absence, and an unowned attribute will drift regardless of how correct it looks today. ## Sources This lesson draws on [What Data Goes in a Digital Product Passport?](/docs/knowledge-base/digital-product-passports/what-data-goes-in-a-digital-product-passport), sections Where Passport Data Actually Comes From and Auditing What You Already Hold. ## Related Docs * [Module 3 assessment](/docs/academy/foundations/module-3/assessment) * [Lesson 2: Who Sees What](/docs/academy/foundations/module-3/lesson-2) * [tieback Frameworks](/docs/knowledge-base/frameworks/overview) * [Passport Data Origin Worksheet](/docs/knowledge-base/templates/passport-data-origin-worksheet) * [What Data Goes in a Digital Product Passport?](/docs/knowledge-base/digital-product-passports/what-data-goes-in-a-digital-product-passport)