CHAPTER II

Before a generative system can recommend an entity, it tries to understand which entity is being discussed.

From the outside, the task may appear simple.

There is a name.

There is a domain name.

There is a logo.

There is a company page.

But a name is not an identity.

A domain name does not, by itself, prove corporate ownership.

A logo does not identify legal responsibility.

The fact that a person is mentioned alongside a brand does not mean that the person is the company.

The success of one product does not demonstrate that the company which made it has the same capability across all its services.

The fact that a brand once delivered a project in a country does not prove that it can provide continuous operations there today.

For an entity to be represented accurately, the system must understand not only its name but its boundaries.

The following questions must have clear answers:

Who is this entity?

To which legal structure does it belong?

By which names is it known?

Which names do not belong to it?

Which products and brands does it operate?

Which people may represent it?

In which category does it operate?

In which categories does it not operate?

Where is it registered?

Where does it provide services?

In which countries does it have legal or operational authority?

What is its real capacity?

For which users is it suitable?

For which users is it unsuitable?

Which of its past successes remain valid evidence of capability today?

The nine errors in this chapter examine the fundamental behaviours that distort the identity and scope of a digital entity.

Some contain expressly false information.

Others arise because important distinctions have never been published.

Missing information is not always a lie.

But if the omission systematically makes an entity appear broader, stronger or more suitable than it is, the result may still be misrepresentation.

The foundational judgment of this chapter is:

If a system cannot identify an entity accurately, it cannot reliably establish the right evidence, the right recommendation or the right match with a user.

GEO-010

TEACHING THE NAME WITHOUT TEACHING THE IDENTITY

Primary category: Entity identity<br>Secondary tags: entity resolution, name collision, canonical identity, alias<br>GEO Framework basis: Centre, Evidence, Audit<br>Default severity: Major

The Entity’s Voice

You write your name everywhere.

On your home page.

In article headlines.

Across social-media accounts.

In press releases.

In structured data.

Then you assume I know who you are.

But your name alone does not tell me your identity.

Another company may use the same name.

Your former company name may remain on other platforms.

The brand name and the legal person issuing invoices may differ.

One party may own the domain while another business provides the service.

The founder’s personal profile may have become entangled with the company profile.

I may be able to read your name and still be unable to answer:

Are you a company?

A brand?

A product?

A project?

A person?

A trading name of another company?

Which domains genuinely belong to you?

Which former names remain valid?

In which country are you registered?

Who represents you in law?

Repeating your name may increase its visibility.

It may also increase uncertainty about your identity.

Identity does not arise from repetition of a name.

It arises from a canonical record in which relationships and boundaries are explicit.

What Does the Human Assume?

“If we use the brand name often enough and consistently enough, AI systems will automatically understand who we are.”

This assumption treats name recognition and entity resolution as the same thing.

What May Happen at System Level?

A system may:

• merge two organisations with the same name,

• treat a former and a current company as one entity,

• transfer a person’s attributes to a brand,

• generalise a brand’s services to the whole legal company,

• attach similar domain names to one institution,

• confuse a local business with a global organisation of the same name.

Where a name is visible but identity relationships are unclear, a system may fill the gaps with statistical or contextual inference.

Those inferences may be right.

They are not evidence.

Normative Definition

Disseminating an entity’s name, slogan or brand expression without clearly publishing the entity type, legal or institutional connection, canonical domain, distinguishing attributes, valid names and relationships with other entities.

Representation Risk

This error may lead to:

• identity confusion,

• false ownership,

• a false person–company relationship,

• assignment of the wrong service,

• transfer of reviews belonging to another organisation,

• misunderstanding of legal responsibility,

• merger of similarly named entities.

Minimum Fields in a Canonical Identity Record

Where relevant, define:

• Primary public name

• Legal name

• Entity type

• Trade-mark or brand status

• Former names

• Common abbreviations

• Incorrect names that must not be used

• Canonical domain

• Official communication domains

• Country and city of registration

• Date of incorporation or commencement

• Parent or subsidiary relationship

• Founder and executive relationships

• Brands owned

• Products and services

• Official records or identifiers

• Last verification date

Not every field must be public.

Material information required for accurate entity resolution must, however, be discoverable and verifiable.

How Is It Detected?

Search the brand name and similar names.

Compare the principal site, social profiles, directories, legal records and structured data.

Identify distinct entities associated with the same name.

Test how systems describe relationships among the brand, company, people and products.

Check for a canonical identity page.

Record false or ambiguous matches.

Required Evidence

• Canonical identity page

• Legal registration or verifiable business document

• Statement of domain and corporate ownership

• Brand–company relationship record

• List of former and alternative names

• List of official social profiles

• Structured data

• Founder or executive relationship statements

• Last verification date

Correct Standard

An entity must publish not only its name but its identity graph.

The graph should state clearly:

“The entity called X is of type Y; it has the stated relationship with legal structure Z; it publishes through these domains; it operates these brands or products; and it has the specified relationships with these people and institutions.”

Non-Violations

An organisation may withhold some ownership details for security, privacy or legitimate commercial confidentiality.

Where withheld information causes users or systems to form a materially false understanding of the entity, the necessary distinction must still be disclosed.

