Docs · How grading works

How grading works

The short version: your machine runs your code; our server owns the verdict. Nothing of yours executes on our side — and nothing of ours needs to trust your machine's opinion of itself.

sboot test — practice

Everything happens on your machine: the course's build runs, the result runs (for the OS courses, your kernel boots in QEMU), and the grading engine — fetched to your machine with the tests, checksum-verified — scores the run against the lab's published checks. The checks are not a secret: every check you are graded on is one you can read, with its points and its evidence, in your own terminal, and the same table is printed on the lab's page.

When you are online, the practice run is recorded to your account — the score and the per-check pass/fail lines, nothing else — and shows up under recent runs on /home and in the lab page's working strip. Your source is not uploaded by sboot test, ever. Offline, the run still grades; it just is not recorded, which costs you nothing — practice never completes a lab. sboot hint sends even less: one line per hint shown, with the course, lab, check, how deep the hint was and which kind it was. Never code, compiler output or file paths.

sboot submit — official

Submit is the same local run plus an upload:

  1. It runs the exact check sboot test runs — one build, one run — and if that fails locally, it stops. Nothing is created, nothing is sent (--force overrides this; see the CLI reference).
  2. On a pass, it uploads that run's captured result and your source tree (source only — build artifacts and .git are excluded).
  3. Our server judges that captured run against the course's canonical rubric, using the same compiled grading engine your machine ran — so a practice verdict and an official one cannot disagree by being different programs — and answers with the verdict in the same command.

The server's verdict is the official one. An official run that does not pass is recorded as exactly that: a failed official attempt on your record, completing nothing.

The review, and what actually completes a lab

Passing the tests is not the same as writing good code, and that gap is the whole point of this product. So a passing submit ends with a link rather than a trophy:

  ✅ official grade: 3/3 — recorded
  Submitted → …/courses/kernel-in-rust/stages/00-welcome?submission=<id>#review
  read your review, then press Complete there — that's what finishes the lab

That link is the lab page's Review tab for that submission. It shows the diff of what you wrote for this lab — your submitted files against the lab's starter files — with an AI code review commented onto the exact lines, arriving as it is written, the way review comments land on a pull request. The mechanical checks sit quietly above it as ✓; they are the precondition, not the feedback. Findings come in two weights: would bite you (a real bug that happened to pass the tests — the highest-value catch) and craft (idiom, structure, what a senior would prefer). Each one says why, because the why is the thing worth having.

Then the part that matters procedurally: the Complete button under the review is what finishes the lab. Not the submit.

  • A finding never blocks you. Even a "would bite you" one, Complete stays your call — the button just renders quieter, with the revise command next to it.
  • A failing check blocks everything: sboot submit refuses to upload until your local run passes, so a review only ever runs on working code.
  • Every resubmit is re-reviewed, and every submission's review stays readable, pinned to that submission. That history is the improvement arc, and it is yours to re-read.
  • Pressing Complete records that submission as the one you finished on. Edit locally afterwards and that version is simply not the one on record — submit again if you want it to be.
  • The review never holds up the grade. If it errors, or is deferred because the mentor is at capacity for the day, the page says so in plain words, your grade is untouched, and Complete is still yours to press.

sboot test can go green a hundred times and completes nothing; a passing submit completes nothing on its own either. Submit, read, Complete.

One exception worth knowing about: a sboot from 0.3.x or earlier predates this and still prints stage complete! on a passing submit. It is wrong — that binary cannot be told otherwise after the fact — and the lab is still finished by pressing Complete. Update, and trust the site over the terminal on what you have completed.

What we keep, and what we don't

A submission's uploads exist to be judged, not to be kept. Once the verdict is written, both the source archive and the captured run are dropped — we do not keep your code. To be precise about what that means: the uploaded source is read during judging (part of the rubric reads your code directly), and then it is discarded. What persists is the record: the verdict, the score, the per-check results, your completion — and, for a passing submission, the diff of what you wrote for that lab (your submitted files against the lab's starter files), because that diff is what your code review is written on and what the review page shows you, for every passing submission, for as long as your account has them. The diff is the one piece of your code that stays; the full source tree and the boot capture still drop the moment the verdict lands.

Who else sees it. The code review and the mentor's replies are written by a large language model, and that means the text reaches the company that runs it: the diff of your submission — plus the files that diff touches — and whatever you type in the chat are sent to Anthropic's API to generate them. Nothing else about your account goes with them: not your name, not your email, not your other courses. That is the only third party your code reaches. If you would rather a piece of code never left your machine, don't submit that lab — the local sboot test loop and the hint ladder run entirely on your own computer and send nothing.

Your code's permanent home is the git repo on your machine — see Your code.

Sequential unlock

Labs open in order, for everyone: lab N stays locked until lab N−1 is a verified completion — and completing is the Complete button on lab N−1's review page, after a passing submission. Practice never unlocks anything, and neither does a passing submit by itself: read your review, press Complete, and the next lab opens. Both the site and the CLI enforce this — a submission for a lab that is not open to you is refused before anything is graded (and sboot submit asks first, so you don't spend a build on a locked lab).

Where a course has a lab 0 — the welcome — it is the first row of that chain: it gates building lab 1 the normal way, while lab 1's lesson stays free to read regardless.

Free labs and paid labs

Your first course is free end to end — every lab of it, graded, with the verified completions that go with them — and the rest of the catalog is paid. Without an account at all, the first lab's lesson of any course is still readable. A welcome lab (00) is different from both: it is always free, and it never uses up one of the free slots — the free floor counts the numbered labs. Which course is the free one, and the exact free line for every other, is on the pricing page — it renders from the same manifests this page cannot read. Two things hold regardless of plan: labs always unlock sequentially, and anything you have completed stays open to you — completions are earned, not rented, and they do not expire with a subscription.

The help surfaces split the same way. The hint ladder — sboot hint and its mirror in the lab page's Stuck? section — is free and unmetered at every tier. The chat in that section is the metered one: your plan decides the allowance, the counter beside the input is the live truth of what is left, and the pricing page says what each plan includes.

The banner in the site header says exactly what is open; believe it over any general rule written here.