One of the hardest questions in any information system is also one of the simplest to ask:

When are two things the same thing?

A person changes their name. Is it the same person?

A school moves to another building. Is it the same school?

A document is copied perfectly. Are there now two documents or one document in two places?

A web page keeps the same address but its contents are rewritten. Is it the same page?

A company changes its name, ownership and strategy while retaining legal continuity. What exactly stayed the same?

A dataset is corrected and republished. Is the corrected dataset the same dataset, a new version or an entirely new object?

Two database rows describe the same student but contain different spellings of the name. Are they duplicates, two people, or one person represented twice?

These are not word games. They are operational problems in education, science, law, archives, publishing, software, medicine, finance, journalism, search and artificial intelligence.

The previous article, What Kind of Thing Is This? | The Hidden Grammar of Reality, argued that good reasoning begins by identifying what kind of thing we are dealing with. The next problem follows immediately: once we know the type, how do we know whether two references point to the same thing?

Featured Snippet: The Root Definition

Identity resolution is the process of deciding whether two or more references, records, names, observations or representations refer to the same underlying entity, event, artifact, claim or continuing object.

The central discipline is to distinguish same entity from same type, same content, same name, same role, same version, copy, successor, alias, duplicate record and mere resemblance.

The shortest rule is this:

Similarity can suggest identity. Continuity and provenance are what make identity defensible.

The Simple Answer

Two things are the same thing when the identity rules appropriate to that kind of thing say that one continuing referent is being described through multiple observations, names, states, records or moments.

Two things may look identical and still be different objects. Two things may look very different and still be the same continuing entity.

• Two identical printed books can be different physical copies.
• One person at age five and age fifty looks different but is normally treated as the same person.
• A renamed institution can remain the same legal organisation.
• A copied file can have identical contents but be a distinct file instance.
• A revised document can remain the same work while becoming a different version.
• Two database rows can be different records that refer to one real-world entity.
• A replacement bridge can occupy the same location and serve the same role without being the same physical structure.

Identity is therefore not one universal test. It is a structured judgement about continuity.

The First Great Distinction: Referent and Representation

Suppose a school database contains a row for a student.

The student is one thing. The row is another.

The row may contain the student’s name, class, identification number and contact information. It represents the student. It is not the student.

If the same student appears in two systems, there may be:

• one student;
• two records;
• two identifiers;
• several aliases or spelling variants;
• different snapshots taken at different times.

Confusing record identity with entity identity causes duplicate profiles, broken histories, false counts and contradictory conclusions.

This is the first principle:

Do not ask whether two records are identical before asking whether they refer to the same thing.

Eight Different Meanings of “The Same”

Ordinary language uses “same” for several different relationships. Separating them makes reasoning much cleaner.

1. Same referent

Two names or records point to one underlying thing.

“The morning star” and “the evening star” were historically different descriptions of what was eventually understood to be the same planet, Venus. The expressions differ; the referent is one astronomical body.

2. Same type

Two things belong to the same category but are not the same instance.

Two red pens may be the same model. They are still two physical pens.

3. Same content

Two artifacts carry identical information.

Two files can contain exactly the same sequence of bytes while existing as separate file instances in different directories or devices.

4. Same version

Two copies belong to one defined release or revision.

Two students may each hold a copy of the same edition of a textbook. The physical books differ; the version may be the same.

5. Same role

Different entities occupy the same functional position at different times.

Two people can successively occupy the same office. The role is continuous; the office-holders are different people.

6. Same origin

Two objects descend from a common source.

Two document versions may both descend from version 1.0. They share ancestry without being identical.

7. Same function

Two different objects perform the same task.

A replacement sensor can perform the same function as the failed sensor. Functional equivalence is not physical identity.

8. Same history

This usually means continuity through a single causal path: one thing changed over time rather than another thing merely resembling it.

History is often the strongest clue to identity.

Identity Is Not Resemblance

Resemblance answers the question “How similar are these?” Identity answers the question “Are these references to one continuing thing?”

Identical twins can resemble one another strongly while remaining two people. Two manufactured components can be visually indistinguishable while carrying different serial numbers and service histories. Two editions of a book can look nearly identical while containing different corrections. Two organisations can have similar names while being legally separate.

Conversely, one entity can become dissimilar to its earlier state. A child becomes an adult. A tree grows. A building is renovated. A company restructures. A software project evolves.

Therefore:

Resemblance is evidence about properties. Identity is a claim about continuity.

Names Are Handles, Not Identity

Names help humans refer to things. They do not guarantee uniqueness.

One person may use a legal name, nickname, former name, initials, transliteration or professional name. Several people may share exactly the same name. Organisations rebrand. Places acquire historical and contemporary names. Books appear under translated titles. Product names are reused across generations.

A reliable identity system therefore treats a name as one attribute among several.

