When Names Stop Meaning the Same Thing

When Names Stop Meaning the Same Thing

The identity problem in AI systems

Ask an AI system what it knows about "Project Alpha" and the request sounds simple.

Then the system finds this:

project-alpha
example/project-alpha
/home/me/work/project-alpha
Project Alpha wiki page
an old fork also called project-alpha

Now the real question appears.

Are these five observations of the same underlying project? Several related things? Or completely different things that happen to look similar?

A human can often infer the answer from context. An AI system working across repositories, local workspaces, knowledge artifacts and agent outputs can't safely assume that the strings mean the same thing.

That distinction matters because a wrong identity judgment contaminates everything that follows.

If two different projects are merged, decisions and documentation can be attributed to the wrong subject. If one project is split into several imagined entities, context fragments and contradictions multiply. And when the available evidence isn't enough, forcing a confident answer simply hides the uncertainty.

Names are evidence, not identity verdicts

The first useful distinction is between what the system observes and what those observations may refer to.

An observed string, path, URL or artifact can play one or several roles.

It might be:

• an alias
• an identifier inside some namespace
• a locator used to access something
• a representation of a subject
• a related artifact such as a fork or replica

The candidate subject is something different. It is the underlying thing the observation may refer to.

Those two levels are easy to collapse.

Take github.com/example/project-alpha

It can act as a locator. Parts of it can identify a repository within GitHub's namespace. The repository itself can also be a representation of a broader project.

None of those facts alone prove that it is the same subject as /home/me/work/project-alpha

The local path may point to a clone of that repository. It may point to another copy with a different remote. It may even be an unrelated directory with the same convenient name.

The label is evidence. The locator is evidence. The repository history may be evidence.

The identity judgment comes after that evidence has been evaluated.

Identity isn't a yes-or-no question

Another useful correction is to stop treating identity as only same or different

For a bounded identity question, the available evidence may support several outcomes:

• same entity
• distinct entity
• related but distinct
• possibly the same entity
• unresolved identity

That last outcome is especially important.

UNRESOLVED_IDENTITY isn't a system failure. It can be the most accurate result available.

Suppose two directories share the same name but there is no remote metadata, no shared history and no explicit relationship between them. The system hasn't proved that they are the same thing. It hasn't proved that they are different either.

The correct next step is to preserve what is unresolved and identify which additional evidence would discriminate between the alternatives.

That is much safer than silently inventing certainty.

A small worked example

Consider the five observations again:

A. project-alpha
B. github.com/example/project-alpha
C. /home/me/work/project-alpha
D. Project Alpha wiki page
E. an old fork also called project-alpha

A may simply be a label or alias. By itself it doesn't establish a subject.

B is a locator to a repository surface and contains provider-scoped identifying information. That still doesn't tell us whether the repository is the complete project or one representation of something broader.

C is a local locator. To connect it to B useful evidence might include its configured remote, repository history or another explicit relationship.

D is a representation. A wiki page can describe a project without being the project itself.

E can be historically related to another repository while remaining distinct from it. A fork, replica and derivative are not one universal relation type, so the exact relationship still has to be established from evidence.

The important move is not to classify each observation once and be done with it.

For each one, ask:

• What observable role or roles does this surface have?
• What candidate subject might it refer to?
• What evidence supports that interpretation?
• What identity outcome does the evidence justify?
• What additional evidence would discriminate the remaining alternatives?
• What uncertainty is still left?

That sequence is small enough to use manually and explicit enough to turn into a repeatable AI workflow.

One title can appear across several related surfaces

This also appears in much less artificial examples.

Take From Blueprint to Application

The title is associated with a book, but it also appears across a wider body of work around that book. There is a manuscript project and repository used to develop the book itself. There is also a separate public showcase repository, a public web representation and bounded interactive demos connected to particular concepts.

Those surfaces are clearly related, and the shared title helps a person orient themselves across them. But the shared title doesn't prove that the book, the wider project and every artifact around them are one interchangeable subject.

A public repository may represent part of the work. A demo may represent one concept from it. A manuscript repository may belong to the process of producing the book.

The useful question is therefore not simply "which one is From Blueprint to Application?"

It is:

What subject does this observation appear to refer to, what role does the surface have, and what evidence supports that relationship?

Questions about which representation is current or authoritative for a particular claim come later. Identity has to be handled first.

Why this matters for AI systems

As AI systems become responsible for working across more heterogeneous sources, they encounter the same semantic problem repeatedly.

A repository name, filesystem path, project card, documentation page and agent-produced reference may all appear to point toward the same thing.

Sometimes they do.

Sometimes they describe different representations of one subject.

Sometimes they are related but distinct.

Sometimes the system simply doesn't have enough evidence yet.

I've been formalizing this class of problem in work on a Semantic Orientation & Relationship Resolver, or SORR. One of the deliberately conservative boundaries is simple:

reference != semantic identity verdict

A name, path, URL or pointer can contribute evidence. It doesn't settle identity by itself.

That principle is useful far beyond one architecture or project. Any AI system that combines context from multiple surfaces eventually has to decide whether the things it has found should be merged, kept separate, related or left unresolved.

A practical identity worksheet

The same reasoning can be reduced to a small reusable structure:

Observation
Observed role(s)
Candidate subject(s)
Supporting evidence
Identity outcome
Residual / discriminating evidence needed

For the identity outcome, keep the full bounded set available:

SAME_ENTITY
DISTINCT_ENTITY
RELATED_BUT_DISTINCT
POSSIBLE_SAME_ENTITY
UNRESOLVED_IDENTITY

This avoids two common shortcuts.

The first is treating similar labels as sufficient evidence for sameness.

The second is treating missing proof as proof of difference.

Both shortcuts throw information away.

Before asking what the AI knows, make sure it knows what you mean

It is tempting to treat identity as housekeeping that happens before the interesting AI work begins.

In practice, it is part of the control surface.

If a system can't distinguish a subject from its names, locators and representations, later reasoning may be internally coherent and still be about the wrong thing.

A useful default is therefore simple:

Before asking an AI what it knows about something, establish what the observed surfaces are, what subject they may refer to, what evidence supports the identity judgment and what remains unresolved.

The next problem begins once those relationships are clearer: a representation may refer to the right subject and still not have authority for every claim about it.

Short glossary

Subject
The underlying thing being reasoned about. A subject is not the same as one of its representations.

Identity question / identity judgment
The bounded evaluation of whether observations refer to the same entity, distinct entities, related-but-distinct entities, a possible match or an unresolved identity.

Alias
An alternative name associated with a subject. An alias is evidence about identity, not proof by itself.

Identifier
A value intended to distinguish or refer to something within a particular namespace or system. An identifier is not automatically a universal identity.

Locator
Information used to find or access a surface. A locator is not an identity verdict.

Representation
A distinct artifact or surface that describes, exposes or represents a subject. The representation is not automatically the subject itself.

Replica or fork
Examples of artifacts that can be related to another artifact while remaining distinct. Their exact semantic relationship has to be established rather than assumed.