The Entity Check: How to Stop AI Writing From Mixing Up Names

A name can be spelled perfectly and still point to the wrong person, company, subsidiary, acronym, product, or version. The entity check gives every important mention a verified identity, relationship, and time boundary before an AI-assisted draft turns a plausible match into a confident mistake.

A Correct Name Can Still Identify The Wrong Thing

AI-assisted writing often fails at identity before it fails at grammar. A model sees “Jordan Lee” in an interview, another Jordan Lee in a research paper, and a company biography that lists J. Lee. It may combine the three into one polished profile. A draft can also treat a consumer brand as the corporation that owns it, attach a parent company’s filing to a subsidiary, or describe features from version 4 as though they existed in version 3.

These errors are difficult to notice because every individual detail may look familiar. The name is real. The company exists. The feature appears in documentation. The problem is the connection between them.

The entity check asks a stricter question than “Is this name correct?” It asks: Who or what does this mention identify here, under which role or relationship, at what time, and according to which source? Until those fields agree, the match remains a candidate rather than a fact.

Protected Spelling And Verified Identity Are Different Controls

A protected-terms list prevents a rewrite from changing exact strings. It can preserve capitalization in “NovaCloud,” keep a model number intact, and stop a quotation from being paraphrased inside quotation marks. That is valuable, but it does not establish what the protected string denotes.

Suppose the source packet contains Nova Holdings, its subsidiary NovaCloud Services, and a product called Nova Cloud. Preserving “Nova” exactly does not tell an editor which one signed a contract, issued a statement, or shipped an update. The draft can repeat every character faithfully while attaching the action to the wrong entity.

Use both controls. Protect exact language when wording must not drift. Resolve identity when facts must not migrate between people or things. One guards the surface form; the other guards the referent.

Build An Entity Ledger Before You Polish The Draft

Create one ledger row for every consequential person, organization, product, dataset, standard, or acronym. Do this before smoothing transitions, because fluent prose makes weak matches feel settled.

Field	What To Record	Question It Answers
Draft mention	The exact name, abbreviation, pronoun, or role used in the draft	What text are we trying to resolve?
Entity type	Person, legal entity, brand, subsidiary, product, version, standard, or other type	What kind of thing is it?
Canonical identity	Verified full name plus jurisdiction, affiliation, vendor, or other discriminator	Which specific person or thing is meant?
Stable identifier	ORCID iD, CIK, LEI, CPE name, internal ID, or another authoritative key when available	Can the match survive a name or label change?
Aliases and relationships	Former names, trading names, parent, subsidiary, brand owner, author role, or acquisition link	How is it connected to nearby entities?
Time or version	Effective dates, affiliation window, ownership period, release, edition, or platform	Was this identity claim true at the relevant moment?
Evidence and status	Authoritative source, supporting locator, and confirmed, conflicting, or unresolved status	Why should an editor accept the match?

Do not invent an identifier to make a row look complete. Not every entity appears in every registry, and absence from one system is not proof that the entity does not exist. “No verified identifier found” is a valid status. It keeps uncertainty visible instead of converting it into a guess.

Disambiguate People With More Than A Display Name

Names are weak keys. People share names, publish under initials, change surnames, transliterate them differently, and move between institutions. Job titles are weak keys too: two organizations can each have a “Director of Research,” and one person can hold that title at different employers over time.

For researchers, ORCID explains how a persistent identifier disambiguates researchers from people with the same or similar names and connects them with professional activities. When a source provides an ORCID iD, use it with the work title, affiliation, and publication date. Do not infer that two profiles belong to one person merely because their names and fields are similar.

Outside research, combine several independent discriminators: full name, employer, role, location, official biography, authored work, and the date on which the affiliation was true. If two candidates remain possible, write the ambiguity into the notes and remove unsupported biography from the draft. A shorter verified description is better than a detailed composite person who never existed.

Keep Companies, Brands, Parents, And Subsidiaries Separate

A familiar brand may not be the legal entity that files a report, employs a speaker, signs a contract, or bears responsibility for a policy. Parent companies and subsidiaries can share logos, websites, executives, and parts of a name while remaining different entities.

