The handover gate

Moving something from one sphere into another sphere's core is never an accident. It's a deliberate, traceable act — a handover — and it's the one kind of movement in the whole model that has to go through an explicit gate, rather than happening as a side effect of someone editing a file in the wrong place.

Why a gate at all

The design target for AIBOS, as the operating model lays out, is real scale — 20 to 100 people, each directing 10 or more agents, hundreds to thousands of coordinating actors. At that scale, the standard failure modes are collision and duplicated work. Conflicting versions follow close behind, and you lose track of where things came from. A sphere is the sanctioned sandbox where exploration inside it is cheap and safe; the boundary between spheres is where coordination actually has to happen, which is exactly why crossing it is the one action that has to be deliberate.

Nesting doesn't change this. Spheres nest inside each other — a person inside a sub-sphere inside a sphere — but a handover stays deliberate even between a parent sphere and its own child. A parent frames its children with policy and boundaries; it doesn't reach into a child's core by accident just because it sits structurally "above" it.

The five rules

The handover gate is enforced through five explicit rules — together, the standard's own answer to what would otherwise be chaos as more actors and more spheres come online.

• One authoritative home per thing. Everything lives in exactly one place it actually belongs. A copy elsewhere is either a link back to that home, or it's archived with a marker pointing to where the real version now lives — never a second living duplicate. This is what kills the "which version is the real one?" question before it starts.
• Boundaries are crossed only by handover. Something never slips from one sphere into another because a file got edited in the wrong place. It crosses through an explicit, recorded handover action, every time.
• Where it came from travels with it. When something crosses a boundary, its origin comes along: who created it, which sphere it came from, and what it descends from. Nothing arrives at its destination stripped of context — this is the same "why travels with what" discipline that governs decisions everywhere in the standard, applied specifically to movement across a boundary.
• Exploring is cheap and isolated. Inside your own sphere, you can experiment freely and reversibly without touching anyone else. That isolation is precisely what lets the boundary itself be strict — you only pay the cost of a handover when something is actually ready to leave the sandbox.
• The status is always readable. Where something stands in its life is never hidden, and it reads as one explicit sequence: exploring → prototype → handed over → built → archived. Anyone can see where something is without having to ask whoever created it.

/motta — the receiving side of the same discipline

Where the handover gate governs handing something off, /motta governs receiving it — the mechanized, intake-facing half of the same discipline. Material arriving in a sphere's incoming/ folder gets triaged into one of four classes before anything is treated as processed:

• work or an idea worth pursuing routes to a new initiative
• something spanning multiple phases gets split
• a decision gets logged to the decision record
• anything purely reference or FYI gets an explicit classification line, rather than being left ambiguous

The rule that gives this teeth: a durable trace has to exist before the source material is allowed to move out of incoming/. Triage isn't considered done because someone skimmed the note — it's done when there's a record showing where the material actually went. That's the same discipline the five rules above apply to outgoing handovers, mirrored on the side that's catching the work rather than sending it.