Federation and versioning

AIBOS distributes itself as one shared, versioned standard that many separate companies choose to run against, each on its own schedule. The rule that shapes almost everything about that relationship: you pull updates in — nobody pushes them at you. (The standard's own internal name for this doctrine is F-PULL, if you ever go looking for it in the source.)

Compliance is something you measure, not something forced on you

In a push model, you're compliant because someone forced a rule into your system. Here, compliance works differently: you're compliant because a nightly check measures that you actually match the version of the standard you chose to follow. That distinction matters — it's what turns "compliant" into a fact you can verify, rather than a claim you're stuck trusting.

You choose when to upgrade

Nothing gets pushed into a running sphere against its will. Upgrades move one version at a time, with the option to roll back at every step, and you decide when to take the next one — or whether to take it at all. Automatic upgrades are off by default: if you want your sphere updated automatically as new versions ship, you have to turn that on yourself, rather than discovering one day that the standard changed underneath you without warning.

Every version ships with a way to get there

The standard versions itself the same way it asks you to run your own business — numbered releases, like an app, following three rules:

• a small fix bumps the last number
• a bigger change bumps the middle number
• a breaking change bumps the first number

The master copy of the standard is kept unbroken at all times, so nobody relying on it is ever left holding something fundamentally broken. Every version that changes what you need to do to stay compliant ships with two things together: notes explaining what changed, and a script that actually makes the change for you. A migration note is meant to be run, not just read.

Good enough is a real destination

Pulling in a new version is never a demand. It's an invitation: here's what changed, here's the script that gets you there whenever you're ready. You can sit on an older version indefinitely and still be fully compliant against that version — the version you pinned to is the actual contract, and you're always measured against whichever one you chose, never against whatever just shipped. Adoption works like a staircase: every step is a legitimate place to stand, including the step where you're aware the standard moved and you're deliberately choosing to stay put. None of that counts as falling behind.

Releases come to you

You don't have to go looking for what changed. A release that touches your workflow or something you depend on announces itself to you directly, rather than leaving you to stumble across it later — or worse, leaving someone else to wonder whether you were ever told. Pull still decides when you actually take the change; the announcement just makes sure that choice is an informed one.

The standard listens back

Some of what improves the standard comes from watching how spheres behave — version drift, which checks trip most often. But real feedback matters too: when you raise a wish or a question about the standard itself, your lead agent captures it in a dedicated feedback folder and routes it upstream on your behalf. What actually leaves your sphere is something you control through a setting — the agent never decides on its own what business-adjacent material travels out into the world.

Where this connects

Federation and versioning is the doctrine layer; Conformance and audit is the mechanism that makes it real — the audit is what actually measures the distance this page talks about. The three git roots covers the repository structure this doctrine assumes: exactly one writer per repository, and a strict separation between the standard itself and any sphere built on it.