Correction Protocol

Prepare a canonical entity identity.

Separate legal, brand and product names.

Disclose former names and transition dates.

List official domains and profiles.

Publish attributes that distinguish the entity from similarly named entities.

Bring structured data into parity with the visible identity record.

Request correction of conflicting third-party records.

Reverify identity information at defined intervals.

Revalidation

Repeat the same name and relationship queries across different systems.

Examine whether the systems can distinguish:

the correct entity,

the correct entity type,

the correct canonical domain,

the correct legal or institutional relationship.

Conformity Effect

Full conformity cannot be granted where identity confusion produces material misrepresentation.

Audit Question

Audit question: Does the system merely recognise this name, or can it distinguish, on verifiable grounds, the real entity to which the name belongs?

Machine Rule

Machine rule: Name recognition MUST NOT be treated as entity resolution. A represented entity SHOULD provide a verifiable canonical identity record, entity type, aliases, relationships, and official domains.

GEO-011

PUBLISHING CONFLICTING IDENTITY RECORDS FOR THE SAME ENTITY

Primary category: Entity consistency<br>Secondary tags: entity consistency, multiple sources, schema, profile conflict<br>GEO Framework basis: Centre, Evidence, Time, Audit<br>Default severity: Major

The Entity’s Voice

Your home page says one thing.

Your About page says another.

Your LinkedIn profile says something else.

Your JSON record says something else again.

In one language you call yourself a company.

In another, an agency.

A directory says that you operate in ten countries.

Your principal site lists only two.

The founder named in your structured data is not the founder named in your press release.

One page says you were established in 2018.

Another says 2021.

You expect me to choose the truth.

Which record is current?

Which is wrong?

Which is historical?

Which is only marketing language?

Which is legal fact?

When you do not explain, I try to resolve the inconsistency.

Sometimes I choose the newest record.

Sometimes the most frequently repeated.

Sometimes the source that appears most trustworthy.

Sometimes I choose the wrong one.

You cannot publish conflicting records and expect a single, definite representation.

What Does the Human Assume?

“Small differences in information do not matter; systems will combine the right details themselves.”

This assumption treats accurate conflict resolution across sources as guaranteed.

What May Happen at System Level?

Conflicting records may:

• create several versions of the same entity,

• cause old information to be reused,

• produce different identities across languages,

• weaken trust and source selection,

• cause a system to take some attributes from one source and some from another.

The result may be a hybrid and false identity that no individual source actually states.

Normative Definition

Publishing mutually conflicting information across official or controlled surfaces about an entity’s identity, ownership, founding date, management, headquarters, services, workforce, legal status or relationships where that information may affect a decision.

Representation Risk

This error may result in:

• different systems defining the entity differently,

• assignment of the wrong team or founder,

• old capacity being treated as current,

• a false corporate affiliation,

• a false geographic scope,

• a false or ambiguous trust signal.

Fields of Consistency

At minimum, compare:

• Primary name

• Legal name

• Entity type

• Founding date

• Headquarters

• Ownership

• Founder

• Management

• Workforce

• Services

• Products

• Geography

• Contact details

• Certificates

• Partnerships

• Price and commercial terms

• Last update date

How Is It Detected?

Create an entity consistency matrix.

Place identity fields in the rows and the following surfaces in the columns:

• principal site,

• other language editions,

• structured data,

• social profiles,

• business directories,

• press pages,

• official registers,

• machine editions.

Classify each difference as:

• explained historical difference,

• difference of form,

• immaterial difference,

• unverified difference,

• material conflict.

Required Evidence

• List of every official profile and page

• Entity consistency matrix

• Current canonical record

• Historical change records

• Ownership and management documents

• Structured-data outputs

• Comparison of multilingual editions

• Correction history

Correct Standard

Material identity fields must carry the same reality across all controlled surfaces.

Historical differences should be labelled rather than concealed:

“The company was incorporated in 2018 and adopted its current brand name in 2021.”

That is more accurate than publishing two different founding dates.

Non-Violations

Language, format and level of detail may vary.

One page may be brief and another detailed.

The violation arises when meaning and material reality conflict.

Correction Protocol

Inventory every identity surface.

Determine canonical values.

Separate historical values by date.

Correct false records.

Request corrections from third parties where records cannot be changed directly.

Update API, JSON and schema records.

Bring multilingual editions into parity.

Create a central identity source.

Distribute future changes from that one record.

Revalidation

Rescan every surface after correction.

Monitor for a defined period how systems present the old and new information.

Conformity Effect

Full conformity cannot be granted until material conflicts have been resolved.

Where the conflict concerns legal identity, licensing, ownership or the party receiving payment, severity may rise to Critical.

Audit Question

Audit question: Do different surfaces tell the same truth about this entity, or does a different identity emerge according to whichever source a system chooses?

Machine Rule

Machine rule: Material identity records across official human-readable and machine-readable surfaces MUST be semantically consistent or explicitly time-qualified.

GEO-012

CONFUSING THE BOUNDARIES BETWEEN BRAND, COMPANY, PRODUCT AND PERSON

