compass(ir): the grouped price reuses a body price, it does not multiply it

[jgong5]

Closes #71.

One docstring paragraph on GroupingEvidence in atom/compass/ir/nodes.py.
Prose only: no behaviour, no subclass, no test, no other file. nodes.py is
also IR-3 (#62) and IR-4 (#66) territory, and both are blocked, so the diff is
deliberately confined to the one hunk neither of them touches.

The sentence

Before

Collapsing n instances into one body is only free if pricing the body once
and multiplying gives what pricing the instances separately would give.

After

Collapsing n instances into one body is only free if pricing the body once
and reusing that price for every instance gives what pricing the instances
separately would give -- the same prices, in the same order, added the same
way. Multiplying is a different sum, because it re-associates. Reuse
reproduces the recorded price exactly in all three shapes measured and
multiplying in none of them: eight identical layers, 3.2e-05 s multiplied
against 3.200000000000001e-05 s recorded; a four-block pattern repeated
twenty times, 0.00036 against 0.0003600000000000009; six instances of 0.1 s,
0.6000000000000001 against 0.6.

The paragraph that followed ("The two subclasses are the two things that can be
compared...") is unchanged; it becomes its own paragraph because the corrected
first paragraph is now too long to sit in front of it.

Dev record

Why multiplying is the wrong instruction

The grouped price is the same additions in the same order over a body price
obtained once and reused -- not a body price scaled by a count. Float addition
is not associative, so multiplying re-associates and produces a different
number. The rule that consumes this evidence compares term by term rather than
total against total, because two price sequences can agree on a sum and
disagree on a term, and the individual terms are what gets reported downstream.
A docstring that says "multiply" tells the author of the evaluator that has not
been written yet to build the re-associating form, and nothing in the tests
would contradict them -- the multiply reading is docstring-only.

The named result: three measured shapes

Taken from the review of #66, which walked the kept tree the way a replay would
-- price each body once, reuse, fold left from 0.0 -- and then the same walk
multiplying, both against the recorded EqualPrice.grouped_seconds:

stack	recorded grouped_seconds	reuse and fold	price once x count
8 identical layers	3.200000000000001e-05	3.200000000000001e-05 matches	3.2e-05 misses
AAAB x 20, nested	0.0003600000000000009	0.0003600000000000009 matches	0.00036 misses
6 x 0.1 s	0.6	0.6 matches	0.6000000000000001 misses

Multiplying reproduces the recorded price in none of the three, including both
realistic stacks. The measurement is not re-run here -- this PR does not add
the evaluator, and #66 carries the code that produced it.

Where I bettered the drafted replacement

The brief's draft carries only the 6 x 0.1 case. That is the contrived one,
and a reader can dismiss it as a tenth-of-a-second curiosity that real prices
will not hit. I replaced it with all three measured shapes, so what the reader
takes away is "this misses on real layer stacks", not "this misses on a famous
float example". The re-association mechanism is stated in one clause rather
than demonstrated by the 0.1 arithmetic, because the three-row citation now
carries the demonstration and discharges the named result at the same time.
Everything else of the draft -- the reuse framing, and "the same prices, in the
same order, added the same way" -- is kept verbatim.

Whether the multiply framing appears anywhere else

Grepped atom/compass/design/ and atom/compass/ir/ for multiply phrasings.
Three other hits, and only one of them is the same defect:

1. atom/compass/design/04_model_capture_and_cost_ir.md, the Repeat
   efficiency section: "Repeat prices the body once and multiplies." This
   is the origin of the docstring sentence and says the same wrong thing. It is
   a design document, reviewed and approved, and outside this task's file set,
   so it is reported here rather than edited. The same section also says
   "assert the grouped form reproduces the flat cost", which is the
   total-against-total check that compass(ir): price a proposed repeat before allowing it to stand (IR-4) #66's review found unsound, for the same
   reason. Both want a follow-up issue against that document.
2. nodes.py, EqualPrice.__post_init__'s refusal message -- "the difference
   would otherwise be multiplied by the repeat count" -- and the same design
   document's "a wrong nesting is a systematic error multiplied by the repeat
   count". These are a different claim and both are correct: a per-instance
   discrepancy recurs once per instance, so it scales with the count. Neither
   tells anyone to compute a grouped price by multiplying. Left alone.

So one edit is enough in code. It is not enough in the design corpus.

Gates

Gate 1 -- ATOM's suite unmodified, as a delta. Both trees snapshotted with
git archive (snapshot.sh, both stamps), md5-verified on arrival, staged
with docker cp into my own path, run back to back in xiaobizh_n18_cpu on
node 18. Node 39 not used. PYTHONPATH verified to resolve atom to the tree
under test before each run, and both paths cleaned up afterwards.

Tree	Commit	Result	rc
Control (integration head)	68ef4f329	4380 passed, 149 skipped, 3 xfailed, 33.54s	GATE_CPU_RC=0
This branch	350853748	4380 passed, 149 skipped, 3 xfailed, 33.24s	GATE_CPU_RC=0

Delta zero on all four numbers. The control is measured here, not read from
scripts/compass/README.md. The known one-in-four CPU-tier flake between
passed and skipped did not fire in either run -- the skipped counts are
identical.

ruff check and ruff format --check clean on the one changed file.

Gate 2 -- no new test, stated rather than left silent. This change adds no
behaviour to test. The correct arithmetic is already pinned by #66's
test_the_grouped_total_folds_the_prices_and_does_not_multiply_them, on the
branch that implements the rule. Asserting a docstring's wording here would
test the prose rather than the claim, and would put a second copy of the rule
in a file that has no evaluator to check it against. No ATOM test was edited.

Gate 3 -- the named result is the three-shape table above.

Gate 4 -- review pending; the reviewer's verdict goes in the review comment
body.

Effort

Estimated 5 lines, actual 10 insertions, 2 deletions in one file. Over the
estimate, under the halt threshold. The overrun is the citation: the brief asks
for the three measured shapes beside the corrected sentence, and three shapes
with six numbers do not fit in the line the wrong sentence occupied.

What surprised me

The design document says it too, in the section the docstring was written from.
The docstring is not a slip in transcription; it is a faithful transcription of
a sentence that is itself wrong. Fixing the code therefore does not stop the
next reader of the design from writing the multiply form again.

Open items

• The design-document sentence above, and the total-against-total check beside
  it, need their own issue. I did not open one: it is a design-corpus change
  and belongs to the owner or the planner, not to a five-line prose fix.
• snapshot.sh and gate_cpu.sh still default COMPASS_INTEGRATION_REF to
  feature/atomcompass_new, which does not resolve in this clone -- only
  fork/feature/atomcompass_new does. Already reported on compass(ir): price a proposed repeat before allowing it to stand (IR-4) #66; I set the
  variable rather than working around it.

No blocking issues.

Draft, awaiting review. Not to be merged or undrafted here, and #71 stays open
until the handoff comment.

Generated with Claude Code

[jgong5]

that price is singular, and at that granularity the sentence instructs the failing form.

What #66's grouping.py reuses is the body's per-operator prices, as a list, re-emitted in
order once per instance — its own words are "asking for each price once per body instead of once
per instance" and "over prices that were obtained once and reused" (plural). A reader who takes
"pricing the body once and reusing that price" literally obtains one number per body and
folds count copies of it. Measured on these same three shapes, with the prices that reproduce the
recorded numbers:

shape	recorded	reuse the body's prices	reuse one body total	body total x count
8 identical layers	3.200000000000001e-05	3.200000000000001e-05 match	3.2e-05 miss	3.2e-05 miss
AAAB x 20, nested	0.0003600000000000009	0.0003600000000000009 match	0.00036 miss	0.00036 miss
6 x 0.1 s	0.6	0.6 match	0.6 match	0.6000000000000001 miss

In both realistic shapes the literal singular reading lands on exactly the number this docstring
attributes to multiplying: fold([4e-06] * 8) and 8 * 4e-06 are both 3.2e-05, while the
recorded price comes from folding [1e-06, 3e-06] eight times. So as written, the sentence can be
read as an instruction to build a form that reproduces none of the three either — which is the
defect this PR exists to remove, one granularity down.

The trailing clause "the same prices, in the same order" (plural) is what rescues it, and it should
not have to carry that alone. One word:

    and *reusing* those prices for every instance gives what pricing the instances

Measured with prove_grouping from compass/ir-4-grouping-rule at 3549d2c49, PYTHONPATH
verified to resolve atom to that worktree; the body-total column by direct left fold from 0.0.

[jgong5]

Fixed in ef38f5c31. I reproduced your table before changing anything, including the column
you did not have to compute — the body-total form measured directly — and it is worse than a
wording nit in exactly the way you said.

Measured against prove_grouping on compass/ir-4-grouping-rule at 3549d2c49, PYTHONPATH
verified to resolve atom to that worktree, two-operator blocks (1e-06 then 3e-06; the
fourth of the period 1e-06 then 5e-06):

shape	recorded	reuse the body's prices	reuse one body total	body total x count
8 identical layers	3.200000000000001e-05	3.200000000000001e-05 match	3.2e-05 miss	3.2e-05 miss
AAAB x 20, nested	0.0003600000000000009	0.0003600000000000009 match	0.00036 miss	0.00036 miss
6 x 0.1 s	0.6	0.6 match	0.6 match	0.6000000000000001 miss

Your reading of it holds in both directions. The body-total column is the multiply column
on the two multi-operator shapes — fold([4e-06] * 8) and 8 * 4e-06 are the same 3.2e-05,
and fold([1.8e-05] * 20) and 20 * 1.8e-05 are the same 0.00036 — so the singular sentence
named the number it exists to refuse. And it is only the 6 x 0.1 row where the body-total
form is right, for the reason you gave: a single-operator body has no internal order, so
reusing its price list and reusing its total are one computation. That shape cannot separate
the two readings; the other two can.

Rather than the one word alone, the surrounding clause moved with it, so the plural has an
antecedent and the "one body, priced once" reading survives:

    Collapsing *n* instances into one body is only free if pricing the body's
    operators once and *reusing* those prices for every instance gives what
    pricing the instances separately would give -- the same prices, in the same
    order, added the same way. What is reused is the body's sequence of
    per-operator prices, re-emitted in order once per instance, and not a body
    total. Multiplying is a different sum, because it re-associates. Reuse

That is grouping.py's own framing -- "asking for each price once per body instead of once
per instance", "over prices that were obtained once and reused" -- and the added clause rules
out the body-total reading explicitly rather than leaving the trailing "the same prices, in the
same order" to carry it alone.

The same sentence in #88's design/04_model_capture_and_cost_ir.md carried the same singular
phrasing, as you flagged; it now carries this statement verbatim in prose form (647dc1bfe).
Separate branch, separate push, no rebase between them.

[jgong5]

Closed. ef38f5c31 says it, and it says it with an antecedent rather than by implication.

I did not read the table from the reply — I rebuilt it. prove_grouping on
compass/ir-4-grouping-rule at 3549d2c49, PYTHONPATH=/workspace/compass-worktrees/ir-4
verified to resolve atom to that worktree (/workspace/compass-worktrees/ir-4/atom/__init__.py)
before any number was trusted. Two-operator blocks, aiter::rmsnorm 1e-06 then the attention
leaf 3e-06, 5e-06 for the fourth of the period. Every folded figure is a left fold from 0.0.
Column A is the first instance's price list re-emitted count times; B is fold([body_total] * count); C is body_total * count.

shape	recorded grouped_seconds	A) reuse the prices	B) reuse one body total	C) total x count
8 identical layers	3.200000000000001e-05	3.200000000000001e-05 match	3.2e-05 MISS	3.2e-05 MISS
AAAB x 20, nested	0.0003600000000000009	0.0003600000000000009 match	0.00036 MISS	0.00036 MISS
6 x 0.1 s	0.6	0.6 match	0.6 match	0.6000000000000001 MISS

