Appendix E - 2. Applying the Recipe

This chapter applies the recipe to self-communicate, self-governance, and self-operate. Self-governance is the recursive case: it models the MAGE method itself. Self-operate tests the method against a less obviously modelable domain: operations.

E.2.1 self-communicate

Problem

The fleet and its operator produce prose and diagrams constantly — control descriptions, design docs, mechanism entries, runbooks, handoffs, and the orchestrator's own status reports and tradeoff explanations to the human. Ungoverned, it drifts: inconsistent terminology, inappropriate document structure, LLM tells, and poor figures. The problem is not generating prose but producing it consistently against an engineering standard. The skill packages the craft needed to do that.

Fundamental Model

Rhetoric as craft. Treat technical writing as a set of named techniques rather than taste alone. Document form, lexicon, voice, audit, and visualization then become independent facets of that model.

Orthogonal Models

One file per facet.

Each answers a different question about the document: form chooses its structure, lexicon its terms, voice its register, rhetoric its sentence-level technique, visualization what should be drawn, and audit how the result is checked.

Governing Principle

The governing principle is that representation should serve rather than distract from the idea. Apply the facets in order: choose the document form, draft in the house voice using varied rhetorical devices, use canonical terms from the lexicon, draw relationships that prose carries poorly, and audit before shipping. One additional rule applies throughout: name the concept once, then use the name.

Layout

self-communicate/
  SKILL.md
  writing/   rhetoric.md  engineering.md  lexicon.md  voice.md  audit.md
  drawing/   diagrams.md  charts.md  tables.md  svg-audit.py

One directory per concern, one file per facet — the tree is the orthogonal-model set.

Lesson

Rhetoric-as-craft turns a collection of style rules into a model. Separate facets can then load independently and be reused by other skills. The skill remains soft; where an audit result must block delivery, the audit belongs in a gate.

E.2.2 self-governance

Problem

An agent can have excellent tools and still engineer badly. It runs the tests, calls the formatter, queries the repository — and still models the wrong thing, gives authority to a fact that should stay advisory, or freezes a one-off mistake into a permanent rule. The missing capability is not another tool. It is the engineering method itself: knowing what to model, what must hold, and which judgment is worth making durable.

Self-governance packages that method as a skill. It teaches the agent to recognize the situation, choose a Modeling or Alignment move, act through the governed environment, and decide what should persist. The skill carries the method, not the codebase's facts. Concrete system knowledge—what the codebase intends, contains, and guarantees—must come from model providers rather than the skill's memory.

Fundamental Model

The MAGE engineering loop. Everything in the skill supports one cycle, run whenever the agent engineers:

Self-governance is not a third MAGE activity; it applies Modeling and Alignment to the agent's own engineering work.

Orthogonal Models

The loop's questions are independent, so each becomes its own facet. Each of six directories answers one question; the router identifies the question and directs the agent to the corresponding facet.

The facets answer independent questions: recognizing the situation does not select the model, choosing a move does not determine its authority, and knowing the method does not supply system facts. Load only the facet the current question requires.

Governing Principle

Apply MAGE to the work itself: model what must be understood, give authority to what must hold, and convert recurring judgment into durable engineering structure. Five operating rules follow:

Self-governance is not self-certification. The agent may select, model, propose, and check, but its belief that the work is correct is not evidence that it is. A skill is soft: it guides a probabilistic agent but cannot block. Hard mechanisms may be proposed or scaffolded by the skill, but enforcement must come from the harness or another external mechanism. The deciding evidence comes from a mechanism that sits outside the reasoning which produced the change.

Layout

self-governance/
  SKILL.md            the router — the loop, the routing table, the ambient stance
  principles.md       the portable engineering method (the ambient reflexes)
  modeling/    repertoire.md  moves.md
  practice/    situations.md  judgment.md
  system/      model-access.md
  skills/      repertoire.md
  alignment/   repertoire.md  mechanisms/INDEX.md  mechanisms/<target>/<family>/<mechanism>.md
  learning/    governance-conversion.md
  templates/   system-models-starter-kit.md  state-machine-model-starter.py  …
               — scaffolds for creating system models, never system-specific truth

