Writing a lab

The lab editor is an Education feature, coming in a later release: a teacher will write a lab in the app, with no file by hand. This tutorial says what a lab is made of, which is the same either way, and how to write one today, by hand. Opening and doing a lab a teacher wrote stays free for students, in every edition.

What a lab is made of

A lab is a project with five parts:

1. The starter: the model the students begin with, and its training settings.
2. What is locked: the blocks students may not change, usually the input, the output and the training blocks, so every hand-in has the same inputs and outputs. The connections between locked blocks are locked with them.
3. What the editor offers: the editor’s policy, six plain choices (below).
4. The steps: the worksheet the Lab page shows beside the model: the goal, the steps, the questions and what to hand in.
5. The checks: the rules that mark the model, each with its points and the feedback a student sees when it fails.

What the editor offers

• Blocks: level 1, 2 or 3 of the Library.
• Code tab: shown or hidden.
• Fixes: one-click fixes on, or explanations only, when finding the fix is the point.
• Subsystems: the student may make them, or the model stays flat.
• Sizes: worked out by the app, or typed by the student, such as a Linear’s in_features after a Flatten.
• Console: on, or off, as for an assessment.

The checks you can use

Each check looks at the model and its training settings, never at a training run, so it answers at once and gives the same marks on any computer:

• The model has no errors (analysis_clean).
• A block’s output has a shape, such as 10 scores for each picture (output_shape).
• The model’s size is at most, or at least, a number of parameters (param_budget).
• The model uses these blocks, such as Dropout (required_ops), or none of these blocks (forbidden_ops).
• The model has at most so many blocks (max_nodes).
• The model has a skip connection (has_skip_connection).
• The locked blocks are unchanged (locked_unchanged).
• A training setting is one of a list, or between two numbers, such as at most 30 epochs (experiment_constraint).

Good checks

• One idea per check, with feedback that says what to do: “Put a Dropout block after each ReLU”, not “Wrong”.
• Points for what the lab teaches. Lesson 3 gives 3 points for Dropout and 1 for each setting it keeps fixed.
• Fix the settings runs compare on, such as the dataset and the number of samples, so students compare like with like.
• Check the starter. It should miss the points the lab is about, and pass the rest.

Writing one today, by hand

Until the lab editor arrives, a lab is an assignment.json file beside the starter’s graph.json. The ten lessons are complete examples, in the repository’s content/lessons/ folder.

1. Build the starter in the app and save it as a project. Its folder is in the workspace, named after the project.
2. Copy a lesson’s assignment.json into the project’s folder, next to graph.json, and change its title, policy and checks. A check names a block by its id in graph.json.
3. Record the locks: list the locked blocks’ ids under locks, then run python -m neblo_core lock graph.json assignment.json from a uv install. It writes the fingerprint that the locked_unchanged check compares.
4. Try it: open the project in the app. Its Lab page shows the checks; Check my work marks the starter.
5. Hand it out: File › Export…, then Project file. The .speliora file is the student’s starter, with the lab inside.

A lab written by hand has no worksheet on its Lab page: give the steps to students on the course’s page instead.

With the lab editor

The lab editor will cover the same five parts in the app: the starter on the canvas, a lock you set on each block, the policy as plain choices, the worksheet written beside a preview, and the checks chosen from a list. Try it as a student will open the lab as your students see it, and Export the lab will write the student’s file and a grading pack that keeps the solution for you alone.