Reviewing Rule Optimizer automated proposals

The optimizer reads how an agent has been performing and proposes a change to its rule file. A proposal is inert: it changes nothing about how the agent behaves while it sits in the queue.

1. differenceReview the proposalRead the proposed change against the version currently in force, and against the runs that motivated it.
2. how_to_regApprove, and only then does it applyApproval is the event that writes the new rule-file version. Declining leaves the agent exactly as it was. There is no code path where a proposal applies itself.

The optimizer reads how an agent has actually been performing — its runs, their outcomes, and where they went wrong — and proposes a change to the rule file that governs it. The proposal is an argument about behaviour, not a configuration tweak.

1. 1Read it against the version in forceA proposal is a change to specific text. What matters is what it adds, removes or reverses, not whether the new text reads well on its own.
2. 2Check the runs that motivated itA proposal argues from evidence. If the runs behind it are a handful of unusual cases, the change may be overfitting to them.
3. 3Approve, or declineApproval is what writes the new version. Declining leaves the agent exactly as it was — there is no partial application and no queue of half-applied proposals.

The new version is append-only like any other, so an approval that turns out to be wrong is rolled back by selecting the previous version rather than by editing the text back.