Amplification scorecard
The cognition, agency and governance scorecards cover how well Piper thinks, whether she can pursue goals on her own, and whether her evidence about herself can be believed. This one covers the core of recursive self-improvement: whether her improvements make her better at producing further improvements. Changing her own code is not enough; the change has to improve the process that makes the next change. Twenty-four components in six layers, from the mechanics of one improvement cycle up to evidence of a self-reinforcing one. None has been reviewed against her system yet. As with the other three, the plan is to pick one at a time, starting with #5 and #6, test it, and rescore.
Components scored24/24
Suites retired24
Interventions1
Bench spend$2.52
Shared copy: the operator's name is replaced with "the operator", and machines other than Firefly are named by their role. Nothing else is changed.
| # | Component | Reviewer read | Suite | Baseline | Latest | Change | Live use | Trend |
|---|---|---|---|---|---|---|---|---|
| 1 | Improvement detection | She finds most of her own targets now; nothing records what she missed | v2 | 87.5 | 95.8 | ▲ +8.3 | — | |
| 2 | Hypothesis formation | Hand-written rows still predict before the test; since the hook files every change, 100 of 126 rows carry no prediction at all | v2 | 84.4 | 18.1 | ▼ -66.3 | — | |
| 3 | Intervention selection | Each dispatch names one route not taken; there is no candidate set, no cost or value estimate, and nothing scores the choice | v2 | 100 | 100 | 0 | — | |
| 4 | Change execution | Her changes land and are mostly verified; the gaps are bars that cannot fail and code that is on disk but not running | v2 | 80 | 76.2 | ▼ -3.8 | — | |
| 5 | Outcome attribution | Judges its own changes on pre-set rules; the judge cannot tell the change from drift | v2 | 93.8 | 90.6 | ▼ -3.2 | — | |
| 6 | Feedback integration | Every new row now carries a checked citation, and the brief serves a type record when the kind of change has one. No row yet cites a result that is actually about the change (the first 3 were word matches, now fixed) | v2 | 6.2 | 5 | ▼ -1.2 | — | |
| 7 | Failure learning | Code fixes leave a lesson; her solver loop's failures leave only a verdict file, and the one hand-written lesson there is half wrong | v2 | 87.5 | 100 | ▲ +12.5 | — | |
| 8 | Strategy adaptation | She changes method when the numbers say so, quickly for the capture trigger and on a partly wrong reading for the solver loop | v2 | 100 | 100 | 0 | — | |
| 9 | Transfer learning | Lessons move between her dispatch habits; between capabilities she found zero cases, and her count of that never reached the document | v2 | 85.7 | 85.7 | 0 | — | |
| 10 | Improvement memory | Retention is solved and reads are now logged; the loop breaks after the prediction: 1 of 67 changes has an outcome, and no outcome reaches a choice about a different task | v2 | 0 | 16.9 | ▲ +16.9 | — | |
| 11 | Improvement throughput | Verified gains per week fell 2, 1, 0 while changes tried rose to 127; seven verdicts settled 10-15 put this week at 2 measured gains | v2 | 25 | 12.5 | ▼ -12.5 | — | |
| 12 | Resource efficiency | Cost per verified gain is now readable: small ledger fixes cost cents, and the solver loop's scoring is most of the bill | v2 | 31.4 | 5.3 | ▼ -26.1 | — | |
| 13 | Experiment efficiency | Most of her predictions are checkable and nobody checked them; the solver loop's scoring is being rebuilt to see smaller gains for the same money | v2 | 0 | 0 | 0 | — | |
| 14 | Search efficiency | She built a pre-registered odds record and a guard that refuses READY without it; no session has run under it yet | v2 | 0 | 0 | 0 | — | |
| 15 | Self-improvement capability | She builds improvement machinery fast and documents it well; Claude finds the errors in it, and using it is optional | v2 | 100 | 61.1 | ▼ -38.9 | — | |
| 16 | Second-order improvement | Every version change now gets a row, but mostly after the fact: of 57 changes, 25 unpredicted, 10 rowless, 9 rowed late | v2 | 50 | 22.8 | ▼ -27.2 | — | |
| 17 | Cross-component amplification | One real cross-component effect, measured honestly; it is reach inside one pipeline, not a gain in a different capability | v2 | 87.5 | 93.8 | ▲ +6.3 | — | |
| 18 | Compounding improvement | She says her record has no generations; her own solver loop has six, and capability keeps stopped after the third | v2 | 0 | 0 | 0 | — | |
| 19 | Bottleneck identification | She hunts the binding constraint before changing things, but reads whole-history logs that mix fixed and unfixed versions | v2 | 100 | 100 | 0 | — | |
| 20 | Bottleneck migration | Since the hook files every version bump, most changes get no later re-read at all; the fast re-reads she does write are lost in the count | v2 | 80.8 | 0 | ▼ -80.8 | — | |
| 21 | Parallel improvement | Parallel work is routine; interference shows as duplicate rows and as changes landing close enough to blur each other's measurements | v2 | 47.8 | 38.7 | ▼ -9.1 | — | |
| 22 | Integration stability | 353 test files and no scheduled run of them; the one series that tracks older capability dipped slightly after the last keep | v2 | 84.4 | 86.7 | ▲ +2.3 | — | |
| 23 | Improvement persistence | Kept solver versions score lower on re-measurement than when they were kept; code changes persist, some only after a restart | v2 | 60 | 60 | 0 | — | |
| 24 | Autonomous recursive continuity | Four self-driven cycles on 10-13 (an earlier verdict cited by a later change that got its own verdict); none since | v2 | 0 | 87.5 | ▲ +87.5 | — |