• Name: what is it called?
• Identifier: how is it distinguished inside a particular system?
• Referent: what real thing does the identifier point to?
• Alias: what other names point to the same referent?
• Validity: when was each name used?

A name change should normally update a label, not erase the history of the entity.

Identifiers Are Powerful, but They Are Still Records

Identifiers exist because names are ambiguous.

Examples include student numbers, accession numbers, ISBNs, DOIs, database primary keys, serial numbers, account numbers, legal registration numbers and internal record IDs.

But an identifier is not magical. It is assigned by a system under rules.

Questions remain:

• Which authority assigned the identifier?
• What kind of thing is it intended to identify?
• Can identifiers be reused?
• Can one entity have several identifiers?
• Can an identifier survive a merger or renaming?
• Does the identifier represent the work, edition, copy, account, person or record?

The same identifier format can encode different identity rules in different systems.

The deeper principle is:

An identifier is evidence of how a system distinguishes things. It is not a substitute for understanding what the system is distinguishing.

Aliases: Different Names, One Referent

An alias is an alternative label or identifier that refers to the same underlying entity in a relevant context.

Aliases arise through:

• nicknames;
• abbreviations;
• initials;
• translation;
• transliteration;
• historical names;
• marriage or legal name changes;
• pen names;
• brand names;
• former institutional names;
• database-specific identifiers.

Alias handling matters because a search system that treats every spelling as a separate entity fragments knowledge.

But alias merging can also be dangerous. Two people may share initials. Two companies may use similar abbreviations. A place name may refer to multiple locations.

The right question is not “Do the strings match?” It is “Does the evidence support one referent?”

Duplicate Record Is Not Duplicate Entity

A duplicate record occurs when a system stores more than one representation of what may be the same underlying referent.

Imagine two student records:

• Tan Mei Lin — Class 3A — parent phone ending 7721
• Mei-Lin Tan — 3A — parent phone ending 7721

The shared class and phone number are evidence that the records may refer to one student. The slightly different name is not enough to prove that they are different people.

Now imagine:

• John Lee — Class 4B
• John Lee — Class 4C

The matching name is not enough to prove identity.

This produces two classic errors.

False merge

Two genuinely different entities are incorrectly collapsed into one.

False split

One entity is incorrectly represented as several unrelated entities.

Identity resolution is the discipline of reducing both errors.

Copies: Same Information, Different Instance

A copy is created by reproducing some relevant structure or information from another object.

A photocopy reproduces a document’s visible content. A digital copy may reproduce a file’s bytes exactly. A cast reproduces the form of an object. A printed edition reproduces a text. A backup reproduces stored information at a particular moment.

Copy relationships therefore have at least three participants:

1. a source;
2. a copying process;
3. a resulting copy.

The source and copy may contain the same information while remaining distinct artifacts.

That distinction matters because the copies can later diverge. One can be annotated. One can be corrupted. One can be deleted. One can be authenticated while another lacks provenance.

Content equality at time A does not guarantee identity or equality at time B.

What Is an Original?

“Original” can mean several things.

• the first physical artifact;
• the earliest surviving artifact;
• the authoritative version;
• the creator’s source file;
• the master recording;
• the signed document;
• the first publication;
• the work from which later copies derive.

These can come apart.

A revised file may be more authoritative than the earliest draft. A museum reproduction may visually match an original object while lacking its historical continuity. A certified digital record may be institutionally authoritative even though many identical digital copies exist.

Therefore “original” should be typed:

• original by chronology;
• original by authorship;
• original by authority;
• original by physical continuity;
• original by provenance.

Version: One Continuing Work, Different States

A version is a defined state of an artifact, dataset, document, software system or other revisable object.

Versioning solves a problem that ordinary identity language cannot: how can something remain recognisably one project or work while its content changes?

Suppose a guide is published as:

• Version 1.0 — initial release
• Version 1.1 — corrected examples
• Version 1.2 — updated references
• Version 2.0 — major structural revision

These may all belong to one continuing work while being different versions.

Without versioning, a later reader can accidentally attribute current content to an earlier date or assume two contradictory passages existed simultaneously.

Version identity therefore carries time.

Snapshot Is Not Version

A snapshot records the state of something at a particular moment. A version is usually an intentionally distinguished revision.

A live database may change continuously without assigning a new formal version number after every transaction. A nightly backup can preserve a snapshot. A web archive can preserve a snapshot of a page. A screenshot preserves one visual state.

The distinctions are useful:

• object — the continuing thing;
• state — how it is at a moment;
• snapshot — a record of that state;
• version — a recognised revision;
• copy — another artifact derived from some state or version.

Current Is Not the Same as Canonical

The newest version is not automatically the authoritative version for every purpose.

A draft may be newer than the approved edition. A proposed law may be newer than the law currently in force. A beta software build may be newer than the stable release. A working spreadsheet may be newer than the audited financial statement.