For U.S. public filings, the SEC’s guidance on EDGAR Central Index Keys describes the CIK as a unique, permanent identifier assigned to a filer account. A CIK can help an editor separate similarly named filers and follow a filer through name changes. It does not mean every brand or subsidiary has its own public-company filing history.

Across financial markets, GLEIF’s introduction to the Legal Entity Identifier explains that an LEI is a unique 20-character code linked to verified reference information about a legal entity. When relevant, an LEI can clarify which legal entity participated in a transaction. It should not be treated as a universal company number or as proof that a parent and subsidiary are interchangeable.

Record the exact legal name, jurisdiction, identifier, former names, and relationship in effect on the event date. Then choose nouns that match the evidence: “the parent company,” “the operating subsidiary,” “the NovaCloud brand,” or the full legal name. Avoid sliding back to a convenient umbrella name after the first sentence.

Bind Product Claims To Vendor, Product, Version, And Platform

Product names are often reused across desktop apps, cloud services, hardware lines, editions, and major releases. “Atlas supports passkeys” is incomplete if only Atlas Cloud added them, the feature arrived in version 5.1, or the mobile edition still lacks it.

For software and hardware, NIST’s Common Platform Enumeration page describes CPE as a standardized method for naming classes of applications, operating systems, and hardware. A verified CPE name can help distinguish vendor, product, version, update, edition, language, and target platform when a catalog entry exists. It is a normalization aid, not proof that a particular customer installed that build or that a feature was enabled.

Pair the normalized identity with vendor release notes, support matrices, and dated documentation. Keep “version not stated” unresolved. Never borrow the newest documentation to fill a gap in an older case study. If a product was renamed, record both names and the date of the change so the final article can explain the relationship without collapsing separate releases.

Expand Acronyms And Replace Ambiguous Pronouns

An acronym can identify different entities even inside one industry. “ARC” might mean an audit and risk committee, an access review council, or a product component called Adaptive Routing Controller. Expand it at first use, attach an entity type, and give each meaning a separate ledger row. If two expansions appear in one article, do not rely on context alone; use distinct short forms.

Pronouns create the same problem invisibly. Consider: “Meridian told Luma that it would replace its security lead.” Which company made the decision, and whose role changes? A fluent model may select the nearest noun, the subject of the previous sentence, or the entity that seems most likely. None is evidence.

Run a replacement test: substitute every consequential “it,” “they,” “its,” “the company,” “the team,” and “the platform” with the canonical identity. If the sentence becomes repetitive, edit it afterward. If the substitution exposes two plausible referents, return to the source rather than asking AI to choose.

Run A Temporal Identity Check

Identity claims have dates. A person joins a company, changes roles, or leaves. A subsidiary is acquired, merged, sold, or dissolved. A product name moves to a different edition. A standard receives a new version. A statement that is true today may be false for the event the article describes.

Add three dates when they matter: the date of the event, the date of the source, and the effective window of the identity claim. For example, a 2026 biography cannot by itself prove that someone held the same role during a 2023 incident. A current ownership page cannot establish who owned a subsidiary before an acquisition closed.

Use time-bounded phrasing when the distinction matters: “At the time of the filing,” “then-chief financial officer,” “the subsidiary, which Meridian acquired the following year,” or “version 3.8, before the product was renamed.” These phrases are not clutter. They prevent present-day labels from rewriting the past.

Example: One Paragraph, Five Identity Collisions

Imagine a draft that says: “After Meridian acquired Luma, Alex Kim said Nova 4 fixed its reporting problem, and ARC approved the release.” Every name is spelled correctly, yet the sentence leaves five unresolved questions.

• Meridian: Is this Meridian Holdings, the listed parent, or Meridian Systems, the operating subsidiary named in the transaction?
• Luma: Is it Luma Data Ltd., its customer-facing brand, or a product line that kept the Luma name after the acquisition?
• Alex Kim: Is this the Luma engineer quoted in release notes or a Meridian executive with the same name?
• Nova 4: Does “4” mean major version 4.0, a fourth-generation device, or a marketing label for Nova Cloud?
• ARC: Is it the internal Architecture Review Council or the product’s Adaptive Routing Controller?

