Federation
Neutron is not one deployment you visit. In federation mode, Neutron Cores talk to each other as peers, and each core centrally controls one or more orbits — satellite nodes that act where the work actually is.
Why this shape
The obvious alternative — one big server everyone logs into — cannot do the thing people actually want, which is an agent that acts where the work is. Some work is on a server another team runs. Some is on the machine in front of you, inside applications that have no API.
Splitting the system into federated cores and orbits has three consequences worth stating plainly:
Orbits make local action legitimate. An orbit runs on a node you own, not on shared infrastructure, so controlling a desktop is a connector rather than a liability.
Federation needs its own governance. One core driving another is exactly the escalation path an attacker would want, which is why cores federate over the same authenticated interface and the same gates as everything else rather than a private side channel. Full governance and auditability apply across the federation, not just inside one core.
The rails move to the edge. An orbit enforces its own limits locally — drift detection on the mouse, caps on session length and action count — because a network round-trip is too slow to stop a runaway input loop.