The course still plays. That is often the first reassurance a team gives itself after a producer leaves or a tool interface changes. But “still plays” is a thin definition of continuity.
Can anyone update the subtitle? Does the latest script exist? Who can explain a learner notice? Which version generated the worksheet? Is the support link still owned by someone who can answer? A video file can survive while the course becomes impossible to maintain.
A China course asset continuity pack is not a backup folder. It is a short, reviewable record of asset × owner × recoverability. Its purpose is to show which part of the learning product can be watched, which can be edited, and which can be responsibly changed.
The seven things a continuity pack should expose
| Asset layer | Record | Recovery question |
|---|---|---|
| Editable source | script, slide source, caption source, worksheet source | Can a named person revise it? |
| Learner-facing asset | video, PDF, module link | Can a learner still reach the intended version? |
| Course facts | course card, outline, FAQ | Who verifies each claim before it changes? |
| Language layer | terminology list and translation decisions | Can a new editor see why a term was chosen? |
| Version trail | date, change reason, affected lesson | Can a mismatch be traced without guessing? |
| Operations | reminder, support and escalation routes | Who owns the next learner-facing message? |
| Evidence record | delivery or completion records where applicable | What does the record actually show? |
This is deliberately not an account-transfer checklist. It does not offer advice on platform permissions, privacy, exports, payment settlement or legal rights.
A constructed failure that looks harmless at first
Picture a course whose original instructor leaves. The team retains a video master and an active learner link. So far, so good. A learner then asks why the Chinese subtitle uses a term that no longer matches the current exercise. The remaining team cannot find the editable subtitle file, the terminology decision or the person who approved the update. They can watch the course but cannot safely correct it.
That is the gap a continuity pack makes visible. The first response should not be “rebuild the course.” It should be a risk label: viewable but not editable; editable but not validated; or maintainable with named owners.
How it differs from a localization source package
A localization readiness review answers what must change in an adaptation. A continuity pack is broader and longer-lived. It asks what happens after the handoff—when the editor changes, a tool changelog appears, or an update has to reach existing learners.
Likewise, a dependency and terminology inventory says what a course currently relies on. Continuity asks whether the people and assets required to make the next change still exist. An end-to-end delivery test should not be used as a substitute for either.
Make the card before the disruption
Start with one module, not the entire library. Put the seven layers in a shared table. For every row, name an owner, link the current asset, and choose one state: recoverable, needs confirmation, or unknown. “Unknown” is useful. It is better than silently assuming the old editor can still be reached.
Then set a small trigger: a team change, a new course version, a broken learner link, or a public claim revision opens a review of the affected rows. This avoids both extremes—ignoring maintenance until it becomes urgent, and treating every interface change as a full relaunch.
Add recoverability, not just file locations
A folder link is only a location. It says nothing about whether the material can be used. For each row in the pack, add a recoverability state:
| State | Meaning | Appropriate next action |
|---|---|---|
| Recoverable | the editable asset, owner and current version can be identified | retain and review at the next trigger |
| Viewable only | learners can see it but the team cannot safely revise it | do not make new claims based on it; find the editable source |
| Needs confirmation | an asset exists but ownership, version or purpose is unclear | assign a short verification task |
| Unknown | the team has no reliable record | treat downstream promises as unconfirmed |
This vocabulary prevents a common argument: “we have the video, therefore we have the course.” A course includes decisions and relationships around the video. The state label lets a new team member see the difference without reading a long history.
A handover card for one module
For a single module, record these fields: module name; learner-facing URL; editable source location; last confirmed version; terminology list; exercise input; support route; person accountable for public wording; and open questions. Put a date next to each confirmed field. A date is not a guarantee that the information is still true; it tells the next reviewer where the confidence stops.
An especially useful field is change consequence. If the subtitle source changes, does the exercise change? If the learner link changes, who updates the course card? If a tool screenshot is stale, can the learning task still be completed? These are not technical trivia. They determine whether a change is cosmetic, operational or curriculum-level.
A test that does not require a crisis
Choose one module and ask a colleague who did not build it to locate the editable source, the current learner path and the owner of the next update. If any of the three takes more than a few minutes or produces competing answers, the continuity pack has found useful work.
Do not simulate account transfers, export learner data, or move platform settings as part of this test. Those actions can have permission and privacy implications. The exercise is an internal record check, not a migration procedure.
Counter-pressure: do not over-document a prototype
Continuity is not an excuse to turn every draft into a permanent archive. A prototype lesson may have no approved learner-facing route and no reason to preserve every interim file. Mark it as experimental, keep only the source necessary to decide the next test, and avoid publishing it as a maintained offering.
The continuity pack is strongest where a team expects change: a different editor, a revised terminology decision, an updated course card, or an ongoing learner obligation. It makes maintenance discussable before somebody leaves and a learner becomes the first person to discover the missing record.
A light review rhythm
Review the pack only when a real trigger occurs: a content change, ownership change, learner-path incident, or public promise update. At that review, compare the card with the actual learner-facing item rather than trusting an old spreadsheet. Confirm one thing at a time: the link resolves, the editable source is identifiable, the owner still accepts the responsibility, and the version note matches the visible course.
This rhythm is deliberately smaller than a full operational audit. It keeps maintenance attached to change. If an unknown field remains unknown after a review, leave the label in place and narrow any related public statement. A visibly incomplete record is safer than a complete-looking fiction.
The pack can also reveal a decision to retire an asset. If a module is viewable only, no editable source exists, and it is no longer essential to the stated learning job, the sensible outcome may be removal from the next course version—not an expensive rescue. That retirement decision should retain its rationale so the next editor does not mistake absence for an accident.
Before closing a review, record the single next owner and due date for every “needs confirmation” row. Otherwise an accurate pack can become a list of problems that no one is responsible for resolving.
When the pack is unnecessary
A one-time internal prototype with no learners, no support commitment and no future maintenance may only need a simple source folder. Do not build a governance system merely to show a three-minute demo.
The pack cannot guarantee recovery, access, sales, compliance or a time-to-fix. It can do something more honest: make fragile dependencies visible before they become a learner-facing failure.
For adjacent decisions, read what must change beyond translation, build a course dependency and terminology inventory, and use the end-to-end test script when the route itself needs proof.
Use a validation review to identify which assets must survive the first China-facing pilot, and which can remain experimental.