Part 1 · Operator’s Guide
Adopt It
Begin with one chat, reconcile your system and grow the loop.
Public teaching edition · 1 October 2026
Distributing the method
Publish the methods people can safely reuse, with one maintained URL per concept. Keep private rosters, messages, incidents, client work and credentials behind the appropriate access boundary.
A public teaching page should stand on its own. Do not make strangers depend on private repository links or imply that a fictional example is a verified execution. Link to public evidence where it actually supports the claim.
Use a source revision and release record to tie derived pages to the master. A public page, an installed package and an operational runtime are separate artifacts. Each needs its own verification.
Keep adopt or merge
Use this worksheet with the system you already have. For each row, name your authoritative record, decide keep/adopt/merge, identify the owner and write one acceptance test.
| Component | Question to resolve |
|---|---|
| Durable record | Where can the next worker reconstruct this task? |
| Claiming | Can workers recognize competing work, and what actually refuses a collision? |
| Definition of done | What proof can the reviewer open? |
| Agent identity | Can you tell which worker performed the action? |
| Rules | Which source is canonical, and which copies are derived? |
| Skill library | How does a fresh task activate the current recipe? |
| Recipe and run record | Is this the method or one execution? |
| Model routing | What is the cheapest method meeting the test within the total budget? |
| Onboarding | What does a new worker read, and how is comprehension tested? |
| Access | Which audience can read and act, through which verified route? |
| Human decisions | Who may authorize consequential changes? |
| Public canon | Which URL is maintained for this concept? |
Do not install a second status board merely because this guide uses one. Reconcile duplicate masters first. A saved document is enough for a first low-risk exercise.
Six congruency gates
Report each gate PASS, FAIL or UNKNOWN, with evidence:
- G1 Identity: exactly one artifact is canonical, and each derived view names it
- G2 Containment: every view element resolves to a master element
- G3 Coverage: each required master element is reachable from an appropriate view
- G4 Arithmetic: either views partition the counted set, or overlapping totals are not added
- G5 Generation: published counts, versions and dates come from the source; rebuilding is stable
- G6 Installation: the consumer has the intended master or selected view, without conflicting duplicate installs
A public view may change presentation, examples and depth. It must preserve the operating sequence, evidence standard, safety gates, authority and definition of done. Restricting private evidence is an audience boundary; removing the safety rule is a change to the method.
For a merge, find the existing artifacts, choose the canonical source, compare sections, classify each as promoted/duplicate/restricted/retained/held, edit the master, then test content, rendering and references. Do not solve two competing guides by creating a third canonical one.
What to assemble
The reusable pieces are the public recipe, agent skill, task record, note template, QA ladder, access boundary, schedule pattern and canonical index. This guide provides the contracts and templates; your team must choose, install and test the implementation.
Start manually. Prove a fresh task can read the method and produce one checked result before adding a clock. For scheduled work, verify the first firing, missing-run detection, safe fallback and stop condition. Test a backup without letting it duplicate a live action.
Choose one integration owner. Keep source review, publication authority, installation and observed operation separate in the release record. A polished document is useful teaching material; it is not evidence that a production system enforces the promises.
Your first 90 days
First session: choose one small drafting-only task using fictional or authorized notes. Give an audience and acceptance test. Inspect the output yourself. Save the request, result, evidence and one lesson. No new platform is required.
Days 1–30: repeat the loop on a few useful tasks. Establish one durable record, explicit ownership and reusable recipes. Test one handoff by having a fresh session continue from the saved record without a re-brief.
Days 31–60: add review proportionate to risk and actual access controls. Test a conflicting claim, a failed acceptance check and a client boundary. Report what is observed and what remains untested.
Days 61–90: improve the methods from real runs. Publish only public-safe lessons at the existing canonical destinations. Compare accepted outcomes, rework, time and whole-job cost against your baseline.
These are suggested stages, not promised installation deadlines. Move at the pace supported by your authority, tools and evidence. Keep what already works; fix a demonstrated gap rather than adding ceremony.