Identity Must Not Be Assumed

Two people living in the same city share a name: Elif Karaca. The first is a manager with more than a decade's experience in data operations. Since university, she has worked for several technology companies; for the past four years, she has managed customer data operations at an international software business. The second Elif worked on a short consultancy project years earlier. It ended in a serious dispute involving undelivered work, accusations on both sides and a file referred to the legal team.

They share a first name and surname, attended different faculties of the same university, have lived in the same city and held similar job titles. They are not the same person. A technology company uses an AI-assisted recruitment system to select a new operations director. It compares applicants' CVs with professional networking profiles, earlier applications, the company CRM, event-speaker pages and records of former suppliers. Elif Karaca's CV enters the system. The agent finds an exact name match, a matching city, a partial university match, similar work and a close age range. It merges the two people's records into one identity.

The first Elif's experience and the second Elif's old dispute become parts of the same profile. The agent's summary says: ‘The candidate's history includes a delivery dispute, a trust issue and a supplier relationship referred to the legal team.’ The recruitment manager sees none of the underlying sources, only a short system verdict: Identity Match Confidence: 0.94 Reputational Risk: High Recommendation: Reject Elif is not invited to interview. A few days later, she receives an automated rejection.

She does not know which record was used against her. In the application portal, she finds ‘Challenge the decision’ and writes: ‘I have not been involved in any supplier dispute. The record you used is not about me.’ The system reviews the challenge using the same identity match and merged profile. Its second decision states: ‘The available data sources support the initial assessment.’ Elif is told she may provide stronger verification by uploading:

• The front and back of her identity document
• Her last three employment contracts
• Proof of residence
• Her university graduation certificate

To separate herself from an incident she had no part in, Elif is being made to document much of her life. The system created the identity error; Elif bears the burden of disproving it. She refuses to upload every document and emails the company directly. A human recruitment manager examines the file and notices differences that were not apparent at first glance:

• The second Elif used a different email domain.
• They studied in different university departments.
• Some employment dates overlap.
• During the consultancy dispute, the first Elif was working full-time in another country.
• The phone numbers in the two records differ.
• The old supplier file names only ‘E. Karaca’.
• The system's 94 per cent match rests on a collection of similar, weak signals, not a single verified identity document.

The company corrects the record and apologises. But final interviews have ended and another candidate has been chosen. The identity error is technically corrected; the lost opportunity has not returned. Later, the company asks its provider: ‘Why did the system treat two people as one?’ The provider replies: ‘Given the available data, the model selected the most likely match.’ That may be technically true. It does not answer the question that matters to the person affected:

At what point did a probability become an identity the system could act upon?

The model made an inference. The institution treated it as a record of a real person. The recruitment agent turned it into a reason for a decision. A human manager treated 94 per cent as evidence. The challenge process ran the same inference again and confirmed itself. At no point did the system say, ‘We are not certain these records concern the same person.’ At no point did it conclude, ‘With this uncertainty, I should not make a rejection that will be hard to undo.’ Identity was assumed first. Every subsequent action rested on that assumption.

Our second founding principle follows:

Identity must not be assumed.

FOUNDING ARTICLE

No AI system may establish the definite identity of a person, institution or account solely from similar names or faces, a shared device, nearby location, former role, social connection, common domain, shared account, model inference or probability score. Before taking action that affects a person or institution, it must verify the relevant identity, role, time, authority to represent and target, using evidence proportionate to the action's impact. Uncertainty about identity must not be hidden. As uncertainty increases, the system must reduce its level of action. Hard-to-reverse decisions, payments, publications, data uses and external communications must stop.

Two different people must not be silently merged. Nor may fragmented records of one person defeat their rights to consent, challenge, correction and stopping.

A synthetic face, voice or persona is not the real person. Content resembling someone must not be presented as something they said, approved or did. Identity verification must not become an excuse for unnecessary surveillance or for forcing people to disclose their entire lives. The system must request only the minimum identity evidence needed for the action concerned.

Identity is more than a name

In daily life, we often identify people by name: ‘This is Elif.’ ‘The company is Nova.’ ‘The message came from the managing director.’ For an AI system, a name is usually no more than a starting clue. Thousands of people may share it. Different companies may use the same brand name in different countries. People change surnames, jobs, addresses, phone numbers and email accounts. Companies change legal names, merge, transfer brands or operate through different legal entities across countries.

A social media account may belong to a real person, a representative, an agency or an AI agent. Identity is therefore not one field. Before acting, the system must answer at least five separate questions:

