Product Portability Audit: Keep the First Offer Honest

The test design is already on the table. It names a buyer hypothesis, one learner action, a route to examine, and a stop condition. The team is now drafting the invitation. Someone adds: “Includes the live office hour and the downloadable field guide.”

That is the point at which a course becomes a promise.

After a bounded test has been designed, make a promise register: list every asset the first offer says a learner will receive, give it a named route, record any dated limitation or unresolved condition, and choose one action—test, replace, defer, or stop promising it. The earlier question of how to design the evidence belongs to the H2-08 test-design comparison (companion decision worksheet). This page begins only after a test design exists: do not let the invitation promise assets the documented route has not been shown to carry.

Why this is a creator workflow question

Course owners already recognise launch preparation as a collection of commitments, not just files. Teachable publishes a course-launch checklist for creators; it is a first-party signal that creators actively prepare a course offer before releasing it.¹ Teachable’s enrollment documentation and Kajabi’s lesson/quiz import documentation also illustrate that a course can be administered through specific people and specific objects.²³

None of those sources establishes a China market, a China route, or the need for this exact worksheet. They provide the overseas reader’s familiar starting point: before someone sees an offer, its contents and learner-facing components have to be stated.

The China-specific addition is that a named route may carry some of those stated assets differently. The promise register makes that difference visible instead of treating it as a later production surprise.

An asset inventory asks what exists. A promise register asks what you are entitled to say a learner will receive through this route, on this date.

The route question that changes a line in the invitation

Before an invitation names a live session, e-book, or other asset, verify the exact route and record a dated observation for the representative lesson. A help-centre description that cannot be re-opened today is not evidence that the asset is filtered, accepted, or deliverable. Until the route is verified, write the promise as pending route verification; do not silently include the asset, delete it, or infer a China-wide rule.

That evidence still does not establish account eligibility, listing, payment, access, distribution, buyer demand, or commercial performance for any course. The decision is about keeping the invitation honest while the route remains untested.

Choose an action, then write the invitation to match it

TEST

Use TEST when the asset is part of the first promise and the approved test design can observe the particular route question. Record the asset, route, test owner, date, conditions, observation, and what result changes the promise. This is not a license to test every course component at once.

REPLACE

Use REPLACE only when the authorised product owner agrees the substituted activity still supports the stated learner action. A different format can change the teaching method; it cannot be silently improvised because the original item is inconvenient.

DEFER

Use DEFER when the asset may be valuable later but is not necessary to make the first test’s invitation truthful. The invitation should name what is included now, rather than imply that a later component is already available.

STOP PROMISING

Use STOP PROMISING when the excluded asset is integral to the original offer and there is no approved, evidenced alternative. This is not a failure of the course. It is a refusal to sell a different product under the same words.

Keep this tool in its lane

Do not use this register to select a test design, identify all content dependencies, or conduct access/payment/delivery acceptance. Those are adjacent but different decisions:

• The H2-08 test-design comparison (companion decision worksheet) owns the information-design choice before a test is set.
• The Course Dependency and Terminology Inventory owns the broad asset and dependency record before a promise is drafted.
• The Access, Payment, and Delivery Test Script owns end-to-end operational observations after a route can be tested.
• Product, buyer, and channel evidence keeps a delivery-route issue from being misread as evidence of demand.

Counterexample

The one-line sign-off

Before an invitation is sent, have the owner sign off on one sentence:

“This test promises [assets] through [named route]. The unresolved asset is [asset]; until [dated test or authorised replacement], we will [test / replace / defer / stop promising] it.”

If you already have a bounded test design and need to turn it into an honest promise register, request a scoped China validation review. Bring the draft invitation and the asset most likely to be assumed rather than checked.

AI-service rules are a dependency boundary, not a portability result

If a lesson depends on a generative-AI service, record whether the dependency is a public-facing service or an internal research/application path before calling the product portable. China’s Measures for the Administration of Generative Artificial Intelligence Services describes a scope for services that provide generated text, images, audio or video to the public within China. This is an operational boundary note, not legal advice.

• Classify the dependency: write the named model or service, intended learner action, public-facing or internal scope, and the date checked.
• Keep tests separate: a technical route observation can tell you whether a defined workflow runs; it cannot stand in for buyer, payment, delivery or learning-outcome evidence.
• Keep the promise honest: if scope, account conditions or route behaviour is unresolved, mark the dependency pending and do not infer that the product is portable or unusable everywhere.

The rule does not establish a particular tool’s availability, an account’s eligibility, course demand, or a learning result. Those remain separate route and buyer questions.

Sources, boundaries, and update note

What this article cannot prove: buyer demand; an operator’s account or listing eligibility; payment, access, delivery, compliance, or learning outcomes; that a route will carry any asset; or that an asset excluded by one named route cannot be delivered through another. Reopen dynamic documentation and retain the route-specific observation before changing a public offer.