The ledger resolves the fictional example: Meridian Systems acquired the shares of Luma Data Ltd.; Alex Kim is identified by an official Luma engineering biography and the release-note byline; Nova Server 4.2, not Nova Cloud, contains the change; “its” refers to Luma Data’s monthly export; and the Architecture Review Council approved deployment.

A defensible revision is longer but clear: “Meridian Systems acquired Luma Data Ltd. After the transaction, Luma engineer Alex Kim wrote that Nova Server 4.2 corrected Luma Data’s monthly export issue. Meridian’s Architecture Review Council later approved that version for deployment.” If any link remains unverified, remove it or label it as reported rather than filling the gap.

Use A Repeatable Entity-Resolution Workflow

1. Extract mentions. Highlight every proper name, acronym, role label, product label, version, and consequential pronoun.
2. Assign types. Mark each as a person, legal entity, brand, subsidiary, product, version, standard, team, or unresolved type.
3. Create candidate rows. Keep candidates separate even when they look like obvious duplicates.
4. Collect discriminators. Add affiliation, jurisdiction, address, vendor, platform, version, publication date, and other context from the source.
5. Check authoritative identifiers. Use ORCID, CIK, LEI, CPE, or a domain-specific registry when applicable. Record verified values exactly; never manufacture a match.
6. Map relationships. Distinguish parent from subsidiary, brand from owner, person from role, and product family from release.
7. Bind time. Confirm that the role, ownership, name, and version were valid on the event date.
8. Resolve references. Replace ambiguous acronyms, pronouns, and umbrella labels with the correct canonical noun.
9. Rewrite from the ledger. Draft only with confirmed rows; mark conflicting or unresolved candidates for human review.
10. Audit the final prose. Trace each consequential verb back to its subject and confirm that no fact crossed from one row to another during editing.

Repeat the extraction after major revisions. A new transition or compressed sentence can reintroduce an ambiguous “it” even when the source notes remain correct.

Let AI Find Candidates, Not Declare Winners

AI can help inventory mentions, spot aliases, propose candidate matches, compare two records, and identify sentences with ambiguous pronouns. It should not be the authority that proves identity. Models can invent identifiers, merge plausible biographies, and treat a search snippet as stronger evidence than the underlying registry or document.

A safer instruction is: “Extract every named person, organization, acronym, product, and version. Create separate candidate rows. For each proposed match, quote the supplied evidence locator, list conflicting details, and mark the result confirmed, conflicting, or unresolved. Do not invent identifiers or select between candidates when the sources do not decide.”

Give the model only the material appropriate for the task, especially when contracts, personnel records, or unpublished product information are involved. Verify proposed identifiers directly in the authoritative source. Then have a human check the high-impact joins: who acted, which legal entity was involved, which version was used, and whether the relationship was true at that time.

The Final Entity Check

Before publishing, confirm that:

• every consequential name, acronym, role, product, and version has a ledger row;
• each row names one entity type and one canonical identity;
• people are distinguished by more than a display name;
• parents, subsidiaries, brands, teams, and legal entities are not treated as synonyms;
• product claims include the correct vendor, product, version, edition, and platform where relevant;
• stable identifiers come from authoritative sources and were not guessed;
• absence from a registry remains unknown rather than becoming “does not exist”;
• former names, aliases, acquisitions, and ownership links are explicit;
• roles, affiliations, ownership, and versions match the event date;
• every acronym has one clear expansion in context;
• consequential pronouns resolve to only one ledger row;
• each action remains attached to the entity supported by the cited source;
• conflicts and unresolved matches are visible beside the affected claim; and
• AI proposed candidates but did not serve as the final identity evidence.

A protected name can remain perfectly spelled while the fact beside it belongs somewhere else. The entity check prevents that quiet transfer.

Verify the person, company, product, relationship, and date first. Then let the writing become smooth.