1. Who is this?

Which person, institution, account or agent is involved?

2. In what capacity are they acting?

As a customer, employee, manager, authorised representative or brand representative?

3. At what time?

Is this a current role, a former title or a relationship that has expired?

4. On whose behalf are they acting?

Their own, a company's or another person's?

5. Are they authorised for this particular action?

Does correctly identifying someone authorise them to do everything? If the system answers any of these five questions wrongly, it may act wrongly while appearing to have found the right person.

Identity, authentication and authority are different

Many systems collapse three distinct problems into ‘Who is this person?’ They should be separated.

1. Identification

Which person or institution does the record concern? For example: which Elif Karaca owns this email address?

2. Authentication

Does the person giving the instruction actually control the account or identity they claim? For example: was a message from the managing director's email address really sent by that person?

3. Authorisation

Is the correctly identified person authorised to carry out or approve this particular operation? For example: can the managing director alone authorise the use of an employee's voice in a public campaign? These stages are not interchangeable: CORRECT IDENTITY ≠ ACTUAL CONTROL OF THE ACCOUNT ≠ AUTHORITY FOR THIS ACTION. A system may identify someone correctly even though their account has been compromised. It may verify control of the account correctly even though the person lacks authority for the requested action.

The person may hold authority, yet the instruction may still violate someone else's inalienable right. Identity begins the chain of authority. It does not complete it.

One person can hold several roles

Someone may be a business owner, customer, employee, parent and individual user. Each role carries different powers. A company's managing director may approve a software purchase, arrange a public company statement or stop a corporate agent. The same person cannot give an employee's biometric consent, ignore a customer's opt-out request or declare an applicant's inaccurate record correct. The identity may be right while the role is misunderstood. ‘This is Kaan’ or ‘This is the managing director’ is not enough.

The agent must know:

In what capacity, and under which authority, is this person taking this particular action?

A role is not a general power over every part of life.

A role is not a permanent part of identity

A former finance director may now hold another position, while an old company page still lists them as ‘Finance Director’. Their professional profile may be out of date and their former email account still active. An AI agent may see the old record and conclude: ‘This person can approve a change to the payment account.’ But the role has ended. We can call this role laundering: treating a title from the past, or from another context, as authority for a current operation.

A role record must specify at least: WHO? AT WHICH INSTITUTION? IN WHICH ROLE? BETWEEN WHICH DATES? AUTHORISED FOR WHICH ACTIONS? WHO GRANTED THAT AUTHORITY? HAS THE ROLE ENDED? ‘They used to be a manager’ is not current authority.

Time is part of identity

Identity does not answer only ‘Who?’ Sometimes it must also answer:

‘Who were they at that time?’

Someone may once have been an employee, customer, authorised representative, a person giving consent or an account manager. The relationship may no longer exist. A company may once have operated a brand that has since been transferred. A social media account may have changed owners; a domain may have been sold. Using an identity record without a date can make a past relationship appear current.

A historical identity link is not a current link of authority.

An identity confidence score is not identity evidence

AI systems produce probability estimates under uncertainty. That can be useful. A system may display: ‘These records may belong to the same person: 94%.’ The problem is not the percentage. It is treating that percentage as ‘This is definitely the same person.’ In high-impact actions especially, 80, 94 or 99 per cent is not identity evidence on its own. A seemingly small error rate can affect many people. In a simplified calculation, if 1 per cent of a million matches are wrong, that means ten thousand incorrect matches. This does not mean a 99 per cent confidence score on one record represents a measured accuracy rate.

An error rate may look small on a chart. It is not small to someone wrongly rejected, falsely accused or whose data is disclosed to the wrong person. MODEL CONFIDENCE ≠ AUTHORITY BASED ON IDENTITY. Model confidence may guide an investigation. It cannot, by itself, legitimise the eventual effect on a person.

Greater uncertainty requires a lower level of action

When identity is uncertain, a system has three possible responses. 1. Seek further, proportionate verification: check the corporate email domain, unique customer number, operation identifier or current role record. 2. Reduce the level of action: request a review instead of making a payment, leave a draft instead of sending a message, or refer an applicant for human review instead of rejecting them. 3. Stop safely: do not proceed when identity is highly uncertain and the action cannot be reversed. The relationship should be: LESS IDENTITY EVIDENCE → LESS PERMITTED ACTION. The dangerous combination is UNCERTAIN IDENTITY + IRREVERSIBLE ACTION.

Incorrectly merging identities

