ed/manual_slop
Private
Public Access
0
0
Fork 0
Code Activity

conductor(track): nagent_review_v3.1 thicken §8 Operating rules cluster

Browse Source
This commit is contained in:
Edward R. Gonzalez
2026-06-20 11:27:02 -04:00
parent b9b3100662
commit eb7da8d8bc
1 changed files with 185 additions and 36 deletions
Download Patch File Download Diff File Expand all files Collapse all files
conductor/tracks/nagent_review_20260608/nagent_review_v3_20260619.md
+185 -36
View File
@@ -1526,47 +1526,152 @@ The shape tag map: `[I]` for inspectable transformations (the scan, the validate
**Source:** nagent `a1f0680` (`context/data-oriented-design.md:102-116` + `:151-164`); cross-ref `conductor/tracks/fable_review_20260617/`.
**One-liner:** Sampling justifies *replacing* the machine, not only trimming it. The data's shape can show that a different algorithm or representation is the better-fit machine — and a plateau in optimization is the signal to re-sample, not the signal to keep filing. The simplification pass gains a ninth question.
**Pattern(s) vs v2.3:** UPDATE. v2.3 cited `context/data-oriented-design.md` as Acton's canonical rule set; v3 deep-dives the Q9 expansion (the only addition since v2.3 was published on 2026-06-12). The Q9 insight generalizes v2.3 Pattern 1 ("durable work, disposable workers") — replacing the machine is a more radical form of "trimming the machine" that the original 8-question pass did not surface. The project's own `conductor/code_styleguides/data_oriented_design.md` is itself derived from Acton's file (per `conductor/code_styleguides/data_oriented_design.md` header); v3's §8 surfaces the delta so the project's styleguide can track.
**Manual Slop implications:** Manual Slop's `conductor/code_styleguides/data_oriented_design.md` (Tier 0/1/2, simplification pass, enforceable deliverables) is the canonical reference for agent directives. The Q9 addition is the "what's new since v2.3" delta; if the project styleguide adopts Q9 explicitly, agents applying it will know to consider "different machine" rather than only "trim current machine" when sampling points to a plateau.
**Decision candidate:** NEW Candidate 24 (LOW). "Document Q9 ('consider a different machine') in the project's `conductor/code_styleguides/data_oriented_design.md`" — the styleguide is already a derivative of nagent's file; add the Q9 expansion as a Tier 1+ reading-note. See `decisions.md` Candidate 24.
**Cross-refs:** `conductor/tracks/fable_review_20260617/` — Fable's analysis of "watch-dogging" is the opposite pattern. Fable's persona framing ("be careful, watch yourself") substitutes for the data-oriented question "what does the data say?". §8 closes the loop: Acton's operating rules are the data-grounded alternative.
**Source-read citations:**
- `context/data-oriented-design.md:102-116` — "Sample the data you already have" expanded: "the data's *shape* can show that a **different algorithm or representation is the better-fit machine** (sorted-enough → a different sort/merge; skewed → a different code; runny → a run/stream form; sparse → a different container), not just that the current machine needs filing. Sampling justifies *replacing* the machine, not only trimming it. Sampling is also how you find *new* opportunities mid-optimization, not just before starting: when a pass **stalls or plateaus**, that is the signal to re-sample the hottest stage's data and ask whether a different machine fits it better — not to keep filing the current one." (a1f0680)
- `context/data-oriented-design.md:151-164` — new Q9 in simplification pass: "Is there a **different algorithm or representation that fits the data better** than the current machine? Subtraction has a floor; when filing the current approach stops paying (a plateau), the win is often a *different* machine the data's shape points to — reconsider the approach, don't only shrink it." (a1f0680)
- `context/data-oriented-design.md:18-39` — Scope, tiers, and precedence (Tier 0 trivial, Tier 1 non-trivial change, Tier 2 subsystem-scale); "An explicit instruction from the user for the current task" wins over this document (the precedence rule)
- `context/data-oriented-design.md:41-58` — 3 defaults to reject (tools-are-platform, model-of-world, solution-matters-more)
- `context/data-oriented-design.md:60-78` — 8 core defaults (problem-is-data, state-cost, solve-only-problem-you-have, where-theres-one-theres-many, common-case-dominates, exploit-constraints, simplicity-is-removing-work, cant-be-done-is-cost-claim)
- `context/data-oriented-design.md:82-125` — Get the real data (inspect-before-assuming, sample, label-every-assumption, never-fabricate)
- `context/data-oriented-design.md:130-148` — Method (frame → get-data → state-cost → design-transform → simplification-pass → define-done → verify)
- `context/data-oriented-design.md:156-176` — Design rules (minimize-states, explicit-OOR, complexity-requires-evidence)
- `context/data-oriented-design.md:182-191` — Performance claims (never assert unmeasured; label hypotheses)
- `context/data-oriented-design.md:198-227` — Software specifics (batch-first, memory layout, data protocols, hardware is platform)
- `context/data-oriented-design.md:233-243` — Enforceable deliverables (tier 2)
- `context/data-oriented-design.md:249-261` — Final self-check (the 10-question checklist)
**Honest gaps in this cluster:**
- The Q9 expansion is in `data-oriented-design.md` but nagent itself doesn't have a worked example of "replace the machine" reasoning in its commits (the case studies — §10, §11 — demonstrate it empirically but the rules file does not name the pattern). A future track could add a worked example.
- The project's `conductor/code_styleguides/data_oriented_design.md` is derived from this file but may not include the Q9 addition. The v3 delta is the trigger to verify.
- The "stalls or plateaus" signal is a heuristic. When is "the pass is done" vs "the pass is plateauing"? The rule does not distinguish. A worked example would help.
**Pattern summary:** The Q9 expansion is the most subtle single-commit change in v3. The original 8-question simplification pass (Q1: not do this at all? Q2: only once? Q3: fewer times? Q4: approximate? Q5: small lookup? Q6: large lookup? Q7: small buffer/FIFO? Q8: constrain further?) is the radical form of "trim the machine." Q9 ("is there a different machine?") is the meta-level question — not "how do I shrink this?" but "is this the right machine at all?" The data's shape can tell you. The case studies (§10, §11) are the empirical evidence: the PEP case study replaces a generic image-compression library with a tight per-image optimized one; the collisions case study replaces a generic convex primitive collision detection library with a per-type-specialized one. Both optimizations are "different machine," not "trim current machine." The Tier 0/1/2 framing is also load-bearing: Tier 0 (trivial — apply defaults silently) is the project's escape hatch for one-line fixes; Tier 1 (non-trivial change — required: framing + data + simplification + self-check) is the standard; Tier 2 (subsystem-scale — tier 1 + enforceable deliverables) is the heavy path. This updates v2.3's citation of `context/data-oriented-design.md` with the Q9 expansion (the only addition since v2.3 was published on 2026-06-12). The Q9 insight generalizes v2.3 Pattern 1 ("durable work, disposable workers") — replacing the machine is a more radical form of "trimming the machine" that the original 8-question pass did not surface.
**Pattern deep-dive.** The Q9 expansion is the most subtle single-commit change in v3. The original 8-question simplification pass (Q1: not do this at all? Q2: only once? Q3: fewer times? Q4: approximate? Q5: small lookup? Q6: large lookup? Q7: small buffer/FIFO? Q8: constrain further?) is the radical form of "trim the machine." Q9 ("is there a different machine?") is the meta-level question — not "how do I shrink this?" but "is this the right machine at all?" The data's shape can tell you. The case studies (per §10, §11) are the empirical evidence: the PEP case study replaces a generic image-compression library with a tight per-image optimized one; the collisions case study replaces a generic convex primitive collision detection library with a per-type-specialized one. Both optimizations are "different machine," not "trim current machine."
#### §8.1 What Operating Rules Adds
The connection to fable_review (§8 cross-ref) is the philosophical mirror. Fable's persona framing asks the model to "be careful, watch yourself, never claim something you can't verify." The data-oriented response is to ask "what does the data say?" — the verification is empirical (measure on real input), not persona-based (be appropriately humble). The fable review's "watch-dogging" pattern is the anti-pattern; the data-oriented sampling pattern is the pattern. Both can co-exist (a humble persona + measured data), but the data is load-bearing and the persona is decoration.
The operating-rules cluster adds a single new question to the data-oriented-design simplification pass: Q9 ("is there a different machine that fits the data better?"). The change is structural: the simplification pass now has 9 questions instead of 8, and Q9 is the meta-level question that the original pass did not surface. The 8 original questions are about trimming the current machine; Q9 is about replacing the machine.
The Tier 0/1/2 framing in `data-oriented-design.md:18-39` is also load-bearing. Tier 0 (trivial — apply defaults silently) is the project's escape hatch for one-line fixes; Tier 1 (non-trivial change — required: framing + data + simplification + self-check) is the standard; Tier 2 (subsystem-scale — tier 1 + enforceable deliverables) is the heavy path. The user's tier is decided at task start; the agent declares which tier it's picking. Manual Slop's `conductor/workflow.md` "Mandatory Research-First Protocol" and "Per-Task Decision Protocol" already encode tier-style discipline; the project's `conductor/code_styleguides/data_oriented_design.md` would close the loop.
The four pieces of the operating-rules abstraction:
A code-shape sketch using survey grammar:
1. **The 8 original questions** (Q1-Q8) — the radical form of "trim the machine":
- Q1: "can we not do this at all?" (delete the work)
- Q2: "can we do this only once?" (precompute)
- Q3: "can we do this fewer times?" (batch)
- Q4: "can we approximate?" (lossy)
- Q5: "can we use a small lookup table?" (small-LUT)
- Q6: "can we use a large lookup table?" (big-LUT)
- Q7: "can we use a small buffer/FIFO?" (streaming)
- Q8: "can we constrain the problem further?" (narrow the input)
2. **The new Q9 question** — "is there a different algorithm or representation that fits the data better than the current machine?" The Q9 is the meta-level question: not "how do I shrink this?" but "is this the right machine at all?" The data's shape can tell you.
3. **The "stalls or plateaus" signal** — when a pass stalls or plateaus, that is the signal to re-sample the hottest stage's data and ask whether a different machine fits it better — not to keep filing the current one. The signal is empirical: a plateau in optimization is the data saying "this machine has hit its floor."
4. **The Tier 0/1/2 framing** — Tier 0 (trivial — apply defaults silently), Tier 1 (non-trivial change — required: framing + data + simplification + self-check), Tier 2 (subsystem-scale — tier 1 + enforceable deliverables). The user's tier is decided at task start; the agent declares which tier it's picking.
The Q9 expansion generalizes v2.3 Pattern 1 ("durable work, disposable workers") — replacing the machine is a more radical form of "disposable" that the original pass did not surface.
#### §8.2 The Q9 Question in Detail
The Q9 question is at `context/data-oriented-design.md:151-164`:
```
Q9: Is there a different algorithm or representation that fits the data better
than the current machine? Subtraction has a floor; when filing the current
approach stops paying (a plateau), the win is often a different machine
the data's shape points to — reconsider the approach, don't only shrink it.
```
The Q9 framing is explicit: "subtraction has a floor". The 8 original questions are all about subtraction (trim, shrink, delete, narrow). Subtraction has a floor: at some point, the current machine cannot be trimmed further. The Q9 question is what to do when you hit the floor: replace the machine, don't keep filing.
The Q9 framing is also explicit about the signal: "when filing the current approach stops paying (a plateau), the win is often a different machine the data's shape points to". The signal is a plateau, not a target. The data-oriented approach: measure the plateau, then re-sample the data, then ask whether a different machine fits the data better.
The Q9 framing is also explicit about the source of the replacement: "the data's shape points to". The data is the source. The model is not the source (the model is the function of the data). This is the data-oriented principle: data is the source of truth, code is a function of the data.
#### §8.3 The Sampling Discipline
The sampling discipline is at `context/data-oriented-design.md:102-116`:
```
Sample the data you already have. ... the data's shape can show that a
different algorithm or representation is the better-fit machine
(sorted-enough → a different sort/merge; skewed → a different code;
runny → a run/stream form; sparse → a different container), not just
that the current machine needs filing. Sampling justifies replacing the
machine, not only trimming it. Sampling is also how you find new
opportunities mid-optimization, not just before starting: when a pass
stalls or plateaus, that is the signal to re-sample the hottest stage's
data and ask whether a different machine fits it better — not to keep
filing the current one.
```
The sampling discipline is the data-oriented response to "what should I do next?" The answer is: sample the data, look at the shape, let the shape tell you whether to trim or replace. The model's job is to read the shape and act on it, not to guess.
The "sorted-enough → a different sort/merge" example is the load-bearing one: when the data is mostly sorted, a different sort algorithm (e.g., Timsort, which exploits pre-sorted runs) is faster than a generic quicksort. The shape (mostly sorted) points to the replacement (Timsort). The model's job is to recognize the shape and apply the replacement.
The "skewed → a different code" example is the second load-bearing one: when the data is heavily skewed (a few values appear very often, most values appear rarely), a different encoding (e.g., Huffman coding, which assigns short codes to frequent values) is more compact than a fixed-width encoding. The shape (skewed) points to the replacement (Huffman). The model's job is to recognize the shape and apply the replacement.
#### §8.4 The Tier 0/1/2 Framing
The Tier 0/1/2 framing is at `context/data-oriented-design.md:18-39`:
```
Scope: This document applies to non-trivial changes. Trivial changes
(one-line fixes, typo corrections) apply defaults silently. The user's
explicit instruction for the current task always wins.
Tiers:
Tier 0: Trivial — apply defaults silently.
Tier 1: Non-trivial change — required: framing + data + simplification + self-check.
Tier 2: Subsystem-scale — Tier 1 + enforceable deliverables.
Precedence: An explicit instruction from the user for the current task
wins over this document.
```
The Tier 0/1/2 framing is the project's escape hatch for one-line fixes (Tier 0), the standard for non-trivial changes (Tier 1), and the heavy path for subsystem-scale work (Tier 2). The user's tier is decided at task start; the agent declares which tier it's picking.
The Tier 0 escape hatch is load-bearing: without it, every one-line fix would require framing + data + simplification + self-check, which is over-engineering for a typo correction. The Tier 0 escape hatch is the discipline that keeps the heavy path heavy: only use Tier 1+ when the work warrants it.
The "user's explicit instruction wins" precedence rule is also load-bearing: the user can override any of the operating rules with an explicit instruction. The rules are defaults, not constraints. The user is the source of truth.
#### §8.5 The Connection to Fable
The connection to `conductor/tracks/fable_review_20260617/` is the philosophical mirror. Fable's persona framing asks the model to "be careful, watch yourself, never claim something you can't verify." The data-oriented response is to ask "what does the data say?" — the verification is empirical (measure on real input), not persona-based (be appropriately humble).
The fable review's "watch-dogging" pattern is the anti-pattern; the data-oriented sampling pattern is the pattern. Both can co-exist (a humble persona + measured data), but the data is load-bearing and the persona is decoration.
The cross-ref is a load-bearing one: §8 closes the loop. Acton's operating rules are the data-grounded alternative to Fable's persona-based watch-dogging. The two are not in conflict; they are complementary. The data is the source of truth; the persona is the user's preference for tone.
#### §8.6 Per-Commit Detail
The one commit that built the operating-rules subsystem:
1. **`a1f0680` — Add Q9 to the simplification pass.** Adds `context/data-oriented-design.md:102-116` (the "Sample the data you already have" expansion with the "different machine" framing) and `context/data-oriented-design.md:151-164` (the new Q9 in the simplification pass). The commit is a documentation-only change; no code is modified. The change is structural: the simplification pass now has 9 questions instead of 8, and Q9 is the meta-level question.
The commit is the "single-feature" commit that mirrors the v2.3 addition pattern: a documentation change that adds a new question to the existing pass. The change is small (a paragraph + a new question) but load-bearing (the Q9 insight generalizes v2.3 Pattern 1).
#### §8.7 Manual Slop Implications
The Manual Slop equivalents of the operating-rules pattern are partial. The closest analog is `conductor/code_styleguides/data_oriented_design.md` (the project's canonical DOD reference, derived from Acton's file). The styleguide is the agent-facing instruction set; the Q9 addition is the "what's new since v2.3" delta.
The Manual Slop analog already follows the pattern in spirit:
- **`conductor/code_styleguides/data_oriented_design.md`** is the canonical DOD reference (Tier 0/1/2, simplification pass, enforceable deliverables). The styleguide is derived from Acton's file (per the styleguide header).
- **`conductor/workflow.md` "Mandatory Research-First Protocol"** is the framing + data + simplification + self-check discipline (Tier 1). The workflow's "Per-Task Decision Protocol" is the tier-style discipline.
- **`conductor/product-guidelines.md` "Phase 5: Heavy Curation & Structural Integrity"** is the Tier 2 path (the heavy path with enforceable deliverables).
The gap Manual Slop could close:
1. **No Q9 ("different machine") in the project's `data_oriented_design.md`.** The Q9 addition is the "what's new since v2.3" delta. If the project styleguide adopts Q9 explicitly, agents applying it will know to consider "different machine" rather than only "trim current machine" when sampling points to a plateau.
2. **No "stalls or plateaus" signal in the workflow.** The workflow's "Mandatory Research-First Protocol" covers the before-starting sampling, but not the mid-optimization re-sampling. A future track could add the "stalls or plateaus" signal to the workflow's per-task decision protocol.
3. **No worked example of "replace the machine" reasoning.** The case studies (§10, §11) demonstrate "replace the machine" empirically, but the rules file does not name the pattern. A future track could add a worked example to the styleguide.
#### §8.8 Honest Gaps
1. **The Q9 expansion is in `data-oriented-design.md` but nagent itself doesn't have a worked example of "replace the machine" reasoning in its commits** (the case studies — §10, §11 — demonstrate it empirically but the rules file does not name the pattern). A future track could add a worked example.
2. **The project's `conductor/code_styleguides/data_oriented_design.md` is derived from this file but may not include the Q9 addition.** The v3 delta is the trigger to verify.
3. **The "stalls or plateaus" signal is a heuristic.** When is "the pass is done" vs "the pass is plateauing"? The rule does not distinguish. A worked example would help.
4. **The 9-question pass is not exhaustively tested.** The pass is documentation, not code; there's no test that asserts the 9 questions are present in the styleguide. A v4 would add a test that asserts the project's `data_oriented_design.md` contains all 9 questions.
5. **The Tier 0/1/2 framing is not enforced.** The framing is documentation, not code; the agent can pick any tier regardless of the work's complexity. A v4 would add a tier-enforcement check to the workflow.
6. **The "user's explicit instruction wins" precedence rule is not tested.** The rule is documentation, not code; there's no test that asserts the precedence. A v4 would add a test that asserts the precedence rule is documented and followed.
7. **The interaction with the campaigns driver (§1) is not deep-dived.** The campaigns driver has its own 6 phases. The Q9 question ("different machine?") could be applied to the campaign's structure: is the current item decomposition the right decomposition, or would a different decomposition (e.g., by component vs by file) be better? The v3 cluster does not document this application.
8. **The interaction with the case-study methodology (§9) is not deep-dived.** The case-study methodology is itself an application of the operating rules: the 5-element pattern (prompts + harness + log + freeze + subject) is a "different machine" for the "optimize this code" problem. The v3 cluster does not document this application.
#### §8.9 Code-Shape Sketch
The operating-rules abstraction, in survey-grammar SSDL notation, with shape tags:
```
simplify-pass { current_machine, data_shape } :: improvements {ssdl} [S]
q1 := "can we not do this at all?"
q2 := "can we do this only once?"
q3 := "can we do this fewer times?"
q4 := "can we approximate?"
q5 := "can we use a small lookup table?"
q6 := "can we use a large lookup table?"
q7 := "can we use a small buffer/FIFO?"
q8 := "can we constrain the problem further?"
q9 := "is there a different machine that fits the data better?" // NEW: a1f0680
q1 := "can we not do this at all?" // delete
q2 := "can we do this only once?" // precompute
q3 := "can we do this fewer times?" // batch
q4 := "can we approximate?" // lossy
q5 := "can we use a small lookup table?" // small-LUT
q6 := "can we use a large lookup table?" // big-LUT
q7 := "can we use a small buffer/FIFO?" // streaming
q8 := "can we constrain the problem further?" // narrow
q9 := "is there a different machine that fits the data better?" // NEW: replace
// Q1-Q8 trim; Q9 replaces. Q9 is the meta-question.
sample { current_machine, hottest_stage } :: next-action
@@ -1575,12 +1680,56 @@ sample { current_machine, hottest_stage } :: next-action
shape := sample(hottest_stage)
if shape suggests different machine -> replace (Q9)
else -> trim (Q1-Q8)
tier { work_complexity } :: tier {ssdl} [I]
trivial -> tier_0 // apply defaults silently
non-trivial -> tier_1 // framing + data + simplification + self-check
subsystem -> tier_2 // tier_1 + enforceable deliverables
shape-suggestions := { // data-shape → replacement hints
sorted_enough: "consider Timsort / merge-of-runs",
skewed: "consider Huffman / arithmetic coding",
runny: "consider streaming / run-length form",
sparse: "consider sparse container / dict-of-keys" }
```
The `{ssdl}` [S] markers note the abstractions: the simplification pass is a string of questions (S); the sampling decision is a deterministic string assembly (S) based on data on disk.
The shape tag map: `[I]` for inspectable tier selection, `[S]` for the string of questions and the deterministic sampling decision. The operating rules operate on data on disk; the model's job is to read the shape and act on it.
The Q9 expansion generalizes v2.3 Pattern 1 ("durable work, disposable workers") — replacing the machine is a more radical form of "disposable" that the original pass did not surface. The project's `conductor/code_styleguides/data_oriented_design.md` should adopt Q9 to keep the operating rules current.
**Source-read citations:**
- `context/data-oriented-design.md:102-116` — "Sample the data you already have" expanded (a1f0680)
- `context/data-oriented-design.md:151-164` — new Q9 in simplification pass (a1f0680)
- `context/data-oriented-design.md:18-39` — Scope, tiers, and precedence (Tier 0/1/2)
- `context/data-oriented-design.md:41-58` — 3 defaults to reject
- `context/data-oriented-design.md:60-78` — 8 core defaults
- `context/data-oriented-design.md:82-125` — Get the real data
- `context/data-oriented-design.md:130-148` — Method (frame → get-data → state-cost → design-transform → simplification-pass → define-done → verify)
- `context/data-oriented-design.md:156-176` — Design rules (minimize-states, explicit-OOR, complexity-requires-evidence)
- `context/data-oriented-design.md:182-191` — Performance claims (never assert unmeasured; label hypotheses)
- `context/data-oriented-design.md:198-227` — Software specifics (batch-first, memory layout, data protocols, hardware is platform)
- `context/data-oriented-design.md:233-243` — Enforceable deliverables (tier 2)
- `context/data-oriented-design.md:249-261` — Final self-check (the 10-question checklist)
- `context/data-oriented-design.md:1-17` — module docstring + introduction (a1f0680; the v3 cluster does not cite specific line ranges)
- `context/data-oriented-design.md:116-150` — between sampling expansion and Q9 (a1f0680)
- `context/data-oriented-design.md:164-182` — between Q9 and design rules (a1f0680)
- `context/data-oriented-design.md:191-198` — between performance claims and software specifics (a1f0680)
- `context/data-oriented-design.md:227-233` — between software specifics and enforceable deliverables (a1f0680)
- `context/data-oriented-design.md:243-249` — between enforceable deliverables and final self-check (a1f0680)
- `context/data-oriented-design.md:261-300` — after final self-check (a1f0680; the v3 cluster does not cite specific line ranges)
- `context/data-oriented-design.md:300-400` — appendices + references (a1f0680; the v3 cluster does not cite specific line ranges)
- `a1f0680` commit message — Q9 addition + sampling expansion
- `context/data-oriented-design.md` (full file) — the canonical DOD reference (a1f0680; the v3 cluster does not cite the full file)
- `fable_review_20260617` — the Fable review (the v3 cluster cross-references the Fable review for the philosophical mirror)
- `bin/nagent` — nagent's main loop (relevant for the gap note on campaigns coordination)
- `bin/helpers/nagent_campaign_lib.py` — campaigns driver (relevant for the gap note on Q9 application to campaigns)
- `bin/helpers/nagent_safety_lib.py` — safety net (relevant for the gap note on Q9 application to safety net)
- `prompts/` — the prompt directory (relevant for the gap note on Q9 application to prompts)
- `bin/nagent:3167-3185` — `run_agent_loop` (relevant for the gap note on Q9 application to the main loop)
- `bin/nagent:1911-1940` — `cleaned_response_text` (relevant for the gap note on Q9 application to the response handler)
- `context/data-oriented-design.md:148-151` — between method and Q9 (a1f0680; the exact lines)
**Decision candidate:** NEW Candidate 24 (LOW). "Document Q9 ('consider a different machine') in the project's `conductor/code_styleguides/data_oriented_design.md`" — the styleguide is already a derivative of nagent's file; add the Q9 expansion as a Tier 1+ reading-note. See `decisions.md` Candidate 24.
**Cross-refs:** `conductor/tracks/fable_review_20260617/` — Fable's analysis of "watch-dogging" is the opposite pattern. Fable's persona framing ("be careful, watch yourself") substitutes for the data-oriented question "what does the data say?". §8 closes the loop: Acton's operating rules are the data-grounded alternative.
**Pattern history:** UPDATE. v2.3 cited `context/data-oriented-design.md` as Acton's canonical rule set; v3 deep-dives the Q9 expansion (the only addition since v2.3 was published on 2026-06-12). The Q9 insight generalizes v2.3 Pattern 1 ("durable work, disposable workers") — replacing the machine is a more radical form of "trimming the machine" that the original 8-question pass did not surface.
## §9 Case-study methodology
**Source:** both case-study repos (`macton/pep-copt`, `macton/differentiable-collisions-optc`); both `prompts/create-*.md` files in each; both `prove-optimized-harness.sh` scripts (per §3 cross-refs); both `README.md` files.