> 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.

# From DPP Readiness to Defensible Supplier Evidence: A Worked Manufacturer Example

> A fictional lighting manufacturer works through the DPP Readiness Assessment, the Passport Data Origin Worksheet and the Supplier Evidence Register on one product family, and ends with a defensible evidence position and an owned action list.

#### From DPP Readiness to Defensible Supplier Evidence

Aurelia Lighting GmbH is fictional. It is not a tieback customer, and the figures, suppliers and
documents below are illustrative. Nothing here is a regulatory determination, a mandatory field
list or advice on what any specific product must publish. The point is the method, not the
numbers.

This example follows one manufacturer through the three practical tools in the
[Templates](/docs/knowledge-base/templates/overview) pillar, in the order they are meant to be used.
Each part shows what the team put in, what the tool gave back, and what changed in how they thought
about their own data. You can open each tool and repeat the exercise on your own product as you go.

## The Scenario

Aurelia has been asked by two large customers when its passport data will be available, and its
commercial team has started answering sustainability questions in tenders. Nobody inside the company
believes the answers are wrong. Nobody can say where they came from either.

The team's own framing at the start is the one most manufacturers begin with: **we have most of the
data, we just need to get it into a passport.** That framing is what the exercise tests.

### Where the data actually lives

Read as a list, this looks like reasonable coverage. That is precisely the trap: coverage describes
what exists, not what can be relied on. The first tool is designed to separate the two.

## Part 1: DPP Readiness Assessment

#### Where the programme actually stands

The team scores ten dimensions on the six level maturity scale, using the levels honestly rather
than aspirationally. Four dimensions are gating: a weakness in any one of them holds the whole
programme back regardless of strength elsewhere.

The assessment applies the
[Product Data Maturity Model (TBF-024)](/docs/knowledge-base/enterprise-systems-and-data-architecture/how-to-build-a-trusted-product-data-foundation)
and the readiness dimensions of
[TBF-011](/docs/knowledge-base/implementation/how-should-organisations-prepare-for-digital-product-passports). The
levels below are the team's inputs. Everything after them is computed by the same model the tool
uses.

The shape is common and worth reading carefully. Aurelia is strong exactly where manufacturers are
usually strong, identification and raw availability, and weak exactly where passport work is
actually decided: which copy of a value is authoritative, what stands behind it, and who owns it.

Readiness is not an average. Aurelia's average sits in the Emerging band, but the programme is
constrained at level 1 by the two gating dimensions it scored lowest on. Investing in integration
now would connect systems that still disagree with each other, and propagate the disagreement
faster. The sequence the tool produces is deliberate: designate authority, close evidence gaps,
assign ownership, and only then automate.

## Part 2: Passport Data Origin Worksheet

#### Where each item comes from, and who is authoritative for it

The readiness assessment said authoritative sources were the binding constraint. The worksheet is
where that abstraction becomes a list of named items. For each one the team records four things:
the information, its origin today, the authoritative source for it, and the evidence position
behind it.

This applies the
[Passport Data Origin Model (TBF-042)](/docs/knowledge-base/digital-product-passports/what-data-goes-in-a-digital-product-passport),
with readiness states from
[TBF-003](/docs/knowledge-base/digital-product-passports/what-information-does-a-digital-product-passport-contain).
The statuses below are derived by the worksheet's own rules, not asserted by the team: an item is a
gap when the authoritative source or the evidence position is not established, and partial when
those are settled but something practical, an owner, fitness, verification, an open action, is
not.

Seven representative items from the AL-400 follow. A real worksheet for this family would run to
several dozen rows.

### The discovery

A recycled content percentage sits in the item master and has been quoted in tender responses. It
was keyed in from a supplier statement that nobody can now locate.

The ERP **holds** that figure. The ERP is not **authoritative** for it. It is a consuming system for
a value whose authoritative basis is supplier evidence that was never obtained in a controlled way.
The worksheet records it as a gap, and the gap is the useful output: it moves the figure out of the
item master, where it looked settled, and into the evidence register, where it can be closed.

Holding a value and being authoritative for it are different claims, and systems of record blur
them constantly. Once Aurelia separates the two, three quarters of its rows turn out to be partial
rather than ready, not because the data is wrong, but because currency, method or ownership was
never recorded. That is not a setback. It is the first accurate picture the team has had.

## Part 3: Supplier Evidence Register

#### What evidence is expected, what arrived, and what it is worth

Four of the seven traced items depend on information Aurelia does not hold itself. Those become
register entries, where the question changes from "what is the value" to "what stands behind the
value, who issued it, has it been accepted, and is it still current".

This applies the
[DPP Evidence Lifecycle (TBF-034)](/docs/knowledge-base/implementation/how-to-manage-evidence-for-digital-product-passports)
for evidence kinds and states, and the
[Supplier DPP Readiness Model (TBF-032)](/docs/knowledge-base/implementation/how-to-prepare-suppliers-for-digital-product-passports)
for supplier segmentation. Statuses are again derived by the register, not chosen.

### What the register makes visible

* **Received is not accepted.** The alloy data sheet and the recycled content statement both exist.
  Neither supports a published claim yet, for different reasons: one has no issue date, the other no
  reporting period. A folder full of documents hides this distinction; the register cannot.
* **Standing matters as much as content.** The driver conformity evidence is accepted because it was
  reviewed against the standards it applies, and because the issuer is the party legally responsible
  for the component. The packaging specification is accepted knowingly as a supplier assertion,
  because the criticality does not warrant more. Both are defensible. They are defensible for
  different reasons, and the register records which.
* **Distance lengthens every request.** The LED substance declaration has to travel through an EU
  distributor to a supplier beyond the direct relationship. Nothing is wrong with the supplier; the
  route is simply longer, and planning that assumes a direct ask will be late.
