The operating model (OM1–OM15)

The operating model is the second of the three heights in the principle foundation — fifteen business-facing principles, OM1 through OM15, each of which stands on its own without requiring code knowledge to understand. This is the layer an owner, partner, or new hire meets when they're trying to understand how the company actually runs day to day, distinct from the philosophy above it (KF) and the technical build below it (P). See Principles overview for how the three heights connect.

Company as Code (OM1)

The company is run as a living, versioned document rather than a pile of scattered files named things like pitch_v2_final_FINAL. A meaningful change — a new offer, a new piece of messaging, whatever it is — gets proposed and tested in isolation before it's merged deliberately into how the business actually operates, with a full history behind it. Rolling back a bad change is as ordinary as undoing a bad save in a document's edit history.

Everything is born a thread (OM2)

Nothing new starts as a stray chat message or an ungrounded file drop. Every piece of new work opens as a Trellis thread from the moment it begins, which is what makes it possible to trace where any given piece of work actually came from later. See Trellis threads for the mechanics.

Capture anywhere, route deliberately (OM3)

An idea can start anywhere, in a conversation or a stray note, and the model doesn't care where it started. What it insists on is that capture gets followed by deliberate routing to the material's authoritative home. A note that's just dropped somewhere and left there isn't captured — it's lost, and routing is the step that makes the difference.

The handover gate (OM4)

Moving something from one sphere into another's core is a deliberate, traceable handover. It never happens by accident, as a side effect of someone editing a file across a boundary. This is covered in full in The handover gate, including the five rules that carry it.

Check the rules before you change something (OM5)

Before touching a single file, a session is expected to check what already governs the thing it's about to change — where things belong, what naming applies, what workflow is in force. A scheduled heartbeat is held to the same expectation as a manual prompt or an incoming issue.

Experiments are first-class and reversible (OM6)

Trying something — a prototype, a spike, a rough draft — doesn't require permission, because it's reversible by design. Experiments get marked EXPERIMENTAL and live in a contained space where trying and discarding costs nothing, which is exactly what keeps the standard from becoming a bottleneck on learning.

One rights model (OM7)

Humans and agents are governed by a single rights model, not two separate systems bolted together. What an actor can do is a function of actor × sphere — who they are, crossed with which sphere they're acting in — the same primitive regardless of whether the actor is a person or an agent.

Nothing is ever lost (OM8)

Whatever an actor builds is guaranteed preserved and findable later. Nothing disappears silently; retiring something means archiving it with a marker and a pointer to where it went, never a quiet deletion. The durability guarantee behind this is what makes people willing to let go of something and explore freely, rather than hoarding out of fear of losing it.

Rationale is first-class (OM9)

"Why" always accompanies "what." Every strategic choice is documented with its reasoning attached, because a choice without a rationale is one nobody downstream can challenge or reconsider later. The manual is the company's reasoning, not merely its rulebook.

Manual and system never drift apart (OM10)

When the system changes, the manual is updated to match — or the system is corrected back to what the manual says. The two are never allowed to quietly diverge, and the nightly conformance audit is specifically what checks that they haven't. See Conformance and audit.

Scale is the design target (OM11)

The design target for AIBOS is 20 to 100 people, each directing 10 or more agents — hundreds to thousands of coordinating actors. A solo sphere is a legitimate starting configuration of the same system, not the ceiling it was designed for; the coordination problems that show up only at real scale are the reason the standard's structure exists at all.

Spheres nest (OM12)

Spheres nest inside each other: a person sits inside a sub-sphere, which sits inside a sphere. Ownership and rights compose through that nesting rather than being centrally assigned — a parent sphere frames its children with policy and boundaries, and a child holds full autonomy within the boundary it's been given.

Typed archetypes (OM13)

Every agent is typed at birth into one of three archetypes. It might be conversational — a thinking partner in a live session. It might be mission-driven — running a defined job around the clock, reporting results rather than reasoning. Or it might be secretary — always on, facing the outside world on the owner's behalf. A fourth role, caretaker, sits outside all three: it never converses and never decides, it just maintains the sphere overnight. The type an agent is born into determines what it's expected to do, and how much it's trusted to do without checking in first. See Agents and autonomy.

A prompt is input, not an order (OM14)

A session treats whatever it's asked to do as input for its own judgment, rather than a command to execute verbatim. If a request conflicts with what the session already knows about how the sphere should run, it owes the requester pushback and a proposed alternative — catching the conflict before acting, rather than fixing it after something has already gone wrong.

Strictness is a sphere setting (OM15)

How tightly the rules are enforced is configurable per sphere and per domain, not a single global constant applied everywhere. An enterprise sphere might demand strict compliance on everything it touches; a solo sphere can run looser, with the owner carrying the consequence of that choice directly. What never flexes, at any strictness setting: every override and every anomaly is logged as a deviation from standard, and the nightly audit catches it.