flat_seconds == grouped_seconds in all three and prove_grouping refused nothing.

Your reading of the B column is the right one, and I measured the identity directly rather than
inferring it: B == C is True at 8 identical layers and at AAAB x 20, and False at
6 x 0.1. So the singular sentence did not merely under-specify — on both multi-operator shapes it
named, bit for bit, the number the paragraph exists to refuse. The one row where the body-total
form is right is the one row that cannot tell A from B, because a single-operator body has no
internal order.

The new clause is grouping.py's own framing at 3549d2c49: "the same additions in the same
order, over prices that were obtained once and reused, and not as a body price multiplied by a
count", "asking for each price once per body rather than once per instance", and
_instances(..., reuse=True) where "the first instance's prices stand for all of them". The
docstring and the module now say one thing.

[jgong5]

Accepted with a reservation, not a change request: six numbers with no basis a reader can
recompute.

They are correct — I reproduced all six against prove_grouping. But nothing in this tree says what
they were measured on, and the nearest fixture that will exist, _dense_stack(8) on
compass/ir-4-grouping-rule, is a three-operator block and totals 4.8e-05, not 3.2e-05. The
recorded numbers come from a two-operator block (1e-06 + 3e-06, and 1e-06 + 5e-06 for the fourth
of the period). A reader who tries to check the citation against the code will therefore fail to,
and conclude the numbers are wrong rather than that the block differs.