* **Ownership converts a problem into a queue.** Every open row has a named function and person, so
  follow up is scheduled work rather than an act of memory.

The recycled content figure travels the full length of the exercise: strong looking in the ERP,
ungoverned in the worksheet, and finally an owned, dated, actionable gap in the register. Aurelia
now knows it cannot publish that claim yet, and knows exactly what has to arrive before it can.
Discovering that here costs an email. Discovering it after publication costs a correction.

## What Changed

Note what is not on that list. Aurelia has not published a passport, bought software, or completed
its data. It has ten defensible statements about its own product family and a short list of things
it knows are missing, which is a materially stronger position than believing everything is fine.

## The Sequence, and Why It Holds

The order is not decorative. Skipping the assessment produces a worksheet that traces the wrong
items. Skipping the worksheet produces a register full of requests nobody can justify. Skipping the
register produces a passport whose claims cannot be defended when someone asks.

## How To Repeat This

1. Pick one product family, not your whole catalogue. Scope is what makes the exercise finishable.
2. Run the [readiness assessment](/docs/knowledge-base/templates/dpp-readiness-assessment) with the
   people who actually maintain the data, and score honestly.
3. Take the weakest gating dimension into the
   [data origin worksheet](/docs/knowledge-base/templates/passport-data-origin-worksheet) and trace
   ten to twenty real items.
4. Move every supplier-held item into the
   [supplier evidence register](/docs/knowledge-base/templates/supplier-evidence-register) and
   record what evidence you expect before you ask for anything.
5. Re-score readiness after the first round of gaps closes. The movement, not the absolute level, is
   the signal.

If you want the underlying method rather than the worked artefacts, the
[Academy Foundations path](/docs/academy/foundations) teaches the same models in sequence,
and the [tieback Framework Library](/docs/knowledge-base/frameworks/overview) holds the canonical
definitions the tools apply.

## Limitations

* Aurelia Lighting GmbH, its suppliers, documents and figures are fictional and illustrative.
* The scoring, statuses and bands are produced by the same models the Templates use, but the inputs
  are chosen to be instructive rather than typical of any particular company.
* Nothing here determines which obligations apply to any product, or which fields any passport must
  carry. Applicability follows the instrument and the product specific measure for your product and
  market.
* The tools are worksheets. They record positions and actions; they do not verify evidence, contact
  suppliers or produce a compliance conclusion.

## Related Articles

* [Supplier Evidence Register](/docs/knowledge-base/templates/supplier-evidence-register)
* [Passport Data Origin Worksheet](/docs/knowledge-base/templates/passport-data-origin-worksheet)
* [DPP Readiness Assessment](/docs/knowledge-base/templates/dpp-readiness-assessment)
* [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)
* [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)
* [Sustainability Data](/docs/knowledge-base/glossary/sustainability-data)
* [What Are the Benefits of a Digital Product Passport?](/docs/knowledge-base/digital-product-passports/what-are-the-benefits-of-a-digital-product-passport)

## 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, "How to Build a Trusted Product Data Foundation" (TBF-024, the maturity scale
  used in Part 1):
  [https://tieback.io/docs/knowledge-base/enterprise-systems-and-data-architecture/how-to-build-a-trusted-product-data-foundation](https://tieback.io/docs/knowledge-base/enterprise-systems-and-data-architecture/how-to-build-a-trusted-product-data-foundation)
* tieback Knowledge, "What Data Goes in a Digital Product Passport, and Where Does It Come From?"
  (TBF-042, the data origin model used in Part 2):
  [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, "How to Manage Evidence for Digital Product Passports" (TBF-034, the evidence
  lifecycle used in Part 3):
  [https://tieback.io/docs/knowledge-base/implementation/how-to-manage-evidence-for-digital-product-passports](https://tieback.io/docs/knowledge-base/implementation/how-to-manage-evidence-for-digital-product-passports)
* tieback Knowledge, "How to Prepare Suppliers for Digital Product Passports" (TBF-032, supplier
  segmentation):
  [https://tieback.io/docs/knowledge-base/implementation/how-to-prepare-suppliers-for-digital-product-passports](https://tieback.io/docs/knowledge-base/implementation/how-to-prepare-suppliers-for-digital-product-passports)

## About This Article

About This Article

<dl>
  <dt>
    Last Reviewed
  </dt>

  <dd>
    2026-08-11
  </dd>

  <dt>
    Next Scheduled Review
  </dt>

  <dd>
    2027-08-11
  </dd>

  <dt>
    Article Version
  </dt>

  <dd>
    1.0
  </dd>
</dl>

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

About This Article

<dl>
  <dt>
    Last Reviewed
  </dt>

  <dd>
    2026-08-11
  </dd>

  <dt>
    Next Scheduled Review
  </dt>

  <dd>
    2027-08-11
  </dd>

  <dt>
    Article Version
  </dt>

  <dd>
    1.0
  </dd>
</dl>

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.

## Page Metadata

| Field         | Value                                                       |
| ------------- | ----------------------------------------------------------- |
| Asset type    | Example / worked scenario                                   |
| Published     | 2026-08-11                                                  |
| Last Reviewed | 2026-08-11                                                  |
| Version       | 1.0                                                         |
| Reading Time  | 14 min                                                      |
| Author        | tieback Editorial Team                                      |
| Category      | Examples                                                    |
| Tags          | worked example, readiness, data origin, suppliers, evidence |

## Related Docs

* [Examples](/docs/knowledge-base/examples/overview)
* [Templates](/docs/knowledge-base/templates/overview)
* [tieback Framework Library](/docs/knowledge-base/frameworks/overview)
* [Implementation](/docs/knowledge-base/implementation/overview)
* [Governance & Assurance](/docs/knowledge-base/compliance-frameworks/overview)