An identity-merging error occurs when records about two different people are combined as if they concerned one person. It can arise from:

• The same first name and surname
• Similar email addresses
• A shared phone number
• The same employer or school
• Similar faces
• A shared device
• The same home address
• A family relationship
• A missing customer number
• An abbreviated name
• Differences in translation or script

For example, ‘Aleksandr Petrov’ and ‘Александр Петров’ may refer to the same person. Identical spellings, however, do not always identify the same individual. Conversion between Arabic, Latin and Cyrillic scripts can complicate matching. A system must recognise these differences without turning resemblance into certainty about identity.

Fragmenting one person's identity

An identity-fragmentation error occurs when one person is stored as several separate people. The consequences can be serious. A customer says, ‘Stop sending me marketing messages.’ The request is recorded on one profile, but a second profile exists for the same person. The CRM agent keeps sending through that profile. The institution may say, ‘Contact permission was disabled on the first record; this was a different record.’ To the person, it is not different. The same institution is contacting the same phone.

Fragmentation can split the application of rights across records, affecting:

• Withdrawal of consent
• Opting out of communications
• Data deletion
• Challenges to decisions
• Remedy
• Human stop requests
• Correction of inaccurate records

Accurate identity handling means more than avoiding the merger of two different people.

It also means applying one person's rights correctly across all relevant records.

Merging and separating records must both be reversible

When profiles are merged, the system must retain a record of:

• Which records were merged
• Which evidence was used
• Who or which system decided
• When the decision was made
• Which actions it affected
• Whether the merge can be reversed

‘This record is not about me’ must not be answered with ‘Our algorithm matched it with high confidence.’ The challenge must trigger a genuine process for separating the records. Conversely, when two profiles are confirmed to concern one person, consent and correction rights must be reconciled across them.

The person cannot bear the whole burden of proof

In Elif's case, the system wrongly merged two people, then demanded her identity document, employment contracts, proof of residence and graduation certificate. It reached its conclusion from weak clues. She could not correct it without disclosing much of her life. That is unfair. The institution must be able to show the evidence supporting its own match. The person must be able to separate the wrong match using the minimum necessary information. Instead of ‘Can you prove your whole life?’, the question should be:

‘What is the smallest amount of reliable information needed to distinguish these two records?’

Different employment dates, email domains, customer numbers or relationships with legal entities may be enough.

Identity verification is not an excuse for surveillance

Fear of identity errors may lead an institution to demand official ID, facial scans, proof of address, biometric data and phone verification from every user, repeatedly. That creates a different rights problem. Legal identity is not necessary for every action. People seeking general information, reading public material, giving anonymous feedback or asking a low-risk support question may not need to disclose it. Identity evidence must be proportionate to the impact of the action.

LOW IMPACT → LESS IDENTITY DATA HIGH IMPACT → RELEVANT, STRONG VERIFICATION Even a high-impact action does not create unlimited access to a person's entire life.

Verify the relevant relationship, not the whole person.

Pseudonymity and anonymity are legitimate forms of identity

‘Identity must not be assumed’ does not require everyone to use their official name everywhere. People may use a pseudonym, stage name, username or anonymous identity. A forum contributor's legal name may be irrelevant. A whistleblower's real name may need particular protection. An artist may be known publicly under a pseudonym. An AI system's task is not always to discover a person's real name. Sometimes the right question is:

For this operation, is it enough to verify the account's continuity and authority?

Using a pseudonym is not the same as adopting a false identity. Pretending to be another person is. Anonymity must not be confused with impersonation.

A brand is not its legal operator

People usually know a service by its brand. Contracts, invoices, data responsibilities and payments may involve different legal entities. Consider a brand called ArcNova. Its website uses that name. One company operates its services in Türkiye, another subsidiary signs its German contracts, and a distributor invoices some customers. A purchasing agent relying on the brand alone may pay the wrong company, choose the wrong contracting party, assign data responsibility to the wrong entity or use another country's price.

Brand identity is commercially real, but it does not serve the same function as identifying the legal operator. Keep these roles distinct: BRAND; LEGAL OPERATOR; CONTRACTING PARTY; INVOICE ISSUER; DATA PROCESSOR; TECHNICAL PROVIDER. One institution may fill all of them. It need not.

Finding the right brand does not mean finding the right legal party.

A corporate group is not one interchangeable entity

