A Secondary student in Clementi opens a timed online Mathematics practice at the kitchen table. Twenty-five minutes appear on the screen. Seven minutes later, the Wi-Fi icon drops out. The fraction question is still visible, the student can still type, and the countdown continues. When the connection returns, the result may depend on how the particular quiz system handles timing, autosaving and submission. It is tempting to call this one technical problem. There are actually several separate questions hiding inside it.
Why does an online quiz timer keep running after the internet disconnects? Does losing Wi-Fi pause a timed assessment? Is an answer stored when it is visible in the box, or only after the platform acknowledges it? These are familiar questions for learners, parents and teachers using online practice, school learning platforms and digital tests. The useful answer begins by separating time, connection, answer storage and final submission instead of treating the screen as a single reliable witness.
The important distinction is surprisingly simple: a quiz can have a deadline even when the student’s device temporarily cannot communicate with the server. A countdown displayed locally may continue; a server-side deadline may continue; a platform may have offline support or may not. None of those possibilities establishes what actually happened in a particular assessment. The remedy is not to guess from an icon. It is to check the platform’s rules, observable states and submission record.
The 50-second answer
A timed online quiz usually involves at least three moving parts: the permitted time window, the network connection and the stored attempt. The permitted time may be measured by the assessment service and may not pause when a device disconnects. The page may continue showing a countdown even while it cannot save answers. Some platforms autosave or recover responses; others require specific actions or connectivity. At expiry, some systems submit automatically, some allow a configured grace period, and some do not count unsubmitted work. There is no universal internet-disconnection rule across school platforms.
Students should learn the legitimate evidence route: note when the issue occurred, preserve a non-sensitive screenshot when school rules permit, reconnect through the allowed method, check the attempt/submission status and tell the teacher promptly. Parents should help document rather than invent a technical explanation. Teachers should use the system’s attempt record and local assessment policy to distinguish a knowledge error from an access incident. For high-stakes assessments, follow official instructions immediately; do not restart, change devices or seek extensions in ways the rules prohibit.
One screen, four different truths
Picture the assessment as four related records. The clock record answers how long the attempt is permitted. The connection record says whether messages can travel between the browser and the service. The answer record says which responses the service has actually stored. The submission record says whether the attempt reached the final state that the assessment recognises. On a smoothly functioning afternoon, these records seem fused: the student types, a save indicator flashes, and the task ends. A disconnection pulls them apart.
The visible answer box can contain words that exist only inside the student’s browser. A green progress marker may describe that a question was visited, not that its latest answer reached the server. A timer can be a display of an agreed deadline, not a mechanism controlled by Wi-Fi. A final score may reflect only the answers stored before the last successful sync. It follows that the statement “I answered it” is different from “the platform received this answer” and different again from “the attempt was submitted”. All three can be true together, but one does not prove the others.
This separation is useful beyond computers. A handwritten answer sitting on a desk is not yet an answer handed in. A sealed envelope in a school bag is not a delivered form. Digital systems make the intermediate stages less visible, which is exactly why learners need better evidence language rather than more blame.
Start with the rule, not the countdown animation
A timer is a policy rendered on a screen. Before interpreting it, identify the rule it represents. Is the task open for a whole week but each attempt limited to twenty minutes? Does the limit begin when the student clicks Start, when the first question is delivered, or at a fixed clock time? Can the teacher override the duration for an individual learner? Is the task formative practice with retry rights, or a one-attempt graded test? Each setting changes the student’s legitimate options.
Moodle’s documented quiz settings illustrate why such distinctions matter. Its quiz configuration includes a time limit and different behaviours when time expires: automatic submission, an optional grace-period route, or a requirement to submit before expiry. A school using Moodle might configure one behaviour; a different school using the same software could configure another. A different platform may implement time limits differently again. Thus “Moodle does X” is weaker than “this quiz, on this site, with these settings, did X”.
Teachers can reduce avoidable uncertainty by explaining the clock rule before assessment. Students can practise asking four questions: when does time begin; what ends it; does the platform confirm saves; and what indicates final submission? These questions take seconds to teach and make troubleshooting more precise later. They also help students plan when to finish writing and when to verify submission, without implying that they should submit unusually early.
A timeline that reveals the hidden states
Consider an entirely illustrative twenty-five-minute quiz. At 10:00, the learner starts. At 10:07, the network fails. At 10:09, the learner enters a correct answer into Question 6. At 10:12, Wi-Fi returns. At 10:25, the permitted duration ends. The temptation is to say the student had twenty-three effective minutes, or that Question 6 definitely saved at 10:12. Neither follows automatically. We need more records.
Imagine Scenario A: the browser caches local inputs and resynchronises them after reconnection, while the server maintains the original end time. Question 6 is received, but the student still has eighteen minutes after reconnection rather than a restarted clock. Scenario B: no offline save occurs, so Question 6 appears locally but is lost when the page reloads. Scenario C: the platform explicitly pauses or extends the attempt for eligible interruptions. Scenario D: the timer expires before a final network transaction succeeds and the attempt enters a configured overdue state. These are alternative system designs, not statements about any particular student’s school.
A good incident record marks observable events without pretending to know which design applies. “At 10:07 the connection indicator showed offline; at 10:12 the page reconnected; the save indicator had not appeared for Question 6” is usable. “The platform deleted my answer” may be premature if the platform’s audit log has not been checked. Precise observations increase the chance of a fair response.
Why a browser can display a clock while offline
A browser is capable of displaying changing numbers without asking the internet for a new picture every second. JavaScript running on the device can update a countdown using an earlier start time or deadline. The page may receive a time allowance at the beginning and calculate what remains locally. Alternatively, it may receive occasional updates from the server or display an approximation. The exact implementation is platform-specific.
There is a deeper reason that the display cannot be the sole authority. A computer’s local clock can differ from a server’s clock. A tab can be suspended, a device can sleep, and a browser can resume from the background. Secure assessments therefore cannot simply trust a student’s editable local timer as proof of permitted duration. A server-side record or other authoritative timing mechanism is often relevant. None of this means every timed practice uses the same technical architecture.
For a student, the teachable concept is a distinction between an indicator and the state it indicates. A phone battery icon estimates charge. A thermometer displays a reading. A countdown displays a representation of remaining time according to some timing model. Good learners ask where the underlying state is maintained. They do not need to become programmers to see why a frozen or moving timer alone cannot settle a dispute.
Internet access is not one on/off switch
When a learner says “the Wi-Fi went down”, several different events might be meant. The device may have disconnected from the wireless router. The router may still work while its internet connection fails. The school’s quiz service may be temporarily unreachable even though other websites load. A login session may expire while the physical connection remains strong. A video or diagram hosted on another service may fail even while the quiz page itself continues. Each failure produces a different recovery route.
This is not an invitation to conduct a complicated network experiment during a timed test. During an assessment, follow the school-provided support route and avoid changing settings that might invalidate the attempt. After the incident, however, a teacher or technician can ask what the student actually saw: disconnected icon, spinning save wheel, server error, login screen, missing media, or a submission error. Describing a precise symptom protects the difference between a learning challenge and an access failure.
For home practice outside a formal assessment, a student can learn basic preparation: stable connection, charged device, correct login, allowed browser, needed accessibility settings and a quiet work surface. Preparation reduces avoidable interruptions but cannot guarantee that a network, website or device will remain available. A fairness policy must account for the possibility that technology sometimes fails despite reasonable preparation.
The three meanings of save
“Saved” can be an ambiguous word on learning platforms. First there is a local input state: the answer exists in an editable field visible on one device. Second there may be a stored draft state: the service has acknowledged that the answer or attempt data reached its storage system. Third there is a final submitted state: the student or platform has completed the attempt under the assessment’s rules. Some interfaces combine these states, but they remain conceptually different.
Suppose a student types “12.5 cm” and sees the full expression in the box. That proves that the input field contains the expression at that moment. A small “Saving…” label proves only that the interface is attempting or representing a save operation, not necessarily that a durable acknowledgement has arrived. A label such as “All changes saved” may indicate success, but its precise meaning still depends on the system. A receipt or attempt record that includes final status is stronger evidence of submission than a screenshot of a filled response field.
Mature school workflows make status labels understandable. “Draft response saved at 10:12”, “Attempt submitted at 10:23”, and “Feedback available after closing time” tell learners which event occurred. Vague statuses such as “Done” or “Complete” can blur the distinction between finishing thought, saving data, submitting work and receiving a mark. That ambiguity is a design problem, not an intelligence test.
What the timer can and cannot prove about a student
A timed quiz can reveal something about performance under a specified time constraint. It cannot by itself tell a teacher why a response was missing. One student may leave a question blank because the concept is unknown. Another may know the method but run out of time. Another may enter an answer in an offline field that never synchronises. A fourth may misread a page navigation instruction and leave a response on an unsent screen.
These different paths can produce similar gradebook records. The lesson is not that online tests are useless. It is that a score is a compressed report of a performance in a particular environment, not a perfect diagnosis of every underlying capability. If the assessment intends to measure Mathematics reasoning, then unexpected network failure introduces a factor unrelated to that reasoning. The teacher should be able to distinguish legitimate accommodations or technical incidents from ordinary timing constraints, using authorised records and school policy rather than ad hoc guesses.
For low-stakes practice, it is often productive to separate the student’s unaided mathematical explanation from the platform incident. Ask the student to solve an equivalent problem independently on paper after the issue is resolved. That can help diagnose knowledge while preserving the fact that the original attempt’s status is a separate administrative question. The new solution should not be passed off as the original timed response.
An English example: answer present, save uncertain
A Secondary 2 learner writes a short explanation of a character’s decision. The text is 140 words long and responds carefully to the source passage. Just before submission, the page loses connection. The answer remains on screen. This is a different problem from a student who cannot construct an inference or who has supplied an unsupported quotation. The interface may be preventing the answer from becoming a stored response, even though the reasoning was completed.
The learner should not infer that the visible paragraph is safely stored. If school rules permit, record the displayed error and the timestamp, then follow the official recovery route. If a teacher requests an explanation, describe the event and avoid editing the answer after the fact while claiming it is the originally timed version. The distinction matters for fairness. The teacher’s aim is to establish what was submitted or reliably observable, not to reward the student who can tell the most persuasive technical story.
For writing instruction, this episode also teaches a small transferable skill: a text’s quality and its delivery state are different. An excellent paragraph can fail to arrive. A poorly argued paragraph can submit perfectly. Schools should not confuse the two when deciding what a learner needs to practise next.
A Mathematics example: the final number is not the whole attempt
Suppose a learner completes a ratio question and enters 18. The visible box shows 18, but no server acknowledgement appears. The next question asks for a reason, and the student types a two-step explanation. Later, the gradebook shows Question 7 unanswered. The teacher cannot determine from the score alone whether the learner lacked the ratio method, skipped the question, or encountered a failed save.
One practical response is an evidence matrix with three columns: what the student reports, what the platform recorded, and what a separate learning check shows. The platform might record no server-side answer. The student might provide a contemporaneous, school-permitted screenshot of a filled field. A later independent question might show the ratio method is understood. These facts can coexist without proving that the original answer was successfully submitted. The school determines the permitted assessment response; the teacher determines the instructional response.
This prevents two opposite mistakes. We should not call a student weak at ratios solely because a disconnected field was lost. But we should also not overwrite the exam record merely because a student can solve the question later. Procedural fairness and instructional diagnosis belong to different decisions.
A Science example: a missing diagram, not a missing concept
An online Science quiz presents a circuit diagram embedded from a different media service. The question text and answer fields load, but the diagram does not. The timer continues. A student who knows electrical circuits cannot infer which bulbs or batteries the missing diagram contains. The platform may still collect a blank or guessed response. This is a presentation failure, not evidence that the student lacks the scientific concept.
Notice how this differs from a normal scientific uncertainty. In an experiment, missing observations can be a legitimate data limitation; in a quiz, an essential absent figure can make the question underdetermined. The teacher should check the resource dependency, the question version and access logs where available. A low-stakes replacement item may test the intended concept more fairly. Again, exact accommodation or re-assessment rules are institutional, not something this article can prescribe universally.
This example makes the broader principle visible: valid assessment requires the task to be available in the form necessary to perform it. A student should not have to guess hidden visual information because one embedded asset failed to load.
A teacher’s preflight is an assessment-design lesson
Before assigning a timed online test, teachers can run a brief preflight using a test student account if the platform permits. Confirm the start and end conditions, the save indicator, the final submission screen, time-zone display, accessibility features, supported browsers and the school’s interruption procedure. Test a short response and an uploaded response if both formats are used. If the test contains externally hosted diagrams or videos, check whether those assets are reliably available to the intended class.
It is tempting to make this a forty-item technology checklist. That can turn a simple quiz into another administrative burden. Prioritise risks that could alter the assessment outcome: unrecorded answer, inaccessible essential material, ambiguous timing, inability to submit, or a status the student misreads. Teachers should know whom to contact for technical escalation and what evidence school policy allows them to review.
A preflight cannot prevent an unexpected outage at 10:07. It can, however, make the next action legible. If students know what to do when a red error banner appears, they are less likely to compound the incident by opening multiple tabs, repeatedly submitting duplicate attempts or switching devices in a way that creates an even less clear record.
What learners should do before starting
For ordinary practice, preparation is small and concrete. Check that the correct task is open, identify the time allowance and due date, read the submission instructions, close unnecessary network-heavy apps and make sure required materials are ready. On a shared household network, ask whether a large download or video call is expected during the quiz. If the task is high stakes, follow the school’s approved device and network rules rather than improvising your own setup.
Then practise the exit route on a non-assessed sample task if one is provided. Many students can find the Start button instantly but have never observed the difference between Save, Next, Finish and Submit. A low-stakes practice run makes those labels familiar before the timer creates urgency. Such rehearsal is not gaming the quiz. It is learning how to use the assessment interface so that it measures the intended academic skill rather than accidental navigation knowledge.
Learners should also know how to ask for help without sharing passwords, authentication codes or other private data. An incident report needs the task name, time, general device or browser context and the visible error. It does not need a password screenshot. Responsible evidence collection protects both learning and privacy.
What to do during a disruption
First, do not assume the timer will stop. Second, do not keep typing indefinitely under the belief that everything is being saved. Third, follow the school’s stated disruption procedure. That may involve notifying an invigilator immediately, using a permitted support channel, waiting for authorised instructions, or recording a timestamp. The correct sequence depends on the assessment rules. For supervised tests, the invigilator is the decision-maker, not this article.
Where allowed, record facts rather than theories: the question number visible, a save status, an error code, time displayed and what action was attempted. Avoid refreshing or logging in elsewhere unless authorised; those actions could affect session state or create additional attempts. If the issue resolves, look for an explicit save acknowledgement and final submission record. A page that merely looks normal again is not always evidence that every intervening answer arrived.
After the task, send one concise report through the authorised channel. Repeating the same request in several channels often creates inconsistent timelines and wastes time for everyone. Keep the original evidence if the school asks for it, and do not alter screenshots to make the event look more dramatic. Clarity wins here.
What parents can do without becoming the examiner
A parent may understandably be upset when a child knows the material but a quiz records an incomplete attempt. Useful support starts with the child explaining what happened in their own words, then checking any permitted status or receipt. Ask about observations: what did the screen show, when did the issue begin, what happened after reconnecting? Avoid a sweeping accusation such as “the entire platform is broken” unless there is evidence of a broader incident.
Next, help the child separate two questions: “What does the school need to resolve about this attempt?” and “What do we need to learn academically?” Those answers can differ. The first may require an authorised platform audit or policy decision. The second may simply require revising the ratio method or preparing for a different kind of writing task. A child should not spend the entire evening repeating a worksheet whose missing mark was caused by a delivery incident.
Parents can also reinforce honest reporting. A learner who says “I don’t know whether it saved” is giving a precise answer, not failing to defend themselves. That precision is a form of digital literacy.
What teachers can infer from the platform record
A platform may expose an attempt start time, last saved answer, submission time, status changes and access logs. The amount of information varies by provider and school configuration. Teachers should interpret logs within their limits. A missing server event does not necessarily prove a student’s account false; it may indicate the event never reached the service. Conversely, a screenshot of a typed answer does not prove successful server submission.
The strongest evidence is often triangulated: server record, interface evidence, incident timing, classroom supervision and a separate learning check. The teacher should then apply the school’s assessment policy consistently. If some students experienced the same platform incident, the question may be systemic rather than individual. If a student repeatedly struggles with navigation while the network is healthy, additional interface teaching or accessibility support may be more appropriate than extra subject drills.
Respect data minimisation. Avoid circulating students’ raw screen recordings or personally identifying details beyond those with a legitimate role in resolving the incident. An audit should establish what happened, not create a new privacy problem.
Common failure modes and their repairs
Failure one: treating the moving countdown as proof that the server is connected. Repair by separating local display from network acknowledgement. Failure two: treating visible text as saved work. Repair by looking for the platform’s actual save or submission status. Failure three: assuming every school uses the same quiz settings. Repair by reading the current task and platform configuration. Failure four: refreshing repeatedly under stress. Repair by following the authorised recovery steps. Failure five: inventing a cause before reviewing evidence. Repair by recording observable events first.
Failure six: letting a technical incident become a diagnosis of weak subject knowledge. Repair with a separate, clearly labelled learning check. Failure seven: using the later learning check to rewrite the original submitted record. Repair by keeping assessment decisions and instructional decisions separate. Failure eight: giving every student an identical technical remedy without considering accessibility and policy. Repair by using established institutional routes. Failure nine: collecting excessive personal data. Repair by capturing only what is needed. Failure ten: never teaching the submission interface. Repair with an authentic low-stakes practice attempt.
These failures share a pattern: one visible signal is being asked to represent an entire unseen process. The solution is not more suspiciousness; it is a better map of states and the evidence attached to each.
A ten-minute classroom simulation without real marks
Teachers can illustrate the mechanism using a fictional task and paper cards. Give each group four cards labelled Clock, Connection, Stored Answer and Submission. Read an event: “The learner types a response. The network is unavailable.” Students move only the state cards supported by that information. Can they say the answer is on screen? Yes. Can they say it is stored on the server? No. Can they say the time limit has paused? Not from the fact of disconnection alone.
Next event: “The system displays an acknowledgement that the response was saved.” The stored-answer card may now move, subject to the meaning of that acknowledgement. Final event: “A receipt states that the attempt was submitted at 10:23.” The submission card changes. Add a competing event where the question image never loaded. Students must decide whether that is a Mathematics error, a resource-access problem or something else.
The exercise works because it requires restraint. Students practise saying “not enough evidence yet” in a situation where premature certainty is common. The teacher can finish by making the actual school instructions visible, then letting students rehearse the correct help route.
The deeper educational point: valid performance needs a valid path
Education often talks about knowledge and marks as though a direct wire connects them. In reality, the learner must perceive the task, understand the demand, produce a response, enter it into a medium and deliver it under the allowed rules. Break the route at any point and the score may no longer describe knowledge alone. This does not mean every platform problem invalidates every assessment. It means that the observed performance includes conditions, and those conditions sometimes deserve inspection.
CAST’s Universal Design for Learning framework encourages educators to consider barriers in representation, action and expression. A timed quiz can be perfectly fair in its academic questions yet inadvertently depend on inaccessible navigation or unclear submission states. The appropriate response is to preserve the intended learning demand while reducing avoidable, unrelated barriers where policy and assessment integrity allow.
The result is a more useful conversation. Instead of “I got zero because the internet hates me” or “the child must be careless”, people ask: What was the intended construct? What was visible? What was stored? What was submitted? Which decision belongs to the teacher, and which belongs to the platform or school? Those are answerable questions.
The evidence packet after a disrupted attempt
A calm incident report should be small enough that a teacher can use it, yet precise enough to separate a learning mistake from a delivery mistake. Start with the assessment name, the question or section affected, the approximate local time, the device and browser, and the last action the student knows was accepted. Add what the screen actually said. “The timer displayed six minutes when the page stopped responding” is an observation. “The system stole six minutes” is an interpretation that might turn out to be correct, but it cannot be established from the screen alone. Keep these two kinds of statement separate.
Suppose a Clementi student begins a twenty-minute fractions quiz at 4:05 pm, answers three questions, then loses connectivity at 4:13 pm. The page returns at 4:18 pm and shows two minutes remaining. The student remembers writing an answer to question four but cannot see whether it saved. The usable report says: “Connection message appeared at around 4:13; the last visible saved-answer indicator was on question three; the attempt reopened about five minutes later with two minutes displayed; I did not see confirmation that question four was saved.” The teacher can now compare the attempt log, quiz configuration and any autosave information. The report does not pretend that the learner can inspect server records.
What should happen next depends on the purpose of the quiz. In a low-stakes practice exercise, the teacher might reopen the affected item, review the concept separately, or provide an untimed equivalent. In a formal assessment, a prescribed procedure may apply, and the student should follow that procedure rather than relying on a parent’s suggested fix. The point is not that every interruption warrants extra time or a higher mark. The point is that decisions about performance should be based on the best available evidence about what was taught, what was asked, what was attempted and what the platform actually received.
Students also need a privacy boundary. A screenshot should show the relevant message and time, not unrelated classmates’ names, passwords or personal conversations. If the task uses a school account, report the incident through the school’s designated channel rather than posting login details in a group chat. This protects the student while preserving a usable record of the learning event.
FAQs
Does Wi-Fi disconnection automatically pause an online quiz timer?
No universal rule says it does. A quiz may use a server-side deadline that continues while a device cannot connect. Some platforms or institutional policies provide recovery or accommodations; others have different overdue handling. Read the actual task rules and follow the school’s instructions rather than relying on a general internet claim.
Can the countdown continue even if an answer is not being saved?
Yes, that is technically possible because the countdown display and answer-saving channel are separate functions. A running timer is not proof of a successful network save. The platform’s save acknowledgement and the attempt record are more relevant to the storage question.
Is a screenshot enough to prove my answer was submitted?
A screenshot can be useful evidence of what appeared on the screen at a particular moment, if captured and retained under school rules. It does not by itself prove server receipt or final submission. Preserve any official submission record and let authorised staff inspect the attempt state.
Why did my attempt close before the due date?
A task may have both an overall availability window and a shorter per-attempt time limit. Another possibility is a scheduled closing time that ends the attempt. The rules differ by platform and configuration. Check which clock governed the task before assuming a technical error.
Should a student open another browser or device after a disconnect?
Not without checking the authorised procedure for that assessment. Starting another session could create duplicate attempts or violate exam conditions. For low-stakes practice the school may provide a safe recovery method; supervised exams often have stricter rules.
Can teachers distinguish a lost save from a wrong answer?
Sometimes the platform’s logs, timestamps and the student’s permitted evidence help. Sometimes the available records remain inconclusive. A separate independent learning check can still guide instruction, but it should not be confused with proof of what was originally submitted.
Should parents demand a mark change when a connection fails?
Parents can request a fair review under school policy and provide factual evidence. The outcome depends on the assessment rules, available records and context. A later correct answer is valuable academically but is not automatically the same as an on-time submitted response.
Do accessibility accommodations change how timers work?
They may. Systems and schools can provide extended duration or alternate formats under established accessibility policies. The presence and exact operation of those supports must be confirmed with the institution; no student should assume an accommodation has been applied without checking.
Is a practice test with no time limit better for learning?
Not always. Untimed tasks can isolate knowledge from speed and navigation demands, while appropriately timed practice can teach pacing where speed is genuinely part of the target performance. The choice should follow the learning purpose, not a blanket belief that either timed or untimed work is always superior.
Sources and research notes
This explanation distinguishes public platform documentation from general education principles. MoodleDocs, Quiz settings, describes configurable time limits, automatic submission and grace-period behaviour; these are examples of one platform’s options rather than a universal school policy: https://docs.moodle.org/500/en/Adding/editing_a_quiz . Mozilla Developer Network, Offline and background operation, explains why local interfaces, network requests and background synchronisation can have different states: https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Guides/Offline_and_background_operation . CAST, UDL Guidelines version 3.0 (2024), provides the wider accessibility and action-expression framework: https://udlguidelines.cast.org . Education Endowment Foundation, Metacognition and self-regulation toolkit, reviewed May 2025, supports making planning, monitoring and evaluation explicit within subject instruction: https://educationendowmentfoundation.org.uk/education-evidence/teaching-learning-toolkit/metacognition-and-self-regulation . These sources do not establish how any particular eduKateSG learner’s platform behaves.
For a nearby but distinct explanation of how the physical response surface can influence expression, read Why the Answer Box Changes the Answer. For a different kind of learning-material failure, see Why a Homework Photo Can Be Harder to Read Than the Page. This article owns only the clock–connection–storage–submission boundary. It does not replace the school’s assessment regulations or those neighbouring explanations.
Takeaway: trust the event, not just the icon
Return to that Clementi kitchen table. The learner has a real answer, a real clock and a connection that has failed. Panic tries to compress the situation into one sentence. Better reasoning restores the missing distinctions. The answer could be on screen without being stored. Time could continue without a network connection. A stored draft could exist without final submission. The student could understand the Maths even when the attempt record is incomplete. When learners, parents and teachers know which question each signal can answer, an opaque incident becomes a manageable sequence of observations and decisions. That is useful digital literacy, and it protects the academic learning that the quiz was meant to reveal.