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.
Capture the decision and its context
The existing review-and-history design provides a useful starting point. A future learning workflow should identify the proposal, the source revision, the reviewer action and a reason where available. It should distinguish a rejected merge from a renamed issue or a source removed because it was imported incorrectly.
Training directly on every click risks reinforcing interface accidents. A user may accept a suggestion to keep working, then restore it later. Corrections should therefore pass a label review process before becoming examples in an evaluation or training set. Permission to use sensitive evidence for this purpose also needs its own defined basis.
Use a small, explicit feedback contract
This synthetic event illustrates the information needed to interpret a correction later. It is a proposal for an experiment dataset, not a description of an existing MailTrace event schema.
{
"proposal_id": "proposal-example",
"source_revision": 4,
"action": "reject_merge",
"reason": "different_request_references",
"label_review": "pending",
"dataset_version": null
}Start by improving evaluation coverage
The first use of reviewed corrections can be a regression set of previously missed cases. This creates value without retraining. Add examples of false merges, missed replies and unsupported answer claims, then test the current rules and prompts against that set.
Only consider training when the labels are consistent, sufficiently representative and separated from a protected test set. Monitor whether new data overrepresents difficult cases selected by the existing model. Active learning can prioritise useful review, but its selection process creates bias that must be acknowledged. The objective is measurable improvement, not an automatic loop that treats every prior model decision as truth.