One directory per question, one file per facet. The mechanism census lives under alignment/, where prevent-versus-detect now sits one level below the loop.

Lesson

Self-governance models the MAGE method itself. Its fundamental model is therefore the engineering loop, not a taxonomy of mechanisms.

The Modeling–Alignment boundary matters especially here: self-governance can propose and scaffold a constraint, validator, or gate, but the resulting mechanism — not the skill's judgment — must supply the enforcement.

It also composes with the other skills: self-governance designs models and mechanisms, self-operate runs them, and self-communicate governs how they are represented.

E.2.3 self-operate

Problem

Operating an agent-fleet repository involves recurring but heterogeneous tasks — dispatch and recover agents, keep the mainline deployable, reclaim disk, weather colima and host-tool trouble, watch cron health, RCA an ambiguous signal. Without a model, each failure must be diagnosed almost from scratch. The skill provides a lifecycle map that routes symptoms to classes and typed runbooks that make responses repeatable.

Fundamental Model

The engineering lifecycles. A fleet repo runs the same few: manage-agents, manage-context, manage-git-repo, manage-deploy, manage-dev-env, plus cron and govern-your-own-loop. Every symptom belongs to one lifecycle, so every break routes to a class instead of being met cold. The lifecycle map is the fundamental model: it turns operational sprawl into a small set of recurring classes.

Orthogonal Models

These answer three independent questions: where the problem belongs, what response it requires, and when that response should trigger.

Supporting resources: build and handoff templates (templates/) — used when operating work crosses into implementation.

Governing Principle

Establish the healthy state first, then classify deviations from it. Route each symptom to a lifecycle and run the corresponding procedure. When diagnosis reveals that a model, mechanism, or authority should change, hand that engineering decision to self-governance. Automate deterministic steps; prepare irreducible judgments for escalation.

Layout

self-operations/
  SKILL.md
  principles.md
  examples/   lifecycle-L1..L6-*.md   runbook-*.md
  hooks/      reflection_facet*.py  hook_*.py  _hook_*.py  README.md  ...
  templates/  pointers-starter.yaml  runbooks-starter.yaml
              gen-and-lint-partb-starter.py  EPIC-TEMPLATE-starter.md  design-doc-template-starter.md

Lesson

The lifecycle model turns incident response into routing: identify the affected lifecycle, select the corresponding runbook, and determine which steps can be automated. Typed runbooks distinguish runnable steps from automatable and irreducible judgment. Self-governance changes models and mechanisms; self-operate runs them and returns evidence; self-communicate governs their representations.

Figure E.2-1 shows the three skills acting on one governed engineering environment: self-governance changes it, self-operate runs it and returns evidence, and self-communicate governs its representations.

Three partner skills acting on one governed engineering environment A central box, the governed engineering environment (GEE), is acted on from three directions. Above it, self-governance engineers and improves the environment: an arrow points down into the GEE, labelled "improves — mints models and mechanisms." Below it, self-operate runs the environment's operational lifecycles: an arrow points up into the GEE, labelled "operates — runs the lifecycles." A dashed return arrow curves up the right side from self-operate back to self-governance, labelled "evidence — returns deficiencies," so that reality exposing a weakness re-enters the engineering loop. To the left, self-communicate supplies the craft for every representation the other two produce: a short arrow points into the GEE, labelled "documents." The three skills are orthogonal — each owns one reason to change — but not isolated: they meet through explicit interfaces on the one environment they share. Self-Governance engineers & improves the environment GEE the governed engineering environment Self-Operate runs the operational lifecycles Self-Communicate governs representations improves mints models & mechanisms operates runs the lifecycles evidence returns deficiencies documents
Figure E.2-1. Three orthogonal skills act on one governed engineering environment. Self-governance improves it; self-operate runs it and returns evidence; self-communicate governs the representations both produce.

Orthogonality does not require isolation. Each skill has one reason to change—communication, engineering judgment, or operation—and explicit interfaces connect them. Self-governance produces models and mechanisms that self-operate uses; self-operate returns evidence; self-communicate governs their representations.

© James C. Davis, 2026–present