Serials stay on this device
The selected files are read in browser memory only. Their contents are not uploaded, saved to lab progress, or placed in the report. The report uses row numbers, never serial values. Close or reset the page to discard the review.
Receive
Request the approved laptop serial-number extract from the asset-data custodian within the team.
Work
Use anonymous codes. Each intern owns records, reviews another person's rows, and builds one safe collection artifact in whichever tool they choose.
Select
Select the collection log, the individual evidence file, and every collection artifact. Files stay on this device.
Correct
Run the check, fix every blocker at its source, then run it again. Do not edit production.
1. Approved intake
Use a message, ticket, or file reference. Do not enter a person's name.
The unique rows in the log must reconcile to this number.
2. Team evidence
Team collection log
One row per approved serial. Use only the controlled method values in the template.
Individual evidence
One row per intern: hypothesis, measured evidence, limitation, data shapes, and the artifact filename.
Collection artifacts
One file per intern, in any tool you like: Python, JavaScript, PowerShell, SQL, Power Query, a notebook. What is checked is the discipline, not the language. It must work against a toscrape.com sandbox, never a real vendor portal.
The defaults create meaningful individual depth inside one shared team deliverable.
3. Team decisions
Minimum 20 words. It must cover serial, warranty, cost, and refresh.
Minimum 20 words. It must make mismatches visible and assign a review action.
Minimum 15 words. It must cover raw evidence, misses, a duration, and archive or deletion.
Nothing here leaves the device
The staging sheet and the rejected rows file are read in browser memory only. Their contents are not uploaded, saved to lab progress, or placed in the report. The report uses row numbers, never serial values. Close or reset the page to discard the review.
Shape
Put the week 4 output into the staging sheet: the brief's four column blocks, one row per asset, and the serial as the match key.
Rule
Write the quality rules before you clean anything, one per line with an id, then refuse rows against them rather than by eye.
Check
Hand check the pilot against the vendor page, one row at a time, and write both sides on the row you checked.
Reverse
Write the way back before anything loads: the export, the object keys, the staging copy, and where the job reference goes.
1. The export you worked from
Rule 1 on the brief: you work on an export, never on production, and the copy is dated in its filename. Do not enter a person's name.
Rows in the sheet plus rows refused must come back to this number.
2. The two files
Staging import sheet
One row per asset, with the column blocks the brief names, the column that says which kind of empty a warranty is, and the two the pilot writes.
Rejected rows
Everything your own rules refused, one row each, carrying the id of the rule that refused it. Rule 6: a row you could not use is a row in this file, not a row you delete.
Twenty is the number the brief asks for. Three is this lab's floor for a list of rules rather than a rule, and a facilitator can move it.
3. What you wrote down
One rule per line, starting with a short id and a space, like R1 serial_number is present and unique. The rejected rows file cites these ids.
Minimum 25 words. It must name the export, the keys, the staging copy, and where the job reference goes.
Nothing here leaves the device
The views summary and the staging sheet are read in browser memory only. Their contents are not uploaded, saved to lab progress, or placed in the report. The report uses row numbers, never serial values. Close or reset the page to discard the review.
Draw
Build the three views the brief names, each one labeled with the question it answers and the consumer who asked for it.
Cover
Put the coverage line on every view: how many devices it is based on, out of how many, as of which date.
Say
Write the note for each view in three parts: the thing, how big it is, and what you would do about it.
Own
Write down one thing you got wrong across the three weeks and what fixing it cost. It is marked, and marked generously.
What this check can see, and what it cannot
Weeks 4 and 5 hand in data, and data checks mechanically. A chart does not. So this page does not read your views and it does not score them. It reads the words the brief already asks you to write beside them, and it checks the things that have an answer: that the figures you claim come back out of the sheet you built them from, that a percentage has a base under it, that the mark is the one the brief's own card for that view describes, that the note names a thing, a size and a consequence, and that no personal data reached a label. Whether the chart is clear, whether the finding is interesting, and whether a consumer written in words is a role or a colleague are read by the facilitator, with the views open.
1. The sheet these views came from
Rule 1 on the brief: you work on an export, never on production, and the copy is dated in its filename. Do not enter a person's name.
2. The two files
Views summary
One row per view: the title, the question, the consumer, the mark, the three parts of the coverage line, and the three parts of the note.
The week 5 staging sheet
The same file week 5 took. It is the dataset behind the views, so it is what every figure you claim is reconciled against, and it is where "out of how many" comes from.
End of life is derived, never typed: a laptop reaches it 1388 days after its acquisition date and a phone 731, which is the brief's 3.8 years and 2 years counted at 365.25 days to a year. Build the column that way and the forecast in view 3 will reconcile.
3. What you got wrong
Minimum 20 words. Name which of the three weeks it happened in, and what the fix cost. The brief marks this generously, so plain and specific beats polished.