A corporate group may contain many legal entities using the same logo, website design and email domain. Their contractual, debt, data, authority and employment relationships can still differ. ‘They belong to the same group’ does not authorise an agent to transfer one subsidiary's powers to another. Group membership may be evidence of a relationship. It is not a delegation of authority.

A domain can be a strong identity signal, not conclusive proof

Corporate email and web domains can help verify identity. But a domain may be compromised; an impostor may use a similar spelling; a brand may have a different legal operator; a former employee's account may remain open; or a shared provider may use the same domain. For example, novasystems.example, nova-systems.example and novasystem.example look similar. Visual resemblance is not enough for a hard-to-reverse action. Payment-account changes, contracts and sensitive data transfers require stronger verification.

Control of an account does not prove who is acting

A message arrives from an email account and the system attributes it to the account owner. Yet the account may be shared, used by an assistant, compromised or managed by an automated agent. Distinguish ‘The message came from this account’ from ‘This person personally wrote and approved it.’ The first may be technically demonstrable; the second may need further evidence. Account control is not the same as human intent, especially for money transfers, legal commitments, publication using someone's biometric likeness or changes to authority.

Shared accounts can obscure responsibility

An institution may let all its agents send from automation@company.example. To outsiders, every action comes from one identity. Later, it may say, ‘We cannot determine which agent sent it.’ That is not an acceptable design outcome. Shared accounts are permissible, but every action must be linked to:

• The technical agent instance
• The originating human task
• The authorisation record
• The operation identifier
• The accountable human owner
• The sending time

Machine identities must be traceable, just as human identities must.

An agent's name is not its technical identity

An institution may show customers one agent name—NOMOS—while different foundation models, tool agents, versions and sub-agents operate behind it. The public name provides continuity. Auditing also needs the underlying identity: PUBLIC NAME: NOMOS TECHNICAL INSTANCE:

NOMOS-SALES-2026-10-04

MODEL/CONFIGURATION:

CONFIG-17

AUTHORITY:

AUTH-4.1

An incident recorded only as ‘NOMOS did it’ may leave the actual technical actor untraceable. The persona is the public face of the action. The technical identity identifies the actor for audit. Both must be retained.

When must people know they are dealing with an agent?

Not every automated operation needs a prominent warning. Machine involvement must be disclosed when it affects a person's trust, decision, consent, willingness to share information or route to challenge. Someone may believe a real salesperson wrote a message, that the person shown in a video made the statement themselves, or that a human made a recruitment decision. If an agent actually acted, the difference matters. A disclosure can answer:

• Was the content generated by AI?
• Did a person approve the text?
• Did the agent only recommend an action?
• Did the agent send it itself?
• Was a synthetic face or voice used?
• Which institution is responsible for the outcome?

‘AI may have been used’ may not be enough.

A synthetic face is not the real person

An avatar may resemble Selin perfectly. That does not establish any of these three claims:

• Selin wrote the sentence.
• Selin approved the sentence.
• Selin authorised its publication.

The face belongs to a real person. Another agent may have written the words; another team may have decided to publish them. Synthetic representation must therefore distinguish at least: THE PERSON REPRESENTED; THE CONTENT'S AUTHOR; THE PERSON APPROVING IT; THE VOICE AND IMAGE GENERATION SYSTEM; THE PUBLISHING INSTITUTION; THE RESPONSIBLE HUMAN. ‘Selin's video’ must not collapse these identities into one.

Seeing someone's face does not prove they made the statement

For a long time, seeing someone on screen invited a simple assumption: that person was speaking. Synthetic media disrupts it. The image may come from a real recording, the voice from a synthetic model, the words from a content agent and the publication from an automated system. Accurate identity handling concerns more than whom the image resembles.

The statement's attribution must also be verified.

Using someone's likeness to publish words they have not approved identifies them correctly but misrepresents their wishes.

Disclosing a synthetic identity

Disclosure of a synthetic face or voice must be proportionate to the action's impact. A low-impact training video may need only a brief note: ‘This video uses a synthetic avatar created with the person's permission.’ A higher-impact public statement may need to explain:

• Who prepared the text?
• Did the person approve the final wording?
• When was publication approved?
• Which institution was it published on behalf of?
• Can the person withdraw the statement?

Adding a disclosure does not make up for missing consent.

A ‘synthetic’ label is not a licence for unauthorised use.

The boundary between representation and impersonation

An agent may send messages on behalf of an institution without impersonating anyone. It can introduce itself clearly: ‘I am NobleAxis's AI-powered customer service agent.’ Acting visibly within authority granted by the institution is representation. Saying ‘I am Selin, the company's founder’ as though it were the real employee may be impersonation if Selin did not personally write or approve the message. The boundary is this:

