Handbooks
Each handbook is one subject, modelled as a .model on the
same engine. The engine does not know what a span is, or what an
opcode is — the model does. That is what makes the second handbook
cheaper than the first.
The anatomy repeats: a roadmap of the order the ideas hold each other up, articles that explain, and labs that run.
OpenTelemetry Visual Handbook
Watch the telemetry move, then read the bytes that moved.
Every concept as a model you can take apart: the service graph on top, the OTLP payload underneath, and the same running state producing both.
- 5 phases
- 15 articles
- 18 of 18 labs running
CPU Visual Handbook
Type an instruction, watch the transistors settle.
Two machines, one engine. A generic accumulator microprocessor that spells the instruction cycle out instant by instant, and a single-cycle RV32I datapath that does the whole thing in one. Both modelled down to the transistor. You write the assembly; the model runs it.
- 6 phases
- 14 articles
- 4 of 6 labs running
Algorithms Visual Handbook
An algorithm is a system of parts. Watch the items move.
A stack is a box with things in it; a queue is a belt with a policy; a sort is a load changing places. Every model here runs, and the answer comes out of parts moving — never out of a script.
- 5 phases
- 6 articles
- 1 of 5 labs running
Kubernetes Visual Handbook
Declare a workload. Watch the system reconcile it.
Edit a native manifest and inspect the difference between desired state, Pod identity, container restarts and node reservations. Interactive state models, with no flow engine required.
- 2 phases
- 2 articles
- 1 of 2 labs running
Splunk Visual Handbook
Four phases, and the only question that matters is which machine runs each one.
Splunk is a pipeline before it is a search bar. A forwarder that does not parse, a parsing phase that happens exactly once, a bucket that ages on disk, and a search that is split between two tiers. Every model here runs, and the numbers come out of the run.
- 6 phases
- 8 articles
- 2 of 5 labs running