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.
Start with the work someone needs to finish
The useful question is rarely “Can AI summarise this mailbox?” It is more often “Which request is this reply answering, what evidence supports that interpretation, and what still needs attention?” That requires a workspace with distinct records for messages, documents, issues, timeline events and interpretations. A summary alone cannot provide those relationships.
The documented MailTrace workflow imports evidence, prepares searchable text, retrieves relevant passages and saves analysis for review. Each stage needs a visible outcome. A successful import does not automatically mean a scanned PDF is searchable, or that an unanswered request has been resolved.
Give evidence and interpretation different records
An email’s source identity and timestamp belong to the evidence record. An issue title, a suggested family and an answer belong to derived records. This separation lets the product improve its interpretation without quietly rewriting history. It also explains why a renamed issue should not break a link to its supporting email.
This synthetic contract illustrates the distinction. It is a teaching example, not an extract from the application’s database schema.
{
"source": {"id": "email-example-1", "case_id": "case-example"},
"interpretation": {"source_id": "email-example-1", "version": 2},
"review": {"status": "pending", "decision": null}
}Make reopening a read operation
The development reports describe persistent jobs, saved results and checks for stale evidence. These support a simple user expectation: opening the same issue twice should show the same saved work. An explicit refresh can fetch newer saved data; it should not silently purchase another model response or reorganise the sidebar.
Progress should therefore be measured across a complete task: import a document, find it, inspect its source, use it in an answer and reopen that answer. Counting modules or AI integrations misses failures between those steps. The rest of this series follows those boundaries, and distinguishes documented development work from proposed experiments.