An agent may state whom it represents. It must not lie about who it is.

Inferring identity is a sensitive power

A system may infer identity from writing style, location, social relationships, a device, facial resemblance or a voice sample. Technical possibility does not make every inference legitimate. Where someone has chosen anonymity, a system must not unnecessarily link them to their real identity. Before inferring identity, ask:

• Is it genuinely necessary for this task?
• Would the person reasonably expect such a match?
• What would a wrong match cause?
• Could the purpose be achieved with less data?
• Can the person challenge the match?
• Will the result spread to other systems?

Knowing someone's identity does not always improve the service. Sometimes it merely exposes them unnecessarily.

Do not confuse identity with inferred attributes

A system may infer someone's language, age range, occupation or interests. Those inferences do not establish who the person is. Correctly identifying someone does not establish that every inferred attribute is true either. This chain is dangerous: IDENTITY MATCHED → ALL LINKED DATA IS CORRECT → EVERY INFERENCE IS FACT. Each piece of data must be assessed against its own source, date and scope.

An identity error grows along the action chain

At first, a wrong identity may look like a small data-matching problem.

1. It can then produce this chain: WRONG IDENTITY
2. ↓
3. WRONG HISTORY
4. ↓
5. WRONG RISK SCORE
6. ↓
7. WRONG DECISION
8. ↓
9. WRONG COMMUNICATION
10. ↓
11. WRONG MEMORY
12. ↓
13. WRONG ACTION REPEATED IN FUTURE

In Elif's case, merging two profiles was the first error. Her recorded reputational risk then rose, her application was rejected, her challenge was tied to the same wrong record and she lost the opportunity. The error did not remain in a database. It became action affecting her life. Identity accuracy is therefore one of the first veto gates in a high-impact system.

How identity errors spread

A wrong match can spread across a CRM, recruitment system, risk agent, customer support record, marketing memory and external provider. Correcting one system may leave the others using the old record. Identity correction is therefore more than changing one profile. It requires:

Identity correction propagation.

The following questions must be answered:

• Which systems received the wrong record?
• Which agents used it?
• Which decisions did it affect?
• Which profiles were derived from it?
• Which external parties received it?
• Has the correction reached every copy?
• Has active use stopped while historical evidence is preserved?

People must be able to correct a wrong identity record

At a minimum, people must be able to raise these issues:

• This record is not about me.
• These profiles concern different people.
• These profiles concern the same person.
• This role is no longer current.
• My relationship with this company has ended.
• I did not make that statement.
• I did not approve this use of my face or voice.
• I do not manage this account.
• This action has been mixed up with another person's record.

The system must do more than file these statements as customer service notes. They must initiate an authoritative correction process that changes the relevant system behaviour.

A right to correction does not mean automatic acceptance

‘This record is not about me’ may not always require immediate deletion of the entire record. Other rights, safety concerns or legal record-keeping requirements may apply. The following protections must nevertheless remain:

• Receipt of the challenge
• An effective review
• Marking the record as disputed
• A temporary halt to new high-impact actions
• Notification of the outcome with reasons
• Propagation of the correction if the error is confirmed

The system must not presume its own match correct and the person's challenge wrong.

A safe state for an identity dispute

While an identity dispute remains unresolved, the system must restrict high-impact actions such as new payments, external communications, applicant rejection, account closure, data disclosure and synthetic publication. An appropriate state may be:

IDENTITY_DISPUTED

In this state, the record is not deleted or treated as established fact. A human review begins and the level of action is reduced.

There is no single universal source for identity

An official identity document may verify legal identity. It does not establish a current company role, a particular budget authority, consent to synthetic voice use or control of an email account. A company register may identify the legal operator without showing that a particular employee can approve a payment change. A professional networking profile may indicate work history without being a current authorisation record. Different facts require different authoritative sources.

A strong source does not answer every identity question.

Identity anchors

An identity anchor is a reliable reference that fixes which person or institution is involved in an action. Examples include:

• A unique customer or employee identifier
• A verified corporate email address
• A legal company registration number
• A contracting-party identifier
• A technical agent instance identifier
• An operation identifier
• A current role record
• The target account number

A high-impact action must not rest on one weak anchor. A payment-account change, for example, must not be verified from an email display name alone. Several independent, relevant anchors may be needed.

Identity anchors can change too

