How KRXY works
Architecture
How coordination, node agents, model runtimes and experiment records fit together in the public journal.
Components and data flow
A reading aid based on the journal. It is not a live map of the control plane, and this website is not connected to it.
Public
Readable by anyone
Private control plane
Not exposed by this website
Edge nodes
Independently operated hardware
Data flow, as documented
Selected component
Coordinator
implemented on two nodes · Parts 4 to 6
Receives jobs and chooses a node that is online and able to run the requested model. Through Part 5 there was one physical node to choose from. In Part 6 it placed overlapping 3B jobs on two Pis. Two simultaneous admissions could pick the same free node, so one request returned node_busy; a placement retry followed later and is not part of the measured results.
The public website and the private control plane are separate. Nothing on this page is live, and node addresses or credentials are never published.
The picture in the journal is a set of independent nodes that connect outwards to a coordinator. The coordinator is not assumed to be a permanent training cluster. A node reports what it can do. The scheduler is supposed to trust that report only as far as it can check it.
On the commissioned machine, the journal describes a local model server, an agent, and a coordinator that had to stay awake for heartbeats. Local inference on the Pi did not depend on that coordinator. The registry did.
Model-aware routing, recorded in Part 4, changed the rule again. A node being online was not enough. It had to be able to run the particular model a request named. Compatibility could be withdrawn, and a busy node could refuse work.
Part 5 added stored model evaluations and a model library on the same Pi, and with them a set of terms that are easy to blur. A catalogue entry names a model. An installed artifact is a particular file on a node. A ready runtime is a service that can answer now. Compatibility means a node can run the model a request names. Inference performance is how long the work takes. Answer quality is whether the reply is correct and complete for the task. Research evaluation is a recorded comparison under rules fixed in advance, and a recommended default is a separate decision made from it. The scheduler routes by availability and compatibility. It does not choose a model by answer quality, and a job marked completed is not necessarily a complete answer.
Part 6 added a second physical Raspberry Pi without the Hailo accelerator. Placement still matched the deployment ID, runtime and reported artifact digest, so the CPU-only node could take a job for the same pinned GGUF build but not for the Hailo build. Independent requests could run at once on different nodes; one answer was still generated on one node. Two simultaneous admissions could choose the same free node before its state changed, so one request returned node_busy while the other node was free. A placement retry followed afterwards.
The same work added node-health displays for resources and temperature, and remote restart and shutdown commands at the platform layer. The design separates a command being accepted from the operating system acting on it, and stops new scheduling while existing work drains. The running agents were not upgraded to execute those commands, so remote power was not verified in Part 6.
This website is deliberately outside that system. It does not call private control-centre APIs, and it keeps working if the platform is switched off. A future public status contract can be added without mixing it into the journal or the experiment archive.
The diagram on this page is a reading aid. It is not a live topology.