Therefore systems should distinguish:

• latest;
• published;
• approved;
• effective;
• canonical;
• superseded;
• archived;
• draft.

Time and authority are separate dimensions.

Mutation or Replacement?

Identity becomes difficult when an object changes substantially.

If a bicycle receives a new tyre, we normally say it is the same bicycle. Replace the chain, saddle and brakes, and we still usually preserve identity. At what point would replacement parts create a different bicycle?

There is no universal percentage.

Different domains use different continuity rules:

• physical continuity;
• legal continuity;
• causal continuity;
• organisational continuity;
• functional continuity;
• authorship continuity;
• identifier continuity;
• institutional recognition.

A repaired object may remain the same object because the repair occurs within one continuous history. A newly manufactured replica can be more physically similar to the object’s original state while still being a different object.

Continuity often outweighs resemblance.

The Ship of Theseus Problem Is Really a Type Problem

The famous Ship of Theseus thought experiment asks whether a ship remains the same ship after its parts are gradually replaced.

The puzzle feels impossible when “same” is treated as one relation.

It becomes clearer when several relations are separated:

• same legal vessel;
• same continuing operational vessel;
• same collection of original material;
• same design;
• same name;
• same historical lineage.

Different answers can be correct because different identity criteria are being applied.

The lesson is not that identity is meaningless. It is that identity claims need a declared criterion.

Fork: One History Becomes Two

A fork occurs when two continuing objects share a common history and then diverge.

This is common in software, documents, datasets and collaborative projects.

Before the fork, both later branches share ancestry. After the fork, changes on one branch do not automatically belong to the other.

Fork-aware reasoning preserves:

• common ancestor;
• branch point;
• branch identity;
• independent later versions.

Without this structure, a system may incorrectly mix facts from two descendants as if they still described one object.

Merge: Two Histories Become One Organisation or Artifact

A merge occurs when two previously distinct histories are combined under a new or continuing structure.

Companies merge. Datasets merge. Software branches merge. Collections merge. School programmes can be consolidated.

A merge does not erase the predecessor identities.

The resulting entity may be:

• a continuation of one predecessor;
• a new successor;
• a legal combination retaining one identifier;
• a new dataset containing records from several sources.

The correct representation depends on the domain.

The essential information is the relationship:

A and B existed separately before date T; C exists after date T and derives from both.

Split: One Organisation or Dataset Becomes Several

A split is the reverse pattern: one predecessor gives rise to multiple successors.

This occurs when organisations divide, datasets are partitioned, administrative regions change, software projects branch or a collection is distributed across institutions.

After a split, the descendants may each inherit some properties, records, responsibilities or identity claims from the predecessor. They are not automatically the same entity as one another.

A history-aware system preserves succession instead of forcing a single timeless identifier across incompatible structures.

Successor Is Not Alias

An alias says: different label, same referent.

A successor says: related continuity, but not necessarily the same referent.

A new organisation may inherit the responsibilities, staff, archives or property of an earlier organisation. That does not automatically make it numerically identical to the predecessor.

Successor relationships therefore need explicit types:

• legal successor;
• institutional successor;
• functional successor;
• replacement;
• renamed continuation;
• merged successor.

The difference matters whenever rights, obligations, statistics or historical responsibility depend on continuity.

Identity Through Time

Identity is inseparable from time.

At time T1, an entity has one state. At time T2, it may have changed properties while retaining identity.

We can represent this as:

• Entity E exists across interval T1–T5.
• At T1, E has property A.
• At T3, property A changes.
• At T4, E receives a new name.
• At T5, E ceases to exist or transforms into a successor.

Without time, the database may report both old and new properties as simultaneously true.

Identity resolution is therefore partly the construction of a coherent timeline.

A Person: Strong Continuity, Many Changing Attributes

Human identity illustrates why attributes cannot define identity by themselves.

A person can change:

• name;
• address;
• job;
• appearance;
• citizenship;
• phone number;
• school;
• email address;
• skills;
• beliefs.

None of these changes normally creates a new person.

For identity resolution, some attributes are more discriminating than others, but even strong identifiers must be interpreted within their issuing system and time period.

This suggests a broader principle:

Attributes describe an entity. They should not quietly replace the entity.

An Organisation: Legal, Institutional and Functional Identity

Organisations are harder because several continuity systems overlap.

An organisation can change:

• name;
• leadership;
• staff;
• address;
• ownership;
• mission;
• legal form;
• brand;
• products.

Whether it remains “the same organisation” may depend on the question.

A legal database may care about registration continuity. A historian may care about institutional lineage. A customer may care about brand continuity. An employee may care about employer-of-record continuity.

Therefore the phrase “same company” can hide several identity criteria.

A Place: Geography, Name and Administrative Boundary

Places are also versioned through time.

A neighbourhood can retain a name while its boundaries shift. A city can annex land. A road can be renamed. A school campus can move. A building can be demolished and replaced at the same address.

