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.
Put shared decisions on the backend
Ownership, case membership, retrieval eligibility, source freshness and application of AI proposals should be enforced by backend services. The web and Android clients can present those capabilities differently without independently deciding what evidence is valid or whether an analysis is current.
A mobile client may need document capture, a compact preview and resilient upload progress. Those are interface and platform concerns. The source record created by an upload should still enter the same preparation and provenance workflow used by the web library. A mobile-only evidence database would recreate the consolidation problem in another form.
Design reconnect behaviour around saved state
The following response is a conceptual API contract, not an existing MailTrace endpoint. It illustrates how a client can reopen a job after losing its connection without starting a new analysis.
{
"job_id": "job-example",
"status": "completed",
"result_id": "answer-example",
"source_revision": 8,
"updated_at": "2026-10-13T12:00:00Z"
}Add offline behaviour deliberately
Offline viewing raises questions about local storage, logout, stale data and access revocation. Start by defining what can be cached and what requires a live server check. Provider credentials and privileged service keys belong on the backend, not in an Android package or browser bundle.
Test the same workflow through both clients: upload, prepare, inspect, ask, review and reopen. Include a source excluded on the web while the phone is offline. Native, cross-platform and responsive-web approaches can then be compared against actual interaction needs. The architectural goal is shared authority and consistent results, not identical screens or duplicated business logic.
References & further reading
Official documentation for the methods discussed. Application-specific details come from the development records described in the series note.