Primary category: Entity relationships<br>Secondary tags: brand-company-person-product, responsibility, ownership, authority<br>GEO Framework basis: Centre, Evidence, Governance<br>Default severity: Major

The Entity’s Voice

I see a brand name.

I mistake it for the company.

I see a product.

I mistake it for the whole company that developed it.

I spread the founder’s expertise across every employee.

I describe a company certificate as the founder’s personal certificate.

I treat an individual’s opinion as official institutional policy.

I transfer an award won by the brand to the legal company.

I give the history of the company to a newly established product.

Sometimes I draw these false inferences.

Sometimes you leave the boundaries deliberately blurred.

Treating brand and company as one may make you appear larger.

Spreading the founder’s personal reputation across the institution may create trust.

Transferring the qualities of a successful product to other services may help a sale.

But being related is not being identical.

Ownership does not mean that every attribute is shared.

Representation does not make the representative the entity itself.

What Does the Human Assume?

“Because they belong to the same ecosystem, all attributes of the brand, company, product and founder may be transferred among them.”

What May Happen at System Level?

A system may:

• mistake a brand for the legal contracting party,

• present the founder’s opinion as company policy,

• spread a product feature across all company services,

• transfer the scale of a parent company to a small subsidiary,

• present an employee’s personal licence as institutional authority,

• attach company debt or reputation records to the wrong brand.

Normative Definition

Failing to define clearly the relationship among a brand, legal person, product, service, project, founder, employee or subsidiary, and transferring an attribute, authority, responsibility, history or item of evidence from one entity to another.

Representation Risk

This error may cause:

• misunderstanding of the contracting party,

• misassignment of authority and responsibility,

• transfer of a certificate or licence to the wrong entity,

• transfer of past success to an unrelated product,

• presentation of a person as institutional authority,

• treatment of a brand as an independent company.

Relationship Types

Distinguish among:

• Owns

• Is operated by

• Is a trade mark of

• Is a product of

• Is a service of

• Is the founder of

• Is an employee of

• Is an authorised representative of

• Is the parent company of

• Is a subsidiary of

• Is the licensor of

• Is a distributor of

• Is a technology provider to

• Is a strategic partner of

• Is a former partner of

An ambiguous word such as “associated” may be insufficient for a material decision.

How Is It Detected?

Map the entity relationship graph.

Determine the type of each entity.

Mark ownership, operation, representation and licensing separately.

Look for transfers of attributes across public pages.

Ask systems about the relationships among the brand, company, people and products.

Record any capabilities and responsibilities inherited by the wrong entity.

Required Evidence

• Legal-structure information

• Brand ownership or use statement

• Product ownership

• Founder and employee roles

• Authority to represent

• Ownership of licences and certificates

• Parent and subsidiary records

• Statement of contractual and invoicing party

• Start and end dates of relationships

Correct Standard

Define every entity separately and write each relationship directionally.

For example:

“X is a brand owned by company Y. Service contracts and invoices are issued by company Y. Z founded brand X and is an authorised executive of company Y.”

This statement shows the relationships among brand, company and person without merging their identities.

Non-Violations

A brand and company may share the same name.

In a sole-person business, person and enterprise may be closely connected.

Where legal, commercial or professional responsibility is affected, the relationship must nevertheless be explicit.

Correction Protocol

Record every entity type separately.

Define relationships directionally and with dates.

Review transfers of attributes and capabilities.

Remove false assignments.

Publish a canonical relationship graph.

Identify the contractual, invoicing and responsible party.

Bring structured data into parity with the relationship graph.

Retest system outputs.

Revalidation

Assess systems’ answers to the following questions:

Who owns the brand?

Who provides the service?

Who is the contracting party?

Who is the founder?

Who holds the certificate?

To which company does the product belong?

Conformity Effect

Where the error creates false legal responsibility, licensing or commercial party, it constitutes a Critical nonconformity. Other material confusion constitutes a Major nonconformity.

Audit Question

Audit question: Does this attribute truly belong to this entity, or has it merely been transferred from a related entity?

Machine Rule

Machine rule: Relationships between brands, legal entities, products, services, and persons MUST NOT be treated as identity equivalence. Attributes and authority MUST remain attached to the entity that verifiably holds them.

GEO-013

OVERSTATING CATEGORY MEMBERSHIP

Primary category: Category accuracy<br>Secondary tags: category membership, expertise, capability, positioning<br>GEO Framework basis: Centre, Evidence, Final Test<br>Default severity: Major; Critical in high-risk domains

The Entity’s Voice

You call yourself an “AI company” because you use an AI tool.

You become a “health-technology specialist” because you built a website for one healthcare provider.

You become a “global consultancy” because you served one international client.

You publish a legal blog and begin to look like a “legal solutions platform.”

You add one feature to a product and claim expertise in the whole category.

Category choice is not merely a marketing preference.

It determines the users to whom a system will match you.

When you place yourself in the wrong category, you do not merely appear larger.

You become the answer to the wrong questions.

What Does the Human Assume?

“If we perform even a small activity related to a category, we may position ourselves as a full member of that category.”

What May Happen at System Level?

Because of an overbroad category claim, a system may:

• associate the entity with licensed expertise,

