> 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 2: Sequencing the First Three Actions

> Academy Foundations Module 6 Lesson 2: turning a readiness position into three ordered first actions, and what to ask suppliers for and when.

**Module 6, Lesson 2 of 3. About 12 minutes.**

## Orientation

A readiness position tells you where you stand. It does not tell you what to do on Monday morning.
The gap between the two is where most organisations lose momentum: they produce an honest, detailed
assessment, present it once, and then default back to whichever action feels most familiar, which is
usually a technology conversation, because that is the layer with visible things to show for effort.

This lesson is about closing that gap by sequencing. Not a full programme plan: three actions,
ordered, with a reason for the order that would survive a challenge.

## Learning Objectives

## Why Order Is the Whole Argument

The nine stage roadmap set out in the canonical article for this lesson exists because each stage
consumes the output of the one before it. Governance written before anyone has assessed the data
governs data that turns out not to exist in the form assumed. An architecture chosen before ownership
is settled encodes decisions nobody actually made, because no one was accountable for making them.
Building before validating means finding your errors in production instead of in review. The stages
are not bureaucracy for its own sake; they are gates that stop wasted effort from compounding.

For a first three actions, you do not need all nine stages. You need to identify which stage your
readiness position from Lesson 1 says you are actually at, and act there, not one stage ahead of it.
If your data assessment is incomplete, the correct next action is more data assessment, not a
governance policy and certainly not a technology evaluation, however urgent either of those feels.

Sequencing also has to include suppliers, because supplier engagement has the longest lead time of
anything in a passport programme and is the most reliably under-resourced. The question is not only
what to ask for, it is when. Asking a supplier for composition data before you know which attributes
you actually need produces a generic data request that gets a generic, unusable answer. Asking after
you have completed your own data assessment, with a specific list, produces something that can be
checked and used. The order matters as much for a supplier request as it does for internal work.

**The common misreading** is to treat sequencing as a scheduling exercise, something a project
manager does after the real decisions are made. It is the opposite: the order is itself the
technical judgement. Two organisations with an identical readiness position can be given the same
three candidate actions and only one of them will have put them in an order that actually works,
because the wrong order means the first action has to be redone once the second one reveals what it
should have assumed.

A tieback framework setting out nine gated stages, from regulatory and product scope through
information requirements, data and source assessment, governance, target architecture, build,
validation, pilot and operation, each with an explicit exit gate, plus feedback loops back to
earlier stages when later work exposes what earlier work missed.

**Use it when** you have more than one plausible next action and need to justify which one comes
first, or when a stakeholder wants to skip ahead to build before an earlier gate has been passed.

**Where it fails:** it is not a waterfall promise. Real programmes revisit earlier stages repeatedly,
and the framework says so explicitly. Do not use it to argue that a stage, once passed, can never be
reopened; use it to argue that skipping a gate without evidence is the actual risk.

#### [How to Build a Digital Product Passport Implementation Roadmap](/docs/knowledge-base/implementation/how-to-build-a-digital-product-passport-implementation-roadmap)

Read the first two phases in full, covering scope, information requirements, data and source
assessment, governance and target architecture. These four stages are where a first three actions
should almost always be drawn from.

#### Sequencing the S2's first three actions

The Lesson 1 position found: three conflicting identifiers across three systems, unrequested
composition data at the contract manufacturer, and a QR pilot that resolves only to a marketing
page.

Action one: reconcile the three identifiers to a single agreed model level identifier, with a named
owner. This is prerequisite to everything else. No later action means anything if the systems cannot
agree what product they are even describing.

Action two: complete the attribute inventory for the S2, marking each attribute's source, owner and
confidence, including the battery pack and the textile strap separately, since they may carry
different requirements. This has to follow identifier reconciliation, because an inventory built
against three different identifiers cannot be reconciled itself.

Action three: only once the inventory names the specific gaps, approach the contract manufacturer
with a specific, bounded request for battery composition data, rather than an open-ended one. Asking
this before the inventory exists would produce a request nobody could act on and would spend the
relationship's goodwill on the wrong question.

The QR pilot is left alone. It is proven, it is cheap to leave as is, and rebuilding it now would be
effort spent one stage ahead of where the S2 actually stands.

#### Sequence your own first three actions

Using the readiness position you wrote in Lesson 1, list three candidate actions. Order them, and
write one sentence for each transition explaining why it could not usefully come earlier. Then
write the one sentence you would send to a supplier, and state at which of the three actions you
would send it, not before.

## Knowledge Check

## Takeaways

* Sequencing is not administration: the order is itself the technical judgement, because doing a stage out of order forces it to be redone.
* Act at the stage your readiness position says you are actually at, not one stage ahead of it.
* Supplier requests should follow your own inventory, not precede it, so they are specific and checkable.
* Leaving a proven, low-value component such as a working carrier alone is a legitimate sequencing decision, not neglect.

**If you remember one thing:** the wrong order does not just slow a programme down, it makes the first action worthless once the second one runs.

## Sources

[How to Build a Digital Product Passport Implementation Roadmap](/docs/knowledge-base/implementation/how-to-build-a-digital-product-passport-implementation-roadmap),
sections Phase 1: Define and Phase 2: Prepare, and
[How Should Organisations Prepare for Digital Product Passports?](/docs/knowledge-base/implementation/how-should-organisations-prepare-for-digital-product-passports),
section Preparing Supplier Collaboration.

## Related Docs

* [Lesson 3: The Five Sentence Brief](/docs/academy/foundations/module-6/lesson-3)
* [Lesson 1: Taking a Readiness Position](/docs/academy/foundations/module-6/lesson-1)
* [How to Build a Digital Product Passport Implementation Roadmap](/docs/knowledge-base/implementation/how-to-build-a-digital-product-passport-implementation-roadmap)
* [tieback Frameworks](/docs/knowledge-base/frameworks/overview)