Miru’s projected engineering assessment is **83.9/100**. A modeled scenario without independent-review fixes, not a measured baseline, scores **53.8/100** under the rule below. These are rubric scores, not task pass rates. The first assumes the remaining agreed migration work and required follow-ups are completed. The second is a calculation from that same projection; no alternative implementation was run or evaluated.

| Rubric view | Projected completion | Modeled scenario | Difference in points |
| --- | ---: | ---: | ---: |
| Engineering | 83.9 | 53.8 | 30.1 |
| Process | 74.0 | 25.8 | 48.2 |
| Overall | 79.3 | 40.7 | 38.6 |
| Overall, excluding the five process categories assumed absent | 81.7 | 56.6 | 25.2 |

The calculation retains the assessment’s fifteen category scores and weights: six engineering categories with weight 51 and nine process categories with weight 45. The original rubric’s four-point economics weight is excluded because completion cost is unknown. Each category uses a 0–5 anchor. A group score is its weighted anchor sum divided by five times its included weight, multiplied by 100. Overall therefore has a denominator of 480, rather than 500.

The review census contains **233 finding threads with retained corrections**, across 70 merged pull requests. Its broader source corpus contains 114 pull requests, of which 103 merged: 99 implementation pull requests, two design pull requests and two human preparation or scope pull requests. Counting only the final substantive author disposition gives 232 fixed threads. One additional thread has an earlier correction that remained in the evaluated code; its final arbitration response accepted that correction and declined a further change. Both definitions are disclosed. Every included thread has an explicit fix reply naming a commit, but this is not a claim that all 233 patches were individually audited. Six additional correction threads on unmerged pull requests are excluded. One thread is not necessarily one unique defect, and several threads can concern the same change. The broader scenario input reconciles with the case study as **196 non-Minor implementation findings + 24 Minor implementation findings + 12 design findings + one retained earlier correction = 233**.

The source assigns each retained thread to one category using its file location, and retains the reviewer’s severity label. The resulting counts are 11 blocker, 66 high, 131 P2 and 25 P3. A test-file finding goes to tests and verification, even when the underlying defect also concerns architecture or correctness. This mapping is a practical proxy for category relevance; it does not measure the defect’s contribution to product quality. The downloadable data includes every category’s counts, score and weight, with a separately reproducible census of the public review records. The final per-finding assignments reproduce all category totals. The exact ordered path rules are supplied because an abbreviated prose description can leave classification choices ambiguous. None of this makes the scoring coefficients a calibrated estimate of quality.

For each engineering category and requirements traceability, the primary rule assigns deductions of 0.50 anchor points per blocker, 0.25 per high finding, 0.10 per P2 and 0.05 per P3. Deductions are summed within a category, capped at two anchor points, and subtracted from its projected anchor, with a floor of one. These coefficients, cap and floor are declared scoring choices; they were not fitted to observed performance in another run. The floor does not bind any category in this projected primary scenario.

For example, architecture has three blockers, eleven high findings and four P2 findings. Its uncapped deduction is 4.65; the cap reduces that to 2.0, changing its projected anchor from 4.5 to 2.5. Code quality has one P2 finding, changing 3.5 to 3.4. Applying the rule to all six engineering categories produces a weighted sum of 137.2 out of 255, or 53.8/100.

The overall scenario makes additional assumptions. Independent review, author response, follow-ups, issue grooming and learnings are set to zero by definition. Their absence was not observed in another run, and does not imply that model sessions cannot perform those activities. Decomposition, scope and communication retain their projected scores because these review findings do not estimate a change in those categories. Traceability uses the finding deduction. The one learning-document finding remains in the count of 233, but its severity penalty is not separately applied because the scenario sets that whole category to zero.

Those five assumed-absent process categories account for 20.5 points of the primary overall gap. Removing them from **both** sides produces 81.7 versus 56.6, using the same projected base and a remaining weight of 69. This exclusion reduces the influence of those process assumptions; it does not convert the calculation into a measured comparison.

The following parameter checks also retain the same projected base. The projected engineering score remains 83.9 and the projected overall score remains 79.3 in every row.

| Scoring rule | Modeled engineering | Modeled overall |
| --- | ---: | ---: |
| Declared severity deductions; two-point cap | 53.8 | 40.7 |
| Blocker and high deductions only; 1.5-point cap | 67.5 | 48.4 |
| Half the declared deductions; two-point cap | 54.0 | 41.3 |
| Declared deductions; one-point cap | 68.7 | 49.6 |
| Declared deductions; three-point cap | 38.9 | 31.9 |

The blocker/high-only alternative changes the engineering score by 16.5 points from the projected base. The older 41.2 result for that rule uses an observed snapshot and is not part of this comparison. Excluding the one retained correction with a final declined disposition leaves every score in this table unchanged: its category remains capped. Values and differences are calculated before rounding to one decimal; a displayed difference can therefore vary by 0.1 from subtracting the displayed endpoints.

These checks illustrate dependence on the chosen rule. They are not confidence intervals, performance bounds or an exhaustive range of reasonable assumptions. Several categories remain capped when severity deductions are halved; that reflects the formula, not proof that missing findings, different category assignments or other assumptions would make no difference.

This analysis does not estimate which issues another run would prevent or fix by itself, how planning and accumulated learning would affect its first implementation, or how the fixes interact. No fixes were reverted to create and evaluate the hypothetical system. The projected starting anchors are also judgments conditional on completion. The calculation therefore supports a transparent scenario, not a claim about another system’s measured quality or the causal benefit of review.

To reproduce the published arithmetic, keep `assessment.json`, `counts-public-findings.json` and `recompute.py` together and run `python3 recompute.py`. The script checks the finding rows against the category rules and counts, including the 233 retained corrections, 232 final-fixed responses and 196-finding case-study subset. It then recomputes every scenario using exact fractions and verifies the stored results. The companion finding-reproduction script reconstructs the rows from the included public GitHub source records. The fifteen anchors, all weights and all scoring assumptions are in the JSON; no private assessment report is needed to recalculate.