tieback Framework Library
What a tieback Framework Is
Every canonical article in the tieback Knowledge Base introduces exactly one original conceptual model. A framework is not a summary and not a checklist. It is a named set of ordered components that explains how a subject works, what depends on what, and where an organisation currently sits within it.
Frameworks exist because the subjects covered here are genuinely complicated. Regulation, product identity and enterprise data each arrive as a mass of detail with no obvious order. A framework supplies that order once, so the detail becomes navigable rather than overwhelming.
Permanent Framework Identifiers
Each framework carries a permanent identifier in the form TBF-001, TBF-002 and so on.
- Identifiers are editorial, not versions. A framework can be refined without changing its identifier.
- Identifiers are permanent. Once assigned, a framework keeps its identifier for good.
- Identifiers are never renumbered and never recycled. A retired identifier is not reissued to a different framework.
- New canonical articles reference existing identifiers rather than recreating similar models.
This registry is the canonical source for the framework set. Individual framework pages do not exist yet; each entry links to the canonical article that introduces and applies the model.
The Framework Registry
Digital Product Passports
| ID | Framework | What it teaches | Source article |
|---|---|---|---|
TBF-001 | The Four Layers of a Digital Product Passport | Separates a passport into regulatory, governance, information and technology layers so programmes can see which layer they have actually built. | What is a Digital Product Passport? |
TBF-002 | The Digital Product Passport Responsibility Model | Maps the six economic operator groups in a supply chain to the passport duties each one actually carries. | Who Needs a Digital Product Passport? |
TBF-003 | The Product Information Readiness Model | Grades each category of passport data by how ready an organisation is to publish it, from already held to not yet obtainable. | What Information Does a Digital Product Passport Contain? |
TBF-004 | The Digital Product Passport Data Flow | Traces the seven stages a passport passes through, from data capture to scan, resolution and presentation. | How Does a Digital Product Passport Work? |
TBF-010 | The Digital Product Passport Value Pyramid | Layers passport benefits from baseline compliance up to operational, commercial and strategic value. | What Are the Benefits of a Digital Product Passport? |
TBF-042 | The Passport Data Origin Model | A matrix model that separates what information a Digital Product Passport needs from where that information actually comes from. Ten rows describe categories of passport information: product identity and reference data, composition and materials, manufacturing and production data, supplier provided data, compliance and conformity information, certificates and declarations, sustainability and environmental information, lifecycle and event data, and the conditional categories of repair and service information and end of life and circularity information. Each row is read across three further columns: typical origins expressed as functions rather than product names, including product lifecycle management, enterprise resource planning, product information management, manufacturing execution and production records, supplier portals and submissions, compliance and evidence repositories, laboratory testing and certification sources, traceability and event systems, service and repair systems and manually maintained or externally supplied records; the authority for that category, which may be the manufacturer, the production site, the supplying organisation, the issuing body, the economic operator carrying the legal duty, or the party that observed an event; and the kind of evidence, if any, that typically supports the claim. A publication band beneath the matrix records that assembled information passes through governance, validation and evidence checks before publication, and that publication does not transfer authority away from the sources. The model rests on seven distinctions: passport data is not one database, it is not whatever the enterprise resource planning system holds, a source system is not automatically the system of record, data is not evidence, product data is not lifecycle event data, required information is not the source of information, and the data carrier, the product identifier and the passport data are three different things. It also separates framework level requirements under Regulation (EU) 2024/1781 from product specific requirements and from implementation choice, and states explicitly that no universal Digital Product Passport dataset exists. It consumes the product information readiness model TBF-003 for passport content without restating it, defers authority resolution to the enterprise source of truth model TBF-027, master data management model TBF-028 and golden record lifecycle TBF-029, defers governance, quality and stewardship to TBF-023, TBF-025 and TBF-026, hands validation to TBF-033 and evidence management to TBF-034, and hands large estate layering to the enterprise reference architecture TBF-030. It is written to remain usable by organisations with no enterprise systems at all, treating controlled spreadsheets, supplier documents and manual production records as legitimate origins subject to the same governance. | What Data Goes in a Digital Product Passport, and Where Does It Come From? |
Regulations
| ID | Framework | What it teaches | Source article |
|---|---|---|---|
TBF-005 | The ESPR Implementation Journey | Shows how ESPR moves from framework regulation to binding product obligations, and where an organisation sits on that path. | What is the Ecodesign for Sustainable Products Regulation (ESPR)? |
TBF-006 | The EU Product Regulation Lifecycle | Explains the stages by which a framework regulation becomes an enforceable product requirement through delegated acts. | What Are Delegated Acts? |
TBF-007 | The Product Category Rollout Model | Groups product categories by rollout position so organisations can judge how soon a passport obligation reaches them. | Which Products Will Require a Digital Product Passport? |
TBF-008 | The Digital Product Passport Compliance Timeline | Separates confirmed legal dates from expected and indicative ones so planning rests on what is actually fixed. | When Will Digital Product Passports Become Mandatory? |
TBF-038 | The DPP Enforcement Lifecycle | An educational model of how Digital Product Passport obligations move from an applicable legal requirement to supervision and, where necessary, enforcement, in eight stages: applicable requirement, market surveillance, information and product check, compliance assessment and finding, economic operator response, corrective or restrictive action, penalties and formal enforcement where applicable, and follow-up and continuing compliance. It is preceded by a legal applicability band distinguishing adoption, publication in the Official Journal, entry into force, date of application, transitional provisions, product-specific application, amendment, corrigendum and guidance, on the principle that no enforcement analysis is possible without an applicable requirement. It separates information non-compliance from substantive product non-compliance as educational categories, distinguishes corrective action from withdrawal and recall, distinguishes penalties from corrective measures, and treats market surveillance, conformity assessment and enforcement as distinct interacting concepts. It records that under the current EU framework common requirements are established by Union legislation while surveillance and enforcement are exercised substantially by competent authorities designated by Member States, supported by Union cooperation and information-exchange mechanisms. No EU instrument defines these eight stages and actual procedures depend on the applicable instrument, the product-specific measure, the product, the operator, the Member State, the nature and severity of the non-compliance and the powers available. It begins where the ESPR framework model TBF-005 and the delegated act lifecycle TBF-006 end, uses the product category rollout model TBF-007 and the compliance timeline TBF-008 to establish stage one, treats enterprise validation TBF-033 as distinct from market surveillance, draws on the evidence lifecycle TBF-034 where evidence validity or expiry becomes relevant, positions the assurance model TBF-035 as pre-emptive internal detection rather than enforcement, hands findings and data defects to the operating model TBF-036 as operational events, and relies on the programme governance model TBF-037 for internal authority over material regulatory responses without implying any influence over the powers of authorities. | How Digital Product Passports Will Be Enforced |
TBF-039 | The DPP Legal Responsibility Model | A role-based educational model of how legal responsibility for Digital Product Passport obligations is allocated. It places the applicable DPP obligation at the centre, defined by the applicable instrument, the product-specific measure, the product and the market, and arranges surrounding roles in three bands: an inner band of potential legal accountability containing manufacturer, importer, distributor and authorised representative where the applicable definition is met; a middle band of role-dependent responsibility containing online marketplaces and fulfilment service providers, whose duties arise under specific provisions of relevant EU legislation rather than automatically; and an outer band of contributing and supporting roles containing suppliers and upstream contributors, laboratories and evidence providers, and technology and service providers, which normally carry contractual, operational or service responsibility rather than statutory product responsibility. A separate authority interaction band records that market surveillance authorities engage with the operators the applicable legislation identifies. A responsibility lens separates five distinct kinds of responsibility: legal, created by applicable law and owed externally; contractual, created by agreement and owed to a counterparty; operational, assigned internally to perform the work; data, domain accountability inside the enterprise; and technical, responsibility for the systems that deliver and publish the passport. The model holds that outer bands move inward only where the applicable legislation defines the party as a responsible operator, and that contractual, operational, data and technical responsibility never rewrite the legal allocation. It further treats responsibility as a property of the pairing between an entity and a specific obligation rather than of the entity alone, using illustrative obligation categories including product conformity, required product information, DPP availability, DPP accuracy, product identification, technical documentation, evidence, information access, cooperation with authorities, corrective action and record retention. No EU instrument defines this model and it does not determine the position of any organisation, product or transaction. It narrows the ecosystem participation lens of the DPP Responsibility Model TBF-002 to statutory accountability, supplies the operator dimension that the DPP Enforcement Lifecycle TBF-038 assumes when authorities assess compliance, explains why supplier contribution under the Supplier DPP Readiness Model TBF-032 does not equal statutory responsibility, distinguishes the internal decision authority of the DPP Programme Governance Model TBF-037 from external legal accountability, and records that Product Data Governance TBF-023 and Product Data Stewardship TBF-026 determine internal ownership and control without redefining legal operator responsibilities. | Who Is Legally Responsible for a Digital Product Passport? |
TBF-040 | The DPP Conformity Assessment Relationship Model | A four layer educational model describing how conformity assessment relates to a Digital Product Passport. Layer one, applicable requirements, holds the framework legislation, product specific measures, delegated and implementing measures, technical requirements and any standards or specifications used. Layer two, conformity assessment, holds the procedure prescribed or permitted by the applicable legislation, including internal production control, testing, examination, quality system assessment, product verification and unit verification, with a conditional branch for third party or notified body involvement that applies only where the applicable legislation requires it. Layer three, compliance evidence and documentation, holds technical documentation, test reports, calculations, risk assessment, supplier declarations, assessment outputs, certificates where applicable and the declaration of conformity where required. Layer four, Digital Product Passport information, holds the narrower subset of information the applicable framework requires to be available through the passport. Two relationships run across the layers: a consistency rail requiring that published passport information does not contradict the authoritative compliance record, and a market surveillance feedback path recording that authorities may examine both the passport and the underlying compliance environment without the passport replacing the assessment. An economic operator responsibility rail runs the full height of the stack, recording that arranging work through a laboratory, consultant or notified body performs the work without moving the statutory obligation. The model is built on the principles that conformity assessment determines or demonstrates whether specified requirements have been fulfilled while a passport makes specified information available, that conformity assessment is not a synonym for third party certification, that self assessment is real assessment, and that publishing correct information is not the same as maintaining conformity. It begins from the requirements produced by the ESPR framework TBF-005 and the product specific measures of the delegated act model TBF-006 without restating them, draws its boundary against the enterprise data controls of the data validation control model TBF-033, consumes but does not recreate the evidence lifecycle TBF-034, states that the enterprise assurance model TBF-035 has no statutory conformity status, supplies the compliance environment that the enforcement lifecycle TBF-038 later examines, and pairs with the legal responsibility model TBF-039 by describing what conformity related responsibilities must be performed or arranged by the operator that model identifies. | How Conformity Assessment Works for Digital Product Passports |
Standards & Technology
| ID | Framework | What it teaches | Source article |
|---|---|---|---|
TBF-009 | The Product Compliance Transformation Model | Describes the shift from document based, point in time compliance to continuous, data based product accountability. | How Will Digital Product Passports Change Product Compliance? |
TBF-012 | The Global Product Identification Framework | Explains how global identification standards make a product mean the same thing to every party that handles it. | What is GS1? |
TBF-013 | The Connected Product Identity Model | Shows how a single web enabled identifier connects one product to many audiences and services. | What is GS1 Digital Link? |
TBF-014 | The Product Identity Stack | Separates the carrier, the identifier and the destination so teams stop confusing a QR code with product identity. | QR Codes vs GS1 Digital Link: What’s the Difference? |
TBF-015 | The Product Identity Hierarchy | Orders identity from product model down to batch and individual item, and shows what each level can prove. | What is a Product Identifier? |
TBF-016 | The Global Product Identity Model | Explains what a globally unique trade item number identifies, and the boundary of what it cannot express. | What is a GTIN? |
TBF-017 | The Product Information Delivery Model | Describes how physical carriers deliver an identifier that leads to product information, rather than carrying the information itself. | What is a Data Carrier? |
TBF-018 | The Product Event Lifecycle | Frames supply chain visibility as a sequence of what, when, where and why events recorded against a product. | What is EPCIS? |
TBF-019 | The Trusted Product Data Flow Model | Follows product data from supplier to consumer and identifies where trust is created and where it is lost. | How Product Data Moves Through the Supply Chain |
TBF-041 | The DPP Standards Landscape Model | A landscape map of the Digital Product Passport standards environment, organised as five zones read against a separate legal effect rail. Zone one, the legal framework, holds Union legislation, the Ecodesign for Sustainable Products Regulation and the product specific measures adopted under it, and is the only source of binding obligation. Zone two, standardisation direction, holds the European Commission acting as regulator and standardisation policy actor, issuing standardisation requests under Regulation (EU) No 1025/2012 and citing references of harmonised standards in the Official Journal without drafting technical standards itself. Zone three, the standards ecosystem, places the European standardisation organisations CEN, CENELEC and ETSI, the joint CEN and CENELEC committee JTC 24 on the Digital Product Passport framework and system, the international bodies ISO and IEC including the joint committee ISO/IEC JTC 5, and industry standards organisations such as GS1 side by side as distinct mandates rather than tiers of a hierarchy. Zone four, technical standardisation domains, separates identification, data carriers, physical to digital linkage, resolution and discovery, data exchange, interoperability, data models and semantics, access rights, authentication and security, application programming interfaces and lifecycle persistence, and event and traceability data. Zone five, the implementation ecosystem, holds the standards, specifications, carriers, resolver services, enterprise systems and passport services an organisation actually deploys. Running beside all five zones is a legal effect rail with five bands: binding law, product specific requirement, harmonised standard where applicable carrying conditional legal relevance through presumption of conformity once cited, other standard or specification which is voluntary unless otherwise required, and implementation choice which carries no legal force of its own. The model exists to make it impossible to read every institution and technology in the landscape as sharing one legal status. It consumes the ESPR framework model TBF-005 and the delegated act lifecycle TBF-006 as the source of binding requirements without restating them, hands the presumption of conformity mechanism to the conformity assessment relationship model TBF-040 rather than duplicating it, defers legal responsibility to TBF-039 and enforcement to TBF-038, draws its enterprise boundary against the enterprise Digital Product Passport reference architecture TBF-030 by stating that a standard defines an exchange contract and not a system of record, and hands delivery sequencing to the implementation roadmap model TBF-031 and standards version monitoring to the operating model TBF-036 and programme governance model TBF-037. | The Digital Product Passport Standards Landscape |
Implementation
| ID | Framework | What it teaches | Source article |
|---|---|---|---|
TBF-011 | The Digital Product Passport Readiness Model | Sequences preparation work that holds its value under any delegated act, from identification to governance and publication. | How Should Organisations Prepare for Digital Product Passports? |
TBF-031 | The Digital Product Passport Implementation Roadmap | A stage gated implementation model with nine stages, from regulatory and product scope through information requirements, data and source assessment, governance and ownership, target architecture, build, validation, pilot and operation, each carrying an explicit exit gate, supported by eight parallel workstreams and explicit feedback loops, so implementation follows requirements rather than technology selection and orchestrates the readiness model TBF-011 and the enterprise capabilities of TBF-020 to TBF-030 instead of duplicating them. | How to Build a Digital Product Passport Implementation Roadmap |
TBF-032 | The Supplier DPP Readiness Model | An eight stage supplier readiness model covering supplier scope, segmentation into differentiated readiness pathways, information and evidence requirements, capability assessment, data and evidence exchange, validation and acceptance, remediation and exception management, and operational monitoring, built on the principle that segmentation drives proportional control rather than one uniform process for every supplier. It operates as the supplier workstream across the implementation roadmap TBF-031, treats supplier systems as source systems within the reference architecture TBF-030, extends the readiness diagnosis of TBF-011 beyond the enterprise boundary, and applies the governance, quality, stewardship, integration and source of truth disciplines of TBF-022, TBF-023, TBF-025, TBF-026 and TBF-027 to information originating outside the organisation. | How to Prepare Suppliers for Digital Product Passports |
TBF-033 | The DPP Data Validation Control Model | A control model combining four governed data states, submitted, validated, accepted and publishable, with three control gates, thirteen validation control classes, a governed validation rule catalogue, three severity levels and an explicit exception and remediation route, built on the principle that information becomes publishable only by passing controls proportional to the element, its source, its regulatory significance, its evidence and its intended publication context. It formalises and extends the submitted, validated and accepted progression introduced by the supplier readiness model TBF-032 to information from all sources, distinguishes validation from the fitness for use dimensions of the product data quality model TBF-025, operates as a control across the trust and governance and integration and orchestration capabilities of the reference architecture TBF-030, and is designed, proven and operated through stages three, six, seven, eight and nine of the implementation roadmap TBF-031, applying the governance and stewardship disciplines of TBF-023, TBF-026 and TBF-027 to the acceptance decision. | How to Validate Digital Product Passport Data |
TBF-034 | The DPP Evidence Lifecycle | A nine stage governed evidence lifecycle covering evidence requirement, request and acquisition, collection, association, validation, verification or review, acceptance and control, controlled use and publication, and monitoring, renewal and retirement, supported by a separate evidence state model of received, associated, validated, verified, accepted and active with the alternative states rejected, expired, superseded and revoked, a claim to evidence relationship model, provenance, validity, versioning and supersession handling, access classification and a practical evidence register. It is built on the principle that evidence supports a claim rather than proving it, that evidence supporting a passport does not necessarily belong inside the passport, and that not every data element requires documentary evidence. It supplies the evidence dimension of the data validation control model TBF-033 at validation, verification, acceptance and publication, routes supplier evidence from the supplier readiness model TBF-032 into the same governed lifecycle rather than a separate architecture, is designed through stages two and three and operated through stages six to nine of the implementation roadmap TBF-031, and places evidence repositories inside the enterprise source and trust environment of the reference architecture TBF-030 while applying the governance, quality, stewardship and source of truth disciplines of TBF-023, TBF-025, TBF-026 and TBF-027. | How to Manage Evidence for Digital Product Passports |
TBF-035 | The DPP Assurance Model | An end to end testing and assurance model combining eight assurance domains, regulatory and requirements, data, identity and association, evidence, integration and process, access, security and publication, lifecycle and change, and operational assurance, with a seven step assurance cycle of scope definition, acceptance criteria, test design and execution, assurance evidence capture, defect and exception assessment, remediation and retest, and a governed assurance decision concluding in the educational states ready, ready with conditions or not ready. It is built on the principle that a passport is not production ready because it renders, that assurance must test the whole operating chain from source to operational response including its failure paths, and that assurance evidence supporting a readiness conclusion is distinct from the claim evidence governed by the evidence lifecycle TBF-034. It assures the whole capability rather than individual information elements controlled by the data validation control model TBF-033, provides the detailed model for stage seven of the implementation roadmap TBF-031 while informing its pilot and operate stages, derives architectural test coverage from the reference architecture TBF-030, extends supplier scope from the supplier readiness model TBF-032, and applies the governance, quality, stewardship and source of truth disciplines of TBF-023, TBF-025, TBF-026 and TBF-027 to the readiness decision. | How to Test and Assure a Digital Product Passport |
TBF-036 | The DPP Operating Model | An operating model for a deployed Digital Product Passport capability, combining eight operating capabilities, regulatory monitoring, data operations, evidence operations, supplier operations, passport service operations, access and security operations, change and release management, and assurance and continuous improvement, with seven operational event types, data, evidence, supplier, product and lifecycle, regulatory, technical, and access and security, and an eight step operational control cycle of monitor, detect, assess, assign, resolve, validate, update and learn, under cross-cutting governance spanning accountability, decision rights, escalation, control, change approval, risk acceptance, reporting and auditability, supported by an operational event record, severity and prioritisation guidance, context dependent service levels, federated operating responsibilities, a governed project to operations transition and an operational metric set. It is built on the principle that implementation creates the capability while operations keeps it trustworthy, that an operational event is anything requiring assessment rather than a synonym for incident, defect or change, and that service availability is not a measure of passport health. It is the detailed capability behind stage nine of the implementation roadmap TBF-031, consumes the readiness decision and its conditions from the assurance model TBF-035, converts the evidence state transitions of TBF-034 and the validation controls of TBF-033 into operational triggers and controls, extends the supplier readiness model TBF-032 into continuing supplier operations, governs the capabilities running across the reference architecture TBF-030, and applies the governance, quality, stewardship and source of truth disciplines of TBF-023, TBF-025, TBF-026 and TBF-027 to continuing operation. | How to Operate a Digital Product Passport Programme |
TBF-037 | The DPP Programme Governance Model | A programme governance model for Digital Product Passports combining five governance levels, executive accountability, programme governance, domain authority, delivery and operational control, and oversight and feedback, with seven decision domains, regulatory and scope, data and evidence, architecture and technology, suppliers and ecosystem, investment and priority, risk and assurance and exceptions, and change and people and adoption, and a governed decision cycle of identify, frame, assign authority, decide, record, execute and review, under a cross-cutting decision rights model separating accountability, authority, responsibility, consultation and information, supported by a decision rights matrix, escalation triggers, exception governance, scope control distinguishing required scope from optional capability, organisational change and adoption governance, a programme change impact assessment and a decision oriented metric set. It is built on the principle that governance is a system rather than a steering committee, that meetings are mechanisms through which governance may operate rather than governance itself, and that a technically deployed capability is not an organisationally adopted one. It governs authority across the implementation roadmap TBF-031 rather than restating its stages, holds the deployment and condition acceptance authority over the readiness conclusions of the assurance model TBF-035, sets the exception and escalation boundaries above the routine controls of the data validation control model TBF-033 and the evidence lifecycle TBF-034, decides supplier escalation where the supplier readiness model TBF-032 reaches its limits, governs deviations from the reference architecture TBF-030, hands the continuing flow of operational events to the operating model TBF-036, and contains rather than duplicates the product data governance and stewardship disciplines of TBF-023 and TBF-026. | How to Govern a Digital Product Passport Programme |
Enterprise Systems & Data Architecture
| ID | Framework | What it teaches | Source article |
|---|---|---|---|
TBF-020 | The Product Data Foundation Model | Distinguishes master, reference, transactional and event data, and shows which of them a passport consumes. | What is Product Master Data? |
TBF-021 | The Enterprise Product Data Landscape | Assigns clear ownership to PLM, ERP, PIM and MDM so teams know which system is authoritative for which attribute. | ERP vs PIM vs PLM: What’s the Difference? |
TBF-022 | The Enterprise Integration Model | Places an integration layer between source systems and the passport so publication draws from authoritative data. | How Enterprise Systems Support Digital Product Passports |
TBF-023 | The Trusted Product Data Governance Framework | Sets out ownership, quality, policies, stewardship, lifecycle and compliance as the six working parts of governance. | What is Product Data Governance? |
TBF-024 | The Product Data Maturity Model | Grades product data capability across six levels, from collection to continuous improvement, per attribute domain. | How to Build a Trusted Product Data Foundation |
TBF-025 | The Trusted Product Data Quality Model | Assesses product information across completeness, accuracy, consistency, validity, timeliness and traceability to judge fitness for intended use. | What is Product Data Quality? |
TBF-026 | The Product Data Stewardship Model | Divides responsibility for product information across business owner, data owner, data steward, data custodian and data consumer. | What is Product Data Stewardship? |
TBF-027 | The Enterprise Source of Truth Model | Separates authoritative sources, data domain ownership, integration and governance, and information use, so multiple authoritative systems can coexist with one defined source of truth per governed element. | What is a System of Record? |
TBF-028 | The Enterprise Master Data Management Model | Connects business domains, authoritative sources, master data management, governance and stewardship, enterprise distribution and passport consumption, showing that MDM coordinates trusted master data between enterprise systems rather than replacing them. | What is Master Data Management (MDM)? |
TBF-029 | The Golden Record Lifecycle | Traces how multiple authoritative sources converge through identity resolution, validation and survivorship rules into one governed representation of trusted data, which is then released through governed distribution to enterprise consumers and the Digital Product Passport, without relocating attribute-level source authority. | What is a Golden Record? |
TBF-030 | The Enterprise Digital Product Passport Reference Architecture | Synthesises the enterprise data capabilities of TBF-020 to TBF-029 into a seven layer reference architecture, from source systems through identity and authority, trust and governance, integration and orchestration, the logical passport service and access and discovery to consumers, with cross-cutting capabilities and three distinct information flows, so a passport consumes and publishes governed information instead of becoming a new master database. | Building an Enterprise Digital Product Passport Architecture |
How to Use a Framework
Read the framework inside its source article first. Each model is introduced with the reasoning that produced it, the components in order, and the practical signals that tell you where you sit. Taken out of that context, a framework reduces to a diagram, which is the least useful part of it.
When several frameworks touch the same subject, they are designed to stack rather than compete. The identity models in Standards & Technology, for example, describe different levels of the same question, and the enterprise data models describe the systems that supply the information the passport models consume.