A course owner has just sent a shared folder to a translator. There are recordings, slides, two quizzes, a workbook, and a note saying, “Let’s get a China version moving.” The next question is usually treated as a production question: How long will translation take?
It is a decision question first: Are we actually ready to start a bounded adaptation project?
For this OriBridge readiness framework, treat a course as ready to begin a scoped adaptation workstream only when the team can name the first learner action, the course objects and learning surfaces in scope, who may approve changes, which asset route is assumed, and what still needs a dated test. If any of those is unknown, the right outcome is HOLD or ESCALATE—not a larger translation quote.
This checklist does not certify that a course is usable, sellable, accessible, payable, or compliant in China. It only decides whether a controlled piece of adaptation work has a defensible starting line.
Why a folder of course files is not a start signal
The word course makes many different objects sound interchangeable. They are not. A lesson page, a quiz, a downloadable workbook, a live session, and a learner-facing interface can each carry different work and different decision owners.
That distinction is visible in mainstream course tools. Teachable separates student-facing school translation from other product surfaces; its help documentation says automatic translation of student-facing web text does not apply to its iOS or Android apps.1 Kajabi documents lesson and quiz import as separate course-object actions.2 Neither source says anything about a China launch. Together, they offer a more modest but useful warning: “we have the videos and copy” is not a complete description of what must be adapted.
Readiness is not “we know what we own.” It is “we know what we are changing, who can approve it, and what must be tested before we make a promise.”
The six-gate readiness check
Use this framework before assigning a full translation, rebuilding a course, or presenting a delivery route as decided. It is deliberately narrower than a market-validation plan: it decides whether a scoped adaptation workstream may begin.
Gate 1: State one learner action and one bounded outcome
Write the first action a learner must take and the outcome that action is meant to support. “Localize the AI course” is not a usable scope. “Adapt the first lesson so a learner can understand and complete one named prompt-writing exercise” is.
Record a success condition and a stop condition beside it. For example, the work may stop if the exercise depends on an unapproved tool substitution, or if the lesson’s promised outcome would have to change. These are planning conditions, not test results.
Decision: If the team cannot choose a first learner action, mark the project HOLD — scope is still a slogan.
Gate 2: Separate the objects from the learner-facing surfaces
List what is actually in the first scope: lesson pages, videos, quiz questions, downloadable files, live sessions, emails, app screens, support instructions, and any other relevant object. Then list which learner-facing surfaces will change: language, instructions, examples, screenshots, exercise steps, or support copy.
This is where the Teachable and Kajabi references help. They do not prescribe a universal workflow; they demonstrate that a course platform can treat language surfaces and course objects as distinct operational things. A translated web page therefore cannot stand in for a review of every learning surface, and a copied lesson cannot stand in for a teaching redesign.12
Decision: If an object or surface is unknown, it may be excluded from the first scope, but it may not be silently assumed to be covered.
Gate 3: Declare the asset route before promising the asset
For each in-scope object, write the intended route: retain unchanged, adapt, replace, defer, or route-test. This is not yet a platform-selection exercise. It is a record of what the project is assuming.
An illustrative example: a team might put recorded lessons in the first scope, defer a live office hour, and route-test a workbook before it is promised to learners. The decision is not that one format is better. It is that the initial scope should not contain an asset whose route is still an invisible question.
Decision: If an essential asset has no stated route, mark it HOLD — route unknown. If it is non-essential, defer it rather than letting it delay every other decision.
Gate 4: Put approval authority next to every meaningful change
The most expensive ambiguity is often not a technical one. It is the sentence, “We can probably change that example.”
For each proposed change, name the source rights holder or designated reviewer, the change they may approve, and the record that would prove approval. Examples and screenshots can carry teaching meaning; a quiz can change the assessment; a replacement tool can change the promised learner outcome. A general conversation or commercial interest is not a substitute for a scoped written approval.
Decision: No written authority for a material change means HOLD — authorization gap. Do not translate first and ask permission after the changed version exists.
Gate 5: Treat the dependency and terminology inventory as an input, not a verdict
The published Course Dependency and Terminology Inventory is the companion record for source terms, teaching claims, dependencies, assets, and change authority. It answers: What are we dealing with, and what cannot drift?
This checklist asks a different question: Does that record now support a start decision? A filled inventory can still lead to HOLD. A glossary does not prove rights, a dependency list does not prove a workable route, and a proposed Chinese rendering does not prove that the teaching experience is ready.
Decision: Link the current inventory version. If essential entries are still unclassified or have no accountable owner, mark HOLD — critical input incomplete.
Gate 6: Write the test that turns readiness into evidence
Every unknown that matters needs a test card: what will be checked, by whom, on which date, in what region or account/device conditions where relevant, and what outcome would stop the work.
This is intentionally not a claim that a test has happened. It is the bridge between a planned adaptation and a controlled validation. For an end-to-end example, see OriBridge’s Access, Payment, and Delivery Test Script. A readiness checklist may identify that a route needs testing; it cannot report the result before that test is recorded.
Decision: If a critical unknown has no test owner, date, or stop condition, mark ESCALATE — an important uncertainty has no path to resolution.
Put the decision on one page
The checklist is useful only if someone can read the record and make a call. Start a new sheet when the scope or a material route assumption changes. Keep the previous version as evidence instead of silently overwriting it.
Use the seven fields below for every gate. Decision, evidence tier, version, owner, boundary, and status are part of the record, not optional notes.
| field | decision this field supports | evidence tier | version | owner | boundary to record | status |
|---|---|---|---|---|---|---|
| first learner action | what the first work package is allowed to change | D: recorded plan | sheet ID + date | scope owner | named action, bounded outcome, success and stop condition | GO / HOLD |
| objects and surfaces | what is included and explicitly excluded | B–D: official object rule, inventory, or hypothesis | inventory version | content owner | lesson, quiz, asset, live component, interface and support surface | READY / INCOMPLETE |
| asset route | whether each promised object has a stated route | B–D: first-party rule or pending route test | route assumption version | delivery owner | retain, adapt, replace, defer, or route-test; named context only | KNOWN / TEST / HOLD |
| approval authority | whether a material change may begin | A: scoped written approval | approval record ID/date | rights holder or designated approver | change type and the limit of the approval | APPROVED / HOLD |
| dependency input | whether critical terms and dependencies have accountable treatment | A–D: linked source record | H3-11 inventory version | product owner | unresolved critical entries and what the inventory cannot prove | READY / HOLD |
| validation plan | how an important unknown will become evidence | C: dated plan, not a result | test-card version | named test owner | region, account/device conditions where relevant, decision rule and stop rule | PLANNED / ESCALATE |
| conclusion | whether the bounded package can start | lowest tier among critical fields | sheet version | decision owner | one-line reason plus what GO does not mean | GO / HOLD / ESCALATE |
The letters are working evidence tiers for this worksheet: A is scoped written authority or an approved source record; B is a current first-party rule for the named context; C is a controlled test record or a dated test plan clearly labelled as untested; D is an editor-recorded hypothesis or planning decision. A lower tier is not automatically bad. It tells the decision owner what remains assumed.
Do not copy a row without its boundary. A platform note that cannot be re-opened today cannot support a current route decision. The approval row is even stricter: if the change is material and the record is not A-level written authority, the status is HOLD.
The labels should be blunt:
- GO (scoped only): the first work package has a defined boundary, relevant authority, and an accountable plan for what remains untested.
- HOLD: a missing scope, route, approval, or critical inventory item makes work premature.
- ESCALATE: the question is real and material, but no accountable person or valid test path can settle it yet.
“GO” never means “China-ready.” It means only that the named, limited work package can start without pretending its unknowns have disappeared.
When the adaptation decision moves into access, payment, delivery, or platform configuration, continue in the Access, Platforms, Payments & Delivery Knowledge Hub. It is the current next-stage entry for those decisions.
When this checklist is the wrong tool
Do not use a readiness worksheet to decide whether China is a worthwhile market, whether a platform accepts a particular operator, or whether a course will sell. Those are different decisions with different evidence requirements.
It is also the wrong tool when the product owner has not agreed that any adaptation is under consideration. In that case, a neat checklist can create false momentum. Keep the work at research or discussion stage until there is a real request and a legitimate decision owner.
Likewise, a team should not use it to make legal, privacy, tax, payment, account, or access conclusions. Those facts are configuration-, entity-, and date-specific. The worksheet can flag the need for review; it cannot replace it.
Start smaller than the course
The most credible first move is usually one representative lesson or workflow, not a full curriculum. Use the broader localization dependency guide to see why the learner journey may contain more work than the script suggests. Then use this checklist to decide whether the first bounded adaptation package has earned a GO.
If you have a representative lesson, a clear learning action, and a person who can approve changes, request a scoped China validation review. Bring the unresolved items too. A useful review starts by making those visible, not by hiding them behind a translation timeline.
Sources, evidence boundaries, and update note
- [S1] Teachable, How do I translate my school?. Rechecked 2026-08-13. Supports the limited distinction between automatic translation of student-facing web text and its non-application to Teachable mobile apps. It does not prove delivery conditions in China.
- [S2] Kajabi, Import a Course lesson or quiz. Rechecked 2026-08-13. Supports the limited point that lessons and quizzes are separately managed import objects. It does not prove a China route, usability, or outcome.
What this article cannot prove: that any course has permission to be translated or adapted; that a platform is available to, accepts, or can pay a particular entity; that a learner can access or complete the course; or that localization will produce commercial or learning results. Recheck dynamic platform documentation and record product-specific approvals before acting on a GO decision.