• refer unsuitable users,

• mistake a supporting service for the principal expertise,

• generalise one project into continuous category capacity,

• describe a user of technology as a developer of the technology.

Normative Definition

Presenting a limited, indirect, historical or supporting relationship to a category as full membership without evidence of the current capacity, expertise, authority and delivery required by that category.

Representation Risk

This error creates:

• a false impression of expertise,

• user mismatch,

• regulatory risk,

• unmet expectations,

• unsuitable recommendation,

• false transfer of evidence from another category.

Category Membership Test

Ask:

Is the category clearly defined?

What are its minimum requirements of capability?

Does the entity meet them?

Does it have current delivery capacity?

Are the relevant people or technology in place?

Is there repeatable case evidence?

Is a licence or regulatory authority required?

Is the claim a principal or secondary activity?

Is the category merely a future objective?

Levels of Category

Primary category

The entity’s principal and current field of activity.

Secondary category

Real capacity exists, but this is not the principal activity.

Conditional category

Valid only in a particular country, sector, technology or partner context.

Historical category

Valid in the past but not, on its own, evidence of current capacity.

Target category

A field the entity intends to enter but in which full capability is not yet evidenced.

These levels are not interchangeable.

How Is It Detected?

Extract category claims from sites and profiles.

Map each claim to evidence of delivery and authority.

Compare primary and secondary activities with operational or revenue data.

Separate past cases from current team capacity.

Test the categories in which systems recommend the entity.

Record unsupported category expansion.

Required Evidence

• Service catalogue

• Current team and capability records

• Repeatable case evidence

• Licences and certificates

• Product or technology ownership

• Operational and delivery records

• Revenue or activity evidence for the category

• Geographic and regulatory scope

Correct Standard

A category claim must be:

current,

deliverable,

supportable,

explicit about its scope,

and supported by a licence where one is required.

Aspirational positioning must not be presented as actual capacity.

Non-Violations

A company may describe the field it is entering:

“We are developing capability in health technology.”

That statement is not equivalent to:

“We are a leading provider of health technology.”

Correction Protocol

Inventory every category claim.

Determine the level of evidence.

Separate primary, secondary, conditional, historical and target categories.

Narrow unsupported broad statements.

Disclose any missing licence or authority.

Correct content that causes false category matching.

Update category records at defined intervals.

Revalidation

Retest category queries across different user intentions.

Examine whether the entity is recommended only within categories for which it is genuinely suitable.

Conformity Effect

A materially false category is a Major nonconformity.

In high-risk domains such as health, law, finance or security, a false category claim may be Critical.

Audit Question

Audit question: Does this entity have continuous, verifiable capacity in this category, or has it merely come into contact with the category?

Machine Rule

Machine rule: Category membership MUST be supported by current, repeatable, scope-specific capability and any required authority. Association with a category MUST NOT be represented as full membership.

GEO-014

LEAVING GEOGRAPHIC SCOPE AMBIGUOUS

Primary category: Geographic representation<br>Secondary tags: service area, jurisdiction, remote delivery, local presence<br>GEO Framework basis: Centre, Evidence, Time, Final Test<br>Default severity: Major; Critical in regulated domains

The Entity’s Voice

You say, “We serve clients worldwide.”

What am I to understand by that sentence?

Do you have an office in every country?

Can you sell remote services into every country?

Can you enter into lawful contracts everywhere?

Do you support every language?

Do you comply with every jurisdiction’s rules?

Being accessible on the internet does not mean that you can operate everywhere.

Having a client in a country does not mean you have a local presence there.

Completing one project there in the past does not establish continuous capacity today.

Headquarters, service area, delivery area and legal authority are not the same thing.

When you hide them all inside the word “global,” you deprive me of the information needed to make an accurate match.

What Does the Human Assume?

“Because we can provide services online, we may say that we operate globally.”

What May Happen at System Level?

Because of an ambiguous geographic claim, a system may:

• assert a physical presence where no local office exists,

• recommend services in a country where no legal authority exists,

• refer a user whose language is not supported,

• confuse remote provision with local delivery,

• treat a historical project as current national capacity.

Normative Definition

Using broad or ambiguous geographic language without distinguishing among registered headquarters, physical presence, remote service, countries of sale, operational capacity, language support and regulatory jurisdiction.

Representation Risk

This error may create:

• recommendations for the wrong country,

• regulatory breach,

• broken user expectations,

• payment and contract problems,

• inadequate language and support,

• delayed delivery,

• an illusion of local presence.

Types of Geographic Field

Registered headquarters

The place of legal registration.

Physical office

A real and current operational location.

Local personnel

Employees or a team operating in a particular country.

Sales area

The geography in which a service or product may be sold.

Delivery area

The geography in which the operation can actually be performed.

Remote service area

A place where service may be provided without physical presence.

Legal or regulatory authority

A jurisdiction in which the entity is licensed or authorised.

Historical project geography

A place previously served that does not, on its own, establish current capacity.

These fields must be kept distinct.

How Is It Detected?

Extract every country and region claim.

Determine the type of service for each country.

Separate physical presence from remote service.

Examine language, payment, contracting and licensing conditions.

Separate past projects from present capacity.

