What a project alias does to inbox search

A person may call a project by its official name in a planning document, an abbreviation in a message, and an older code name in a calendar event. The person knows these labels refer to the same work. A search engine that only matches the words in the question may not.

This is one reason to explore a personal world model rather than treating all connected app records as an undifferentiated pile of text. But a graph is not automatically better: it can join the wrong people, propagate an outdated alias, or turn an uncertain relation into a confident search expansion. We isolated the retrieval effect of a known project alias in a reproducible set of generated inbox records.

Dataset and run: The October 9, 2026 test uses 120 generated inbox-style entries and 60 defined questions. It measures the ranker's top-three retrieval hits.

Question

When the user asks about a project under its canonical name, does adding an explicit, previously known project alias improve retrieval of the message containing the requested approval record? We measure retrieval, not the quality of a natural-language explanation that might be written from that message.

The comparison is between a literal lexical search and that same lexical search with an alias supplied from a generated project directory. The alias is a relationship fact, not a synonym the evaluator invents after seeing the expected answer.

Setup

We generate 30 projects. Each has four inbox-like entries: one message carrying the final approval reviewer, one directory entry connecting a canonical name to an alias, and two plausible distractions. There are 120 entries overall.

Six projects use their canonical title in the approval message. The other 24 use an alias instead. Every project receives two questions, for a total of 60. The answer key is the ID of the approval message; finding the directory link alone does not count. There are 12 direct-title questions and 48 alias-only questions.

The baseline ranks the entire collection by IDF-weighted overlap with the question. The linked condition uses the same score, same corpus, and same top-three cutoff, but adds the directory alias tokens to the query. Neither condition uses embeddings or AI-generated rewrites. Both are deliberately simple so the effect of the extra relationship can be isolated.

For each query, a hit means the expected approval record is anywhere in the first three results. We save all top-three IDs, the expected ID, and the condition-wise result in raw.json. The experiment contains no private source data and uses a fixed seed.

Results

The all-question chart is a count of correct records retrieved within the top three, not a percentage of accurate generated answers.

Literal search | ██████████████████       45 / 60
Alias-expanded | ████████████████████████ 60 / 60

Top-three hits for 60 generated questions, with and without known-alias query expansion.

The difference comes entirely from the alias-only subset. On direct-title questions, both methods retrieve the desired record on every trial. Where the approval message uses another name, lexical ranking sometimes prefers a directory record or a distraction with the canonical title. Adding the alias makes the approval record available in the top three in all evaluated cases.

The directory mapping supplies correct project aliases, isolating the effect of an established relationship on search. With those links, top-three hits rise from 45 to 60 of 60 questions. Inferring aliases from noisy inbox content is a separate task.

The decision underneath the result

The useful design idea is not that every search should become graph search. It is that relationships should be addressable, inspectable data. If the user has confirmed that the planning title and the inbox title refer to one project, retrieval can exploit the relationship without requiring the model to infer it repeatedly.

Such relationships should also carry provenance. Which message established the alias? Was the name valid last month but not today? Does another project now use the same shorthand? A system that cannot answer those questions could turn a small recall gain into a hard-to-debug false match. In a personal context engine, wrong joins can be more damaging than missing a low-priority result because they can contaminate the evidence supplied to an AI.

The test also suggests recording separate metrics for direct references and indirect references. An aggregate score can hide a weak alias-handling pathway when many easy direct-title records dominate the data.

Measurement scope

The baseline is a small IDF-weighted ranker and the second condition adds known aliases to the same ranker. We chose a small IDF scorer intentionally. Our corpus contains English text, short records, clean project identifiers, and no competing meanings for the generated aliases. The scoring measures top-three inclusion, not ranking position, evidence citation, or the time needed to acquire the directory mapping.

A real world model also connects people and projects across accounts with incomplete permissions. It may have to treat an alias as disputed rather than verified. Incorrect joins, changing names, multilingual threads, and repeated organizational acronyms could reverse the result. We did not inject those difficulties here.

There is also no language model in the loop. The retrieved message could contain the right field yet the model could answer incorrectly. A high retrieval hit rate is only one prerequisite for an accurate response.

Testing contested aliases

Make the alias directory imperfect on purpose: missing links, stale names, shared acronyms, and adversarial near-matches. Compare direct text search, confirmed-link expansion, and uncertain-link expansion. Report both recall and false-positive joins, including examples of how each failure would affect a user-visible answer. Finally, repeat the test under per-app permissions, because a link may exist while the underlying message is not authorized for the destination AI.

The experiments/linked-retrieval/run.py entrypoint and raw.json retain the expected record and both sets of top-three results for every query.