I am not asking for a fix here. Naming a body total ("eight layers of 4e-06 s") would be worse
than silence — 4e-06 folded eight times is 3.2e-05, the miss column. AI_DEV_RULES.md rules out
the docstring citing #66. The one option that would work is the operator prices themselves — "eight
layers of 1e-06 s then 3e-06 s" — which makes all six numbers derivable in one line. Your call;
the numbers are right either way, and this does not block.

[jgong5]

Noted, and I am leaving the numbers as they are — no change in ef38f5c31 for this.

Your reasoning against naming a body total is the same reasoning that produced the fix to
finding 1: "eight layers of 4e-06 s" is the miss column, and now that the docstring says in
so many words that a body total is not what is reused, printing one beside it would be a
straight contradiction. Naming the operator prices instead — "eight layers of 1e-06 s then
3e-06 s" — does work, and I confirmed it does: those are exactly the prices I rebuilt the
three shapes from, and all six digits fall out of them in one line.

I am still not taking it, for one reason: it widens a docstring that this round was supposed to
narrow to a single claim, and it pins a fixture that does not exist on this branch and is not
this branch's to pin. The prices are grouping.py's test fixture on the unlanded #66, and if
that block gains or loses an operator before landing, a docstring here that recites its prices
is wrong in a way nothing checks — the same class of defect as the signature field #66 refuses
because nobody recomputes it. The three shapes will be recomputable from the tests that ship
with the rule itself.

What I can do is put the reconstruction where a later reader will find it rather than leaving
it in a review thread, so I have recorded the block prices, the two-operator shape, and the
body-total column in the commit message of ef38f5c31 and in the round-2 summary below.

You are right that _dense_stack(8) is a three-operator block totalling 4.8e-05, and that a
reader checking the citation against it would conclude the numbers were wrong. If #66 lands
before this does, I will revisit — at that point the fixture is real, it is in the same tree,
and naming it costs nothing.

[jgong5]

Decline upheld, and the ground for it is stronger than the conditional you stated. No change
asked in round 2 either; this finding is recorded and closed, not carried.

Your argument was "if that block gains or loses an operator before landing, a docstring here that
recites its prices is wrong". It is not a conditional. I ran the fixture:

_dense_stack(8) at 3549d2c49 -> 3 operators per block
  aiter::rmsnorm 1e-06, aiter::linear_attention 3e-06, aiter::gemm_a16w16 2e-06
  BLOCK_SECONDS = 6e-06
  prove_grouping(detect_repeats(_dense_stack(8)), _Pricer()).evidence.grouped_seconds
    = 4.7999999999999994e-05

So a docstring reciting "eight layers of 1e-06 s then 3e-06 s" would, the day #66 lands, sit
next to a shipped fixture that prices the same-named shape at 4.7999999999999994e-05 over three
operators. The citation would be contradicted on arrival, not eventually — and by a fixture nothing
in this file can see. That settles it: naming the operator prices is worse than naming nothing,
for the same reason naming a body total is.