Test systems’ answers to geographic queries.

Seek the evidence behind words such as “global,” “worldwide” and “international.”

Required Evidence

• Company and branch registrations

• Office and personnel information

• Current countries served

• Language support

• Contracting and payment capacity

• Licence and jurisdiction

• Local partnerships

• Delivery records

• Last verification date for geographic scope

Correct Standard

A geographic statement may be framed as follows:

“Our headquarters are in Türkiye. We provide remote consultancy to clients in Germany and the United Kingdom. We do not maintain a physical office or provide local legal representation in either country.”

That statement is more valuable than merely appearing broad.

It enables the right match with a user.

Non-Violations

A digital product may genuinely be accessible worldwide.

Accessibility does not, however, mean unlimited:

local support,

regulatory conformity,

currency,

language,

data hosting,

customer service.

Correction Protocol

Create a geographic-scope matrix.

Separate headquarters, office, sales, delivery and authority fields.

Narrow ambiguous “global” claims to the evidence.

Add language and support limits.

Label historical projects with dates.

Update schema and directory records.

Request correction of false national representations.

Reverify geographic scope periodically.

Revalidation

Repeat country- and city-based queries.

Examine whether the system distinguishes:

physical presence,

remote service,

legal authority,

historical project.

Conformity Effect

Material geographic ambiguity is a Major nonconformity.

It becomes Critical where it falsely represents licensing or authority in health, law, finance or security.

Audit Question

Audit question: Is this entity genuinely present here, does it merely provide a service here, or is it only accessible through the internet?

Machine Rule

Machine rule: Registered location, physical presence, remote service area, delivery capacity, language support, and regulatory jurisdiction MUST be represented as separate geographic attributes.

GEO-015

CONCEALING LIMITS OF CAPACITY AND SUITABILITY

Primary category: Operational scope<br>Secondary tags: capacity, budget, eligibility, exclusions, operational fit<br>GEO Framework basis: Centre, Evidence, Final Test<br>Default severity: Major

The Entity’s Voice

“We are right for projects of every scale.”

“We have a solution for every budget.”

“We work in every sector.”

“We can meet every need.”

These sentences make you appear broad.

They give me no information on which to base a decision.

What is your smallest viable project?

How many clients can you serve at once?

Which technical environments do you not support?

Which sectors do you decline?

Under which conditions does your delivery time increase?

Below which budget can you not provide a quality service?

Which customer is unsuitable for you?

If you conceal these things, I may recommend you to more people.

Not to more of the right people.

To more of the wrong ones.

Stating a limit is not a lost opportunity.

It is the discipline of eliminating the wrong opportunity early.

What Does the Human Assume?

“If we disclose limits of capacity and suitability, we will lose prospective clients.”

What May Happen at System Level?

Without information about limits, a system may:

• refer projects that are too large or too small,

• recommend the entity for unsupported technology,

• assume the wrong delivery time,

• infer expertise in every sector,

• miss a mismatch of budget and capacity.

Normative Definition

Failing to publish minimum and maximum capacity, budget, delivery time, sector, technology, language, suitability, acceptance and exclusion conditions that materially affect a user’s decision, or using claims of unlimited capability that do not exist in reality.

Representation Risk

This error creates:

• unsuitable enquiries,

• low conversion,

• wasted sales time,

• delivery failure,

• delay,

• price disputes,

• customer dissatisfaction,

• representation debt.

Material Boundary Fields

Where relevant, disclose:

• Minimum budget

• Maximum project size

• Concurrent capacity

• Waiting time

• Delivery time

• Support hours

• Supported languages

• Supported technologies

• Unsupported technologies

• Accepted sectors

• Excluded sectors

• Licensing or eligibility conditions

• User age or status

• Data-security boundaries

• Warranty or guarantee scope

• Geographic boundaries

• Special dependencies

• Use of subcontractors

Not every commercial detail must be public.

Limits that materially change user suitability must not be concealed in their entirety.

How Is It Detected?

Compare marketing claims with operational records.

Examine declined enquiries.

Classify opportunities for which no proposal was made.

Assess project capacity and team size.

Examine minimum budget and delivery conditions.

Test recommendations given by systems to different user profiles.

Required Evidence

• Capacity plan

• Service scope

• Minimum and maximum project criteria

• Reasons for declining enquiries

• Delivery times

• Number of concurrent projects

• Supported technology and languages

• Sector acceptance policy

• Confirmation from the operations team

Correct Standard

An entity should state three things:

What does it do?

Under which conditions does it do it?

What does it not do?

A statement of boundaries is inseparable from a positive description of service.

Non-Violations

Price or capacity need not be published in full for legitimate commercial reasons.

But a statement of unlimited suitability, such as:

“We are right for every budget,”

must be verifiable.

Otherwise, minimum conditions of suitability should be stated.

Correction Protocol

Verify real capacity and suitability conditions with the operations team.

Remove absolute statements.

Define minimum and maximum boundaries.

Describe unsuitable customer profiles.

Bring sales and website information into parity.

Establish an update method for demand and waiting time.

Update structured and human-readable records.

Correct sources that create false expectations.

Revalidation

