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.
Canonical should mean maintained authority
A canonical module is the implementation the product relies on for a defined capability. It does not mean the newest repository or the largest file. Evidence storage, issue membership, retrieval, AI execution, identity and review each need an explicit owner, with consumers that use a stable contract.
Several repositories can work when their responsibilities and release relationships are clear. A single repository can still be fragmented if it contains competing services for the same decision. Repository count is therefore not the primary problem. Unclear authority and unverified connections are.
Map the boundaries before moving code
This proposed ownership map is deliberately small. Real consolidation should name the actual maintained modules and verify the routes and clients that use them. It is not a claim that this target architecture has already been implemented.
{
"evidence": ["source identity", "ownership", "preparation status"],
"organisation": ["issue membership", "proposal review", "history"],
"retrieval": ["eligible indexes", "ranked source passages"],
"ai_execution": ["provider calls", "jobs", "usage records"],
"clients": ["display saved state", "submit explicit user actions"]
}Migrate a complete workflow in a reviewable stage
Choose one user task, preserve its current interface where appropriate and replace the underlying capability behind a tested contract. Verify the whole path before moving the next module. Keep source repositories read-only during inventory, preserve history and make the destination and rollback plan explicit.
For MailTrace, a valuable acceptance path is evidence import through saved retrieval and a cited answer, reopened without another model call. Another is issue selection through a stable timeline and visible source evidence. These workflows reveal integration gaps that isolated module tests miss. Progress becomes a sequence of working, reviewable capabilities rather than another repository that promises to contain everything.