Skip to content OpenLabs

See how the thing actually works.

OpenLabs builds handbooks that run. Most material shows you a diagram and a config file; here the diagram is the running mechanism — change something, watch it react, then open it up and read the exact data that produced what you just saw.

Different subjects, shared tools: a flow you can open, a cluster that reconciles, a chip you can lift the lid off and follow down to the gates. Each lab has a showcase that walks you through it and a simulation you can break.

Browse the handbooks Read the documentation

OpenTelemetrycheckoutSDKpaymentsSDKCollectorbackendKubernetesschedulerpod-1Runningpod-2Runningpod-3Runningpod-4RunningCPUDRAMRV32Icore

Live simulation, not a video · OpenTelemetry · click a span to follow it

service · source Where the load is born. — Processor: it acts on the data crossing it.out · exportservicecollector · composite Groups other objects. Does not act on its own. — Processor: it acts on the data crossing it.collectormore insidebackend · store Holds many values at once, and answers by key. — Processor: it acts on the data crossing it.in · inbackend
  • data
  • control
  • logic 1

waiting for the first span

The first span is on its way.

What a lab is

Every lab answers one concrete question through interaction. When the subject is a layered flow, the outside view shows the parts and what moves between them. Go one level down and you are inside a part. Keep going and you reach the thing itself — the bytes on the wire, or the wire that is either high or low.

Those are not separate drawings. They are views of one running state, so what you read at the bottom is what produced the picture at the top. Only the leaves have behaviour; everything above is the result of running what is inside it. When a lab makes a claim, the repository has a way to check it against the real thing.

For layered flow scenarios, the compositional engine is a graph you can go into. It draws a running flow, and each layer of abstraction opens into the one below — not another diagram of the same thing, the same thing seen closer.

  1. Open a part Double-click any box and you are inside it, looking at the parts it is made of.
  2. Open a message The thing moving on the wire has a body, and you can read it field by field.
  3. Follow one item Click it and its whole path opens up, with what each stop changed lit where it lives.

And when a subject is not a flow with layers — or when the thing that matters is one item and not the pipeline it crosses — the lab is a different one, built for it. A street is a poor way to explain a door.

The handbooks

Each one chooses the interactive models its subject needs, and shares the same anatomy: a roadmap, articles, and labs. Open one to see where it stands — nothing here claims to be finished when it is not.

OpenTelemetry

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
  • 9 of 18 labs running
otel.model the CPU

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
cpu.model algorithms

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
algo.model Kubernetes

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
pod-lifecycle · state model splunk

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
splunk.model

The written record

The design is written down as it happens, and it is incomplete on purpose — publishing only what is finished would hide the part that is still being argued. Every chapter says which it is: 6 settled, 12 drafted, 3 still proposals.

Read all of it →