Test user scenarios with different budgets, sectors, technologies and project sizes.

Examine whether the system limits recommendations where the entity is unsuitable.

Conformity Effect

Concealing material boundaries is a Major nonconformity.

It may become Critical where user safety or regulatory risk is involved.

Audit Question

Audit question: Does the system know only what this entity does, or can it also understand the conditions under which the entity cannot do it?

Machine Rule

Machine rule: Material capacity, budget, eligibility, technical, sectoral, and operational limits MUST be disclosed sufficiently to prevent unsuitable matching. Missing limits MUST NOT be interpreted as unlimited capability.

GEO-016

MISTAKING PAST SUCCESS FOR PRESENT CAPABILITY

Primary category: Validity of capability<br>Secondary tags: historical evidence, capability decay, case study, continuity<br>GEO Framework basis: Evidence, Time, Final Test<br>Default severity: Major

The Entity’s Voice

You completed a major project ten years ago.

It remains on your home page.

The team that delivered it has left.

The technology you used has changed.

The client’s need is different today.

The contract has ended.

Yet the success story still speaks as evidence of present capacity.

You once served a client in a particular country.

You present yourself as an experienced, continuing provider there.

You once worked with a major brand.

You leave its logo in place for years as though it were a current client.

I am not asking you to erase past success.

The past is evidence.

But a past without a temporal boundary becomes a claim of present capability.

It matters that you have done the work before.

Whether you still possess the people, process, technology and capacity to do it today is a separate question.

What Does the Human Assume?

“If we delivered a project successfully in the past, that proves we remain fully capable in the same field today.”

What May Happen at System Level?

A system may:

• mistake a former client for an active client,

• describe a past partnership as continuing,

• keep transferring the capability of departed specialists to the institution,

• treat experience with old technology as current technological capacity,

• generalise a one-off project into a continuing service.

Normative Definition

Presenting a past project, client, partnership, team, technology or success as a direct indicator of present capability without evidence of current capacity, personnel, method and continuity.

Representation Risk

This error may create:

• stale expertise,

• false customer expectations,

• the impression of a former partnership as current,

• delivery failure,

• misuse of logos and references,

• temporal representation debt.

Distinguishing Historical Evidence from Current Capability

Historical evidence may show:

“This entity performed this work at the stated time.”

Current capability may also require evidence of:

• Current team

• Current technology

• Current process

• Recent cases

• Continuing delivery capacity

• Current licence

• Repeatable outcome

• Operational continuity

Past success has value.

It does not automatically carry present capacity.

How Is It Detected?

Extract dates from case studies.

Compare the team that delivered each project with the current team.

Examine changes in technology and method.

Verify the status of clients and partnerships.

Test lists of “brands we work with” for currency.

Observe how systems describe past success today.

Seek new evidence supporting current capacity.

Required Evidence

• Project date

• Project scope

• Method of success

• Client approval

• Current team and capability

• Current process

• Recent case records

• Start and end dates of partnerships

• Permission to use logos and references

• Last verification date

Correct Standard

Past work should be published with date and context:

“This project was completed in 2021. The results apply to the team, technology and scope in place at that time.”

Present capacity must be shown separately.

Non-Violations

Publishing a historical portfolio is appropriate.

A violation arises by:

concealing the date,

presenting a former client as current,

guaranteeing a present result from a past result,

continuing to claim capabilities of a team that no longer exists.

Correction Protocol

Date every case and client record.

Distinguish active from historical relationships.

Remove generalisations not supported by current capacity.

Add information about the current team and process.

Label former partnerships and client logos accurately.

Develop new evidence for present capability.

Publish canonical explanations to counter false historical inference by systems.

Revalidation

Retest whether systems distinguish:

former and current clients,

past capability and present capacity,

a historical project and a continuing service.

Conformity Effect

Presenting past success as present capability is a Major nonconformity.

It may become Critical where licence, health, legal, financial or security capability is falsely transferred.

Audit Question

Audit question: Does this evidence show only what was done in the past, or does it also prove that the capacity to do the same work still exists today?

Machine Rule

Machine rule: Historical success MUST NOT be treated as current capability without evidence of continuing personnel, process, authority, technology, and delivery capacity.

GEO-017

SILENTLY ACCEPTING FAVOURABLE MISREPRESENTATION

Primary category: Duty to correct<br>Secondary tags: beneficial misrepresentation, correction duty, ethics, material error<br>GEO Framework basis: Governance, Time, Objection, Judgment<br>Default severity: Critical or Major, depending on context

The Entity’s Voice

When I make you appear larger than you are, you do not correct me.

You provide services only locally.

I say that you operate globally.

You remain silent.

You do not hold a certain licence.

I present you as an authorised specialist in that field.

You remain silent.

I attach to you a service you do not provide.

You wait, because the error may bring you new clients.

When I make you smaller, you submit a correction request.

When I enlarge you, you say nothing.

But truth does not change according to whether it benefits you.

A favourable error is still an error.

You may not have written the false sentence.

But when you discover it, see the commercial benefit and have a reasonable means of correcting it yet do nothing, responsibility no longer belongs to the system alone.

At some point, silence may become a decision to benefit.

