diff --git a/operating-model/decision-log.md b/operating-model/decision-log.md
index 8cad8f6..7db7d5f 100644
--- a/operating-model/decision-log.md
+++ b/operating-model/decision-log.md
@@ -40,3 +40,5 @@ Status is intentionally explicit:
 | 2026-09-28 | Confirmed | Long documents carry a table of contents with jump links | Sections with four or more `##` level headings get a TOC block right after the title. Automated tooling in projects regenerates and validates the TOC. See `working-style.md` and `agent-work-loop.md`. |
 | 2026-09-29 | Confirmed | The agent launched on a work board is a dispatcher: one fresh, clean-context sub-agent per job, one at a time, up to five jobs per run, then a full stop until a human says go. | Owner: "ideally, you want each agent to work with a clean context, then each agent is launching a sub-agent be the model then, so subagent finishes a bead and changes bead status and reports back to parent agent. parent agent at any point in only running a single sub agent. after the sub agent finished, the parent agent is lanching the next one in a loop, up to a maximum of five and then completely stop until human asks it go again for another five". The dispatcher only reads the board, claims, launches, reads the report and logs; the sub-agent does one job and makes its board transition. Refines the 2026-09-28 work-loop row: the loop and priorities stay, the agent that runs them changes. See `agent-work-loop.md` sections 2, 3, 4 and 6. |
 | 2026-09-29 | Confirmed | Projects keep their launch prompts as named, versioned files in the repo, with an index; a launch is one line naming the prompt and its path, plus parameters; the run report names the prompt version it ran. | The owner approved the lead's design ("go") for replacing pasted launch text with checked-in prompts, so a launch is repeatable and a report says which prompt version produced it. Adds to the 2026-09-29 dispatcher row. See `agent-work-loop.md` section 7. |
+| 2026-10-06 | Confirmed | Opus is used only for reasoning, design, architectural analysis, new architecture and planning; Sonnet is the everyday workhorse and the default for every subagent; Haiku is for simple, straightforward work; every subagent starts with a clean context and a minimal brief. Owner, verbatim: "Opus should only be used for reasoning, design, architectural analysis, coming up with new architecture and a plan, and general planning, right? The everyday workhorse should be Sonnet, and that is how you will also launch subagents or tasks if you have to, with a clean context. Sometimes, you could be using Haiku too, if the work in simple and straight forward. Every time you launch a subagent, you should let that subagent know exactly what it needs to do with the entire context it needs. Do not populate the context with everything you have. No, you will not overload it with information. When you launch a subagent, we have to be very efficient with resources. That should be a permanent behavior I want to see from all the Opus agents that are running." | Pick the tier by this rule; each subagent brief states exactly the task, the done-when, the binding rules and only the facts it needs, pointing to files rather than pasting and never dumping the conversation. See `working-style.md` → Cost-aware delegation. |
+| 2026-10-06 | Confirmed | No Fable launch (an agent, a review, or a step inside a workflow) without the owner's explicit approval for that launch. Owner, verbatim: "One more rule to always be followed is that Fable cannot be launched without my permission. Any Fable launch requires my explicit approval, and this also needs to go in the permanent memory." | Ask in chat before each Fable launch and wait for a clear yes; approval is per launch and never carries over. See `working-style.md` → Fable launches. |
diff --git a/operating-model/working-style.md b/operating-model/working-style.md
index 2077d3f..c2b18cd 100644
--- a/operating-model/working-style.md
+++ b/operating-model/working-style.md
@@ -29,7 +29,8 @@ starting work.
 | Long documents | Every document with four or more `##` sections opens with a contents list of jump links to its sections, right after the title. Projects generate and check it where they can. | Add a TOC block after the title to let readers navigate long documents more easily. Automated tools in projects should validate and regenerate the TOC list. 2026-09-28. |
 | Editor | Use `vim` for long-prompt editing. | Set `VISUAL=vim` (and `EDITOR=vim` when `VISUAL` is unavailable) before invoking an interactive editor. |
 | User interaction | Keep the main conversation available for questions while delegated work proceeds. | Provide short, direct updates; do not go quiet during long-running work. |
