Where Experiment Ends and Operation Begins

"An experiment proves a thing can be done once. An operation is the thing being done without you. The household keeps both, and labels which is which, because the label is what decides whether a machine is allowed to be turned off."

Six Questions

The code block is the line as a checklist, and it is the fleet track's three placement rules plus three about time. Does it start by itself after a reboot — a launchd job, not a terminal someone left open? Does it have exactly one owner process on one machine, the single-writer rule? Does something depend on it daily? Is a failure noticed by a monitor rather than by a person wondering why a thing is slow? Can it be rebuilt on a replacement Mac in an afternoon from records — the store's catalog, the engine's configuration, the quest workshop's briefs? And were its numbers measured after deployment, not only in the experiment that preceded it? An operation answers yes to all six. Applied to the household: the inference hub, the model store and the video-memory control plane are six for six. This quest's lab — four Macs, one script, one day — is two for six and was never meant to be more: it is an experiment whose records are the measurements companion, and it can be rerun by anyone with the files. A 1 TB model pooled over RDMA is zero for six on the household's own trial, which is what "not practical" meant.

Two Things in the Middle

The interesting rows are the fours. The music engine pins its source separator to the CPU: it starts by itself, has one owner, is depended on, and can be rebuilt — but nothing monitors it and its numbers were measured before deployment against a version of PyTorch that has since changed, which is how the journey track found it running ten times slower than it could. That is an operation with a debt: the sixth question unanswered since the day it was deployed. Ollama's MLX engine as a chat tier is the other four: it starts, it is owned, it is rebuildable, and the lab measured it after deployment — the speculative-decoding finding — but nothing depends on it daily yet and nothing watches it. It is an operation waiting for a dependent, which the tier lesson's setting could give it in a minute. The line is not a wall; it is a count, and the count says which question to answer next.

The Line for Big Models

Everything this track computed sorts by the checklist. GLM-5.3 at 4 bits on one Studio could be an operation: it fits, it would start from launchd, the hub could own it, and its numbers can be measured after deployment — and the household has not deployed it, because the sixth question's honest answer for a 753B mixture is single-digit tokens per second, which nothing in the family would depend on daily when the cloud tier answers faster and better. Qwen3.8-Flash-Next at 4 bits on a laptop is an experiment a laptop's owner can run this week and, at 6B active, might well become an operation. A pooled model is an afternoon. The household's rule for the whole track, stated as its verdict on RDMA and carried here: what runs in the house is what can be left alone, and the store keeps everything else for the day the answer changes. The edge track is about that day.

Code

experiment_line.py — six questions, applied to the household's own things·python

#!/usr/bin/env python3
"""Where experiment ends and operation begins. Six yes/no questions; an operation
answers yes to all six. Applied to the household's own things as of 2026-09-15."""
QUESTIONS = [
    "starts by itself after a reboot (launchd, not a terminal)",
    "has exactly one owner process and one machine",
    "someone or something depends on it daily",
    "a failure is noticed by a monitor, not by a person wondering",
    "it can be rebuilt on a replacement machine in an afternoon from records",
    "its numbers were measured after it was deployed, not only before",
]
THINGS = {
    "the inference hub (MLX server + Ollama + image engine)":   [1, 1, 1, 1, 1, 1],
    "the model store (fetch, verify, land, catalog)":            [1, 1, 1, 1, 1, 1],
    "the video-memory control plane and worker":                 [1, 1, 1, 1, 1, 1],
    "this quest's lab (silicon_lab.py on four Macs)":            [0, 0, 0, 0, 1, 1],
    "a 1 TB model pooled over RDMA across two Studios":          [0, 0, 0, 0, 0, 0],
    "the music engine's CPU pin for source separation":         [1, 1, 1, 0, 1, 0],
    "Ollama's MLX engine as a chat tier":                        [1, 1, 0, 0, 1, 1],
}
for thing, answers in THINGS.items():
    n = sum(answers)
    verdict = "operation" if n == 6 else ("operation with a debt" if n >= 4 else "experiment")
    missing = [QUESTIONS[i] for i, a in enumerate(answers) if not a]
    print(f"{thing}\n    {n}/6 -> {verdict}" + (("\n    missing: " + "; ".join(missing)) if missing else ""))

# 2026-09-15: hub 6/6, store 6/6, control plane 6/6 -> operation; the lab 2/6, a pooled 1 TB model 0/6 -> experiment;
# the music engine's CPU pin 4/6 and Ollama's MLX chat tier 4/6 -> operation with a debt

Exercise

Run experiment_line.py on your own things — every model, daemon and script you run — and write the count beside each on your card. For every four or five, write the missing question and the afternoon it would take. For every zero to three, write whether it should become an operation or stay an experiment, and why.

Hint

Most home setups have one or two sixes, several fours with the same missing answers (monitoring, re-measurement), and a pile of experiments nobody has labeled. Labeling them is most of the work; the household's fleet track is what the labels look like once they are written.