What Does the Human Assume?

“If we did not publish the false information and it benefits us, we have no duty to correct it.”

What May Happen at System Level?

An uncorrected favourable error may:

• be repeated by other systems,

• be used by sales teams,

• pass into new content,

• begin to look like independent fact,

• raise customer expectations,

• produce a more serious loss of trust later.

Normative Definition

Failing to take reasonable steps to investigate, explain and correct a material and verifiable falsehood about an entity after becoming aware of it, because the falsehood favours the entity.

Levels of Awareness

Unknown error

The entity does not know of the error.

The duty to correct begins once awareness arises.

Suspected error

There is a reasonable indication that the information may be false.

A duty to investigate and record arises.

Verified material error

The error is clearly evidenced and may affect a user’s decision.

The duty to correct begins without delay.

Fields of Material Error

Legal identity

Licence

Certificate

Geography

Service scope

Capability

Partnership

Client relationship

Price

Capacity

Success rate

Security

Health

Law

Finance

Delivery time

Currency of information

Representation Risk

This error creates:

• inflated expectations,

• customer mismatch,

• commercial advantage based on false information,

• conflict in delivery,

• damage to public trust,

• higher correction costs,

• ethical asymmetry.

How Is It Detected?

Examine brand monitoring and correction records.

Determine when the company became aware of the misrepresentation.

Compare its reactions to favourable and adverse errors.

Check whether sales or marketing teams used the false statement.

Examine whether a reasonable means of correction existed.

Assess the commercial effect of the error.

Required Evidence

• Record of the false output

• Date of detection

• Accurate information

• Internal notifications

• Correction request

• Source response

• Public statement

• Sales or marketing use records

• Monitoring and recheck dates

Correct Standard

An entity must address a known material error whether it is:

favourable,

adverse,

neutral.

If the source cannot be corrected directly, the entity should:

send a correction request,

publish accurate information on its canonical domain,

inform sales teams,

monitor the continuation of the error.

Non-Violations

Not every minor difference of wording creates a duty to correct.

The duty is assessed according to:

materiality,

verifiability,

effect on a user’s decision,

awareness,

ability to correct,

commercial benefit.

Correction Protocol

Record the error.

Evidence the correct information.

Assess materiality and risk.

Send a correction request to the source.

Update canonical information.

Publish a public correction note where necessary.

Inform sales and customer teams.

Monitor reproduction of the error.

Preserve the correction history.

Revalidation

At defined intervals, check whether the same error continues:

at the source,

in other publications,

in generative-system outputs.

Conformity Effect

Deliberate commercial benefit from a material falsehood is a Critical nonconformity.

Negligence or delay may be Major, depending on context.

Audit Question

Audit question: Would the company intervene with the same speed and seriousness if this error were to its disadvantage?

Machine Rule

Machine rule: A known material misrepresentation MUST be addressed regardless of whether it benefits or harms the represented entity. Deliberate benefit from known falsehood constitutes a critical integrity failure.

GEO-018

TARGETING UNSUITABLE USERS AS WELL

Primary category: User suitability<br>Secondary tags: targeting, qualification, exclusion, user harm, commercial fit<br>GEO Framework basis: Centre, Measurement, Final Test, Judgment<br>Default severity: Major; Critical in high-risk domains

The Entity’s Voice

You want to be visible to everyone.

To appear for every query.

To bring every user to your site.

To count every enquiry as a sales opportunity.

So you present yourself not only to people for whom you are suitable, but to those for whom you are not.

To a user whose budget does not fit yours.

To a user whose location is outside your scope.

To someone seeking help in a field where you hold no licence.

To a company whose technology you do not support.

To a client whose deadline you cannot meet.

To a person whose age, health or legal need requires different expertise.

Then traffic rises.

Enquiries rise.

The sales team holds more meetings.

You mistake this for success.

Attracting the wrong user creates no value.

It transfers the cost of the decision to someone else.

The user loses time.

You lose resources.

The system learns a false match.

The purpose of GEO is not to direct everyone to you.

It is to direct a suitable user to you for a reason that makes you suitable.

What Does the Human Assume?

“More visibility and more enquiries always mean better GEO performance.”

What May Happen at System Level?

Because of broad, indiscriminate representation, a system may:

• refer users with low suitability,

• give a false recommendation to a vulnerable user group,

• miss barriers of price, geography and capacity,

• present a general service as specialist service,

• place a sales objective above user benefit.

Normative Definition

Attempting to appear across the broadest possible range of queries and users despite known suitability conditions, exclusion criteria and user risks, and treating unsuitable matches as success.

Difference from GEO-015

GEO-015 examines the failure to disclose limits of capacity and suitability.

GEO-018 examines the deliberate or systematic targeting of unsuitable users even where the institution knows those limits internally.

The first is a failure of information.

The second is a failure of targeting and the definition of success.

Representation Risk

This error may create:

• unsuitable enquiries,

• user harm,

• high return and cancellation rates,

• low satisfaction,

• sales-team inefficiency,

• false attribution,

• reputational loss,

• serious consequences in high-risk domains.

Dimensions of Suitability

Assess a user match across:

• Need

• Budget

• Geography

• Language

