Passport Data Origin Worksheet
Map every item of information a passport has to carry to where it comes from, who is authoritative for it, and what evidence stands behind it. The output is a per item origin map with an explicit gap list, which is the working document a data programme is built from.
- Product data and master data teams
- Compliance and regulatory affairs teams assembling passport content
- Procurement and supplier quality teams chasing supplier-held values
- Sustainability teams sourcing product level environmental data
- IT and integration teams deciding what to connect, and in what order
- After a readiness assessment, when you know the programme is real
- Before selecting or configuring any system, so integration follows the map rather than setting it
- When two systems disagree about the same attribute and nobody can say which one wins
- Before a supplier data request goes out, so you ask for evidence rather than numbers
This is a practical tool, not a canonical Knowledge article and not a tieback framework. 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?. 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.
Open worksheet ↓Goes straight to the worksheet. The context below stays here if you want it.
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.
The item the passport has to carry.
Where the value comes from today, expressed as a function.
Who is authoritative when sources disagree.
What proves the value, or a decided position that none is required.
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 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
- Fix the scope first: one product family, one market. Write the scope down before you add the first row.
- List the information items the passport has to carry for that scope. Use the ten TBF-042 categories as prompts, not as a checklist. If the applicable delegated act is not yet adopted, list what is confirmed and what is likely, and mark the difference.
- For each item, record the origin as it is today, not as it should be. A supplier email is an origin. Record it honestly; the map is worthless if it describes the intended state.
- Name the authoritative source. If you cannot name it, leave it blank rather than guessing. A blank authority is a finding, and the worksheet counts it as one.
- Record the evidence position. "Internal control, none required" is a valid answer once it has been decided; "not yet decided" is not, and the worksheet treats it as a gap.
- Open the practical detail panel for owner, availability, update frequency and last verified. An item with no named owner is not governed, however good the system it sits in.
- Read the summary, take the Gap rows into a plan with owners and dates, and re-verify the map when suppliers, materials or systems change.
Origins Are Functions, Not Products
TBF-042 names origins by what they do, not by product name. A controlled spreadsheet and a configured PLM instance are both legitimate origins of specification data; they differ in effort and in risk, not in standing. Use the function that best describes where the value actually comes from today.
| Origin | What it covers |
|---|---|
| Product lifecycle management | Design and specification records, however they are held. |
| Enterprise resource planning | Commercial, purchasing and production planning records. |
| Product information management | Published product descriptions and reference attributes. |
| Manufacturing execution and production records | What actually happened on the line, batch by batch. |
| Supplier portals and submissions | Questionnaires, declarations and supplier system feeds. |
| Compliance and evidence repositories | Regulatory affairs records and technical documentation. |
| Laboratory testing and certification sources | Accredited laboratories, testing organisations, certification bodies. |
| Traceability and event systems | Logistics, warehouse and distribution event records. |
| Service and repair systems | Authorised repairer records, spare parts and service history. |
| Manually maintained or externally supplied records | Controlled spreadsheets, supplier PDFs, paper production records. A legitimate origin, subject to the same governance. |
The Worksheet
These are completeness counts for this worksheet, not a score and not a compliance determination. A row is a Gap only when the authoritative source or the evidence position has not been established, because those are the two elements that decide whether a published value can be defended.
3 illustrative example row(s) are still present. They are worked examples, not a regulatory field list. Remove them before using the worksheet for real.
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
Worked example: see this tool used end to end, alongside the other two Templates, in Example 01: From DPP Readiness to Defensible Supplier Evidence.
Limitations And Regulatory Caution
- This worksheet maps where data comes from. It does not validate the data, and completing it does not establish that any value is correct.
- The ten information categories are a structuring lens from TBF-042, not a regulatory field list. What a specific product must carry is set by the applicable delegated act or product specific measure.
- The illustrative rows supplied with the worksheet are worked examples only. Remove them before using it for real work.
- Status counts describe worksheet completeness. They are not a maturity score, a readiness score or a compliance determination.
- Entries are stored in this browser only. Clearing site data, switching browser or switching device loses them; export the worksheet if it matters.
- This is not legal advice. Confirm applicability and evidence expectations with qualified regulatory or legal advice for your products and markets.
Related Articles
- Supplier Evidence Register
- DPP Readiness Assessment
- From DPP Readiness to Defensible Supplier Evidence: A Worked Manufacturer Example
- What Information Does a Digital Product Passport Contain?
- What Data Goes in a Digital Product Passport, and Where Does It Come From?
- DPP Governance: Who Owns What?
- How Will Digital Product Passports Change Product Compliance?
- 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
- 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
- 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
About This Article
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.