Inventory your kit

Summary

B0 is the Build Track's onboarding milestone. You catalogue the hardware you own, place each piece on the compute spectrum, and work out which pathways are reachable today and which would need an upgrade. The output is a short profile file you keep in your builds/ folder and update whenever your hardware changes. It needs no spending and no installs beyond what ships with your operating system, so it's achievable by every learner, including one with a single old laptop.

It is the milestone that grounds every later build on real silicon. By the end you should be able to say, in your own words, why your machine sits where it does and why that decides what you can build.

Learning goals

• Know what hardware you own, described by capability class (memory, parallelism, power) rather than product name.
• Place each device on the compute spectrum (tiers 0 to 3, with 4 and 5 as the conceptual cloud tiers).
• Understand which pathways are available to you now, and which need future hardware.
• Understand that pathways are optional, independent, and equal, so a lower tier is a different environment, not a worse one.
• Internalise the binding constraint of the whole track: memory and parallelism, not raw clock speed, decide what a machine can run.

Prerequisites

• L0 (Entering the stack) read, so you know what the Build Track and the compute spectrum are.
• A machine you can inspect, with enough access to read its specs. Nothing else.

Estimated time

30 to 60 minutes. This is onboarding. If it runs longer, you've drifted into benchmarking or installing things, which is a later build, not this one.

Deliverables

One markdown file, suggested path builds/B0/README.md (alongside this page's folder), with five sections you fill in:

1. Hardware I own, a table: device, CPU (cores), RAM (capacity, and speed if you can find it), GPU or accelerator (and its VRAM), any embedded or microcontroller boards, and whether you have two or more machines you could network.
2. Compute-spectrum placement: each device assigned a tier, with a one-line reason.
3. Pathways available now: Budget, Edge AI, Prosumer, AI Server, each marked reachable or not, with the reason.
4. Upgrade roadmap: what capability class would unlock each pathway you can't reach yet.
5. What I learned: two or three sentences, in your own words, on why your hardware lands where it does.

A starter skeleton you can copy:

# B0 · My Build Track profile
Last updated: YYYY-MM-DD

## Hardware I own
| Device  | CPU (cores) | RAM   | GPU / accelerator | VRAM   | Embedded board? | Could network with others? |
|---------|-------------|-------|-------------------|--------|-----------------|-----------------------------|
| laptop  | 8           | 16 GB | integrated        | shared | no              | no                          |

## Compute-spectrum placement
- laptop: tier 1, because ~GB of RAM, no discrete GPU, runs small quantised models on CPU.

## Pathways available to me now
- Budget Lab:    yes    -- tier 1 hardware is exactly its home.
- Edge AI Lab:   not yet -- I own no microcontroller-class board or sensor.
- Prosumer Lab:  not yet -- no discrete GPU with enough VRAM.
- AI Server Lab: not yet -- only one machine.

## Upgrade roadmap (capability classes, not products)
- Unlock Edge:     a microcontroller-class board (tens of KB RAM) plus one sensor.
- Unlock Prosumer: a discrete GPU with roughly 12 GB+ of VRAM.
- Unlock AI Server: a second networked machine, or a multi-GPU node.

## What I learned
<your own words>

The compute spectrum, by capability class

Classify each device by what it can do, not by its product name. The product dates in months; the capability band stays true for years.

The four pathways are equal deployment environments, not a ranking. A higher tier is a different place a system runs, not a better learner. The Budget Lab on a plain laptop is a real pathway, not a waiting room.

Step-by-step instructions

1. Make the folder and file. Create builds/B0/README.md and paste the skeleton above. Set today's date.
2. Read your CPU. Note core count and architecture. On Linux, lscpu. On macOS, sysctl -n machdep.cpu.brand_string and About This Mac. On Windows, Task Manager's Performance tab or Get-ComputerInfo. You want the capability ("8 cores, modern x86" or "Apple Silicon"), not the marketing name.
3. Read your RAM. Capacity is what matters; speed is a bonus. On Linux, free -h. On macOS, About This Mac. On Windows, Task Manager. Write the number in GB.
4. Read your GPU, if any. Record the class, and above all its VRAM. NVIDIA: nvidia-smi. AMD: rocm-smi or system info. Apple Silicon: note that the GPU and CPU share one unified memory pool. Integrated-only? Write "integrated, shares system RAM." VRAM is the single most decision-relevant number in this whole build, so don't skip it.
5. Note any accelerators or boards. A recent laptop or phone NPU, a Raspberry Pi, a Jetson, an Arduino, an ESP32, a Pico. These open tier-0 and edge work. Own none? Write "none," which is fine.
6. Note your network reality. Do you have a second computer on the same network you could actually use alongside this one? This is the gate for tier 3.
7. Place each device on the spectrum. Use the capability bands in the table above, not a product lookup. Give each device a tier and a one-line reason.
8. Map pathways to your tiers. Budget Lab is reachable from tier 1, so almost everyone can start it now. Edge AI Lab needs a tier-0 board and a sensor. Prosumer Lab needs a tier-2 GPU. AI Server Lab needs tier-3 hardware. Mark each reachable or not-yet, with the reason. This is awareness, not commitment.
9. Write the upgrade roadmap. For each pathway you can't reach, record the capability class that would unlock it, in classes not products, so the note stays true across hardware generations.
10. Write what you learned, and save. Two or three honest sentences on why your kit lands where it does. Save the file. You'll re-run this whenever your hardware changes.

A note on the two pathways with a hardware gateway: the Edge AI Lab opens through an optional core build on a microcontroller (B6), and the AI Server Lab opens through an optional core build on two machines (B17). B0 only makes you aware of that; you decide later.

Validation criteria

Assess yourself against the Build Track Validation Standard. The bar is understanding, not a filled-in table.

The validation standard's fourth outcome, TOOL-LOCKED, doesn't apply here: B0 uses only built-in tools and plain text. The nearest trap is knowing one operating system's command without the capability it reports. Learn the capability, and the command becomes incidental.

Common pitfalls

• Recording product names as the answer. "16 GB RAM, no discrete GPU, tier 1" stays true for years; a chip model number dates in months. Capability classes are the point.
• Confusing system RAM with VRAM. This is the most consequential mix-up in the whole build, because VRAM gates which models fit on a GPU. Apple Silicon blurs the line with one unified memory pool, so note that explicitly if it applies to you.
• Reading a higher tier as "better." The pathways are equal deployment environments. Tier 1 is the home of the Budget Lab, not a lesser starting point.
• Scope creep into benchmarking. Running a model or measuring throughput is a later build. B0 is inventory and classification only.
• Reading "no GPU" as "I can't do the course." Conceptual completion needs no hardware at all, and the Budget Lab runs on a plain laptop. B0's job is to show you what's reachable now, honestly.

Optional extensions

• Add a power and thermal note per device (watts, and whether it throttles under load). This matters at tiers 0 and 1, and it pays off when you reach the roofline build.
• Note the unified-memory versus discrete-VRAM distinction explicitly if your machine has shared memory.
• Draw a one-line sketch of the full spectrum, tiers 0 to 5, and mark where each of your devices sits, including the conceptual cloud tiers you don't own.
• If you have an old laptop in a drawer, add a short "second machine" note: two modest machines on a network is the cheapest taste of tier 3.
• Set a recurring reminder to re-run B0 at any hardware change, so the profile stays a living document.