This page presents the values from the candidate’s sample JSON in the Lab’s website layout. The candidate’s generated HTML report is self-contained. No private package or executable is provided here.
| Scenario / volume | Budget | Allocated / peak | After reclaim | Remaining at peak | Status |
|---|---|---|---|---|---|
| Example: add two service allowances | 4,096 | 2,816 | Not applicable | 1,280 | within allowance |
| Example: same allowances exceed a smaller host | 2,048 | 2,816 | Not applicable | -768 | over budget |
| Example: existing usage not recorded | 4,096 | Unknown | Not applicable | Unknown | unknown |
| Hypothetical: after fits but peak does not archive and restore volume | 1,500 | 1,584 | 1,456 | -84 | over budget |
| Hypothetical: free space cannot move between volumes archive volume | 1,100 | 1,264 | 1,136 | -164 | over budget |
| Hypothetical: free space cannot move between volumes restore volume | 1,000 | 448 | 448 | 552 | within allowance |
Three details to notice
- Unknown is not zero. Unrecorded existing usage leaves the memory result unknown. “After reclaim” is not applicable to memory rows; those fields remain null in the JSON.
- A smaller final total does not erase a peak. The 1,500 MiB storage budget is exceeded by 84 MiB at the 1,584 MiB peak, even though 1,456 MiB could remain after a hypothetical validated reclaim.
- Volumes do not pool their free space. The archive volume is 164 MiB over budget; the restore volume’s 552 MiB spare allowance does not fix it.
“Within allowance” only means the entered arithmetic fits. A negative remainder is a deficit. “After reclaim” is a hypothetical planning number, not evidence that any files were removed. The sample downloads preserve the original null values and candidate labels.