Can a project keep its identity across apps?

A person can switch from an email thread to a calendar invitation and then to a document without thinking they have changed projects. The titles may differ, but the work is continuous. Importing each record correctly is not enough if the system cannot connect the same project across different app labels.

Zortex's intended world model connects people, projects, and records from the apps a person already uses. The central engineering question is not simply whether it can draw links between items. It is whether those links preserve identity when labels change without merging two unrelated pieces of work. We measured the difference using a controlled set of generated project records.

Dataset and run: Generated project records, evaluated October 9, 2026, with the stand-alone matcher. The reported joins are from this rules test.

Question

Given an email record for a project, can a matcher find its corresponding calendar and file records when some titles use aliases? How does exact title equality compare with a small graph-style rule that also accepts shared project codes and explicit alias-directory entries?

The task is a record-to-record join. It does not evaluate whether a language model can write a useful summary of the project. It also does not ask a model to discover a relationship without the supporting metadata.

Setup

We build 36 projects. For each project we make one email item, one calendar item, and one file item, yielding 108 records. The email uses a canonical project title. Calendar and file records may use the canonical title, an alternate workstream name, or a deliberately ambiguous label shared by other projects. Some records carry a stable project code; others do not.

Each email produces two search tasks: find the correct calendar item and find the correct file item. There are 72 source–target pairs in total. The generator retains a hidden project ID solely to score whether a candidate join is right. The matcher cannot read that answer key.

The exact-title baseline requires the source and candidate titles to match after lowercasing. The graph condition can additionally match on a nonempty shared code, or normalize an alias through a separate directory of known alias relationships. Some directory entries are omitted by design; the graph does not get the entire answer key.

Both methods are conservative about ambiguity. If more than one target meets a rule, they abstain instead of choosing the first plausible answer. We record three mutually exclusive outcomes for each method: correct, false match, or abstained. This is stricter than merely counting how many links a system draws.

Results

The chart compares correctly recovered project identity across the app boundary.

Exact title      | █████                    14 / 72
Code + alias     | ███████████████████████ 69 / 72

Correct cross-app joins in the 72-pair generated matching task; ambiguous matches were left unresolved.

Title equality is too narrow for this generated workstream: it recognizes a matching project label only where that label survives unchanged. The richer rule recovers most target records because it has two independent forms of continuity evidence. Three targets remain unresolved rather than being joined on weak shared titles.

Neither algorithm produces a false join in these 72 pairs. The methods abstain when the candidate set is ambiguous, leaving difficult matches open rather than guessing. The rule explicitly abstains when the candidate set is ambiguous, and the fixture supplies clean project codes and mostly correct directory entries. False merges become more likely when titles collide, IDs are recycled, or outdated directory rows persist. A useful real-world test must introduce those conditions intentionally.

Design implications

A link should carry its reason. A shared provider identifier is different evidence from matching display text, which is different again from an explicit alias asserted by a project directory. Keeping those sources separate makes it possible to explain why two items were joined and to retract a relation when a source changes.

Abstention should be a first-class outcome. If the same short title refers to unrelated projects, an AI can still be useful by saying that the connection is uncertain and offering the competing records. A wrong automatic merge is harder to notice because the resulting answer may sound coherent while mixing different projects.

There is also a permission dimension. A graph can learn that two records describe the same project while a particular AI is allowed to see only one. The system should not expose the contents of the restricted record merely because the join is confident. Structural continuity and disclosure authorization are separate decisions.

Finally, identity is temporal. Project names, teams, and responsibilities change. A world model should distinguish the same project under a new name from a new project reusing an old name. Our rules do not model time, so they should not be promoted directly into a production identity policy.

Measurement scope

The generated records are short and rigidly structured. Codes and aliases are cleaner than those in most organizations. The matcher does not parse email threads, attachments, calendars, or files; it reads prepared fields. It does not contend with multilingual names, access revocations, deleted records, or cross-account duplicates. The hidden ID is convenient for evaluation and would rarely exist in real cross-app data.

The 72-pair test measures correct joins, false joins and abstentions. Its result isolates the benefit of known project codes and alias entries to deterministic matching.

Which evidence belongs in a link

Increase the collision rate, introduce stale directory entries and changed identifiers, and require the matcher to attach provenance to every join. Measure false-merge rate, correct-link recall, and the fraction of unresolved cases separately. Then simulate permission changes mid-session and verify that inferred graph links cannot be used to retrieve restricted source content.

The experiments/app-continuity/ runner and raw.json record the generated source-target pairs, known answers, selected matches and abstentions.