# Niodoo interpretability and the cybernetics loop > Source: > Published: 2026-09-07 01:06:16+00:00 For now, I took a quick look: What stands out to me here is that these traces may be more useful as **control-loop traces** than as correctness demos. The paired examples are actually helpful precisely because the same kind of control request can sit next to both a good trajectory and a bad one. A `FOCUS` can stabilize something correct, but stabilizing the current trajectory is not the same thing as making that trajectory correct. Likewise, `SPIKE`/` EXPLORE` can produce useful escape in one run and extra wandering in another. So I think the cleanest decomposition is something like: ``` current state ↓ REQUEST selection ↓ gate / effective runtime action ↓ change in the subsequent trajectory ↓ task result ``` Those are four different things that can succeed or fail independently. That separation also seems nicely aligned with the older **Model-Requested Adrenaline** setup you described [here](https://discuss.huggingface.co/t/i-injected-a-physics-engine-into-llama-3-8b-it-hallucinated-its-way-to-the-right-answer/171704/7): the interesting question now is less “can the model emit `FOCUS`?” and more “what did it see, what did it request, what did the runtime actually do, and what changed afterward?” If I were choosing the lowest-cost next step, I would probably not start with a large benchmark. I would take **one request event** and make its provenance/order completely explicit. Something like: ``` decoded token(s) ↓ REQUEST detected ↓ gate decision ↓ effective action actually fired ↓ runtime state / telemetry change ↓ next forward step ↓ subsequent decoded text ``` For future readers, it would also help a lot if the trace distinguishes these three sources when they happen to look similar in text: ``` MODEL: text actually decoded by the model RUNTIME: text/state injected or generated by the harness DISPLAY: annotation added only for the human-readable trace ``` In particular, I would not want to infer the provenance of lines such as `[INTERNAL MONITOR: ...]` or `[ACTIVE SYSTEM: ...]` from the typography alone. The exact commit/branch/harness that produced the September 4 traces would probably be the single most useful breadcrumb, because there have been several Niodoo/Path-B variants and the exact event ordering matters here. The small control I think would give the most information So my default next move would be very small: If those four pieces line up, then I think the pre-request latent-state question becomes much more interesting — and the existing traces give you a good set of naturally occurring examples to start from.