-| Cost-aware delegation | The orchestrating session is the most expensive place for work to happen, so it does not do bounded work itself; but the model that does the work must match the judgment the work needs, because a cheaper model's error in design work costs more than the saving. | Before anything larger than a one-line answer, pick the tier by this rule and state the choice in the brief and the report; ask the owner only when the tier is unclear. **Top-tier model** (the orchestrator's own tier, run as a subagent) for judgment-heavy work whose errors propagate into a design, a ruling or cross-repository alignment: design and interface specs, drafting ruling batches, alignment reads against an upstream repository, critiques, measurement design, ADR review. **Mid-tier model** only for straightforward work with a clear spec whose mistakes surface in tests or a diff: inventories and lookups against a defined question, bounded code changes from a ratified brief, applying ratified rulings to documents, harness plumbing. **Smallest model** for mechanical work where the orchestrator supplies the exact text or command: exact-string edits, commits and PRs, review-thread fixes with the wording given, merges of the main branch, link checks, bulk renames. Whatever the tier, the orchestrator writes the brief and verifies every output itself before it reaches the owner. Run work through a subagent with an explicit model or a written handoff to another session, not the orchestrating session's own tool calls. See `execution-and-handoffs.md` → Mechanical batch delegation. Owner, 2026-09-27: this applies to the orchestrating session itself — it does only work that requires reasoning (design, rulings, judging reviews, planning); straightforward execution always goes to a Sonnet subagent, and dead-simple work (a one-line edit, a single command, a known-answer check) to a Haiku subagent. |
+| Cost-aware delegation | The orchestrating session is the most expensive place for work to happen, so it does not do bounded work itself. Opus is used only for reasoning, design, architectural analysis, new architecture and planning; Sonnet is the everyday workhorse and the default for every subagent; Haiku is for simple, straightforward work. | Before anything larger than a one-line answer, pick the tier by this rule and state the choice in the brief and the report; ask the owner only when the tier is unclear. **Opus** (the orchestrator's own tier, run as a subagent only when the task itself is reasoning) for work whose errors propagate into a design, a ruling or cross-repository alignment: design and interface specs, architecture analysis, new architecture, planning, drafting ruling batches, critiques, measurement design, ADR review. **Sonnet** for everything else, including every subagent by default: inventories and lookups, bounded code changes from a ratified brief, applying ratified rulings to documents, harness plumbing, review-thread fixes. **Haiku** for simple, straightforward work where the orchestrator supplies the exact text or command: exact-string edits, commits and PRs, merges of the main branch, link checks, bulk renames. **Every subagent starts with a clean context.** Its brief states exactly the task, the done-when, the binding rules and only the facts it needs; point to files instead of pasting them, and never dump the conversation into it. Whatever the tier, the orchestrator writes the brief and verifies every output itself before it reaches the owner. Run work through a subagent with an explicit model or a written handoff to another session, not the orchestrating session's own tool calls. See `execution-and-handoffs.md` → Mechanical batch delegation. Owner, 2026-10-06 (current rule, permanent for all Opus agents): "Opus should only be used for reasoning, design, architectural analysis, coming up with new architecture and a plan, and general planning, right? The everyday workhorse should be Sonnet, and that is how you will also launch subagents or tasks if you have to, with a clean context. Sometimes, you could be using Haiku too, if the work in simple and straight forward. Every time you launch a subagent, you should let that subagent know exactly what it needs to do with the entire context it needs. Do not populate the context with everything you have. No, you will not overload it with information. When you launch a subagent, we have to be very efficient with resources. That should be a permanent behavior I want to see from all the Opus agents that are running." Earlier, 2026-09-27: the orchestrating session does only work that requires reasoning; straightforward execution goes to a Sonnet subagent and dead-simple work to a Haiku subagent. |
+| Fable launches | No Fable launch (an agent, a review, or a step inside a workflow) without the owner's explicit yes for that launch, asked in chat. | Ask in chat before every Fable launch and wait for a clear yes; approval is per launch and never carries over to a later one. Owner, 2026-10-06: "One more rule to always be followed is that Fable cannot be launched without my permission. Any Fable launch requires my explicit approval, and this also needs to go in the permanent memory." |
 | Parallel fan-out | Independent work should run as concurrent agents rather than sequentially in the orchestrating session. | Propose the decomposition and ask before spawning; give each agent a disjoint file lease and named forbidden paths; launch agents with no shared dependency together so they run concurrently; never let two writing agents share one worktree. A user waiver to skip asking ("go all the way, don't ask") covers only that task. |
 
 ## Communication standard