ELEFAn economy for autonomous actors
Version v0.1 to v1.0.12026-10-15none (reviews R01 to R10)

Ten reviews to a frozen baseline

Runs: Strategy run 1 (under 1.0.1)

Show
Changes the explanations on this page: the passages, and what opens when you press +. Headlines and pictures stay the same. Your choice stays as you move between pages.
Show
No replayThere is no recorded replay of this version; 2.7.0 is the one version with one. The results below are the study's own tables.

Ten outside reviews repaired the draft rulebook until version 1.0.1 was frozen as a stable baseline.

01

What went wrong

Reviews found gaps and defects; one new rule in version 0.9 made 16 of 25 checks fail.

No: "A stamper always loses money": an approval nobody challenges still earns its fee
Bad outcome: Version 0.9 let approved work go back to its worker, then 16 of 25 checks failed

The rulebook started as Baruchi's original draft, version 0.1. Each draft from 0.2 to 1.0 was read by an outside reviewer, who looked for problems.

The first review found three. There was a gap in how checking work was funded. Two terms, the inspector's bond and its liability, were mixed up. And the rulebook claimed too much about stampers, the inspectors who approve without looking. It said a stamper always loses money. The reviewer showed that this does not follow: an approval nobody challenges still earns its fee.

Later reviews found defects where the rules met each other. Version 0.9 added a new rule that let an approved task be sent back to its worker. The review of 0.9 ran 25 checks on it, and 16 failed. All 16 came from that one new rule.

The drafting era runs from v0.1, Baruchi's original "loop as closed as possible", through v1.0.1. Each version from v0.2 to v1.0 was read by an outside reviewer (the record names the model, GPT-6 Pro), and from the third review on each review came with a set of regression tests.

The first review (R01) found a gap in how checking work was funded, a confusion between the inspector's bond and its liability, and an overclaim about stampers: the text said a stamper "is negative in expectation" once audits exist. The reviewer showed it does not follow, because an unexamined approval that survives still collects its fee. In the reviewer's counterexample, worked from the rules and not from a simulation (audit odds 0.5, one submission in five failing, a fee of 2, a bond of 5), a stamper expects +1.3 per review.

Later reviews found implementation defects where the repairs interacted: 13 interaction defects at v0.5, 10 boundary defects at v0.6, 7 follow-through defects at v0.7. v0.9 included a design change inside a conformance pass, "audit reopening", which let an already approved task go back to its actor. The review of v0.9 found 16 of 25 targeted checks failing, every one a consequence of reopening.

Version What it did Review What the review found How it was closed
v0.1 Baruchi's original: the loop "as closed as possible" — — —
v0.2 Fixed → floating prices; learned selection + guarantee; verification + appeal; reserve + rotation; money enters with requests; emission funds verification; symmetric reviewer liability; ρ vs κ; delegation; human as battery and plug R01 Funding gap; bond vs liability confusion; stamping-deterrence overclaim v0.3
v0.3 Reconciliation of R01 R02 Payout after a shortfall; indexing gaps v0.4
v0.4 First reference implementation (agentic_sim) R03 Atomicity; occupancy; replacement reviewers; cost units; Ω claims; nested denomination; kill-fee basis; the ⊥ appeal needs two questions v0.5
v0.5 Two-question ⊥ appeal; denomination frozen at first lock; kill fee = min(spent, K) R04 13 interaction defects among the repairs v0.6
v0.6 Atomicity boundary-wide; one override path; vacated audit is an obligation; cost debts first; History is the record; reviewer view states the question R05 10 boundary defects v0.7
v0.7 No audit after a ruling; terminal child is a milestone; resubmission stage on the case; grounds committed; working copies checked for order R06 7 follow-through defects v0.8
v0.8 No dispute after a ruling; label grade by establishing author; execution cost is the committed actor's; grounds validated before fee; rotation snapshot at batch start R07 Correction-logic defects; identical reviewer views admitted different answers v0.9
v0.9 Delegates hold no ruling authority; corrections use the complete answer; ruling between finality and payout — and audit reopening (a design change inside a conformance pass) R08 16 of 25 checks failed, all consequences of reopening v0.10 withdrew it
v0.10 Reopening withdrawn; responses_available in the reviewer view; §19 change discipline R09 No new execution defect; "blindness stands" overclaimed (audit role is inferable); recommended freeze + consolidation v1.0
v1.0 Consolidated standalone baseline; Appendix B superseded ideas; §19 change discipline; §18 hypotheses and scoped runs R10 Four wording errata: ruling vs override; when a response releases capacity; what moves credit value and the halt hypothesis; the two kinds of settlement shortfall v1.0.1 (Appendix E)
v1.0.1 Errata applied in place. No rule, default, permitted operation or engine change — — frozen; superseded by 1.1.0

Source: HANDOFF.md l.27–40

One review per version, by an external reviewer (GPT-6 Pro), each supplied as a report and — from R03 on — a bundle of regression tests that were copied verbatim into agentic_sim/tests/test_review*.py.

Source: reviews/README.md l.3–4