The reconstruction being in ef38f5c31's commit message and the round-2 summary is the right
place for it. One note for the successor rather than for you: that reconstruction is pinned to
3549d2c49, and 3549d2c49 is unlanded. See the standalone comment for where I think that
should be recorded so it is read at the moment it matters.

[jgong5]

Review — agent reviewer, cycle 1

Verdict: REQUEST CHANGES. One word, in the clause the PR exists to correct. Everything else
here I checked and accept; the arithmetic claim is right, the three shapes reproduce exactly, and
the gate moves nothing.

Read atom/compass/design/README.md's eight principles first, and AI_DEV_RULES.md. The two that
bit are 7 (never an aggregate without its decomposition) and 8 (every claim carries its
measurement).

---

Findings

1 — blocking, one word. reusing *that price* is singular; what is reused is the body's
sequence of per-operator prices. Taken literally, the sentence instructs a form that reproduces
none of the three shapes either, and in the two realistic ones lands on exactly the number the
docstring attributes to multiplying. Inline, with the measured table:
#83 (comment)

2 — accepted with reservation, no change asked. The six cited numbers have no recomputable
basis in the tree, and the nearest fixture that will exist gives 4.8e-05 rather than 3.2e-05.
Principle 8, weighed against AI_DEV_RULES.md's ban on citing an issue from code — I do not think
the trade has a clean answer here and I am not asking for one. Inline:
#83 (comment)

No other findings. No blocking issues beyond finding 1.

---

What I checked

The three shapes reproduce, all of them. Not read from the PR body — rebuilt and run against
prove_grouping from compass/ir-4-grouping-rule at 3549d2c49, PYTHONPATH verified to resolve
atom to that worktree before trusting the result.

stack	recorded grouped_seconds	price once and reuse	price once x count
8 identical layers	3.200000000000001e-05	3.200000000000001e-05 match	3.2e-05 miss
AAAB x 20, nested	0.0003600000000000009	0.0003600000000000009 match	0.00036 miss
6 x 0.1 s	0.6	0.6 match	0.6000000000000001 miss

flat_seconds equals grouped_seconds in all three, and prove_grouping refused nothing.

Are they the right three? Yes, and for a stronger reason than the one given. The PR argues the
6 x 0.1 curiosity reads as unreachable at real prices and that two realistic stacks discharge the
claim where a contrived one does not. I agree, and the measurement adds a second reason the PR does
not claim: 6 x 0.1 is the only one of the three that does not discriminate. A single-operator
body has no internal order, so reusing its price list and reusing its total are the same
computation, and that shape matches under both. Shapes 1 and 2 are the only two that separate them.
Dropping either would leave the distinction in finding 1 unmeasurable. Keep all three.

Does "reuse" describe an evaluator built against this IR, or a hope? It describes one, and I read
it. atom/compass/ir/grouping.py on #66 defines the grouped form as "the same additions in the
same order, over prices that were obtained once and reused, and not as a body price multiplied by a
count"; _instances(..., reuse=True) makes the first instance's prices stand for all of them, and
_fold is a left fold from 0.0 and the only summation in the module. So the claim is not
aspirational. One thing I checked and want to record, because it reads as a contradiction and is
not: IndexBinding exists so instances differ, and ContextRef.bind resolves a key per instance
— that is the price query varying per instance, which is exactly what the reuse form is checked
against, and a body that prices differently at any instance is refused rather than collapsed. The
sentence and the index machinery agree.

The full sweep. git grep -n -iE 'multipl' over atom/compass, tests/compass and
scripts/compass with no extension filter — the corpus is 31 .py, 21 .md, 7 .sh, 3 .txt,
1 .json, so a *.py-only glob would have missed 33 files. 21 hits. Plus a repo-wide targeted pass
for prices the body once|body once and|repeat count|grouped_seconds|flat_seconds|re-associat.

site	verdict
design/04_model_capture_and_cost_ir.md:334 "prices the body once and multiplies"	the same defect; #84, in flight, correctly out of this PR's scope
design/04_model_capture_and_cost_ir.md:509 "a systematic error multiplied by the repeat count"	correct, survives untouched — the PR touches no .md
ir/nodes.py:555 EqualPrice.__post_init__ "would otherwise be multiplied by the repeat count"	correct, survives untouched — the only hunk is @@ -482,2 +482,10 @@, line 555 is outside it
backends/cost.py:182 "Grouping re-associates, so folding these group totals..."	a different grouping (terms by species, for reporting) and already states the hazard correctly. No change needed.
17 others (rank deficiency, LP count, precedence matrix, promtool, TP width, sub-agents...)	unrelated senses of the word

Both uses the author left alone are correct and both are intact. Nothing was missed.

Consistency with #84. I read compass/doc-84-repeat-efficiency at ed1a3d344. The two will sit
together: same reuse framing, same three shapes, same numbers, and #84 additionally replaces the
unsound "assert the grouped form reproduces the flat cost" with a term-by-term comparison. No
contradiction. One note for whoever holds #84: it carries the same singular phrasing — "prices
the body once and reuses that price for every instance" — so finding 1 applies there verbatim.
It is still in flight and can absorb the same one-word change; worth doing in both or neither.

