Track and review · Lesson 11
Capture real Jupyter cells and the hidden calibration change
The video drives a real ipykernel through a terminal. It uses the same fraud holdout as lesson 10, then changes an unlogged calibration offset before repeating a captured cell. It is not a recording of a Jupyter graphical frontend.
By the end of this lesson
- Distinguish notebook file identity, kernel cell identity and Run identity.
- Predict the four retained captures, including a repeated cell.
- Explain the actual effect of the unlogged calibration_offset.
Watch the lesson
English · 5:55 · Recorded with Apizr 0.4.6 development candidate.
Chapters in this recording
| Time | Chapter |
|---|---|
| 00:00 | The notebook screen is not the whole execution history |
| 00:28 | Three identities to keep separate |
| 00:59 | Predict the number of retained captures |
| 01:30 | Execute the actual cells and repeat a call |
| 02:45 | Read cell evidence in the shared history |
| 03:40 | Variant: the unlogged calibration offset |
| 04:21 | What this does not reveal about kernel state |
| 04:53 | Your turn: same cell, same result? |
| 05:13 | Review the execution, not just the latest display |
| 05:45 | Continue with the written guide |
Read the recording transcript and commands
This is the retained English narration, in the original chapter order. Commands keep the recorded version and prerequisites; setup additions in the lesson are labelled separately.
00:00 — The notebook screen is not the whole execution history
In a notebook you can rerun a cell after changing a threshold or changing kernel state. The visible output is then only the latest display for that cell. How do you review the actual calls you made? We use the same fraud holdout evaluation from the SDK lesson inside a real installed ipykernel. We will repeat a cell and inspect the retained evidence rather than relying on its position on screen.
00:28 — Three identities to keep separate
A saved notebook has a file identity. A running cell has an identity supplied by its frontend and an execution count assigned by the kernel. An experiment Run has its own retained digest. These identities answer different questions. Repeating a cell can keep its cell identifier while advancing execution count and creating another Run. It does not establish that the notebook was saved or that all earlier cells were executed in order.
00:59 — Predict the number of retained captures
Our notebook loads the real evaluation sample, captures one evaluation session, defines a decorated evaluator and calls it at two thresholds. We then repeat the first call cell. Predict how many Runs should remain: defining a function is not an evaluation call. Also predict whether the repeated cell will share its identifier, its execution count and its Run digest. We will check these distinctions against actual kernel messages.
01:30 — Execute the actual cells and repeat a call
This recording sends the prepared notebook cells to a real ipykernel using the candidate interpreter. The displayed source and outputs are actual kernel messages. Watch the session result, the two threshold evaluations and the repeated first variant. Our capture is a terminal view of that live kernel, not a recording of a notebook frontend. We keep the original cell identifiers and record each returned execution count so that the repetition can be verified afterwards.
python -m scripts.qualification.experiments.academy_kernel --notebook fraud-thresholds.ipynb --workspace "$APIZR_ACADEMY_KERNEL_WORKSPACE" --input evaluation.csv --pause 3
02:45 — Read cell evidence in the shared history
Now read the store created by those kernel executions. We expect one session capture and three decorated-call captures. Find the first variant cell twice: its cell identifier is the same, while its execution count differs. The metrics remain observations of the selected evaluation file and threshold. Separate Runs keep the history of repeated work instead of replacing the previous cell display.
apizr experiment list --store "$APIZR_ACADEMY_KERNEL_WORKSPACE/.apizr/experiments/v1"
(cd "$APIZR_ACADEMY_KERNEL_WORKSPACE" && python "$APIZR_ACADEMY_LAB" history)
03:40 — Variant: the unlogged calibration offset
The final notebook cell deliberately changes a calibration offset in live memory before the first variant is repeated. Its threshold and selected CSV identity stay the same, but the classification calculation reads that changed offset. Read the two actual results from the repeated cell. Cell identity plus an input file digest is not a complete kernel-state snapshot. The correction is practical: explicitly log calibration offset as a parameter and preserve the relevant source, rather than claiming that matching cell identifiers establish equivalent executions.
04:21 — What this does not reveal about kernel state
Execution counts tell you about order in this kernel; they are not a complete snapshot of memory. A repeated cell may read variables created earlier or modified elsewhere. Logging the evaluation file gives us content evidence for that selected input, but does not turn every live object into a verified snapshot. A saved notebook can also differ from the currently executing cell. Keep these limits explicit when explaining a result to a colleague.
04:53 — Your turn: same cell, same result?
Pause and answer. You rerun the same cell identifier with the same threshold but have changed an unlogged in-memory array. Must the metric stay the same? Does a new execution count tell you which array values were used? Explain what you would log or preserve to make that comparison useful.
05:13 — Review the execution, not just the latest display
The same cell can produce another result when its live inputs differ. Its execution count alone cannot identify those values. Our real notebook example produces four retained captures, including two executions of the first variant cell. You can now read the shared history without confusing a cell, its latest display and a saved file. The VS Code lesson uses the same retained evidence; its native recording remains a separate task.
05:45 — Continue with the written guide
The current written guide remains authoritative. Continue there for the detailed steps. Thank you for following Apizr Academy.
1. Use the recorded notebook and holdout
Prepare evaluation.csv as in lesson 10, using the fraud-detection/ folder in the recorded materials. That folder includes the actual fraud-thresholds.ipynb, not a substitute demonstration notebook.
For manual practice, open it with the scientific environment's Jupyter kernel, execute its code cells in order, then repeat first-variant after calibration-change. Defining the decorated function is not an evaluation call.
Exact terminal replay: the recording uses the product checkout's scripts.qualification.experiments.academy_kernel driver. With its source root on PYTHONPATH, run the selected scientific interpreter using:
python -m scripts.qualification.experiments.academy_kernel --notebook fraud-thresholds.ipynb --workspace "$APIZR_ACADEMY_KERNEL_WORKSPACE" --input evaluation.csv --pause 3
Set APIZR_ACADEMY_KERNEL_WORKSPACE to a fresh directory outside the checkout. The driver sends the actual cells to ipykernel and then repeats first-variant; it checks the four resulting captures. The recording procedure describes the checkout/interpreter selection for this terminal driver.
2. Read the four captures
The retained recording shows one session, two threshold calls, then the first call again:
| Captured cell | Kernel count in the recording | Threshold | Flagged rows |
|---|---|---|---|
session |
2 | 0.5 | 35 |
first-variant |
4 | 0.35 | 60 |
second-variant |
5 | 0.65 | 21 |
first-variant, repeated |
7 | 0.35 | 103 |
Use apizr experiment list and show on that workspace's history. With the terminal driver, select --store "$APIZR_ACADEMY_KERNEL_WORKSPACE/.apizr/experiments/v1". Your own frontend may provide different cell metadata or execution counts; read what was actually captured.
3. Explain the calibration variant
Before the repeated call, the notebook changes calibration_offset from 0.0 to 0.2 in live memory without logging it. The threshold and selected CSV identity stay the same. Yet the repeated first-variant flags 103 rather than 60 rows; recorded recall changes from 0.6875 to approximately 0.9792.
The saved input file, cell ID and logged threshold do not identify all live kernel state. A new execution count tells you order, not the values of every in-memory object.
Practice
Use the filmed question: must the same cell ID and threshold produce the same metric after an unlogged in-memory input changes? Can the execution count tell you which values were used? Propose the missing observation.
Check your reasoning
The same cell can read different live state. A new count and Run preserve a distinct execution, not a complete memory snapshot. In this case, explicitly log calibration_offset as a parameter and preserve the relevant source. Keep that proposed correction separate from the recording, which deliberately leaves the offset unlogged to demonstrate the limitation.