How to prepare private company data for AI research

Preparing private-company data for an AI assistant is not mainly a prompt-engineering problem. It is an identity, provenance and field-definition problem. The model needs a record that tells it which legal entity is being discussed, what each source actually established, when the evidence was observed and which requested facts remain unknown.

A flat spreadsheet can support that work, but only if its columns preserve those distinctions.

Start with a stable entity key

Company names change, repeat across jurisdictions and differ from the brand shown on a website. The minimum durable key is:

jurisdiction + registry identifier

Store the legal name as a sourced attribute, not as the identifier itself. Where a company has a Legal Entity Identifier, add it as another mapped identifier. GLEIF describes the LEI as a unique code connected to verified legal-entity reference data. It is valuable for entity resolution, but it is not universal coverage for private companies and should never be invented when absent.

The identity block should contain:

Field	Required treatment
Jurisdiction	Use a defined jurisdiction code, not free-text country variants
Registry identifier	Preserve leading zeros and the issuing register
Legal name	Store the exact current registry value
Former names	Keep each name with effective dates where available
Trading name	Separate from the legal name and cite the company source
LEI	Optional mapped identifier; blank when no match is established
Group relationship	Link parent, subsidiary and operating entity only with evidence

This prevents the retrieval layer from joining a brand’s website, a similarly named legal entity and another group company’s accounts into one fictional business.

Preserve source values before normalization

AI search works better with normalized fields. Analysts work better when they can see what was normalized.

For example, a company may describe itself as “a specialist workflow platform for independent clinics.” A taxonomy might normalize that to healthcare software. Keep both:

• activity_source_text: the company’s words;
• activity_normalized: the controlled category used for filtering;
• activity_source_url: the page supporting the description;
• activity_observed_at: when the page was checked; and
• activity_mapping_method: manual, rules-based or model-assisted.

The model can retrieve on the normalized category while quoting or reasoning from the underlying statement. If an analyst disputes the classification, the transformation is visible and reversible.

Give every material field provenance

A useful field is more than a value. It is a small evidence record:

• value: what was observed;
• source type: registry, filing, company website, regulator or announcement;
• source locator: URL, document identifier or filing reference;
• source date: when the document was published or filed;
• observation date: when the research was performed;
• entity key: which legal entity the value describes;
• treatment: reported, calculated, normalized or modelled; and
• confidence or review state: confirmed, conflicting or unresolved.

GLEIF’s data-quality framework distinguishes qualities including accuracy, completeness, consistency, currency, integrity, provenance and uniqueness. Those categories are useful design tests even when the companies in a dataset do not have LEIs.

“Complete” should mean the required schema was evaluated. It should not mean every cell was filled.

Keep legal and operating evidence separate

Companies House makes statutory information searchable but also states limitations on the information filed. A registry record is the authoritative source for the legal facts it contains. It does not by itself establish that the entity is commercially active or that the registered office is where it trades.

Use separate fields for:

Evidence family	Example fields
Legal status	Registry status, incorporation date, dissolution date
Filing behaviour	Last accounts date, last confirmation filing, dormancy statement
Operating evidence	Own website live, current service description, recent attributable activity
Location	Registered office, headquarters claim, trading address
Contact route	Public company email, switchboard, contact page

Then define the rule used for a higher-level label such as operating_evidence_present. Do not ask the LLM to decide from an unlabeled address and an “active” status.

Model missingness explicitly

A blank cell is ambiguous. It could mean the researcher did not check, the source did not publish the fact, the value does not apply, or two sources conflict.

Represent the state directly:

• not_published
• not_applicable
• not_checked
• unresolved_conflict
• source_unavailable

For numerical fields, keep a sourced value and a modelled value in different columns or objects. A revenue estimate must never overwrite missing filed revenue. Include the estimation method, input date and range if modelling is permitted.

This prevents three common AI errors: treating unknown as zero, treating absence as a negative, and repeating an estimate as if it appeared in filed accounts.

Ownership needs the same discipline. A registered shareholder, parent, director, beneficial owner and person with significant control are different relationships. The companion guide on whether AI can find a private company’s beneficial owners shows how to preserve the applicable jurisdiction, control test and evidence chain without turning a partial public record into a complete cap table.

Resolve conflicts before retrieval

Sources will disagree. A registry may show an old legal name while a company website uses a new brand. Two pages may show different addresses. A group website may describe activity performed by several subsidiaries.

Do not silently choose whichever value was collected last. Create a conflict record containing:

1. both values and their sources;
2. the dates attached to each source;
3. the field-definition rule;
4. the chosen current value, if one can be established; and
5. the reviewer and reason for the decision.

If the conflict cannot be resolved, return it to the AI as unresolved. A model that knows there is a conflict can explain the limitation. A model given only the chosen value cannot.

Separate extraction, transformation and judgment

A practical preparation pipeline has three stages.

1. Extract

Capture source text and structured registry or filing fields without changing their meaning. Record the source and observation time at ingestion.

2. Transform

Normalize jurisdictions, addresses, dates, currencies and activity categories. Map identifiers and create relationships. Keep the original value beside every transformation.

3. Review

Approve entity matches, operating-evidence labels, group relationships and any modelled values. Record why a candidate was rejected or left unresolved.

Only reviewed fields should enter decision-grade retrieval. Candidate matches can remain available for research, but they should be labelled so the model cannot present them as confirmed.

Test the dataset with adversarial questions

Before connecting it to an LLM, test whether the data can answer:

• Which legal entity owns this website?
• Is “active” a registry status or a conclusion that the business trades?
• Does this address belong to the company, an accountant or a group entity?
• Is this revenue filed, calculated or estimated, and for which period?
• Is the ownership relationship current, historical or unresolved?
• Why is this field blank?
• Can every claim in the answer be traced to a source and date?

If the schema cannot answer those questions, a longer prompt will not repair it.

What to send to the model

Retrieve the smallest evidence bundle needed for the task: stable entity keys, the relevant source values, dates, transformations and explicit limitations. Instruct the model to distinguish facts from calculations and to return “not established” when the evidence does not support a conclusion.

NIST identifies confidently stated erroneous content as a generative-AI risk. The practical response is not to make the prompt sound cautious. It is to make every important field traceable and every missing field legible.

SeekCompanies is building hand-checked private-company research around these distinctions. Read the broader case for verified private-company data in finance AI, then review the coverage methodology and current access path.

Frequently asked questions

What is the minimum identifier for a private company in an AI dataset?

Use the jurisdiction plus the authoritative registry identifier as the primary legal-entity key. A company name alone is not stable or unique. Add an LEI where one exists, but do not assume every private company has one.

Should an AI dataset keep the original source text?

Yes. Preserve the observed value or source passage alongside any normalized field. The normalized value helps filtering, while the original text lets an analyst understand what the source actually said and review ambiguous classifications.

How should missing private-company fields be represented?

Use null with a reason such as not published, not applicable, unresolved or not checked. Do not use zero for an unknown financial value, copy a registered office into a missing trading-address field, or ask the model to complete the gap.

Sources

1. GLEIF Data Quality Checks — Global Legal Entity Identifier Foundation; accessed September 19, 2026
2. The Legal Entity Identifier — Global Legal Entity Identifier Foundation; accessed September 19, 2026
3. Companies House disclaimer — Government of the United Kingdom; accessed September 19, 2026
4. Artificial Intelligence Risk Management Framework — Generative Artificial Intelligence Profile — National Institute of Standards and Technology; accessed September 19, 2026