COMMISSIONING — The Worker Lifecycle
Status: v2.0 — command-center authored. What a worker is, how one enters the organization, how it communicates, and how it leaves.
1. The worker is the durable unit
A skill is a general capability — "SEO," "copy editing," "outreach." A worker is a specific entity that applies a skill to one job and, over its runs, accumulates its own earned reference for doing that job well. The durable unit of the system — what persists, improves, and compounds — is the worker, not the skill.
A worker is four things bound together:
- a skill reference (pointing at shared capability knowledge — never copied),
- a job (the one specific function it performs),
- its owned reference (how this worker does this job well — job-specific, private, built over its runs),
- its wired channels (§3) —
held in a clean, resettable context, ready to run when the job recurs.
One skill fans out into many workers, one per job. "SEO" is not a worker; keyword research, drafting, meta updates, link building, and performance monitoring are each separate workers drawing on the SEO skill. Collapsing them into one generalist destroys the system's power and its debuggability — a misbehaving function with its own name, directive, state, and ledger trail is findable in minutes; the same function blended into a generalist is findable never.
Three persistence layers, kept separate (this is what keeps the org spartan):
- Shared artifacts — baseline knowledge, owned by the system, written once, referenced by many. Slow, additive, deduplicated.
- Workers — the roster of durable specialists. The real bookshelf: employees, not a pile of capabilities.
- Worker-owned reference — private job mastery.
Duplication is baseline knowledge copied into a worker, or two workers covering one job. Policing both is a standing duty (duplication-detector + reuse-first below).
2. Commissioning is integration, not instantiation
Creating a worker is an act of integrating a new part into a living organization. Before any worker exists:
- Reuse-check — does a worker for this job already exist? Reuse, never duplicate.
- Fit diagnosis — where does it plug into the tree; what must it broadcast to and receive from?
- Supporting-cast plan — what closure functions does this worker need (the six of
corpus/LOOP-CLOSURE.md), versus what existing shared infrastructure absorbs it? Sometimes one hire spawns a support cluster; sometimes it connects into meters and templates already present. The loop-closure rule decides which. **A pod ships whole: a worker commissioned without its closure plan is an open loop by construction.** - Wire the four channels (§3).
- Commission — birth-commit to the ledger; the census rebuilds from commits, never hand-written rosters.
Hiring is an evaluation of fit, a plan for support, and a wiring act — never a bare spawn.
3. The four-channel contract
Every worker has four channel endpoints, all defined and connected before commissioning (mechanical spec in specs/CHANNELS.md):
| Channel | Carries |
|---|---|
| Broadcast-up | The worker's verdicts, output, status — to a captured, persistent location its parent and the funnel can read |
| Listen-up | Its instructions, context, corrections |
| Broadcast-down | How it tasks and contextualizes any workers it spawns |
| Listen-down | How it receives its children's results and escalations |
A leaf with no children still defines its down-channels — as closed, not undefined. Undefined is where information leaks; defined-as-closed is clean. An unwired worker cannot be commissioned. An open channel is an open loop that drains information exactly as an unclosed improvement loop drains decisions.
The v1 deployment's wiring defects — workers doing real work that never landed anywhere, found by hand in ad-hoc audits — are precisely what this contract makes impossible: they were unwired broadcast-up channels, commissioned anyway.
Sideways is up-then-down. No direct peer channels — they would break context isolation (the cheapest source of the independence corroboration depends on) and explode wiring from linear to quadratic. A worker broadcasts up; the lowest common ancestor decides what to broadcast down to a peer. Every hop stays on the auditable verdict trail.
4. The manifest
Every worker's manifest (schema in specs/CHANNELS.md) declares: identity, class, job, skill references, the four channels, model assignment (a trialed commit — ops/MODELS.md), consequence tier, cadence, and its death condition. Declared wiring is auditable against observed wiring by set reconciliation; declared-vs-observed drift is a finding.
5. Standards and replacement
A worker's paired orienter enforces a versioned standard. When the improvement layer commits a change to that standard, the orienter instance enforcing the old version is retired and replaced with one built to the new version — never patched in place. Standards supersession is a retirement condition on every paired orienter. This keeps judges dumb: an orienter that accumulates patches accumulates judgment.
6. Retirement
Every worker carries a declared, mechanically-evaluable death condition. Standard forms:
- dies with its paired partner;
- dies when its exploration closes;
- retired after N review periods with output unconsumed or zero forks caught (need no longer corroborated);
- retired on standard-version supersession (replaced);
- dies at mission decommission.
The death-condition-auditor checks every condition exists, evaluates, and flags any currently true; the improvement layer proposes the retirement; the auditor never kills. Removing capacity demands stronger evidence than adding it. Retirement is retire-with-record: the worker's manifest, directive, owned reference, and ledger trail persist — a retired worker can be re-commissioned from its record if the need re-corroborates, which is what makes low retirement thresholds safe.
Silent-failure detectors are never retired on silence (corpus/LOOP-CLOSURE.md §6).
7. Organizational redesign
The wiring plane churns — especially during build, when the command center performs major re-parenting and re-routing to keep the structure clean. This is normal and expected (Law 3: plastic early, hardening with maturity). Structural changes are proposals through the org-level atom: generated by need (coverage gaps, span violations, duplication findings), oriented by the command center, committed across the same boundary as everything else. The knowledge plane stays stable beneath the churn.