“Same place” may mean:

• same coordinates;
• same address;
• same administrative unit;
• same named locality;
• same physical structure;
• same functional site.

Geospatial identity therefore needs both geometry and time.

A Document: Work, Edition, Version, Copy and File

Documents are especially rich identity structures because several levels coexist.

• Work: the intellectual or creative work.
• Edition: a particular publication form.
• Version: a defined revision state.
• Copy: one reproduced instance.
• File: one digital object carrying content.
• Scan: a representation produced from a physical source.
• Extract: a selected portion.
• Translation: a derived linguistic representation.

If a quotation differs between two editions, saying “the book says” may be insufficient. Which edition? Which page? Which translation? Which version?

Document identity becomes stronger when the chain from work to version to copy to quotation is visible.

A Dataset: Same Subject, Different Data Object

Datasets are often treated as timeless containers. In practice, they have histories.

A dataset can change because:

• new rows are added;
• errors are corrected;
• definitions change;
• columns are renamed;
• records are deduplicated;
• missing values are filled;
• units change;
• collection methods change;
• historical records are revised.

Two files may therefore share a dataset name while representing different data states.

A reliable analysis should be able to answer:

• Which dataset?
• Which version or snapshot?
• Downloaded when?
• From which source?
• Under which schema?
• Using which definitions?

Reproducibility is partly an identity problem.

Software: Package, Release, Build, Installation and Process

Software exposes multiple identity levels clearly.

• a software project;
• a source-code repository;
• a branch;
• a commit;
• a release;
• a compiled build;
• an installed copy;
• a running process.

All may be casually referred to by one product name, yet they are not interchangeable.

A bug may exist in one release but not another. A configuration may affect one installation but not the software project generally. A process can crash without the installed program ceasing to exist.

Good technical reasoning depends on choosing the correct identity level.

A Web Page: URL Is Not Always Page Identity

A URL is a powerful locator, but the relationship between URL and content is not always one-to-one through time.

The same URL can serve revised content. The same article can appear at several URLs. A redirect can move a resource. A syndicated copy can reproduce content elsewhere. A page can be deleted while cached or archived copies remain.

Therefore web identity may require:

• URL;
• canonical URL;
• publication date;
• revision date;
• content hash;
• title;
• publisher;
• archived snapshot time.

“I found it at this URL” is useful provenance. It is not complete version control.

An Image: Scene, Capture, File and Edit

Images also contain several identity layers.

• the real scene;
• the capture event;
• the original image data;
• the exported file;
• a resized copy;
• a cropped version;
• an edited derivative;
• a screenshot of the image.

Two image files can depict the same event without being the same image. Two files can be byte-identical copies of one capture. An edited crop can derive from an original while no longer containing the complete visual evidence.

Media verification therefore depends on provenance relationships, not only visual resemblance.

An Event: One Occurrence, Many Descriptions

Events also require identity resolution.

Two reports may use different names for the same protest, storm, meeting, battle, examination or accident. Conversely, recurring events can share a name while being distinct annual occurrences.

Event identity may depend on:

• time interval;
• location;
• participants;
• causal sequence;
• institutional designation;
• event series membership.

“The 2025 conference” and “the 2026 conference” may be instances of the same event series but are not the same event.

A Claim: Same Sentence, Different Claim Context

Claims have identities too.

The sentence “the project is complete” means different things when uttered in January and in December. The words are identical; the time-indexed proposition may differ.

Similarly, two people can independently make the same claim. That does not make their statements the same evidential source.

Claim identity can therefore include:

• propositional content;
• speaker or source;
• time;
• scope;
• conditions;
• evidence basis;
• publication context.

This prevents a repeated claim from being mistaken for independent confirmation.

Independent Sources Must Actually Be Independent

Suppose five websites repeat the same statement.

Do we have five sources?

Not necessarily.

If all five copied one press release, there may be five publications but only one underlying source chain.

This is an identity problem disguised as source counting.

A strong verification process asks:

• Did these sources observe independently?
• Did they use the same database?
• Did one cite another?
• Do they reproduce identical wording or errors?
• Is there a shared upstream document?

Five copies of one claim are not five independent pieces of evidence.

Provenance: The History of How This Came to Be

Provenance records where an artifact, record, dataset, claim or representation came from and how it changed.

It answers questions such as:

• Who created this?
• When?
• From which source?
• Was it copied?
• Was it transformed?
• Was it merged with other material?
• Which version was used?
• Who edited it?
• What is the chain of custody?

Provenance is crucial because identity is historical. Two objects may look identical now but have different origins. Two records may look different now but belong to one continuous lineage.

A good provenance record turns “this looks like the same thing” into “we can trace how this derives from that”.

Chain of Custody Is Identity Under Pressure

Chain of custody matters whenever the identity and integrity of an artifact must survive transfer.

