KRXY

Plan, labelled as a plan

Roadmap

Phases from the original plan are labelled with the status the public record supports, not the status the plan hoped for.

completed
1
ongoing
4
planned
1
exploratory
1

Phases

  1. Phase 1completed

    One physical node

    Part 2 records a commissioned Raspberry Pi that boots, has an identity and can be given a local job. Hardening continued after that day.

  2. Phase 2ongoing

    A job leaves and a result comes back

    Part 2 records one assigned job and one returned answer. That is an early path, not a finished gateway.

  3. Phase 3ongoing

    More than one participant

    Part 6 records a second physical Raspberry Pi, CPU-only, alongside the Hailo node. The two ran independent requests in parallel. Independently operated participants are not yet in the record.

  4. Phase 4ongoing

    Scheduling and recovery

    Part 4 begins model-aware routing, including capability withdrawal and a busy node. Part 5 adds a model library that separates installed, ready and default deployments. Part 6 places overlapping jobs on two Pis, finds an admission race that returned node_busy while another node was free, and adds remote restart and shutdown in the API, not yet verified on the nodes. Routing does not choose by answer quality, and recovery is not claimed as complete.

  5. Phase 5ongoing

    Measurement

    Part 2 records a narrow soak: temperature, free memory and a single reply. Part 5 adds stored answer evaluations and a frozen 24-case hold-out across three deployments on one Pi. Part 6 measures compute time, client wait and batch throughput for paired 3B requests on two Pis in one session. None of these is a general benchmark, and time to first token and power were not measured.

  6. Phase 6planned

    Learning experiments

    Parts 2 and 6 state that no training step was run. Part 6's attempt to split one answer across two nodes was an inference experiment, and it failed its validation. Distributed learning remains ahead of the public record.

  7. Phase 7exploratory

    Less dependence on one coordinator

    Part 1 files this as a direction to earn, one experiment at a time. It is not a design that has been demonstrated.

Recorded so far

The journal entries that move the roadmap, with publication and work dates.

  1. Part 1plan published

    Plan, before hardware

    The research question, a heterogeneous Raspberry Pi design and a phased roadmap. None of it had been tried on real hardware yet.

    published
    evidence
    Design and roadmap only
    Read Part 1
  2. Part 2demonstrated

    One node commissioned

    A Raspberry Pi 5 with an AI HAT+ 2 booted, kept its identity across a reboot and returned one short prompted answer. No training step was run.

    work
    published
    evidence
    Commissioning notes, one inference reply
    Read Part 2
  3. Part 3implemented

    Identity and heartbeats

    A node agent that identifies itself and reports health, rather than an anonymous machine on a network.

    published
    evidence
    Node agent behaviour described in the journal
    Read Part 3
  4. Part 4implemented

    Model-aware routing begins

    Being online was no longer enough: a node had to be able to run the requested model. The same entry says there was still one physical Pi.

    work
    published
    evidence
    Capability routing on a single node
    Read Part 4
  5. Part 5measured

    Answers measured before choosing a model

    Part 4 got a request to the right model; Part 5 asked whether the answer was any good. A frozen hold-out compared a 3B CPU candidate with two 1.5B deployments. It passed more cases but missed the promotion rule, so the default stayed on Hailo. Still one physical Pi.

    work
    to
    published
    evidence
    Stored evaluations, 23 paired synthetic cases
    Read Part 5
  6. Part 6measured

    Two physical nodes, parallel inference

    A second Raspberry Pi 5 without Hailo joined. Paired Qwen2.5 3B jobs finished in about the wall time of one, roughly twice the batch throughput, but no single answer got faster. Splitting one answer across both Pis failed its validation. No training was run.

    work
    to
    published
    evidence
    36-request 512-token matrix, one session
    Read Part 6
  7. planned

    A sturdier two-node setup

    Part 6 names the next work: repairing the admission race, improving streaming and context handling, aligning live services with startup units, and testing remote power recovery. Not in the public record yet.

    published
    not yet
    evidence
    No public evidence yet