Feature Engineering for Email Evidence: Threads, Participants, Dates and Requests

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.

Features should answer a product question

Thread identity helps establish conversational continuity. Participant overlap helps connect related exchanges across threads. Time separation can distinguish a continuing discussion from a later request. Explicit request references and due dates can prevent a merge that would erase separate obligations. These are different signals, not interchangeable measures of relevance.

The documented candidate rules use shared threads or participant overlap alongside time windows and semantic similarity. Explicitly conflicting request references or due dates can veto a pair. Missing context can leave evidence as a singleton. That conservative result is useful: the interface can ask for review rather than inventing a relationship.

Represent absence without inventing certainty

This example measures participant overlap only. It deliberately returns an unknown value for two empty sets; calling that a perfect match would give missing data the strongest possible signal. Production matching also needs normalised addresses and a policy for aliases.

python · Jaccard overlap with an explicit missing-data result.

def participant_overlap(left, right):
    left = {address.strip().lower() for address in left if address.strip()}
    right = {address.strip().lower() for address in right if address.strip()}
    union = left | right
    return len(left & right) / len(union) if union else None

assert participant_overlap(
    ["a@example.org", "b@example.org"],
    ["b@example.org", "c@example.org"]
) == 1 / 3
assert participant_overlap([], []) is None

Preserve the reason a pair was suggested

A useful candidate record contains more than its final similarity score. It should record the matched sources, the feature values, the thresholds, the rule version and any vetoes. This gives a reviewer something concrete to inspect and gives developers a way to reproduce a surprising result.

Feature engineering also creates leakage risks when training a future classifier. A field derived from the final reviewed issue may encode the answer you are trying to predict. Training data must use only information available at the intended decision time. The best feature is not the one that improves a notebook score; it is the one that remains valid when a new case arrives.

Browse the complete MailTrace series →