Which company does this information actually describe?
Accurate data can still lead to the wrong decision when a system loses the legal entity, group boundary or ownership context the information describes.
The useful question is not simply whether a company data point is accurate. It is:
Accurate for which legal entity, over what scope, at what time and based on what evidence?
A workflow can preserve that meaning by keeping five things connected: the legal entity, its relevant relationships, the attribute's scope, its effective date and its supporting evidence.
The five fields that keep a company fact usable
- Legal entity: The registered company the workflow has established as its subject or counterparty. Without it, a trading name, similarly named company or another group member may be treated as the same company.
- Relationship context: Relevant parents, subsidiaries, owners or controlling parties, without collapsing them into one entity. Without it, a group relationship may be ignored or mistaken for legal identity.
- Attribute scope: Whether the fact describes one legal entity, another related entity, a consolidated group or another defined boundary. Without it, a true group-level or parent-level fact may be presented as though it describes the subsidiary.
- Effective date: When the fact and relationship context applied or were last checked. Without it, current software may act on a relationship or attribute that has changed.
- Evidence: The source, method, confidence, alternatives and explanation supporting the association. Without it, the result cannot be inspected or reconstructed when it is questioned.
These fields do not make the business decision. They preserve enough context for a person, application or AI agent to apply the organisation's own rules to the right company information.
A worked example: one company, two different scopes
Consider a fictional operating company called Northstar Logistics Ltd. It enters into a contract and is therefore the legal counterparty in a workflow. Northstar Holdings plc is its parent.
A company-register record can establish the registered identity and status of Northstar Logistics Ltd. A relationship source may separately establish that it has a direct or ultimate accounting consolidating parent. A published greenhouse-gas inventory may cover operations within the parent group's chosen organisational boundary.
The downstream record should not simply say:
> Northstar Logistics Ltd — emissions: 120,000 tCO₂e
That presentation implies that the figure describes the operating company itself. If the published figure actually covers the consolidated group, a safer representation keeps the scope visible:
- Legal entity in the decision: Northstar Logistics Ltd — synthetic example identifier and jurisdiction.
- Relevant relationship: Subsidiary of Northstar Holdings plc — relationship source and effective date retained.
- Intelligence: Reported emissions figure associated with the Northstar group.
- Attribute scope: Consolidated reporting boundary; not asserted as the subsidiary's stand-alone emissions.
- Evidence: Published inventory, reporting method, reporting year and retrieval date.
The Northstar names and values are synthetic. The distinction is grounded in the source models: Companies House records individual registered companies; GLEIF separates entity identity from direct and ultimate accounting consolidating-parent relationships for entities in scope; and the GHG Protocol requires a reporting company to select and apply an organisational boundary for consolidating emissions.
The source can therefore be accurate while an unqualified downstream association is misleading.
Accuracy and association are different tests
A source-quality review asks whether the information is credible, current and supported by an appropriate method.
An association review asks whether that information has been attached to the entity and scope it actually describes.
Both tests are necessary. A highly credible source does not make every downstream use of its data correct. The consuming system still needs to preserve the subject, boundary, date and evidence.
The same principle applies beyond emissions. A relationship, classification, ownership fact or restriction can be true while its consequence for another legal entity depends on the relevant facts, rules and workflow. The relationship should inform that assessment without being silently converted into a different claim.
A practical inspection checklist
Before software uses a company attribute, ask:
1. Which registered legal entity is the subject of the decision?
2. Which source and identifiers establish that entity?
3. Which parent, subsidiary, ownership or control relationships are relevant?
4. Does the attribute describe this entity, another entity, a group or a separate reporting boundary?
5. When did the attribute and relationship context apply, and when were they checked?
6. What evidence supports the association, and what uncertainty or alternative remains?
7. Can the next person or system inspect that context before acting?
If those answers are reduced to one name and one value, the workflow has probably discarded part of the meaning it needs.
How Sustema ENTITY fits
Sustema is developing ENTITY as Trusted Company Identity Infrastructure. Its intended role is to make the legal identity, relevant relationships, associated intelligence and supporting evidence available as one governed result through an API:
1. Anchor the request to the corresponding legal identity using authoritative records.
2. Map parents, subsidiaries, ownership and control while preserving each distinct legal entity.
3. Extend the identity with relevant intelligence while retaining the scope and evidence for each supported association.
4. Assure the result by exposing confidence and explanation, preserving provenance and monitoring change over time.
ENTITY cannot make every association where evidence or coverage is incomplete, and it does not apply the customer's business rules. It is intended to make the available company context explicit, governed and inspectable before people or systems decide or act.
External access is being prepared in controlled stages. We are qualifying suitable workflows now.
If your product, workflow or AI system depends on company information, where does the link between a data point and the legal entity become uncertain? Tell us what you are trying to establish and where the current process creates work. We would like to explore it with you.