Mastery checkpoint: the project workspace

Where we are on the map

Can you say you understand the computer if three files open only on your own laptop and only while you give hints? This checkpoint tests another person’s independent use.

A familiar image and the precise model

Viewing pages creates familiarity but does not prove recall. Mastery requires 8 of 10 now including transfer, and 7 of 10 after seven days. An error identifies the link to rebuild, and attempts are unlimited. Project evidence also matters: another person must locate data and explain its structure from the README.

Defend version 0.1 as a small investigation

A checkpoint is a moment to test the result against known conditions. An artifact is a file, diagram, or table left by the work that someone else can inspect. Reproducibility means another person gets the same result from your instructions. Transfer is using a known rule in a new setting, such as another device. A criterion is an observable condition for success, not “I liked it.”

Give a classmate the version 0.1 folder but do not touch their device. They must (1) find README; (2) use it to open three fictional records; (3) explain why an on-screen change does not prove saving; (4) name an exact path; (5) show which permission the app really needs; and (6) read task state without relying only on colour. If they ask where to begin, the instruction needs repair. Revise README and repeat with someone else.

A ten-point quiz does not replace a working project. Show both answers and artifacts: the folder tree, input/output table, decision log, source register, and reproducible instructions. A week later solve an equivalent task with another file. A score of 7/10 signals retained knowledge, not a label for ability. Each error points to one step to rebuild.

The limit of the analogy

The familiar image opens the topic but does not replace the mechanism. State where the analogy stops being accurate.

The lesson’s support signal

explain → model → diagnose → transfer → project evidence → 8/10 now → 7/10 later

Worked example

The display shows three records. That is insufficient: test restart, wrong path, empty input, least permissions, decision history, and a system explanation. Every success leaves observable evidence.

Predict before observing

Before the experiment, hide the continuation and predict the result in writing. Give the chain of causes from the support signal as well as the answer. Perform the action, record the observation, and compare it with the prediction. A match without an explanation is luck rather than understanding; a mismatch is useful evidence about the link that needs rebuilding.

Recall without a prompt

Hide the page, rebuild the signal, and explain every transition with a new example.

Explain the topic to someone who has not read the lesson. Do not use a new term until you have unpacked it in plain words. Then restore its precise name and show its place in the system. The listener should be able to predict the next step and give a different example. If they merely repeat a sentence, reduce the explanation to the support signal and rebuild it.

Find and correct the mistake

“I got eight answers, so I am done.” Identify explanation, transfer, a checked artefact, and the delayed attempt date.

Transfer to a new setting

Apply the model to a device or file absent from the lesson. Separate observation from assumption.

Project change

Version 0.1 contains a passport, three fictional records, folder tree, input-output contracts, device table, source register, decision log, and README. Defend one corrected misconception.

Keep four lines in the decision log: the intended result, the observation, the reason for the chosen action, and the verification. A screenshot can support evidence but cannot replace text and the working file. Do not use personal data: three fictional records provide the same testability and let you show the project safely to another person.

Exercise

Required. Complete the example, correct the error, and make the project change with a reason.

With your own data. Test the decision on three fictional records.

Optional. Ask another person to rebuild the explanation from the map.

The readiness criterion is concrete: reproduce the signal without the page, correct the proposed error, transfer the model to an unfamiliar example, and show the project change. If one part fails, return to that link instead of rereading the whole lesson. After repairing it, repeat only an equivalent task with different data.

Retrieval after 1, 7, and 30 days

Rebuild the signal tomorrow; solve an equivalent task after seven days; after thirty days, verify the decision in the project.

Next lesson: the bit: two distinguishable states