# Project Name Map: Connect Codenames, Phases, and Customer Shorthand

> Build a project name map that distinguishes codenames, customer shorthand, phases, and unrelated names. Keep the right decisions attached to the right scope.

- URL: https://www.hemory.com/blog/searchable-memory/project-name-map/
- Language: English (en)
- Author: Hemory Team
- Published: 2026-11-04
- Last updated: 2026-11-04
- Summary: A project-name mapping guide for a history spread across codenames, customer shorthand and phases. A completed map connects Atlas with Intake Hub, keeps phase two distinct and excludes another Atlas. Hemory provides captured context for substantiating relationships; the map lives in an existing project reference.
- Tags: project names, conversation search, project history, project aliases

You search for “Intake Hub” and find the recent reviews, but not the discussion where the pilot's access rules were agreed. That meeting happened before the project was renamed; the team was still calling it “Atlas.”

Build a small project name map: the labels people used, their relationship, the scope they cover, and the source that connects them. Unlike a simple list of synonyms, the map also records which names or phases should stay separate.

## Work out what changed: the name or the project

Not every different name is an interchangeable label. The relationship determines which history you can combine.

| Relationship | Example | How to handle it |
|---|---|---|
| Explicit rename | “Atlas is now called Intake Hub; the pilot scope is unchanged.” | Connect the two names and retain the timing |
| Contextual shorthand | “The Cedar upload work,” in a discussion explicitly about the Intake Hub pilot | Use it as a clue in that context, not as a universal synonym |
| New phase or version | “Intake Hub phase two” | Keep shared background but check which decisions apply to this phase |
| Related initiative | A reporting project uses the same customer and team | Connect relevant dependencies without merging the projects |
| Same name, different project | Another “Atlas” appears in an older analytics discussion | Keep it separate unless the record establishes a relationship |

A customer name is especially easy to overuse. One customer can have several projects, and one feature can appear in several products. Neither label alone establishes that two conversations share the same scope.

## Gather names for the map from actual project records

Start with the question you need answered, such as the pilot's access rule. Use the current name and the known subject. If a result refers to the old name, a kickoff, or a related customer discussion, follow that clue.

You can also begin from a project brief, rename announcement, meeting note, or a colleague's remembered term. Treat an uncertain relationship as a candidate until the source supports it.

Search implementation varies. Some tools can connect related wording; others need another term. You do not have to assume that all search is literal, or that AI will recognize every nickname correctly. Trying a confirmed alternative is a practical way to recover missing history.

If the conversations were captured in [Hemory](/features/), use the available topics, timeline, and transcript context to revisit them. In a known discussion, ask which project or phase the speakers mean and whether they explain a name change.

## Example: join the rename, preserve the phase boundary

This fictional map illustrates the method, not a customer history or Hemory output. The available project records contain:

- **September 12, Atlas pilot review:** the authorized project lead accepts staff login for the pilot and rules out guest links.
- **September 26, naming review:** the team renames Atlas to Intake Hub and explicitly keeps the pilot scope unchanged.
- **October 2, Cedar discussion:** the speakers call it “the Cedar upload work” and identify it as the Intake Hub pilot.
- **October 18, planning discussion:** “Intake Hub phase two” refers to a proposed wider rollout; its access model has not been selected.
- **An older analytics record:** another project called Atlas concerns an unrelated reporting tool.

A compact reference would be:

| Name found | Relationship | Useful limit or source |
|---|---|---|
| Atlas, in the September pilot records | Earlier name for Intake Hub | Rename established September 26 |
| Intake Hub | Current project name in these records | Same pilot scope after rename |
| Cedar upload work, in the October 2 discussion | Contextual reference to the pilot | Do not equate every Cedar project with Intake Hub |
| Intake Hub phase two | Proposed wider rollout | Access choice remains open for this phase |
| Atlas, in the older analytics record | Different project | Exclude from this pilot history |

The recovered answer is:

> The Intake Hub pilot requires staff login and excludes guest links, as accepted in the September 12 discussion under the name Atlas. The September 26 rename did not change the pilot scope. Phase two is a separate proposed rollout whose access model was still open in the October 18 discussion.

This preserves continuity without carrying the pilot's rule into a phase where it has not been adopted. It also prevents a same-name analytics discussion from entering the history.

## Let an agent help connect the accessible discussions

Hemory's built-in Q&A can retrieve the project history across captured conversations. If you are preparing the map in a compatible AI agent connected to Hemory, let it identify candidate relationships and draft the map from accessible context. Begin with the names you know; the map can develop from the retrieved discussions.

```text
Find the history of the Intake Hub pilot's access rules in the Hemory
discussions you can access. It was previously called Atlas.
Look for evidence connecting the names. Distinguish confirmed renames,
contextual shorthand, separate phases, and unrelated same-name projects.
Draft the pilot's accepted access rule with its source and scope.
Keep any phase-two proposal separate from an accepted pilot decision.
```

Give the agent a rename note or current project brief separately if it cannot access that source. Check the relationships that materially affect the answer, especially when several projects share a name or customer.

Hemory's contribution is the preserved context around each name. You and the agent can use the discussion itself to connect records, rather than relying only on a manually maintained list of synonyms.

## Place the map beside the current project brief

If the naming confusion recurs, add a short reference to your existing project notes:

```text
Working project name:
Earlier or alternative name:
Relationship and applicable period or scope:
Source establishing the relationship:
Names or phases not to merge:
```

Use the working name in the heading of a new brief and retain the original name in its source reference. That makes the brief readable while preserving the path back to the discussion.

Keep the map beside the brief people already use, with the source that establishes each relationship. Add a discovered name when it affects retrieval or interpretation. The map can remain in that document; it does not require a special Hemory project view.

Do not remove an old name simply because a recent search found nothing. It may still be the only useful clue for an earlier conversation. Keep obsolete names recognizable as historical names rather than current instructions.

If you have one established rename and simply need the older record, use [searching transcripts under old and new names](/blog/searchable-memory/find-transcripts-after-name-changes/). The map helps when several labels, phases or unrelated projects could otherwise be combined.

## FAQ

### Should I search every known name every time?

No. Start with the clue most likely to answer the task. Add other names when coverage is missing or you need a broader project history.

### Can an agent suggest that two names refer to the same project?

Yes, as a candidate relationship based on accessible context. Check the supporting discussion or project record before using that relationship to combine decisions or commitments.

### Does a rename change the status of earlier decisions?

Not by itself. Preserve the accepted scope and look for an actual change to the decision. A new phase or changed project scope may require a different assessment.