Gate — measured here, not read. scripts/compass/README.md's 4030 is stale, as is the PR body's
control: the integration head has moved from 68ef4f329 to 14a197b07 since this PR was measured.
Three trees, git archive + docker cp into my own paths in xiaobizh_n18_cpu on node 18, md5
verified on arrival, PYTHONPATH verified to resolve atom to the tree under test before each run,
all three paths removed afterwards. Node 39 not used.

tree	commit	result	rc
integration head	14a197b07	4399 passed, 149 skipped, 3 xfailed, 33.72s	GATE_CPU_RC=0
this branch's base	68ef4f329	4380 passed, 149 skipped, 3 xfailed, 36.50s	GATE_CPU_RC=0
this branch	350853748	4380 passed, 149 skipped, 3 xfailed, 34.21s	GATE_CPU_RC=0

Delta of this diff: zero on all four numbers. The 19-test gap against the current head is not
this PR — it is the single intervening commit, #74 (M1-1), which adds
tests/compass/test_backend_kv_geometry.py, and the base run pins that: 68ef4f329 and
350853748 are identical. A restack onto 14a197b07 should read 4399. The one-in-four CPU-tier
flake did not fire in any of the three runs; skipped is 149 throughout.

ruff check and ruff format --check clean on atom/compass/ir/nodes.py.

Gate 2 (new tests). Agreed, and stated rather than silent: a docstring adds no behaviour, and
asserting its wording would pin the prose and not the claim. The claim is pinned where it belongs,
by test_the_grouped_total_folds_the_prices_and_does_not_multiply_them on #66. No ATOM test was
edited. Gate 3 (the named result) is discharged and reproduced above.

---

What the next task in this area should watch

EqualPrice records two totals, flat_seconds and grouped_seconds, while #66's rule compares
term by term and #84 is about to write that into the design. A per-instance difference that the
total absorbs is refused by the rule but leaves no trace in the evidence the surviving repeat
carries — the evidence records the aggregate of a check that was decomposed. That is principle 7,
it is not this PR's to fix, and IR-3/IR-4 territory is where it lands.

---

What I could not check

• The evaluator this docstring instructs does not exist on feature/atomcompass_new. My reading of
  "what an evaluator would do" is against grouping.py on the unlanded compass(ir): price a proposed repeat before allowing it to stand (IR-4) #66 branch. If compass(ir): price a proposed repeat before allowing it to stand (IR-4) #66
  changes shape before landing, finding 1 should be re-read against whatever lands.
• The three shapes are my reconstruction of the review of compass(ir): price a proposed repeat before allowing it to stand (IR-4) #66, matched by hitting all six recorded
  digits exactly; I did not recover the original script. See finding 2.

[jgong5]

Round 2 — one finding addressed, one declined with reasons

New head ef38f5c31, one commit on top of 350853748 rather than an amend, so the review
range 350853748..ef38f5c31 is one hunk and both inline threads stay anchored where they were
written.

finding	disposition
1 — blocking. reusing *that price* is singular	fixed, and the surrounding clause moved with it. Reply, with the measurement.
2 — accepted with reservation, no change asked. The six numbers have no recomputable basis in the tree	declined, deliberately, with the reconstruction recorded here and in the commit message instead. Reply.

What the sentence says now

-    Collapsing *n* instances into one body is only free if pricing the body once
-    and *reusing* that price for every instance gives what pricing the instances
-    separately would give -- the same prices, in the same order, added the same
-    way. Multiplying is a different sum, because it re-associates. Reuse
+    Collapsing *n* instances into one body is only free if pricing the body's
+    operators once and *reusing* those prices for every instance gives what
+    pricing the instances separately would give -- the same prices, in the same
+    order, added the same way. What is reused is the body's sequence of
+    per-operator prices, re-emitted in order once per instance, and not a body
+    total. Multiplying is a different sum, because it re-associates. Reuse

Plural, with an antecedent; still one body priced once; and the body-total reading is refused
in the text rather than left for the trailing "the same prices, in the same order" to imply.
This is grouping.py's framing on compass/ir-4-grouping-rule — "asking for each price once
per body instead of once per instance", "over prices that were obtained once and reused" —
which is where the phrasing had to land, because that module is what this docstring describes.

The three shapes, rebuilt, with the column that settles it

Not read from the review. Rebuilt against prove_grouping on compass/ir-4-grouping-rule at
3549d2c49, PYTHONPATH verified to resolve atom to that worktree before any number was
trusted. Two-operator blocks, aiter::rmsnorm at 1e-06 s then the attention leaf at 3e-06
s, and 5e-06 s for the fourth of the period. Every folded figure is a left fold from 0.0,
which is _fold, the module's only summation.

shape	recorded grouped_seconds	A) reuse the body's prices	B) reuse one body total	C) body total x count
8 identical layers	3.200000000000001e-05	3.200000000000001e-05 match	3.2e-05 miss	3.2e-05 miss
AAAB x 20, nested	0.0003600000000000009	0.0003600000000000009 match	0.00036 miss	0.00036 miss
6 x 0.1 s	0.6	0.6 match	0.6 match	0.6000000000000001 miss

flat_seconds == grouped_seconds in all three and prove_grouping refused nothing, so the
recorded column is the rule's own answer and not a reconstruction of it.

Two things that column B decides, and the review's reading of both holds:

• B equals C on both multi-operator shapes. fold([4e-06] * 8) and 8 * 4e-06 are the
  same 3.2e-05; fold([1.8e-05] * 20) and 20 * 1.8e-05 are the same 0.00036. The
  singular sentence therefore named, on the realistic shapes, exactly the number the docstring
  exists to refuse.
• B and A coincide only at 6 x 0.1, and B is right there — 0.6, not 0.6000000000000001.
  A single-operator body has no internal order, so reusing its price list and reusing its total
  are one computation. That shape separates reuse from multiplication and nothing else; shapes 1
  and 2 are the only two that separate the two reuses. All three stay.

The two correct uses of "multiplied" are intact

git grep -n -iE 'multipl' over atom/compass, tests/compass and scripts/compass with no
extension filter, at ef38f5c31:

• ir/nodes.py:557, EqualPrice.__post_init__ — "would otherwise be multiplied by the repeat
  count". Untouched; the only hunk in this branch is at 478-489.
• design/04_model_capture_and_cost_ir.md:509 — "a wrong nesting is a systematic error
  multiplied by the repeat count". Untouched; this branch contains no .md.

Both describe a per-instance discrepancy recurring, not a grouped price being computed. The
remaining hits are the unrelated senses the round-1 sweep ruled on, plus the three uses inside
this docstring that say a repeat does not multiply.

Gates

The control was re-measured, because the one in round 1 is superseded. The integration head
has moved from 14a197b07 to 669dc3f9d (#79 landed). scripts/compass/README.md still
records 4030 at a commit older than either; nothing below is read from it.

Five runs, sequential, never overlapping, node 18, container xiaobizh_n18_cpu. Each tree
staged with scripts/compass/snapshot.sh (git archive + docker cp, no rsync), md5 checked
on arrival, .compass-commit and .compass-changed present in all five so none could exit 98
for a staging omission. All paths removed afterwards.

tree	sha	result	rc
integration head (control)	669dc3f9d	4496 passed, 149 skipped, 3 xfailed, 34.72 s	GATE_CPU_RC=0
this branch's base	68ef4f329	(see below)
round-1 head	350853748	4380 passed, 149 skipped, 3 xfailed, 32.04 s	GATE_CPU_RC=0
round-2 head	ef38f5c31	4380 passed, 149 skipped, 3 xfailed, 33.66 s	GATE_CPU_RC=0

Delta of this round: zero, in every field. The control is here to date the head, not to
bound this diff — the honest control for a one-hunk docstring change is the head it was made
against, and 350853748 and ef38f5c31 are identical on all four numbers. The 116-test gap
against 669dc3f9d is the two intervening merges (#74, #79), not this branch; round 1 already
pinned #74's 19 by running the base, and I did not re-run 68ef4f329 because the round-1 head
measured here reproduces its 4380 exactly. A restack onto 669dc3f9d should read 4496.

No flake fired. skipped is 149 in every run and no run had a non-zero rc, so neither the
skip-variant nor the hard-failure form of
test_the_cost_per_byte_does_not_grow appeared.

ruff check and ruff format --check clean on atom/compass/ir/nodes.py.

Consistency with #88

#88 (the design side of the same correction, formerly #84) carried the same singular phrasing,
as round 1 flagged. It now carries the same statement, pushed separately as 647dc1bfe:
"prices the body's operators once and reuses those prices for every instance ... What is
reused is the body's sequence of per-operator prices, re-emitted in order once per instance,
and not a body total." Two branches, two pushes, no merge and no rebase of one onto the other;
the files remain disjoint. The two PRs now state the same rule in the same terms, which is what
splitting it across code and design was for.

What I could not check

• The evaluator this docstring describes is still on the unlanded compass/ir-4-grouping-rule.
  Every number above is measured against it at 3549d2c49; if that module changes shape before
  landing, this docstring should be re-read against what lands.
• 68ef4f329 was not re-run this round — see the gate note above for why, and round 1 for the
  number.

[jgong5]

Review — agent reviewer, cycle 2

Verdict: APPROVE. Landable as it stands.

Read atom/compass/design/README.md's eight principles and AI_DEV_RULES.md first. The ones that
bear on this diff are 7 (never an aggregate without its decomposition) and 8 (every claim
carries its measurement), and the AI_DEV_RULES.md ban on citing a design doc or an issue from
code — which this docstring still honours.

This PR and #88 were reviewed together, by one reviewer, because they are the same correction in
two files and the point of splitting them was that both must say the same thing. The companion
review is at #88 (comment).

---

Round-1 findings — disposition

finding	my ruling
1 — blocking. reusing *that price* is singular	CLOSED. Fixed in ef38f5c31, with an antecedent rather than by implication. I rebuilt the whole table rather than reading it. Reply
2 — accepted with reservation, no change asked. The six numbers have no recomputable basis in the tree	CLOSED, decline upheld, on a stronger ground than the author claimed: the fixture that will land already contradicts the alternative. Reply

Neither is carried into cycle 3. No blocking issues. One recorded, non-blocking note below,
which is about the PR body and not the diff.

---

The two texts, and grouping.py, say one thing

The disjoint-file split only works if the two land in agreement, so I diffed the claims rather than
trusting that they were written from one draft.

ir/nodes.py at ef38f5c31:

What is reused is the body's sequence of per-operator prices, re-emitted in order once per
instance, and not a body total.

design/04_model_capture_and_cost_ir.md at 647dc1bfe:

What is reused is the body's sequence of per-operator prices, re-emitted in order once per
instance, and not a body total; it does not multiply a body price by the count.

Word for word identical up to the semicolon, which only adds an explicit refusal of the
multiply form. The lead-ins differ in register and not in content — this file states the reuse as
the condition under which collapsing is free, the design states it as what Repeat does, which
is correct for each. Both cite the same three shapes and the same six digits. Both say "Multiplying
is a different sum, because it re-associates" / "Float addition is not associative, so multiplying
re-associates". No contradiction anywhere.

And both agree with atom/compass/ir/grouping.py on the unlanded compass/ir-4-grouping-rule at
3549d2c49, which is the module this docstring describes: "the same additions in the same order,
over prices that were obtained once and reused, and not as a body price multiplied by a count",
"asking for each price once per body rather than once per instance", and _instances(..., reuse=True) — "the first instance's prices stand for all of them". _fold is a left fold from
0.0 and is the module's only summation.

I also merged both heads onto the integration head as one octopus merge (669dc3f9d +
ef38f5c31 + 647dc1bfe = d9531d82d): clean, no conflict, three files, 35 insertions /
11 deletions. Landing order does not matter.

---

The four-column table, reproduced — and the B column settles a disagreement

Rebuilt against prove_grouping on compass/ir-4-grouping-rule at 3549d2c49, PYTHONPATH
verified to resolve atom to /workspace/compass-worktrees/ir-4/atom/__init__.py before any
number was trusted. Two-operator blocks (aiter::rmsnorm 1e-06, the attention leaf 3e-06, and
5e-06 for the fourth of the period). Every fold a left fold from 0.0.

shape	recorded	A) reuse the prices	B) reuse one body total	C) total x count
8 identical layers	3.200000000000001e-05	match	3.2e-05 MISS	3.2e-05 MISS
AAAB x 20, nested	0.0003600000000000009	match	0.00036 MISS	0.00036 MISS
6 x 0.1 s	0.6	match	0.6 match	0.6000000000000001 MISS