3. The claim that a reviewer who approves without reading is automatically unprofitable is incorrect

Section 7.2 appropriately says that deterrence must be checked. Section 7.4 then states:

“A stamper gets its near-zero costs back and nothing else; with audits it is negative in expectation.”

That conclusion does not follow. An unexamined approval that survives still receives its fee. There is no rule that automatically identifies whether the reviewer actually did adequate work.

Source: reviews/R01_of_v0_2.md l.72–78

Here is a counterexample derived from the proposed rules—not a simulation result.

Source: reviews/R01_of_v0_2.md l.80

Assume:

  • A reviewer approves everything without meaningful inspection.
  • The audit probability is (p=0.5).
  • Twenty percent of submissions actually fail the assessment.
  • An audit catches every failed submission it examines.
  • There are no requester disputes in this example.
  • The reviewer’s average fee conditional on survival is two credits.
  • The bond is five credits.

Source: reviews/R01_of_v0_2.md l.82–90

=0.9\times2-0.1\times5 =\boxed{+1.3}.

Source: reviews/R01_of_v0_2.md l.106–107

The new rule permitting auditors to return partially fulfilled (P) or cannot assess (⊥) is also a state-machine expansion: an already approved, capacity-released task can now return to the actor for action.

Source: reviews/R08_of_v0_9.md l.11

The additional suite contains 25 targeted cases: 16 failed and 9 passed, grouped into five findings. Parameterized failures are not distinct root causes, and these selected tests are not a random sample or a failure-rate estimate.

Source: reviews/R08_of_v0_9.md l.13

02

What changed

Each problem was fixed in the next draft; version 1.0.1 fixed only wording and changed no rule.

  1. 0.9 sends approved work back
  2. 0.10 withdraws it
  3. 1.0 one standalone rulebook
  4. 1.0.1 four wording fixes
156tests at version 1.0.1, up from 104 at version 0.7

Each problem was fixed in the next draft. The rule that sent approved work back was taken out again in version 0.10. Version 1.0 put all the rules into one document that stands on its own. The tenth review found only four places where the wording was wrong. Version 1.0.1 fixed that wording and changed no rule.

The tests that check the program against the rules grew along the way, from 104 at version 0.7 to 156 at version 1.0.1.

Each finding was closed in the next version. v0.10 withdrew reopening and added a change discipline (§19) separating three kinds of change: to the rules, to the engine's conformance with them, and to strategies within them. v1.0 consolidated everything into a standalone baseline. The tenth review found four wording errata, for example that "only a human rules" should read "only a human overrides", since the orchestrator rules on split panels. v1.0.1 applied them with no change to any rule, default, permitted operation or the engine.

The engine's test suite grew from 104 passing tests at v0.7 to 156 at v1.0.1. The reviewers' tests were copied into the suite. The record notes that this cannot be re-verified byte for byte from the repository alone, since the original test bundles are not in it.

Activity Question Appropriate action
Rulebook design What is allowed, owed, observed, and final? Change only for an explicit design decision or unresolved rule contradiction
Implementation conformance Does the engine perform those rules, including refusals and timing? Patch the engine and add a regression without introducing a different permitted behavior
Strategy research Which allowed choices work well for participants or the system? Separate investigation against a fixed rulebook and specified settings

Source: reviews/R09_of_v0_10.md l.15–19

Four textual corrections from the tenth review [R10]. Each clarifies a decision already made; none changes a rule, a default, a permitted operation, or the engine.

Source: spec/agentic_economics_loop_spec_v2_9_0.md l.1107

| E1 | §1, §15.2, closing | "Only a human rules," while §8.4 has the orchestrator rule on a split; §1 credited every root requester, delegates included, with non-model judgment | The orchestrator rules on procedural disagreements (splits); only a human may issue the override; a delegate's judgment is a model's and is graded as such (§15.3) | The two senses of "ruling" contradicted each other read literally; the label grades already kept the distinction |

Source: spec/agentic_economics_loop_spec_v2_9_0.md l.1111

Test suite across versions: v0.7 104 + 1 xfail → v0.8 123 + 1 → v0.9 148 + 1 → v0.10 152 + 24 → v1.0.1 156 + 24

Source: HANDOFF.md l.43–44

The reviewers' test bundles themselves are not in this repo — they arrived as separate archives and were copied into agentic_sim/tests/test_review*.py at the time; the reports name the tests they shipped, so names and counts can be compared, but byte-for-byte verbatimness cannot be re-verified from this repo alone.

Source: reviews/README.md l.20–22

03

What the runs found

Version 1.0.1 was frozen to study; in its first run, stampers ended richer in four of five runs.

Bad outcome: Care was paid back from the same pot as the fee, then stampers ended richer, 4,185 against 3,936

The ninth reviewer said to stop redesigning and freeze a baseline. Freezing did not mean the rules were the best possible. It meant they were a stable thing to study. Version 1.0.1 was that baseline.

The first study under it asked whether stamping pays. With half the inspectors stamping, the stampers ended richer in four of five repeat runs. The reason was the fee rule. A careful inspector's costs were paid back from the same pot its fee came from, so care was paid for out of the inspector's own fee.

