A learned improvement needs an undo record
By DX Research Group · · Data and learning flywheels
A proposed rollback map ties adaptation failures to the smallest reversible release artifact.
A feedback-driven release needs an undo record as concrete as its improvement claim. When behavior changes, researchers should be able to identify the responsible artifact and restore the previous tested behavior without silently restoring obsolete owner instructions. We propose a rollback map attached to every candidate adaptation.
DXAP's release notes already distinguish agent-scoped chat memory from trading notes and settings. The chat guide makes confirmed persistent instructions a separate owner action. Those distinctions matter during recovery: reverting a memory-processing component and reverting an owner's approved strategy are different operations.
A failure with two histories
Consider an illustrative sequence. At 09:00, an owner confirms instruction version 8. At 10:00, a candidate memory summarizer is released. At 11:00, the owner confirms instruction version 9. At noon, the summarizer incorrectly presents an earlier market thesis as a current preference.
Rolling the entire agent back to its 09:00 snapshot would restore instruction version 8 along with the old summarizer. That would discard an authorized change made after the release. The proposed recovery instead restores the previous summarizer version, identifies entries produced by the faulty version for review or exclusion, and preserves instruction version 9. The exact data repair depends on which records can be reconstructed from permitted source material.
The rollback map should bind the candidate artifact to its output records. For a memory-processing change, record which entries it wrote and their source exchanges. For a harness revision, identify which turns used that revision. For a proposed trained model release, record the model artifact used at inference. These bindings let investigators separate new behavior from simultaneous owner changes.
Reproduce recovery before deployment
We would test recovery on a synthetic timeline containing a release, an owner edit, a failure, and a rollback. After recovery, the previous component must be active, the latest approved instruction must still be active, and affected outputs must have an explicit disposition. A record excluded from active context can remain in the permitted diagnostic history; deletion and retention should follow the applicable data rules.
The rollback decision should name the triggering failure class. An illustrative trigger could be a reproduced memory entry assigned to the wrong agent. That is an operational containment rule chosen for this proposed test, rather than a claim about DXAP's production thresholds. Forecast underperformance would need a different decision rule because short windows can produce noisy reversals even when an implementation is correct.
Recovery also has a trading boundary. Restoring an earlier component cannot reverse venue fills. The policy documentation distinguishes submitted orders and actual execution outcomes. Any affected positions or resting orders require current account reconciliation and handling through the authorized trading path. A software rollback should never be presented as an economic undo.
A useful release receipt would therefore show the artifact restored, the records affected, the owner configuration preserved, and the recovery fixture result. Our proposed map turns reversibility into a tested property of the feedback loop. It makes a failed adaptation a diagnosable version event rather than a reason to erase the owner's subsequent decisions.