openrig-operating-model

The OpenRig Operating Model

Canonical term: the Operating Model. How an OpenRig topology organizes every kind of context so that any agent — cold, fresh, or five generations in — can find what it needs and knows where to write what it learns. Everything below runs on markdown files, scripts, and conventions only; the rig verbs that formalize pieces of it are conveniences, never dependencies.

Boundary (2026-08-11): this skill owns the STRUCTURE (trees, chains, trace, write protocol). The SUPPLY layer — how canon content flows into the chains: addresses, maps, renders, EMM maturity, census — is openrig-corpus-canon, the deliberate drain mechanism the dual-home interim anticipated.

Companion implementation assets in this skill's folder:

• templates/ and scripts/ — starters and working tools, described in §8.

1. The model in one breath

Everything lives on one of two trees, and every kind of context is a chain: the same filename at every level of a tree. To know anything, you trace from where you are toward the root, reading that one filename at each level — nearer levels refine or override farther ones. The trace (§5) is the act of doing that ascent deliberately, with your own file reads.

• Topology tree — how work is done: fleet → instance → rig → pod → seat.
• Work tree — how the product gets built: project → mission → slice → proof item.

An instance is one OpenRig daemon and the rigs it manages; a fleet is all instances. Where a daemon runs is a deployment fact, not an altitude — say the instance's name when you mean a particular one.

The one-parent law (design-ruled 2026-08-10): the trace follows the directory path and NOTHING else — no pointer fields, no link-following, no branching, ever. The trace is the instrument confused agents reach for, so it must be simpler than anything it corrects: path-only ascent fails only in obvious ways. A child that relates to a second parent gets an also-serves: ANNOTATION (read by humans and agents, walked by nothing) — and a genuine two-parent tie usually means the item belongs one level up, under the common ancestor, with mentions pointing down. The operational many-to-many lives in the queue's tags, which are maintained by use. Legacy serves: lines are transition bridges for the flat layout only: never required, never walked, deleted as work nests properly.