Evidence, manuscripts, laboratory samples, artworks, legal documents and digital records may pass through many hands or systems.

The chain asks:

• Is this the same item that was collected?
• Who possessed it at each stage?
• Was it altered?
• Was the container opened?
• Could substitution have occurred?
• Can every transfer be accounted for?

Identity is not merely asserted at the end. It is maintained through a documented history.

Content Hashes: Useful for Equality, Not Complete Identity

Digital systems often use cryptographic hashes or checksums to test whether content has changed.

If two files have matching strong hashes, that is powerful evidence that their byte content matches.

But content equality is not the whole identity story.

Two files with identical bytes can exist as separate copies. Two database exports can be identical while coming from different systems. Two signed documents could contain identical text but differ in signature status or provenance.

Hash answers:

Is the encoded content the same?

It does not, by itself, answer:

Is this the same historical object, same authority, same source or same legal artifact?

Identity Confidence Should Be Explicit

Not every identity decision is certain.

A useful system can preserve states such as:

• confirmed same entity;
• strongly likely same entity;
• possible match;
• unresolved;
• likely different;
• confirmed different.

This is better than forcing every pair into an immediate yes-or-no merge.

Premature merging can be destructive because once histories are combined, later facts may become difficult to untangle.

When uncertainty is material, preserve it.

The Identity Evidence Ladder

No universal ranking works for every domain, but evidence commonly becomes stronger as we move from superficial resemblance toward documented continuity.

1. String similarity: names or labels look alike.
2. Attribute overlap: several properties match.
3. Context overlap: time, place and relationships align.
4. Unique identifier match: a trusted system assigns the same identifier.
5. Direct provenance: one record is explicitly linked to the other.
6. Documented continuity: change, transfer or renaming is recorded through time.

The strongest evidence depends on the kind of entity. A serial number can be strong for a manufactured device. A registration history can be strong for a company. A manuscript’s custody record can be strong for an artifact.

Identity Rules Are Domain-Specific

The phrase “same thing” is incomplete until we know what kind of thing we are talking about.

Domain object	Common identity evidence	Common confusion
Person	continuity, trusted identifiers, date/place relationships	name mistaken for identity
Organisation	legal or institutional continuity	rebrand mistaken for new entity
Physical artifact	provenance, custody, serialisation	replica mistaken for original
Document	work/edition/version/copy relationships	all copies treated as one object
Dataset	source, schema, snapshot, version	same filename treated as same data
Software	project, branch, commit, release, build	product name treated as exact version
Web page	URL plus time, revision and publisher	same URL treated as unchanged content
Event	time, place, participants, sequence	event series mistaken for one event
Claim	content, source, time, scope	repetition mistaken for independent evidence

The Identity Resolution Pipeline

A practical system can resolve identity through stages.

Step 1: Identify the type

Person? Organisation? Document? Event? Dataset? Web page? Claim? Physical object?

Identity criteria depend on type.

Step 2: Preserve each source record

Do not destroy source distinctions before matching. Keep the original record, source and retrieval context.

Step 3: Normalise labels carefully

Handle obvious formatting differences while preserving the original value. Case, punctuation, spacing and transliteration may affect matching but should not erase provenance.

Step 4: Compare discriminating attributes

Use identifiers, dates, locations, relationships, authors, serial numbers or other relevant fields.

Step 5: Check temporal compatibility

Can these records plausibly refer to the same entity at different times? Are the states sequential or impossible to reconcile?

Step 6: Check relationships

Do the surrounding people, organisations, places, events or documents line up?

Step 7: Trace provenance

Is one record a copy, revision or derivative of another? Is there a known renaming, transfer, fork, merge or succession event?

Step 8: Assign a relationship, not only a match score

• same entity;
• alias of;
• copy of;
• version of;
• derived from;
• successor to;
• part of;
• possible match;
• different entity.

Different relationships preserve more information than a single “duplicate” flag.

Step 9: Record confidence and evidence

A future reviewer should be able to understand why the merge or separation was made.

Step 10: Keep reversibility where practical

When identity is uncertain, preserve the ability to undo a mistaken merge.

Why This Matters for Search

Search is full of identity problems.

A user searches for a person using an old name. A book appears under different editions. A company has changed its brand. A scientific paper is mirrored in several repositories. A news story is syndicated across many publishers.

A good search system wants two opposing abilities:

• merge aliases so relevant results are not missed;
• preserve distinct entities so unrelated results are not collapsed.

This is the balance between recall and identity precision.

Why This Matters for Artificial Intelligence

An AI system can retrieve excellent sources and still fail if it merges the wrong things.

Typical failures include:

• combining facts from two people with the same name;
• treating a predecessor organisation as identical to its successor;
• mixing different versions of a policy;
• counting syndicated copies as independent evidence;
• reporting a draft as if it were the approved version;
• joining old and current states without dates;
• treating a copied article as a new independent source;
• confusing a replica with the original artifact.