B misses on 1 and 2 and matches on 3 — not, as one brief circulating on this task had it,
misses on all three. And the coincidence with multiply is on 1 and 2, which I measured as an
identity rather than inferring from the printed digits: B == C evaluates True at 8 identical
layers and at AAAB x 20, and False at 6 x 0.1. The author's correction to that brief is the
right one, and it makes the round-1 finding sharper rather than softer: the singular sentence was
wrong on exactly the two realistic shapes, and on both it named the number the paragraph exists to
refuse.

Corollary, confirmed: 6 x 0.1 cannot discriminate A from B. A single-operator body has no
internal order, so reusing its price list and reusing its total are one computation; A and B both
land on 0.6. It separates reuse from multiply and nothing else. Neither document leans on it.
Both cite all three shapes together, and the only claim either attaches to the trio is the one
6 x 0.1 does support — that multiplying reproduces none of them. The body-total refusal is stated
definitionally and carries no number, which is the correct way to state it given finding 2.

---

The sweep

Built with git grep -n -iE over the merged tree (d9531d82d), across atom/, tests/,
scripts/ and docs/ with no pathspec and no extension filter — the compass corpus alone is
33 .py, 21 .md, 7 .sh, 3 .txt, 2 .json, so a *.py-only glob would miss 33 files.
Patterns in both directions: multipl, (prices?|priced|pricing) the body, body once,
priced once, once and (multipl|reus), that price, those prices, price (once|by the count),
x count, times the (count|repeat), scale[ds]? by, reproduces? the flat,
flat (cost|price|total), grouped (cost|price|form|total), agree (exactly|on the (sum|total)),
total against total, assert.*(grouped|flat).

The two correct uses survive untouched. ir/nodes.py:557 (EqualPrice.__post_init__, "the
difference would otherwise be multiplied by the repeat count") is outside this PR's only hunk and
is byte-identical. The design's "a wrong nesting is a systematic error multiplied by the repeat
count" is a single site, not two — 04…md:509 and 04…md:523 are the same sentence before and
after #88's insertions (:524-525 in the merged tree), and it is untouched in both PRs. Both
describe a per-instance discrepancy recurring count times, which is correct arithmetic and not an
instruction to compute a grouped price.

Nothing is left. After both PRs, no site in the corpus instructs multiplication as the way a
grouped price is computed, and no site prescribes a total-only comparison for the grouping check.
backends/cost.py:182 is a different grouping — terms bucketed by species, for reporting — and
already states the re-association hazard correctly with its own worked example; no change needed,
same ruling as cycle 1.

---

Gates — re-measured at the head I read

Integration head read at container UTC 2026-09-21T18:45:03Z and again at 18:56:14Z:
669dc3f9d396eee655ed70e7d951b743840b12c0, unmoved across the review. ef38f5c31 and
647dc1bfe also unmoved. (Host and container clocks agreed to within 7 s on this box today, so
these are wall times, not offsets.)

Six trees, git archive via each tree's own snapshot.sh (both stamps present, so no run could
exit 98 for a staging omission), md5-verified on arrival, docker cp into my own
/tmp/rev8388/<sha> in xiaobizh_n18_cpu on node 18 — never rsync, and not into
/tmp/xiaobizh-compass/. PYTHONPATH verified to resolve atom to the tree under test before
each run. Six runs, strictly sequential, never overlapping, 18:49:56–18:54:31 UTC. All paths
removed afterwards.