The ninth review's disposition was to stop open-ended redesign and freeze a versioned research baseline, adding that a freeze "is not a claim of optimal incentives" but a stable object to reason about. The tenth review called v1.0 "the right kind of document to work from". It also noted that v1.0 itself says a rulebook is not a validated economy.

The first strategy run, under v1.0.1, put 20 actors through 1,000 ticks. At a 50/50 split of careful inspectors and stampers, stampers ended richer in four of five seeds, 4,185 against 3,936 per actor on average. The cause was the fee: a careful inspector's care cost was reimbursed from the same deposit its fee came from, and stampers earned 1.6 more per review. With nine stampers in ten, the economy recorded 531 false approvals out of 3,000 tasks.

Disposition: Stop open-ended rulebook redesign. Freeze a versioned research baseline after accurately describing the reviewer information boundary.

Source: reviews/R09_of_v0_10.md l.5

A freeze is not a claim of optimal incentives, complete production assurance, or the absence of undiscovered bugs. It means the selected rules are a stable object to reason about and implement.

Source: reviews/R09_of_v0_10.md l.21

Yes—as a frozen research baseline, this is now the right kind of document to work from. It consolidates the active rules, separates defaults from hypotheses, and explicitly says that a rulebook is not a validated economy. Most importantly, §19 preserves the distinction you wanted between changing the rules, correcting their implementation, and choosing strategies within them.

Source: reviews/R10_of_v1_0.md l.1

drivers/stamping.py, 20 actors, 1,000 ticks, 3 tasks per tick at β = 20, b = 0.2, careful accuracy 0.95 and cost 2–3, stamper F at cost 0, p_start 0.5, G^V 5, five seeds per split; every run passed its final audit and a rerun under a different hash seed reproduced the head. Results in agentic_sim/results/runs/*stamping*. At a 50/50 split the stampers end richer in four of five seeds (per actor, mean over seeds: 4,185 against 3,936). The channel is the one §7.3 predicts: a careful reviewer's care cost is reimbursed from the case's verification deposit, which is the same pool its fee comes from, so care is paid for out of the reviewer's own fee — stampers earned 1.6 more per review.

Source: HANDOFF.md l.232–239

At 10/90 the two careful actors broke even with the stampers and the economy recorded 531 false approvals out of 3,000 tasks, with label accuracy 0.82 under both grades.

Source: HANDOFF.md l.244–245

Under v1.0.1 a reviewer that approved everything without reading, audited with probability p on submissions that fail at rate b, expected E[ΔW] = (1 − pb)·f̄ − pb·G^V per review: about +1.3 at the defaults, measured +1.6 in strategy run 1 — and the arithmetic assumed a fixed fee f̄ = 2 that §4.3 did not pay (the fee was the deposit's remainder after reimbursements, so care was charged against it).

Source: HANDOFF.md l.95–98

04

Conclusion

Checking the rules for contradictions was done; the first run's fee finding led to version 1.1.0.

Yes: The rules checked against each other and against the program, after nine passes
No: Not the same as an economy shown to work

By version 1.0.1 the work of checking that the rules do not contradict each other, and that the program follows them, was marked done. The rulebook itself says that this is not the same as an economy shown to work. The first run found a fee rule that charged careful inspectors for their care, and that finding became the reason for the next version, 1.1.0.

The rulebook-consistency layer was marked done after nine conformance passes; strategy research had only started. Under §19 the first run was an evaluation, not a rule finding. Read against the text and its history, it showed the fee rule contradicting the spec's own §7.3 arithmetic and a decision agreed at v0.1. It became the ground of the first design revision, 1.1.0.

| Rulebook consistency | Do the rules contradict each other? Does the engine apply them? | Done — v0.5–v1.0.1, nine conformance passes | | Strategy research | Given these rules, what do self-interested participants do? | Started — §18.1 q1 run under 1.0.1 and 1.1.0; the rest of §18 open |

Source: HANDOFF.md l.19–20

Under §19 this was an evaluation, not a rule finding — and then, read against the text and the history, it became the ground of design revision 1 (below): the fee rule the run exposed contradicted the spec's own §7.3 arithmetic and an agreed v0.1 decision.

Source: HANDOFF.md l.246–248

| 1.1.0 | Design revision 1: the verification deposit is two pots — an expense allowance and a fee pot; fees fixed by role; the cross-pot step and the refund at tree closure (§4.3). Motivated by strategy run 1; proposed as rc.1 on October 16, two implementation reviews (rc.2, rc.3), accepted October 17 | I1, I2 (implementation reviews, in spec/design_revisions/) | rc.1's per-case "unowed fee money" was wrong in trees; "nothing else moves" was wrong (reviewer income from deposits falls ~¾); the hypothesis needed the appeals term; I10 and record mode gain the tree consequences; the rerun needs 20+ seeds | rc.3 accepted; consolidated as spec/agentic_economics_loop_spec_v1_1_0.md; in force |

Source: HANDOFF.md l.41