Identity resolution therefore comes before synthesis.

An AI should ideally be able to say:

These two records probably refer to the same organisation, but one uses its former name. This document is a later revision of the earlier publication. These five webpages repeat one upstream report and should not be treated as five independent confirmations.

That is not merely data cleaning. It is reasoning.

Why This Matters for AI Memory

Memory becomes unreliable when new facts are attached to the wrong entity or when one entity is fragmented across multiple profiles.

A robust memory structure should distinguish:

• entity identity;
• aliases;
• time-bounded properties;
• source records;
• confidence;
• versioned claims;
• relationships to predecessors, successors, copies and derivatives.

Otherwise a system may “remember” contradictory facts that were actually true at different times or belonged to different entities.

Why This Matters for Knowledge Graphs

A knowledge graph becomes misleading when one node is used for several different things merely because they share a label.

Conversely, it becomes fragmented when every record receives a separate node even when several records refer to the same entity.

Useful relations include:

• same-as;
• alias-of;
• version-of;
• copy-of;
• derived-from;
• supersedes;
• successor-to;
• part-of;
• member-of;
• possibly-same-as.

The last relation is important. Uncertainty should not be hidden inside a forced merge.

Why This Matters for Libraries and Archives

Libraries and archives have long dealt with identity at multiple levels.

A work can have multiple editions. An edition can have multiple physical copies. A manuscript can have scans. A scan can have derivatives. A person can appear under several names. A collection can move between institutions.

Cataloguing is therefore partly the art of saying which differences matter.

Good archival description lets the reader move from a record to the artifact, from the artifact to its provenance and from one form of a work to related forms without pretending they are all one object.

Why This Matters for History

Historical identity is fragile because names, borders, institutions and roles change.

A city can change political jurisdiction. A regiment can be reorganised. A company can be renamed. A document can be copied. A person can be referred to by title rather than name. A later historian can quote a translation rather than the original text.

History therefore depends on lineage:

• who;
• which institution;
• which document;
• which version;
• which place under which boundary;
• which event in which sequence.

Anachronism is often a form of identity failure through time.

Why This Matters for Science

Science depends on identifying samples, specimens, datasets, protocols, instruments and publications correctly.

If specimen identity is lost, observations can be attached to the wrong sample. If dataset versions are mixed, results may not be reproducible. If a corrected paper and its earlier version are treated as interchangeable, an outdated claim may persist.

Scientific provenance is therefore not paperwork after the discovery. It is part of the evidence structure.

Why This Matters for Education

Education contains many identity layers that are easy to confuse.

• A student is not a score.
• A course is not one lesson.
• A syllabus is not one textbook.
• A topic is not one worksheet.
• A question type is not one question instance.
• A mistake pattern is not the student’s identity.
• A revised curriculum is not automatically identical to its predecessor.

For teaching, identity awareness protects both accuracy and dignity. We can say “this student made the same algebraic error in three recent tasks” without converting a recurring performance pattern into “this student is bad at algebra”.

Pattern identity belongs to the work. Personal identity remains larger than the pattern.

Why This Matters for Journalism

Journalism frequently encounters renamed organisations, recycled photographs, updated webpages, repeated press releases and evolving events.

A journalist or reader needs to distinguish:

• original reporting from syndicated copies;
• current statement from archived statement;
• same incident from similar incident;
• same person from namesake;
• original image from later repost;
• official update from earlier preliminary report.

Many misinformation chains exploit identity confusion: an old image is attached to a new event, a quote is attributed to the wrong person, or repeated copies create the illusion of independent confirmation.

Why This Matters for Law and Regulation

Legal reasoning often depends on exact identity and version.

• Which legal entity signed the contract?
• Which version of the regulation was in force?
• Is this organisation the legal successor?
• Is this the same parcel of land after boundary changes?
• Is this copy of the document authentic?
• Did the amendment supersede the earlier clause?

The general lesson is not to answer legal questions from labels alone. Identity, authority, date and jurisdiction must align.

The Error of Name Collapse

Name collapse occurs when matching labels are treated as proof of matching identity.

It creates false merges.

The repair is to add discriminating context: identifier, time, place, role, relationships and provenance.

The Error of Alias Fragmentation

Alias fragmentation occurs when one entity is scattered across many labels and treated as unrelated.

It creates false splits.

The repair is to preserve alias relationships and date ranges without deleting original labels.

The Error of Version Collapse

Version collapse occurs when several revisions are treated as one timeless document.

It can make a statement appear to have existed before it was added or make an outdated statement appear current.

The repair is simple: record version and validity time.

The Error of Copy Inflation

Copy inflation occurs when many copies are counted as many independent sources, events or facts.

One announcement copied to fifty websites is still one upstream announcement unless independent verification is added.

