> 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. # Passport Data Origin Worksheet > A vendor neutral worksheet that maps every item of passport information to its origin, its authoritative source and the evidence behind it, and shows where the gaps are. This is a practical tool, not a canonical Knowledge article and not a [tieback framework](/docs/knowledge-base/frameworks/overview). It operationalises **TBF-042, the Passport Data Origin Model**, described in [What Data Goes in a Digital Product Passport, and Where Does It Come From?](/docs/knowledge-base/digital-product-passports/what-data-goes-in-a-digital-product-passport). The model is not restated here; the worksheet applies it. The worksheet is vendor neutral and scale neutral. It can be completed with a spreadsheet and no tieback product, and it works whether your origins are ERP, PLM and MES instances or a controlled spreadsheet and a folder of supplier emails. Nothing you enter leaves your browser. ## Purpose Most passport programmes fail on origin rather than on content. A team can list the fields a passport needs in an afternoon. The expensive questions come afterwards: where does this value come from today, who is authoritative for it when two systems disagree, and what stands behind it if a market surveillance authority asks. TBF-042 answers those questions as a single chain, and this worksheet makes that chain explicit item by item. Two of those four links do most of the work. **Origin** describes where a value comes from today, which is a statement of fact. **Authoritative source** describes which record or party wins when sources disagree, which is a decision somebody has to take. Confusing the two is the most common failure in the estate: a value that exists in four systems has four origins and, until somebody designates one, no authority at all. **Evidence** is the third recurring failure. A value that cannot be substantiated is not a passport value, it is an assertion. TBF-042 treats "internal control, no external evidence required" as a legitimate evidence position, but only when it has been decided rather than assumed. The worksheet distinguishes a decided position from an undecided one, and treats only the second as a gap. ## Who It Is For The worksheet is deliberately scale neutral. * An **SME** with one product family may find that most origins are a controlled spreadsheet, a folder of supplier declarations and an accounting system. That is a legitimate set of origins. What matters is that each item has a named authority and a decided evidence position, not that the origin is expensive. * A **mid sized manufacturer** typically finds the opposite problem: several systems hold the same attribute, and no rule says which one is authoritative. The worksheet exposes that directly. * An **enterprise** should run it per product family or business unit. Completing one worksheet for "the company" produces an average, and averages hide the unit that fails first. ## When To Use It Run it after the [DPP Readiness Assessment](/docs/knowledge-base/templates/dpp-readiness-assessment) and before any system selection or integration work. Readiness tells you whether the organisation can do this. The origin map tells you what specifically has to be connected, negotiated or created, and in what order. Integration designed before the map is designed against assumptions. ## Instructions ## Origins Are Functions, Not Products ## The Worksheet ## How To Interpret The Result The three counts are a completeness signal for this worksheet, not a score and not a compliance determination. Read them as a shape rather than a total. * **Many gaps concentrated in one category:** usually composition, sustainability or supplier-provided data. This is a sourcing and supplier engagement problem, not a systems problem, and it has the longest lead time in the estate. Start it first. * **Gaps spread thinly across every category:** the estate has not designated authority anywhere. This is a governance decision that can largely be taken in a room, and it is cheaper and faster than it looks. * **Origins recorded but authority blank:** the classic multi-system condition. The data exists several times over and nothing arbitrates between the copies. Designating authority is the prerequisite for any integration work; connecting systems first will propagate the disagreement. * **Authority named but evidence undecided:** the value can be published and cannot be defended. Treat these as higher risk than an outright missing value, because a missing value is visible and an unsubstantiated one is not. * **Many Partial rows with no owner or no verification date:** the data is present but unmaintained. This is how attributes captured at product launch become quietly wrong three years later. A worksheet with no Gap rows means the map is complete, not that the data is correct, current or compliant. Correctness is established by the evidence you have recorded; compliance is determined against the applicable legal instrument and the product specific measure covering your product. ## Related Frameworks And Knowledge > **Note** > > Worked example: see this tool used end to end, alongside the other two Templates, in [Example 01: From DPP Readiness to Defensible Supplier Evidence](/docs/knowledge-base/examples/readiness-to-evidence-manufacturer-example). ## Limitations And Regulatory Caution ## Related Articles * [Supplier Evidence Register](/docs/knowledge-base/templates/supplier-evidence-register) * [DPP Readiness Assessment](/docs/knowledge-base/templates/dpp-readiness-assessment) * [From DPP Readiness to Defensible Supplier Evidence: A Worked Manufacturer Example](/docs/knowledge-base/examples/readiness-to-evidence-manufacturer-example) * [What Information Does a Digital Product Passport Contain?](/docs/knowledge-base/digital-product-passports/what-information-does-a-digital-product-passport-contain) * [What Data Goes in a Digital Product Passport, and Where Does It Come From?](/docs/knowledge-base/digital-product-passports/what-data-goes-in-a-digital-product-passport) * [DPP Governance: Who Owns What?](/docs/knowledge-base/compliance-frameworks/dpp-governance-who-owns-what) * [How Will Digital Product Passports Change Product Compliance?](/docs/knowledge-base/standards-and-technology/how-will-digital-product-passports-change-product-compliance) * [Product Data](/docs/knowledge-base/glossary/product-data) ## References * Regulation (EU) 2024/1781 (Ecodesign for Sustainable Products Regulation), Chapter III on the Digital Product Passport: [https://eur-lex.europa.eu/eli/reg/2024/1781/oj](https://eur-lex.europa.eu/eli/reg/2024/1781/oj) * tieback Knowledge, "What Data Goes in a Digital Product Passport, and Where Does It Come From?" (TBF-042, the model this worksheet applies): [https://tieback.io/docs/knowledge-base/digital-product-passports/what-data-goes-in-a-digital-product-passport](https://tieback.io/docs/knowledge-base/digital-product-passports/what-data-goes-in-a-digital-product-passport) * tieback Knowledge, "What Information Does a Digital Product Passport Contain?" (TBF-003): [https://tieback.io/docs/knowledge-base/digital-product-passports/what-information-does-a-digital-product-passport-contain](https://tieback.io/docs/knowledge-base/digital-product-passports/what-information-does-a-digital-product-passport-contain) ## About This Article About This Article
Last Reviewed
2026-08-10
Next Scheduled Review
2027-08-10
Article Version
1.0
tieback Knowledge is a continuously maintained reference library covering Digital Product Passports, product traceability, product compliance and related regulations. Articles are reviewed regularly as legislation, standards and implementation guidance evolve. ## About This Article ## Page Metadata | Field | Value | | ------------- | ---------------------------------------------------------- | | Asset type | Template / practical tool | | Published | 2026-08-10 | | Last Reviewed | 2026-08-10 | | Version | 1.0 | | Reading Time | 8 min | | Author | tieback Editorial Team | | Category | Templates | | Tags | data origin, evidence, governance, suppliers, product data | ## Related Docs * [Templates](/docs/knowledge-base/templates/overview) * [tieback Framework Library](/docs/knowledge-base/frameworks/overview) * [Digital Product Passports](/docs/knowledge-base/digital-product-passports/overview) * [Implementation](/docs/knowledge-base/implementation/overview) * [Enterprise Systems & Data Architecture](/docs/knowledge-base/enterprise-systems-and-data-architecture/overview) * Learn this model first: [tieback Academy, Foundations Module 3](/docs/academy/foundations/module-3) * [Example 01: From DPP Readiness to Defensible Supplier Evidence](/docs/knowledge-base/examples/readiness-to-evidence-manufacturer-example)