About the implementation and examples
Engineering notes draw on author-supplied MailTrace development reports through 13 October 2026. They describe the documented revision, including local work, rather than independently verified live deployment. Experiment designs and architecture proposals describe work to evaluate. Examples are educational, use synthetic data and are not copied production code.
Show the proposed difference before applying it
A useful review includes the current issues, proposed issues, supporting sources and any evidence left unassigned. The documented design requires review before application even when model confidence is high. The backend then checks current ownership, source membership, families and the proposal’s base revision.
This protects against a common race: evidence changes while an AI job is running. A proposal that was valid at generation time may no longer be valid at application time. The user needs an explanation of that conflict rather than an apparently successful button that overwrites newer work.
Restore must also respect later changes
A restore action should not blindly replace the current state with an old snapshot. The following example illustrates an optimistic revision guard. It is not a substitute for the transaction and locking needed by a real database implementation.
def require_revision(expected, actual):
if expected != actual:
raise ValueError("The case changed; compare before restoring")
require_revision(7, 7)
try:
require_revision(7, 8)
except ValueError:
conflict_detected = True
else:
conflict_detected = False
assert conflict_detectedPreserve identity wherever the relationship survives
The implementation report describes preserving original rows and history through merges and splits, retaining identifiers for suitable one-to-one changes, and recording additive membership for non-email evidence. These are useful foundations because evidence links should survive a change in the label used to organise them.
Test the whole sequence: generate, inspect, apply, reopen and restore. Include a source exclusion between generation and apply, and a reviewer edit between apply and restore. A workflow is not reversible merely because it has an Undo button. The test is whether the system can restore the intended relationships without erasing someone else’s later work.