An attendance export answers a narrow question: which accounts, or which names, appeared to enter a scheduled session? It does not answer whether a learner could watch the replay, received the promised materials, completed a task, or needed help. For a China-facing course, those are separate operational facts.
This distinction matters whenever an overseas team reports a pilot to a partner. “Twenty-two people attended” sounds complete. It may actually hide a broken replay link, a missing worksheet, or a login failure affecting three of the people who were counted. The responsible record is not a bigger attendance number. It is a short chain of evidence with each layer labelled.
The four layers
Attendance. Record the session, scheduled time zone, participant identifier as displayed by the system, join and leave information where available, and any stated attendance rule. Do not turn a display name into verified identity. Tencent Meeting documentation describes participant and check-in surfaces; it does not independently verify who was sitting behind an account.
Replay access. Record whether a replay was created, when it became available, who was given access, and whether a controlled test account could open it. A replay file is an asset, not proof that every learner received or used it. ClassIn’s LTI material separates historical recordings and reports from other classroom data. That separation is useful precisely because it prevents one field from doing several jobs.
Task or material receipt. Record the worksheet, reading, prompt, or submission expected after the session, plus the delivery channel and timestamp. “The slide deck was uploaded” is not the same as “the learner received the deck.” If the programme promised no task, write “not in scope” rather than inventing a completion field.
Support and exception. Record access errors, missing links, language questions, schedule conflicts, or content corrections separately. A support event should have a status, owner, next action, and closure time. It should not silently overwrite the attendance result.
A practical delivery card
Use a row per session or cohort, not one celebratory sentence:
| Layer | Evidence to retain | Safe wording |
|---|---|---|
| Attendance | exported participant list and session window | “22 displayed participants joined.” |
| Replay | URL or platform record plus controlled open test | “Replay was available to the test account at 16:20.” |
| Task | material name, destination and submission state | “Worksheet sent; 9 submissions recorded.” |
| Support | ticket, category, owner and resolution | “3 access incidents; 2 closed, 1 pending.” |
This card is deliberately unglamorous. It gives a reviewer enough information to ask the next question without pretending that a dashboard metric is a learning result. ClassIn 5.0 describes activities, progress and capability indicators as distinct product surfaces. That is a strong design clue for operators: keep the fields distinct in your own report.
Illustrative scenario
Imagine a two-hour workshop for a China-facing cohort. Twenty-two accounts appear in the sign-in export. Eighteen can open the replay. Nine submit the exercise. Three report that the login route fails on their device. The honest summary is: “22 displayed participants joined; replay access was confirmed for 18; 9 submissions were recorded; 3 access incidents were logged.”
That sentence is more useful than “22 learners completed the workshop.” It tells the delivery team where to investigate and lets a buyer decide which obligation has actually been met. It also preserves uncertainty: the export does not prove that all displayed names were the intended learners, and a submission does not prove mastery.
The counterexample: when attendance is enough
There are cases where attendance is the only promised deliverable. If a contract says “a two-hour briefing will be hosted for invited participants,” a valid attendance export may be sufficient evidence that the briefing occurred. The mistake is not using attendance. The mistake is extending it to claims the scope never covered: replay consumption, task completion, skill acquisition, or business impact.
Write the narrow commitment beside the metric. “Briefing hosted; attendance export retained” is defensible. “Training completed successfully” is a different claim and needs different evidence.
What this record cannot prove
Even a carefully completed delivery card cannot prove identity authenticity, teaching quality, certificate validity, learning outcomes, platform reliability beyond the tested moment, or compliance with every privacy rule. Those questions require their own evidence and, where appropriate, specialist review. Chinese platform documentation describes interfaces and capabilities; it does not convert a product feature into a legal or educational conclusion.
For a broader path test, see End-to-End Access, Payment and Delivery Test Script. For the distinction among a room, broadcast and replay surface, read China-Facing Live Cohort Room, Broadcast and Replay. The evaluation logic behind buyer, problem, alternative and delivery is set out in Buyer–Problem–Alternative–Delivery Worksheet.
A small operating rule
Before reporting a China-facing delivery, ask four questions: What was attended? What could be opened? What was received or submitted? What went wrong and who owns it? If a question is out of scope, mark it out of scope. A trustworthy record is allowed to contain blanks, pending items and exceptions.
If you need a scoped review of the evidence your course would require in China, submit a validation request. It is a request for assessment, not a promise of platform access, eligibility or commercial outcome.
Sources and evidence boundary
- ClassIn LTI — checked 2026-08-23. Supports the existence of classroom, attendance, interaction, recording and report surfaces; does not prove a specific learner’s delivery or outcome.
- ClassIn 5.0 — checked 2026-08-23. Describes activities, progress and capability indicators as product concepts; does not prove capability improvement.
- Tencent Meeting Personal Center — checked 2026-08-23. Describes participant and check-in management; does not prove identity or attendance quality.
Before the next session
Create the delivery card before opening the room. Name the session, cohort, owner, promised outputs and time zone. Decide in advance what counts as attendance and whether a replay, task or support response is in scope. This prevents the team from changing the definition after seeing a favourable number.
After the session, export the source record without editing names into a marketing summary. Add a plain-language interpretation beside each field. If an export is unavailable, write that the field is unavailable; do not infer it from chat activity. A participant who posted in chat may still have joined late, and a silent participant may have followed the session. These are reasons to preserve the raw evidence, not reasons to manufacture certainty.
For replay, test the route as the intended learner would encounter it. An administrator view can conceal a permission problem. For a task, save the instruction and the destination together, because a submission without the original prompt is difficult to interpret. For support, record whether the issue was caused by the platform, the delivery configuration, or an unanswered question. The cause may remain unknown until a test is run.
Keep a version of the card. If a replay permission is repaired on Tuesday, the original failed state still explains why a participant contacted support. Do not overwrite it with the later green result. A short timestamped change note is enough. The record then tells a sequence: what was promised, what was observable at delivery, what failed, and what was repaired.
That sequence is particularly useful when a pilot has more than one delivery surface. A live room, a replay page and a file-sharing link can each be open while the learner’s journey is still broken between them. Record the handoff, not just the existence of each component. If a participant can see a replay but cannot find the worksheet, the correct state is partial delivery. The phrase may sound cautious, but it tells the team exactly what to test next.
The record should remain readable to a buyer who never saw the platform. Use ordinary nouns, links, timestamps and pending states. Avoid turning a vendor’s internal status code into a promise. A human reviewer should be able to reconstruct the delivery without guessing what “complete” meant.
That readability is part of delivery quality: evidence that cannot be understood cannot reliably support acceptance.
Keep the raw export and the interpreted card together, with access limited according to the team’s own controls.
The card is an operational aid, not a public case study.
It should help the next operator find evidence, test a route and state what remains unknown.
At review time, compare the card with the promise made to the buyer. If only a live briefing was promised, the completion decision may end at “briefing hosted.” If a replay and exercise were promised, those are separate acceptance checks. The card should make the difference visible to someone who did not attend the meeting.