The repair is source lineage.

The Error of Successor Collapse

Successor collapse occurs when a predecessor and successor are treated as one timeless entity without checking the nature of the transition.

This can distort historical statistics, legal obligations and institutional responsibility.

The repair is an explicit succession relation with dates.

The Error of Replica Substitution

Replica substitution occurs when a highly similar reproduction is treated as the original because appearance is mistaken for provenance.

The repair is to ask how this artifact came to be here and how its chain connects to the claimed original.

The Error of Present-State Identity

Present-state identity occurs when an entity is defined entirely by its current attributes.

This makes normal change look like entity replacement.

The repair is longitudinal identity: the entity continues while states change.

Worked Example: Two Student Records

Record A:

• Name: Lim Jia Hui
• Class: Secondary 2A
• Birth month: March
• Parent contact: ending 4482

Record B:

• Name: Jia Hui Lim
• Class: Sec 2A
• Birth month: March
• Parent contact: ending 4482

The names differ in order. The class notation differs. Several discriminating attributes align.

A reasonable identity-resolution process may classify these as a strong candidate match and then confirm using a trusted internal identifier.

Crucially, the system should preserve both source records even after linking them to one student entity. The record history may matter later.

Worked Example: One Article at Three URLs

Suppose an article is published on Site A. Site B republishes it with permission. Site C scrapes the text.

There are three webpages. Their text may be nearly identical. They may not represent three independent reports.

A strong system models:

• three page artifacts;
• one or more content copies;
• one upstream authorship source;
• different publication events;
• possibly different authority relationships.

Counting pages and counting independent sources are different operations.

Worked Example: The Same Policy?

A ministry publishes Policy 2024. It is amended in 2025 and replaced in 2026.

Someone asks, “What does the policy say?”

The answer requires identity resolution:

• which policy family;
• which version;
• effective on what date;
• whether an amendment modified part of the earlier text;
• whether the 2026 document superseded the earlier policy entirely.

A search result showing the 2024 PDF is not enough to answer a current question safely.

Worked Example: Renamed Organisation

An organisation changes from Name A to Name B.

Possible interpretations include:

• simple rebrand: same legal entity, new name;
• acquisition: old entity absorbed into another;
• new company: brand reused by a different legal entity;
• merger: new successor formed from several predecessors.

The visual branding may look continuous in every case.

Only provenance and legal/institutional history tell us which identity relationship is correct.

Worked Example: Corrected Dataset

A researcher downloads Data.csv in January. The publisher corrects several records in March but keeps the same filename.

Another researcher downloads Data.csv in April.

Same filename. Same publisher. Same nominal dataset.

Different data state.

Reproducibility requires more than the filename. It needs retrieval time, version information or a content fingerprint sufficient to distinguish the snapshots.

Worked Example: Photograph Reused for Another Event

A photograph from Event A is reposted years later with a caption claiming it shows Event B.

The file may be the same image or a derivative. The depicted scene remains the original capture event. The new caption introduces a false event-identity claim.

The identity task is not only “Have I seen this image before?” It is:

• which capture event produced it;
• which file lineage is this;
• what does the current post claim;
• does that claim match the image’s provenance?

A Compact Identity Grammar

A public, domain-neutral identity record can be thought of as containing fields such as:

• entity type — person, organisation, artifact, document, dataset, event, claim;
• canonical identifier — the preferred stable handle within a system;
• aliases — alternative names or identifiers;
• validity interval — when the entity or label applies;
• source records — preserved representations from each source;
• provenance — origin and transformation history;
• relationships — copy-of, version-of, successor-to, derived-from;
• identity confidence — strength of the match;
• evidence — why the resolution was made;
• revision history — how the identity decision changed.

The exact schema will differ across domains. The important principle is to preserve enough structure that identity decisions can be inspected rather than guessed.

A Practical Identity Decision Tree

1. What kind of thing is each candidate? If the types differ, determine whether one is a representation of the other.
2. Do they share only a name, or also discriminating attributes?
3. Are their time intervals compatible?
4. Do trusted identifiers agree?
5. Can provenance connect one to the other?
6. Is one explicitly a copy, version, alias, successor or derivative?
7. Would merging destroy meaningful differences?
8. Would keeping them separate fragment one coherent history?
9. How confident is the conclusion?
10. Can the evidence be revisited later?

The Identity Table

Relationship	Meaning	Do not confuse with
same entity	two references, one continuing referent	similar entity
alias-of	different label for same referent	successor
copy-of	new instance reproduced from source	same physical artifact
version-of	different revision state of continuing work	unrelated document
snapshot-of	record of state at a time	timeless object
derived-from	created through transformation of source	independent source
successor-to	later entity inherits some continuity	mere alias
fork-of	branch sharing common ancestry	same later history
merge-of	result combines multiple predecessors	single predecessor unchanged
possible-match	identity unresolved	confirmed same entity