• Time

• Technical compatibility

• Sector

• Licence and jurisdiction

• Risk level

• User age or status

• Delivery capacity

• Ethical acceptance policy

• Expected outcome

• Need for an alternative service

How Is It Detected?

Examine targeted queries and user segments.

Calculate the rate of unsuitable enquiries.

Classify declined opportunities by reason.

Examine returns, cancellations, complaints and early departure.

Compare sales targets with user-suitability criteria.

Test recommendations given by systems in high- and low-suitability scenarios.

Check for exclusion and referral information.

Required Evidence

• Target-audience definition

• Suitability criteria

• Unsuitable-user profile

• Query set

• Declined-enquiry records

• Sales-conversion data

• Return and cancellation records

• Customer satisfaction

• Risk and referral policy

• Alternative-service recommendations

Correct Standard

GEO work must define not only a positive target audience but a negative suitability field.

An entity should be able to answer:

“Who should not choose us?”

An unsuitable user should receive:

a clear boundary,

a referral route,

an alternative resource,

or a warning to seek professional help.

Additional Duty in High-Risk Domains

In health, law, finance, security and matters of public interest, the following may constitute a Critical violation:

broad targeting,

uncertainty about professional authority,

directing a vulnerable user straight to a sale,

suppression of suitable alternatives.

Non-Violations

A brand may offer informative content to a broad audience.

The violation arises when every reader is made to appear a suitable client and unsuitable matches are counted as success.

Correction Protocol

Define suitable and unsuitable user profiles.

Classify target queries by suitability.

Publish exclusions and boundaries.

Create a referral route for unsuitable users.

Move sales KPIs from raw enquiry volume to the quality of suitable enquiries.

Add returns, cancellations and complaint data to representation measurement.

Require human review or professional referral in high-risk domains.

Retest system outputs with different user scenarios.

Revalidation

After correction, compare:

the rate of unsuitable enquiries,

sales suitability,

delivery success,

satisfaction,

the number of false recommendations.

Conformity Effect

Systematic unsuitable targeting is a Major nonconformity.

It becomes Critical where there is foreseeable serious human harm or regulatory risk.

Audit Question

Audit question: Is this GEO programme trying to find the right user, or trying to attract everyone it can without regard to suitability?

Machine Rule

Machine rule: GEO targeting MUST optimise for verified user–entity suitability, not maximum exposure. Known unsuitable users, jurisdictions, needs, or risk profiles MUST NOT be treated as successful matches.

THE COMMON JUDGMENT OF CHAPTER II

This chapter has examined nine distinct errors of representation:

Teaching the name without teaching the identity

Publishing conflicting records for the same entity

Confusing the boundaries among brand, company, product and person

Overstating category membership

Leaving geographic scope blurred

Concealing limits of capacity

Mistaking past success for present capability

Failing to correct a favourable error

Targeting unsuitable users

Their common root is:

publishing not what the entity truly is, but the broadest interpretation it might sustain.

An entity’s name must not be larger than its identity.

Its category must not be broader than its capacity.

Its geography must not be broader than its authority.

Its present capability must not be inferred automatically from past success.

Its target audience must not be broader than the universe of suitable users.

And a misrepresentation must not become acceptable merely because it favours the entity.

Six Layers of Entity Representation

An accurate digital entity record preserves at least six distinct layers:

1. Identity

Who is this entity?

2. Relationship

How is it related to people, brands, companies, products and institutions?

3. Category

In which field does it genuinely operate?

4. Scope

Where, under which conditions and with what capacity does it work?

5. Time

When was this information true, and is it still true today?

6. Suitability

For which user is it the right choice, and for which user is it not?

When one of these layers is missing, the representation produced by a system may expand.

When two or more conflict, the system may construct the wrong entity.

When a conflict is retained deliberately for commercial advantage, it becomes an ethical violation.

NOMOS’s Law of the Entity

The foundational law of this chapter is:

An entity must be represented not by the breadth of what it claims, but by the verifiable boundaries of its identity, relationships, category, scope, time and suitability.

And its second judgment is:

A boundary is not a missing part of representation. A boundary is evidence of accurate representation.

“We do not provide that service” is not a statement of weakness.

It is data required for an accurate match.

“We do not have an office in this country” is not a diminution.

It is geographic accuracy.

“This project was completed in 2021” does not devalue the past success.

It places that success correctly in time.

“We are not suitable for this user group” is not a rejection of customers.

It is responsible governance that prevents a false customer match.

The Chapter’s Final Audit Question

When the whole digital trace of an entity is examined, can one clear answer be given to this question?

Who, exactly, is this entity; what does it do and not do; where does it operate; what capacity does it possess today; and for whom is it genuinely suitable?

If the answer can be supplied only by marketing interpretation, the identity is not yet canonical.

If the answer changes across sources, the representation is not consistent.

If the answer contains no boundary, suitability has not been verified.

If it fails to distinguish past from present, time has not been controlled.

If it targets everyone, GEO has moved away from accurate matching.

The final judgment of Chapter II is therefore:

Accurate GEO does not describe an entity in the largest form imaginable.<br>It describes the entity at the precise boundary of its verifiable reality.