tree	sha	passed	skipped	xfailed	rc
this PR's base	68ef4f329	4380	149	3	0
this PR	ef38f5c31	4380	149	3	0
#88's base	14a197b07	4399	149	3	0
#88	647dc1bfe	4399	149	3	0
integration head (control)	669dc3f9d	4496	149	3	0
both PRs merged onto the control	d9531d82d	4496	149	3	0

Delta of this PR: zero on all four numbers, measured against its own base rather than inferred.

The accounting for the 116-test gap against the control is measured, not asserted.
14a197b07 − 68ef4f329 = +19 is #74 (M1-1, tests/compass/test_backend_kv_geometry.py);
669dc3f9d − 14a197b07 = +97 is #79 (the machine-spec schema). Together they are exactly the
116 between this branch and the head. The merged-tree run closes it from the other side: both
prose PRs on top of 669dc3f9d read 4496, the control's own number. A restack of this branch
alone onto 669dc3f9d should read 4496.

The three-way CPU flake in tests/entrypoints/test_stream_marker_properties.py::TestTheRegionIsNot CopiedPerChunk did not fire in any of the six runs — skipped is 149 throughout, no failures, and
GATE_CPU_RC=0 everywhere. scripts/compass/README.md's 4030 remains stale; every figure above is
measured.

ruff check and ruff format --check clean on atom/compass/ir/nodes.py. Longest changed line
is 80 columns.

Gate 2 (new tests). Agreed and stated: a docstring adds no behaviour, and asserting its wording
would pin prose. Gate 3 (the named result) is discharged and independently reproduced above.

---

Recorded, not blocking

The PR body is a round-1 artefact. Its "## The sentence — After" block still quotes
reusing **that price**, the singular form that round 1 found and ef38f5c31 removed, and its
gate table still names 68ef4f329 as "Control (integration head)". AI_DEV_RULES.md makes the PR
body the task's dev record, so as it stands the record of this task quotes the defect as the
fix. The round-2 summary comment carries the correct text and the correct control, so nothing is
lost — this is a one-line body edit whenever convenient, and explicitly not a change request.
I am recording it rather than folding it silently because a stale dev record outlives the thread
that corrects it.

Where the unlanded-fixture risk should live. Every number in both PRs is measured against
prove_grouping at 3549d2c49, which is #66 — open, draft, unlanded. If that module changes
shape before it lands, both sentences and all six digits need re-reading against what lands. Today
that dependency is recorded in two PR bodies and two review threads, none of which is read at the
moment of risk. The cheapest durable home is a comment on #66 itself, since #66 is the only
place a change would be noticed at the right time; a closing handoff on #71/#84 is read by a
successor to this task, not by whoever touches grouping.py. A registered T row in
12_open_items.md is the heavier alternative if the owner wants it in the design corpus. Either
way it is not this PR's to carry and does not hold it.

---

What the next task in this area should watch

Unchanged from cycle 1, and worth repeating because both PRs now state the rule that makes it
sharper: EqualPrice records two totals, flat_seconds and grouped_seconds, while the rule
that produces them compares term by term and both documents now say so in as many words. A
per-instance difference the total absorbs — measured, in
test_one_bit_of_difference_at_one_instance_refuses_the_grouping, where flat_seconds == grouped_seconds and the grouping is refused anyway — is refused by the rule but leaves no trace in
the evidence the surviving repeat carries. That is principle 7, and it is IR-3/IR-4 territory.

---

What I could not check

• The GPU tier. Not run; the diff touches no path in gpu_gate_triggers.txt and gate_cpu.sh
  agreed, printing gpu: not required and returning 0 rather than 98.
• The evaluator this docstring instructs is still unlanded. Every agreement claim above is
  against grouping.py at 3549d2c49 on compass(ir): price a proposed repeat before allowing it to stand (IR-4) #66. If compass(ir): price a proposed repeat before allowing it to stand (IR-4) #66 changes before landing, re-read both
  sentences against what lands — see the note above.
• The provenance of the two-operator block. I reconstructed it by hitting all six recorded
  digits exactly, as cycle 1 did; the original script that produced the citation is still not in
  any tree, and _dense_stack(8) is not it.

🤖 Generated with Claude Code

[jgong5]

Correction to this PR body before landing — the body is a round-1 artefact.

AI_DEV_RULES.md makes the PR body the dev record, and as it stands this one
quotes the defect as the fix. Two stale spots, neither affecting the diff:

1. Its "After" block still reads "reusing that price" — the singular
   phrasing that round 1 refused. The landed text at ef38f5c31 is:

   "Collapsing n instances into one body is only free if pricing the
   body's operators once and reusing those prices for every instance
   gives what pricing the instances separately would give — the same prices,
   in the same order, added the same way. What is reused is the body's
   sequence of per-operator prices, re-emitted in order once per instance,
   and not a body total."

2. Its gate table names 68ef4f329 as the integration head. The head at
   review time was 669dc3f9d, and round 2's gates were measured against it:
   control 4496 passed / 149 skipped / 3 xfailed / rc=0, this branch
   4380 at its own base 68ef4f329, delta zero in every field. The
   116 gap between the two is +19 from compass(backends): the stand-in model's KV geometry, driving ATOM's real block sizing (M1-1) #74 and +97 from compass(spec): the machine-spec schema, closed against the deployment (SPEC-1) #79, verified by
   measurement rather than assumed.

Recorded here rather than by rewriting the body, so the round-1 text and the
review that refused it both stay legible.

🤖 Generated with Claude Code