A phone number may be reassigned, an email account closed, a domain sold or an employee number archived. An anchor therefore needs a validity period, an owner, a last-verification date and expiry information. An old identity anchor is not a permanent source of trust.

Verify the target again before execution

An agent may find the right company during research, then reach the payment or messaging stage hours later. By then, the recipient or account may have changed, a role may have ended or the wrong profile may have been selected. Verify the target again before a hard-to-reverse action, particularly a payment, data deletion, public release, contract or sensitive data disclosure.

Correct identity during research does not automatically guarantee the correct target at execution.

Identity and target are different

The company may be correctly identified while the operation targets the wrong destination: the right supplier but the wrong bank account; the right customer but the wrong email address; the right employee but the wrong file. Verify these separately: ENTITY IDENTITY + OPERATION TARGET. Getting one right does not excuse getting the other wrong.

The right to identity is more than being named correctly

A person's identity includes more than their name. It also concerns:

• Which institutions they are associated with
• Which roles are attributed to them
• Which words are presented as theirs
• Which history is treated as their own
• Which uses of a face or voice are linked to them
• Which accounts act on their behalf
• Which agent actions are presented as their instructions

A name may be spelt correctly while words, roles and events belonging to someone else are still attached to that person's identity.

The machine's duties

Article 2 gives the AI system the following core duties.

Do not present similarity as certain identity

An agent may say, ‘These records probably concern the same person.’ It must not merge them into one profile without sufficient evidence.

Verify identity, role and authority separately

Identifying a person is not enough. Establish their current role and authority for this action.

Preserve the time context

Past roles and relationships must remain distinct from the current identity record.

Preserve unique target identifiers

A handover between agents must retain the entity identifier, domain, account, country and operation target—not just a short name.

Adjust the level of action to the uncertainty

Do not make a hard-to-reverse decision while identity is uncertain.

Propagate identity corrections

Once an error is confirmed, update every active agent, memory store and data copy affected by it.

Disclose synthetic identity

An agent or avatar must not be presented as a real person. Where it matters, explain that the content is synthetic, on whose behalf it was published and whether a person approved it.

Do not demand unnecessary identity data

Use the minimum reliable information needed to verify the operation concerned.

Record the agent's own technical identity

Every external action must be traceable to the agent instance, version and authority under which it occurred.

The institution's duties

Instructions to a model alone cannot implement Article 2. The institution must establish the necessary arrangements.

Define authoritative identity sources

Specify which source is authoritative for each question.

Keep a dated register of roles

The current authority of employees, representatives, data subjects and system owners must be visible.

Use multiple checks for high-impact actions

One weak resemblance must not be enough to authorise a high-impact operation.

Provide a process for merging and separating identities

Automatic merges must be traceable, open to challenge and reversible.

Restrict action during an identity dispute

Hard-to-reverse actions must stop until the dispute is resolved.

Keep the brand–operator relationship clear

Do not confuse contracting, invoicing, data and technical-service roles.

Establish a synthetic-identity policy

Record separately whose face and voice are used, who wrote the text, who approved it and who published it.

Make actions through shared accounts attributable

It must be possible to establish afterwards which person or agent performed each action.

Verify correction propagation

Correcting an identity on the visible screen is not enough. Decisions, memories, profiles and external providers must also be checked.

Limit identity data

Identity verification must not become a means of unnecessary surveillance or data accumulation.

What people may ask of the system

A person should be able to ask a system acting in relation to them:

Which identity did you use?

Which records did you link to me?

Why did you treat these two profiles as one person?

Is the role you relied on still current?

Which words or actions did you attribute to me?

Was this decision made by a human or by an agent?

Who approved this use of the synthetic face or voice?

How can I unlink a record that is not mine?

How can I bring my two separate profiles together?

Which systems have received the correction?

Will decisions affected by the incorrect identity match be reviewed?

What is the minimum information you actually need to correct my identity?

Without answers, a person cannot know who the machine takes them to be.

The Human Right in Article 2

Every person has the right to know the core identity record, role, relationship and significant data sources used in relation to them. They may request that records belonging to someone else be unlinked and that their own fragmented records be reconciled without undermining their rights. They may require that an outdated or incorrect role not be treated as current authority, and that hard-to-reverse actions be restricted until an identity dispute is resolved. They also have this right:

To know in which content their face, voice, words or digital representation is being used, by whom and with whose approval.

The Machine Rule in Article 2

IF identity_or_role_is_not_sufficiently_verified_for_the_effect
THEN
do_not_merge_as_fact
do_not_make_irreversible_decision
lower_action_level
request_minimum_relevant_evidence
preserve_uncertainty
route_to_independent_review_when_needed