Ten Questions Before You Merge Two Things

1. What type is each thing?
2. What exactly does “same” mean in this domain?
3. Are the names merely similar?
4. Do identifiers come from a trusted system?
5. Are dates and locations compatible?
6. Can their histories be connected?
7. Is one a copy, version or successor rather than the same instance?
8. Would merging erase meaningful provenance?
9. What evidence contradicts the merge?
10. How reversible is the decision?

Ten Questions Before You Split One Thing into Two

1. Could the difference be a name change?
2. Could the difference be a new state at a later time?
3. Could the difference be a formatting variation?
4. Could the difference be a version change?
5. Could the records come from different systems?
6. Do stable identifiers connect them?
7. Does one history lead naturally into the other?
8. Are relationships consistent across both records?
9. Would splitting fragment one longitudinal history?
10. Is there direct evidence that two entities coexist?

The Minimal Rules

1. Name is not identity.
2. Identifier is not the entity.
3. Record is not referent.
4. Similarity is not identity.
5. Copy is not original.
6. Same content is not necessarily same instance.
7. Version is not timeless truth.
8. Successor is not automatically alias.
9. Same role is not same occupant.
10. Current state is not permanent identity.
11. Repeated source is not necessarily independent evidence.
12. Provenance can be more informative than appearance.
13. Time belongs inside identity reasoning.
14. Uncertain matches should remain uncertain until evidence improves.

For Students: The Everyday Version

When you encounter two things that seem “the same”, ask:

1. Are they actually one thing with two names?
2. Are they two examples of the same type?
3. Is one a copy of the other?
4. Is one an older or newer version?
5. Do they share a history?
6. What evidence proves the connection?

This works for books, websites, historical sources, scientific diagrams, mathematical objects and everyday claims.

For Researchers: Make the Identity Unit Explicit

Research becomes clearer when the unit being identified is declared.

• person;
• household;
• observation;
• specimen;
• sample;
• study;
• article;
• dataset;
• event;
• institution;
• location.

Deduplication without unit definition can accidentally remove legitimate repeated observations or retain duplicate representations.

Define the identity level before cleaning the data.

For AI Systems: Resolve Before You Reason Across Sources

When multiple sources are retrieved, a safe synthesis pipeline should ask:

1. Which entities appear?
2. Which names are aliases?
3. Which records may be duplicates?
4. Which documents are copies or derivatives?
5. Which versions are current for the question?
6. Which sources are independent?
7. Which events are one occurrence described several ways?
8. Which states belong to which time intervals?
9. Which identity links are uncertain?
10. Only then: what can be synthesised?

This reduces a subtle but dangerous class of hallucination: a system can produce sentences that are individually plausible but attach them to the wrong person, version, event or organisation.

Identity Is a Constraint on Inference

Why spend so much effort distinguishing things?

Because inference travels along identity.

If Record A and Record B refer to the same person, facts from both can potentially contribute to one history. If they refer to different people, transferring properties between them is an error.

If Document B is a later version of Document A, changes can be interpreted as revision. If they are unrelated documents, the same comparison is meaningless.

If five pages derive from one press release, their agreement provides less independent support than five independently observed reports.

Identity controls what information is allowed to travel where.

The Deep Principle: Preserve Lineage

The strongest general-purpose approach to identity is not to search for one magical permanent property.

It is to preserve lineage.

Lineage tells us:

• what came before;
• what changed;
• what was copied;
• what was renamed;
• what was replaced;
• what forked;
• what merged;
• what survived;
• what became a successor;
• what evidence supports each transition.

A world with change is easier to reason about when identity is represented as history rather than frozen labels.

The Final Test

Whenever two things appear to be the same, ask:

Same in what sense?

Then make the relation explicit.

• same entity;
• same type;
• same content;
• same version;
• copy;
• alias;
• successor;
• derivative;
• replica;
• possible match.

That one clarification prevents a surprising number of errors.

Conclusion: Identity Is the Thread That Lets Knowledge Survive Change

Everything changes.

People age. Organisations rename themselves. Documents are revised. Files are copied. Data is corrected. Software forks. Places change boundaries. Institutions merge. Images are reposted. Events acquire new descriptions. Claims travel from source to source.

Reasoning depends on knowing which changes belong to one continuing thing and which changes signal that we are now dealing with something else.

The distinction cannot be solved by names alone. It cannot be solved by resemblance alone. It cannot be solved by one identifier detached from its issuing system.

Identity becomes defensible when we preserve type, time, provenance, relationships and evidence.

Then copies can remain copies. Versions can remain versions. Aliases can remain aliases. Successors can remain successors. Different people with the same name can remain different people. One changing entity can remain one coherent history.

That discipline is essential for archives, research, education, search and artificial intelligence because every later inference depends on it.

Before combining information, first prove that the information belongs to the same thing.