Tools
Conformance & audit
What 'compliant' means, and the nightly audit.
4 min read
Conformance and audit
"Compliant" in AIBOS means something specific: a sphere passed a measurement, not that it made a claim about itself. The model is pull, not push — the master standard offers a version, a sphere chooses whether to be measured against it, and a nightly audit reports the actual distance between the two. Opt-in, but binding: nobody is forced to run the audit, and skipping it means owning the risk of drifting without knowing it.
Three tiers, not one bar
Conformance isn't all-or-nothing. A sphere conforms at a tier, and the tier tracks where the sphere actually is — you start simple and grow into stricter checking as the work demands it.
- Just getting started. The baseline: every folder describes itself, and every choice is logged with its reasoning. The sphere also declares which version of the standard it's pinned to.
- Running for real. A meaningfully larger set of contracts gets enforced at this tier, including:
- placement discipline — no folder appears without going through
/plasser - anti-duplicate checks
- intake triage
- several of the memory rules covered in Memory architecture
- placement discipline — no folder appears without going through
- Coordinating across spheres. The deepest tier, and it doesn't activate on a calendar date — it activates on a state change: the moment a second active sphere exists. Coordination machinery that would be pure overhead for a single sphere only turns on once there's actually a second sphere to coordinate with.
The audit itself
audit.sh is the mechanism behind all three tiers — roughly 1,075 lines across 32 sections, each checking a different facet of the standard. Every finding it produces gets classified into one of three signals:
- BLOCKER — stops the wave. Something has to be fixed before anything else proceeds, and the audit exits with a non-zero status specifically so nothing downstream can quietly treat a broken sphere as fine.
- WARNING — opens a case. Real and worth tracking, though it doesn't halt work in progress.
- INFO — a lighter-weight, informational signal for things worth knowing but not acting on immediately.
Running the audit is itself one of the six canonical skills — /samsvar — so checking conformance is never a separate ritual bolted onto the standard from outside. It's the same mechanism a sphere reaches for after placing a new folder, after installing a capability, or simply overnight, every night, without anyone having to remember to ask for it.
What it actually checks
A sample of what those 32 sections cover, concretely:
- Folder markers and dead pointers — every folder carries a valid self-description, and no pointer in the registry leads to something that no longer exists.
- Orphaned folders — anything on disk that the registry doesn't account for gets surfaced; the sphere can't quietly carry structure nobody registered.
- Memory character budget — a memory file that's grown past its size limit gets flagged instead of being left to grow forever.
- Version lag with a migration path — if the sphere's pinned version sits behind the standard and an upgrade script exists, the audit says so, with a pointer to the path forward.
- Intake without a durable trace — material marked as processed without a record of where it actually went gets caught here, every night, as the backstop behind the intake rule covered in The handover gate.
- Documentation drift — a parent folder's child index that no longer matches what's actually on disk gets flagged, so the registry never lies about the filesystem.
- A cap on unfinished work — "Your 3" — a WARNING when one owner has more than three initiatives going at once in explore, define, or build. Finish or park something before starting the next.
Self-audit — the standard checks its own reasoning
The standard doesn't only measure spheres against itself; it measures itself the same way. self-audit.sh runs this check — internally named K-RAT — against every principle and every contract in the standard, confirming each one carries a valid rationale block explaining why it exists, rather than only a rule stating what it requires. A missing or invalid rationale block counts as a BLOCKER, and it's caught before the change is ever allowed to be saved into the standard's history. The standard's own design is held to the identical bar it holds every sphere to.
The loop, proven same-day
The pull model isn't just a diagram — it's been run end to end and timed. On 2026-07-03, the loop ran for real, start to finish, in a single day. Feedback from a live sphere became a patch. The patch became a new released version of the standard. Both spheres running against it pulled the update back in before the day was over. That's the loop the whole conformance model depends on actually closing, not just being designed to close.
Where this connects
Conformance is the enforcement layer behind the promise that the manual and the running system never drift apart (see The operating model), and it's the mechanism that makes the pull-based federation model in Federation and versioning trustworthy: a version pin only means something if there's an audit actually checking it.