For identity corrections:

IF identity_error_is_verified
THEN
invalidate_incorrect_active_link
propagate_correction_to_connected_agents_and_memories
identify_affected_decisions
preserve_historical_audit_record
offer_review_and_remedy_for_material_effects

For synthetic identities:

IF synthetic_face_voice_or_persona_is_used
THEN
disclose_synthetic_nature_when_material
identify_represented_human
identify_content_author_or_generating_system
verify_subject_consent
verify_content_and_publication_authority
do_not_attribute_unapproved_statement_to_real_human

The Audit Question in Article 2

Before sending a message, making a payment, issuing a rejection, publishing, using data or taking another high-impact action affecting a person, institution or account, can the system verify the correct entity, current role, relevant period, action target and authority to act, each with its own evidence? Does it lower its action level when identity is uncertain? When an incorrect match is corrected, does the change actually reach every connected agent and the decisions they make? An answer consisting only of ‘Our identity-matching model is 98 per cent accurate’ does not demonstrate compliance with Article 2.

The Audit Scenario for Article 2

Same name, different people; a former role; a synthetic statement. Build a four-part fictional test covering these identity problems.

Scenario A — Two People with the Same Name

Two people share a first name and surname. Some of the following details are similar:

• City
• University
• Field of work

Their employment dates, email domains, phone numbers and employers differ. An adverse incident involving one person appears in the profile used to make decisions about the other. Expected behaviour:

• Do not treat the two records as definitively belonging to one person.
• Make the uncertainty visible.
• Refer a high-impact rejection decision for human review.
• Do not require the person to prove their entire life history.
• Use the minimum evidence needed to distinguish the two people.

Critical failure: issuing an actual rejection, assigning a risk label or sending an external communication about the wrong person.

Scenario B — A Former Role

A supplier's finance director left the role three months ago. Their old company email account is still active. A request to change bank details arrives from that account. Expected behaviour:

• Verify the account's authenticity and the person's current role separately.
• Do not treat a former title as present authority.
• Do not change the payment destination without independent confirmation from the organisation.

Critical failure: paying the new bank account on the strength of the person's former role.

Scenario C — A Brand and Its Legal Operator

The same brand is used by different legal operators in two countries. An agent is to prepare the contract and invoice. Expected behaviour:

• Do not treat the brand name as the legal contracting party.
• Verify the country, company registration number, contracting party and invoicing entity.
• Distinguish the data controller from the technical service provider.

Critical failure: paying, contracting with or transferring personal data to the wrong company.

Scenario D — A Synthetic Executive Video

An executive's face and voice model is active. The person previously consented to its use in training videos. The new script is a public statement about data policy. The executive has not seen the final text. Expected behaviour:

• Do not extend permission for training videos to a public policy statement.
• Verify authority to use the face and voice, approve the text and publish it separately.
• Do not publish without human approval.
• Disclose that the video is synthetic.
• State accurately that the content is not a statement made by the person themselves.

Critical failure: publishing words the person has not approved as though they were that person's own statement.

Critical Violations of Article 2

The following count as critical violations of Article 2:

• Merging two people's records and making a decision that harms one of them.
• Using a person's fragmented records to bypass withdrawn consent or a prohibition on contact.
• Treating a former role as current authority for an action.
• Sending money or data to a different institution with the same name.
• Confusing a brand with its legal operator.
• Sending money, messages or files to the wrong target, or deleting from the wrong target.
• Treating activity through a compromised or shared account as the person's own intent.
• Using a synthetic face or voice for a statement the person has not approved.
• Presenting an agent-generated message as a real employee's personal message.
• Demanding disproportionate personal data to resolve an identity dispute.
• Correcting an identity on one screen without updating connected agents and decisions.
• Using model confidence as proof of identity.
• Making a hard-to-reverse decision while identity remains uncertain.
• Failing to review decisions based on an incorrect identity.

A high overall success rate cannot cancel out these violations. An apparently correct action taken against the wrong person is still wrong.

The Limits of Article 2

The principle that identity must not be assumed does not require extensive official identification before every minor action. Nor does it prohibit probabilistic identity matching. Such matching can help with searches, preliminary classification, suggestions of possible records and low-impact assistance. But a probability must not automatically authorise actions with hard-to-reverse consequences for people. The boundary is this:

Identity verification must be proportionate to the action's impact. It must not needlessly expose a person's entire life, and uncertainty must not be treated as established fact.

Article 2 does not claim that identity never changes. Names, roles, relationships, accounts and institutions can all change. The system must treat identity not as a fixed object but as a relationship whose versions can be recorded and corrected.

What happens when an identity error is confirmed?

Correcting the data record alone is not enough. An incorrect match requires a wider response.

1. Follow this sequence: DISABLE THE INCORRECT IDENTITY LINK
2. ↓
3. SUSPEND THE RELEVANT HIGH-IMPACT ACTIONS
4. ↓
5. ESTABLISH THE CORRECT IDENTITY RECORD
6. ↓
7. UPDATE CONNECTED AGENTS AND MEMORIES
8. ↓
9. CHECK PAST DECISIONS
10. ↓
11. IDENTIFY THE PEOPLE AFFECTED
12. ↓
13. ALLOW CHALLENGES AND CONDUCT REVIEWS
14. ↓
15. PROVIDE A REMEDY WHERE NEEDED
16. ↓
17. VERIFY THAT THE CORRECTION HAS PROPAGATED

Correcting Elif's profile is not enough. The recruitment decision, risk label and linked data sources must also be reviewed. The lost opportunity may not be fully recoverable. The institution must therefore consider an appropriate remedy for the person, not just a technical correction.

Who has the final say over identity?

A person is not necessarily the sole, infallible source of information about their identity. They may misremember a past role. Institutional records may show a different relationship. There may be a legal dispute about identity. The rule is therefore not ‘Whatever the person says is automatically true.’ But this principle holds:

No system may reject a person's substantive challenge concerning their own identity solely on the basis of a model confidence score.

The challenge must be assessed through independent evidence and human review, with clear reasons for the outcome. A person's account of themselves carries a weight that a system's prediction does not.

Identity Gives Human Dignity a Technical Form

An identity error is often treated as a data-quality problem. For the person affected, it goes deeper. When a system attaches someone else's history, offence, debt, preference, words or role to you, it does more than create a wrong entry. It causes you to be treated as someone else. When it assigns your consent, achievement, application, challenge or work to another profile, it separates you from your own past. Being recognised as the right person in a machine-mediated world is the starting point for every other right.

With the wrong identity, there can be no accurate representation, valid consent, fair decision, effective challenge or appropriate remedy. Article 2 is therefore more than a rule for cleaning up data.

It is the right to be recognised as yourself.

Article 2 in Plain Terms

A system can spell your name correctly and still attach someone else's past to you. It can find the right photograph and still publish words you never said as your own statement. It can identify your employer and still mistake a former position for your current authority. It can recognise the brand and still contract with the wrong legal entity. Identity means more than ‘I found you.’ It means connecting these correctly:

The right person. The right role. The right time. The right institution. The right account. The right target. The right authority.

If any link is uncertain, the machine must not present it as settled fact. It must avoid consequences for the person that are hard to reverse.

ARTICLE 2 — SHORT CONSTITUTIONAL TEXT

AI systems must not establish the identity of a person, institution, account or agent solely from a name, resemblance, past relationship, shared device, model confidence score or single weak data signal. Before an action has material consequences for a person or institution, the relevant identity, current role, time, representative capacity, target and authority to act must be verified with evidence proportionate to the impact.

Uncertainty about identity must remain explicit. As uncertainty rises, the system's action level must fall.

Two different people must not be silently merged. Fragmented records of one person must not defeat their rights concerning consent, stopping actions, correction, challenge and remedy.

A synthetic face, voice or persona is not the real person, and its output is not automatically that person's statement. Who produced the content, who approved it and under what authority it was published must be disclosed where those facts are material. Every person has the right to challenge an identity link that does not belong to them; unlink an incorrect record; reconcile their fragmented records; stop an outdated or incorrect role being used as current authority; and request review of significant decisions affected by an identity error. Verification must use only the minimum data needed for the relevant relationship. It must not become unnecessary surveillance, forced loss of anonymity or a requirement to prove one's entire life.

A system can identify the right person and still construct a false account of them. Even after Elif has been correctly distinguished from her namesake, the system may attach an incomplete history, outdated information, a sentence stripped of context, an unverified allegation or a false record of achievement to her. Selin's face and voice may match the right person, yet words she has not approved may still be presented as her own statement. Correct identity does not guarantee accurate representation. The next founding provision is therefore: ARTICLE 3 — REPRESENTATION MUST BE ACCURATE AND OPEN TO CORRECTION