The three git roots

AIBOS runs on three separate homes, and mixing them up is the easiest way to misread how the whole system actually works. They can look alike on the surface — folders, a registry, a set of rules — but they play completely different roles, and the whole model depends on keeping the difference clear.

A quick word on version history

All three of these homes run on git underneath, which — if you've never touched it — is really just a very thorough version history. Think of "see edit history" in Google Docs: every change gets saved, along with who made it and when. You can always step back and see exactly what a file looked like at an earlier point. Nothing gets silently overwritten. Git does the same thing for a whole folder of files at once, and it's the quiet machinery underneath almost every promise this standard makes about nothing ever getting lost.

The standard

The standard itself is the versioned master copy. It holds:

• the philosophy and the operating principles
• the rules and contracts
• the skills
• the catalog of add-on capabilities

— all under one numbered version. When someone says "AIBOS" without qualifying it further, this is what they mean. It's the copy every sphere's nightly check measures itself against, and its main line of history stays unbroken at all times: nobody building on the standard is ever left holding a copy that's fundamentally broken.

Your own sphere

Your own sphere is raised by the installer and pinned to whichever version of the standard you chose. This is where your actual company lives — your registry and your agents, your rules and your memory — and it's genuinely yours: nothing lands in it that you didn't pull in on purpose. Your sphere is measured against the version it's pinned to; it doesn't inherit changes from the standard automatically, and it never writes back into the standard's own registry directly.

The sandbox

A third kind of space exists purely for trying things — somewhere to test something reversible without touching your sphere's core directly. This is where reversible experiments actually happen: build-to-learn work marked EXPERIMENTAL and kept isolated from anything running for real, so trying something and throwing it away costs nothing. Nothing here has to pass a go-live gate, because nothing here is live.

One writer per home

A simple rule keeps these three homes from bleeding into each other: each one has exactly one authoritative writer — its own owner. Nobody saves a change directly into a home they don't own. (Saving a change into a home's history is called a commit, if you ever see the word in a tool.) The standard reaches your sphere by pull, never by push. Your sphere reaches back toward the standard, when you've got something worth contributing, through a review gate — and your own local registry stays local, never quietly propagating into the standard's own register.

How a contribution actually travels

A change usually starts somewhere ordinary: inside a real sphere, where day-to-day pressure surfaces something the standard doesn't yet handle well. It gets proposed back through the review gate, rather than saved straight into the standard. Once accepted, it becomes part of a new version of the standard, released with its own upgrade script. From there, every sphere — including the one where the idea started — picks it up the same way any other sphere would: by choosing to pull it in, on its own schedule, never because it got pushed. Having raised the idea doesn't earn a sphere special write access to the master copy; it goes through the same gate everyone else does.

Where this connects

This structure is what makes Federation and versioning — the pull model, numbered versions, upgrade scripts — actually enforceable rather than just aspirational. Three homes, one writer each, one direction of authority: it's a small set of rules, and nearly everything about how the standard scales to many spheres rests on them holding.