Identity

Part of the WebMEM® Protocol
Location: /protocol/identity/
Status: Current Draft
Last Updated: 2026-08-24

Overview

Identity is the semantic mechanism through which WebMEM establishes what a knowledge object represents and what subject an assertion, relationship, policy, procedure, directory entry, recommendation, or other structure actually describes.

Identity is not optional descriptive metadata.

It is a structural requirement of the knowledge model.

A value may be correct. Its provenance may be complete. Its temporal scope may be accurate. But if the value is attached to the wrong entity, the resulting assertion is wrong.

Consider:

premium = 18.50 USD

Suppose that value applies specifically to:

segment:H5521-290-001

but is represented as applying to:

plan:H5521-290

The value has not changed.

The source may not have changed.

The provenance may not have changed.

The subject changed.

That change can transform a correct value into an incorrect assertion.

Identity exists to prevent that collapse.

Why Identity Is Structural

Machine knowledge requires an identifiable subject.

An assertion such as:

maximum_out_of_pocket = 4900 USD

cannot be interpreted correctly unless the machine can determine what the assertion describes.

It may describe:

a carrier;
a contract;
a plan;
a plan segment;
a geographic market;
a product;
a program;
or another entity.

Those entities may be related without being equivalent.

For example:

Carrier
└── Contract
    └── Plan
        └── Segment

An assertion about one level should not automatically be generalized to another.

Related identity is not equivalent identity.

Identity Is Part of Meaning

Identity participates directly in the meaning of an assertion.

Compare:

subject: plan:H5521-290
predicate: monthly_premium
value: 18.50
unit: USD

with:

subject: segment:H5521-290-001
predicate: monthly_premium
value: 18.50
unit: USD

The predicate and value are identical.

The assertions are not.

The subject determines what the value describes.

The same principle applies throughout the WebMEM architecture.

Semantic Concern	Question Answered
Identity	What entity or object does this knowledge describe?
Fragment Class	What kind of knowledge is being represented?
Assertion or Structure	What does the publisher state?
Context	Where, when, for whom, or under what conditions does it apply?
Provenance	Where did the knowledge come from, and how was it produced?
Relationships	How does this object connect to other objects?
Resolution	What must be known or traversed before the applicable object can be reached?

Remove provenance and evidentiary lineage collapses.

Remove identity and subject collapses.

In both cases, the visible value may survive while essential meaning is lost.

Entity, Identifier, Name, and Resource

WebMEM distinguishes among an entity, an identifier, a name or label, and a resource.

These concepts are related but not interchangeable.

Concept	Meaning
Entity	The person, organization, product, plan, contract, place, dataset, concept, or other thing being represented.
Identifier	A value used within a defined identification system to distinguish an entity.
Name or Label	A human-readable designation associated with an entity.
Resource	A document, page, endpoint, file, URI, or other information resource that describes, represents, or provides access to knowledge about an entity.

For example:

Entity:
A particular Medicare contract

Identifier:
H5521

Name:
Example Health Medicare Contract

Resource:
https://example.org/contracts/H5521/

The identifier identifies the entity within an identification system.

The name labels the entity.

The resource describes or represents the entity.

None of those objects is automatically identical to the others.

Names Are Not Identities

A name can help identify an entity, but a name is not necessarily a stable or unique identity.

Names may:

change over time;
be shared by multiple entities;
exist in abbreviated and expanded forms;
vary by market or jurisdiction;
contain branding that changes independently of the underlying entity;
or be translated into multiple languages.

For example:

AARP Medicare Advantage

may describe a family of products rather than uniquely identify one plan, contract, or segment.

Likewise:

Mohave County

is a useful human-readable label, but a geographic identifier may provide a more stable machine identity.

WebMEM may preserve names and aliases while maintaining a separate canonical entity identity.

Identifiers Are Not Entities

An identifier is a reference used to distinguish an entity within an identification system.

It is not the entity itself.

For example:

H5521

may identify a Medicare contract.

The contract is the entity.

H5521 is an identifier assigned to that entity within the applicable identification system.

This distinction matters because:

one entity may have multiple identifiers;
different identification systems may assign different identifiers to the same entity;
identifiers may change;
identifiers may be reused under some systems;
and identifiers at different levels may refer to different entities.

WebMEM therefore treats identifiers as identity evidence and resolution keys rather than assuming that the identifier string itself contains the complete identity model.

Identifier Type

An identifier is meaningful only when its identification system or type is known.

For example:

may be meaningless without context.

Within a Medicare plan hierarchy:

contract_id = H5521
plan_id = 290
segment_id = 001

the values participate in different identity roles.

A machine should not infer that two identical identifier strings represent the same kind of entity merely because the strings match.

Identity should therefore preserve, directly or through unambiguous context:

the identifier value;
the identifier type;
the identification system or namespace;
and the entity scope represented by that identifier.

Identity Scope

Identity scope defines the level of entity represented by an identifier or identity declaration.

Consider:

H5521
H5521-290
H5521-290-001

These identifiers may participate in one hierarchy, but they do not identify progressively more detailed descriptions of one undifferentiated object.

They identify different entity scopes:

H5521
→ Contract

H5521-290
→ Plan

H5521-290-001
→ Segment

This distinction is critical when facts, policies, availability, benefits, or other knowledge differ by level.

An identifier without scope can create the appearance of identity while leaving the actual subject ambiguous.

Hierarchical Identity

Many domains contain entities organized into parent-child hierarchies.

Examples may include:

Organization
└── Division
    └── Product
        └── Variant

or:

Carrier
└── Contract
    └── Plan
        └── Segment

or:

Country
└── State
    └── County
        └── Municipality

Hierarchical relationships do not make the participating identities interchangeable.

A child entity may inherit or share some characteristics of a parent while maintaining its own identity and scope.

A parent entity may aggregate or contain children without acquiring every child-specific assertion.

The identity model should therefore preserve both:

the identity of each entity; and
the relationship connecting the entities.

Hierarchy is a relationship among identities, not a substitute for identity.

Canonical Identity

A canonical identity is the publisher’s stable identity anchor for an entity within the WebMEM knowledge structure.

A canonical identity may be based on:

an authoritative external identifier;
a publisher-defined identifier;
a composite identifier;
a stable URI;
a domain-specific identifier;
or another identifier appropriate to the entity.

The purpose of canonical identity is not to claim that one identifier is universally authoritative across every system.

Its purpose is to establish:

Within this published knowledge representation, these references identify the same entity.

For example:

canonical_entity:
plan:H5521-290-0

external_identifiers:
  contract_id: H5521
  plan_id: 290
  segment_id: 0

The publisher-defined canonical entity identity provides a stable anchor through which fragments and relationships can refer to the same plan entity consistently.

Multiple Identifiers

One entity may legitimately have multiple identifiers.

For example, an organization may have:

a publisher-defined ID;
a government registration number;
a tax identifier;
a domain name;
an industry-specific identifier;
and a canonical URI.

These identifiers may all refer to the same entity while serving different systems or purposes.

WebMEM may represent multiple identifiers when doing so improves identity resolution.

The relationship should remain:

Identifier A ──┐
               │
Identifier B ──┼──→ Canonical Entity
               │
Identifier C ──┘

Multiple identifiers should not be represented as multiple entities merely because the identifier strings differ.

Conversely, identifiers should not be merged merely because they share a label or similar syntax.

Composite Identity

Some entities can be uniquely identified only through a combination of identifier components.

For example:

contract_id: H5521
plan_id: 290
segment_id: 001

may combine to identify:

segment:H5521-290-001

The component identifiers retain their own semantic roles.

The composite identity represents the entity defined by their combination.

A composite identity should preserve enough structure to distinguish its components rather than treating the combined string as semantically opaque when the component meanings matter.

Aliases and Alternate Names

An entity may have multiple names without having multiple identities.

Alternate labels may include:

abbreviations;
trade names;
former names;
common names;
acronyms;
translated names;
branding variations;
or publisher-normalized labels.

Aliases should remain subordinate to canonical entity identity.

For example:

Canonical Entity
  entity_id: org:example-health

  canonical_name:
    Example Health Insurance Company

  alternate_names:
    Example Health
    ExampleHealth
    EHIC

The alternate names improve recognition and resolution.

They do not create three additional organizations.

Identity Across Time

Identity may persist while some attributes of an entity change.

An organization may change its name.

A person may change roles.

A product may change branding.

A web resource may move to a new URL.

A plan may change benefits from one plan year to another.

Those changes do not necessarily create a new underlying entity.

Conversely, two objects that share a name across time are not necessarily the same entity.

WebMEM therefore distinguishes between:

entity continuity;
attribute change;
role change;
name change;
resource relocation;
version change;
and actual entity replacement.

Temporal continuity must be established rather than inferred solely from a repeated label.

Historical and Retired Identity

Historical identity relationships may remain useful after an entity name, resource, role, or structural relationship has changed.

For example:

Former Name
→ previousNameOf
→ Current Entity

or:

Retired Resource
→ represented
→ Entity
→ nowRepresentedBy
→ Current Resource

or:

Former Role
→ heldBy
→ Person
→ currentRole
→ New Role

Retirement does not necessarily imply deletion.

Preserving historical identity relationships can help machines understand continuity without treating obsolete labels or resources as current.

Entity Identity and Resource Identity

A web resource describing an entity is not necessarily the entity itself.

For example:

Entity:
plan:H5521-290-0

Canonical Resource:
https://example.org/medicare-advantage/plan/H5521-290-0/

The plan is the entity.

The URL identifies a resource describing the plan.

This distinction allows:

multiple resources to describe the same entity;
a resource URL to change without necessarily changing entity identity;
an entity to exist without a dedicated web resource;
and relationships to distinguish between linking to an entity and linking to a representation of that entity.

A canonical resource can represent an entity without becoming identical to that entity.

Web Resource, Dataset, SDT, Fragment, and Entity

WebMEM itself contains several identifiable objects that should not be conflated.

For example:

Web Resource
https://example.org/medicare-options/arizona/mohave-county/

Dataset / SDT Identity
https://example.org/medicare-options/arizona/mohave-county/#webmem

Fragment Identity
fragment:mohave-county-plan-index

Represented Geographic Entity
county:04015

Represented Plan Entity
plan:H5521-290-0

These identities participate in the same publication, but they identify different objects.

Object	Identity Represents
Web Resource	The human- and machine-accessible publication resource.
Dataset / SDT	The page-level machine knowledge dataset associated with the resource.
Fragment	A modular WebMEM knowledge object within the SDT.
Represented Entity	The real-world, conceptual, geographic, organizational, product, or other subject represented by the knowledge.

Conflating these identities can produce incorrect relationships.

For example, the Dataset may describe Mohave County without being Mohave County. An IdentityFragment may establish the county’s identity without itself being the county. A web page may represent a Medicare plan without the URL itself becoming the plan entity.

Representation of an entity does not create identity with the entity.

Dataset and SDT Identity

Under the current WebMEM publishing model, Schema.org Dataset JSON-LD may declare the page-level machine dataset and bind that declaration to the SDT through a shared identity.

For example:

{
  "@context": "https://schema.org",
  "@type": "Dataset",
  "@id": "https://example.org/resource/#webmem",
  "url": "https://example.org/resource/"
}

with:

<template
  data-webmem-sdt
  data-sdt-id="https://example.org/resource/#webmem">

  ...

</template>

The shared identifier establishes that the Dataset declaration and SDT refer to the same page-level machine dataset.

The web resource remains separately identifiable:

https://example.org/resource/

and the entities represented inside the SDT maintain their own identities.

Read Dataset Declaration and SDT Mapping →

Fragment Identity and Entity Identity

A WebMEM fragment has an identity distinct from the identity of the entity it describes.

For example:

Fragment:
fragment:plan-h5521-290-0-benefits

Entity:
plan:H5521-290-0

The fragment is a knowledge object.

The plan is the subject of that knowledge object.

This distinction allows multiple fragments to describe the same entity:

plan:H5521-290-0
│
├── IdentityFragment
│   └── canonical plan identity
│
├── DataFragment
│   └── plan benefits
│
├── ExplainerFragment
│   └── benefit explanation
│
└── RecommendationFragment
    └── applicable publisher recommendation

All four fragments may refer to the same plan while maintaining their own fragment identities and semantic roles.

The identity of the knowledge object is not the identity of its subject.

Identity and Assertions

A factual assertion must identify or inherit the subject to which it applies.

For example:

DataFragment
  entity: plan:H5521-290-0

  monthly_premium = 0 USD
  maximum_out_of_pocket = 4900 USD

Both assertions inherit the plan identity from the containing fragment.

If a particular assertion applies to a more specific entity, that distinction must remain explicit.

For example:

DataFragment
  entity: plan:H5521-290

  plan_type = PPO

  monthly_premium = 18.50 USD
    entity: segment:H5521-290-001

The segment-specific assertion must not be generalized to the parent plan merely because the containing fragment describes the plan.

The governing principle is:

Identity may be inherited only while the inherited subject remains accurate.

Read Facts and Assertions →

Identity and Fragment Classes

Different Fragment Classes use identity in different ways.

Fragment Class	Identity Role
`DataFragment`	Identifies the subject of source-observed factual assertions.
`DerivedStatsFragment`	Identifies the entity, geography, population, or other subject to which derived assertions apply.
`IndexFragment`	Identifies the collection context and the identities of its members.
`DefinedTermFragment`	Identifies the defined term as a semantic entity.
`MetaFragment`	Identifies the information resource or dataset being described.
`DirectoryFragment`	Preserves the identities of directory entries and their relationship to the directory context.
`EligibilityFragment`	Identifies the program, policy, population, or other entity to which eligibility criteria apply.
`ProcedureFragment`	Identifies the process, program, resource, or task to which the procedure applies.
`PolicyFragment`	Identifies the policy and the entities, programs, jurisdictions, or subjects it governs.
`RecommendationFragment`	Identifies the subject, option, resource, or action involved in the recommendation.
`IdentityFragment`	Explicitly represents the canonical structured identity of an entity.

Other Fragment Classes may likewise reference entity identities when identity is necessary to interpret their contents correctly.

Identity is therefore a protocol-wide semantic concern rather than a capability limited to IdentityFragment.

Identity and IdentityFragment

IdentityFragment is the Fragment Class used when identity itself must be represented as a modular knowledge object.

It may establish:

canonical entity identity;
entity type;
canonical name;
external identifiers;
aliases;
roles;
affiliations;
historical identity relationships;
canonical resources;
and other structural identity attributes.

But an IdentityFragment is not required merely because another fragment refers to an entity.

For example:

DataFragment
  entity: plan:H5521-290-0

may identify its subject directly when that identity is already sufficiently established.

An IdentityFragment becomes useful when the identity itself requires explicit representation, reconciliation, relationships, aliases, multiple identifiers, historical continuity, or resolution.

Identity is the protocol concept. IdentityFragment is one Fragment Class for representing identity knowledge.

Read the IdentityFragment specification →

Identity and Provenance

Identity and provenance answer different but complementary questions.

Identity asks:

What does this knowledge describe?

Provenance asks:

Where did this knowledge come from?

Consider:

subject: plan:H5521-290-0
maximum_out_of_pocket = 4900 USD
source: CMS PBP

The plan identity establishes the subject.

The provenance establishes the evidentiary origin.

Both are necessary to preserve the assertion accurately.

A perfectly sourced assertion attached to the wrong entity remains wrong.

A correctly identified assertion with unrecoverable lineage remains evidentially incomplete.

Identity preserves subject. Provenance preserves lineage.

Read the Provenance specification →

Identity and Relationships

Relationships connect identifiable objects.

A meaningful relationship therefore requires distinguishable identities at both ends.

For example:

contract:H5521
→ hasPlan
→ plan:H5521-290

or:

plan:H5521-290
→ hasSegment
→ segment:H5521-290-001

or:

plan:H5521-290-0
→ representedBy
→ https://example.org/plans/H5521-290-0/

The relationship does not replace the identity of either object.

Likewise, knowing that two objects are related does not mean they are the same object.

Relationships require identity boundaries in order to preserve what is being connected.

Read the Relationships specification →

Identity and Resolution

Identity is foundational to machine resolution.

A resolver may begin with an identifier rather than a fully established entity.

The resolution process may therefore require:

Observed Identifier
        ↓
Determine Identifier Type
        ↓
Determine Identifier Scope
        ↓
Resolve Canonical Entity
        ↓
Traverse Entity Relationships
        ↓
Resolve Applicable Knowledge or Resource

For example:

H5521
→ identifier type: Medicare Contract ID
→ entity scope: Contract
→ contract:H5521
→ related plans
→ canonical plan resources

or:

H5521-290-001
→ composite identifier
→ entity scope: Segment
→ parent plan
→ geographic applicability
→ segment-specific benefit

If the initial identifier is resolved to the wrong entity type or scope, every subsequent step may operate on the wrong subject.

Resolution cannot be more precise than the identity it resolves.

Read the WebMEM Resolution Model →

Identity and Resolvers

Resolvers frequently use identity as their entry point.

A resolver may be organized around:

a Contract ID;
a Plan ID;
a Formulary ID;
a geographic identifier;
a product identifier;
an organization identifier;
or another stable resolution key.

The resolver’s first responsibility is not merely to match the string.

It must establish what the identifier represents.

For example:

Input:
H5521

Not merely:
"Find pages containing H5521."

Instead:
H5521
→ Medicare Contract ID
→ Contract Entity
→ Carrier Relationship
→ Plans
→ Applicable Resources

This is the difference between string retrieval and entity resolution.

Read the Resolvers specification →

Identity Is Not `sameAs`

External identity-linking mechanisms such as Schema.org sameAs may be useful for connecting an entity to other resources or external representations.

They do not replace a complete identity model.

A sameAs relationship does not by itself establish:

identifier type;
identifier scope;
parent-child identity;
temporal continuity;
alias status;
resource-versus-entity distinction;
or whether two superficially similar objects actually represent the same semantic entity.

WebMEM may interoperate with external identity vocabularies while preserving its own identity distinctions.

Identity equivalence should be asserted only when the represented entities are genuinely equivalent at the applicable semantic scope.

Identity Is Not a URL

A URL may serve as an identifier for a resource and may sometimes serve as a useful canonical identifier within a knowledge system.

But a URL should not automatically be assumed to be identical to the entity described by the resource.

For example:

https://example.org/contracts/H5521/

may identify a page describing:

contract:H5521

The resource and contract remain distinguishable objects.

This distinction is especially important when:

multiple resources describe the same entity;
a canonical resource moves;
an entity has no dedicated public URL;
a URL identifies a dataset rather than the entity represented within it;
or historical resources must remain distinguishable from current representations.

Identity Is Not Classification

An entity’s classification, role, status, or type may participate in its identity representation without necessarily defining the persistence of the entity itself.

For example, a person may move from:

Role A
→ Role B

without becoming a different person.

An organization may change:

Classification A
→ Classification B

while preserving organizational continuity.

A product may move between categories without necessarily becoming a new product entity.

WebMEM therefore distinguishes:

Entity Identity
≠ Role
≠ Classification
≠ Status
≠ Label

Those attributes may change over time while the underlying entity remains continuous.

Identity Is Not String Matching

Two identical strings do not necessarily identify the same entity.

Two different strings do not necessarily identify different entities.

For example:

could appear as:

a plan identifier;
a product code;
a county code in another identification system;
a numerical value;
or another unrelated identifier.

Likewise:

Example Health Insurance Company
Example Health
EHIC

may all refer to one organization.

Identity resolution therefore depends on type, namespace, scope, context, relationships, and other evidence—not merely lexical equality.

Identity Failure Modes

Several common patterns cause identity to collapse.

Entity Collapse

Related entities are treated as though they were the same entity.

Contract = Plan = Segment

when the actual model is:

Contract
→ contains
→ Plan
→ contains
→ Segment

Identifier Scope Loss

An identifier is published without enough information to determine what level of entity it identifies.

Label Matching

Two objects are treated as identical because they share the same or similar human-readable name.

Resource/Entity Conflation

A web page or URL is treated as though it were identical to the real-world or conceptual entity it describes.

Parent-to-Child Generalization

An assertion attached to a parent entity is assumed to apply to every child, or a child-specific assertion is generalized to its parent.

Temporal Identity Collapse

Historical and current names, roles, resources, or entity states are treated as simultaneous or interchangeable.

Alias Proliferation

Alternate names or identifiers are incorrectly represented as separate entities.

False Equivalence

Two related or similar objects are declared equivalent without sufficient evidence that they represent the same entity at the same semantic scope.

These failures may preserve correct values while attaching them to the wrong subjects or relationships.

Identity failure does not require the underlying data to be wrong. The knowledge becomes wrong when the data is attached to the wrong thing.

Minimum Identity Model

The exact identity information required by a WebMEM representation depends on the entities and knowledge being represented.

At minimum, identity should make it possible to determine or resolve:

Entity Identity: the stable identity of the subject being represented;
Entity Type: what kind of entity the identity represents when that distinction is necessary for interpretation;
Identifier: the identifier or identifiers associated with the entity when applicable;
Identifier Type or Namespace: the identification system in which an identifier has meaning;
Identity Scope: the semantic level represented by the identity;
Canonical Name: the preferred human-readable designation when applicable;
Canonical Resource: the resource representing or describing the entity when one exists;
Relationships: parent, child, membership, affiliation, equivalence, representation, or other identity relationships necessary to distinguish the entity;
and Temporal Context: historical, current, effective, or retired status when time materially affects identity.

These elements may be represented directly, inherited from unambiguous context, or resolved through relationships to other WebMEM knowledge objects.

The requirement is not that every reference to an entity reproduce a complete identity record.

The requirement is that the subject remain distinguishable and resolvable at the semantic scope required by the knowledge.

Identity Granularity

Identity should be represented at the level where meaningful entity distinctions occur.

Too little granularity can collapse different entities into one identity.

Too much granularity can create artificial entities for what are merely attributes, versions, labels, or representations of the same underlying thing.

For example:

Carrier
└── Contract
    └── Plan
        └── Segment

may require four distinct entity levels because assertions and relationships can differ materially at each level.

By contrast:

Plan Name
Plan Marketing Name
Plan Display Label

do not necessarily represent three entities. They may be three labels associated with one plan.

The appropriate identity boundary is determined by whether the object can independently participate in meaningful assertions, relationships, applicability, provenance, or resolution.

Identity and Applicability

Identity and applicability are closely related but distinct.

Identity establishes what the entity is.

Applicability establishes whether particular knowledge applies to that entity under the relevant conditions.

For example:

Plan
  plan:H5521-290

Segments
  segment:H5521-290-001
  segment:H5521-290-002

The plan identity may be stable across both segments.

A benefit may nevertheless vary:

segment:H5521-290-001
monthly_premium = 18.50 USD

segment:H5521-290-002
monthly_premium = 32.00 USD

The difference is not merely contextual decoration around one plan-level fact.

The assertions apply to different identifiable segment entities.

When applicability depends on a more specific identity, the knowledge should be attached to that identity rather than generalized upward.

Identity and Collection Membership

Collection membership does not change entity identity.

For example, a plan may participate in several collections:

plan:H5521-290-0
│
├── memberOf → Mohave County plan index
├── memberOf → Arizona PPO collection
└── memberOf → Contract H5521 plan collection

The plan remains the same entity.

The collections provide different contexts through which the entity may be discovered, grouped, compared, or resolved.

An IndexFragment may establish membership without redefining the identity of the member.

This distinction allows WebMEM to represent the same entity within multiple meaningful collections while preserving one canonical entity identity.

Identity and Canonical Resources

An entity may be associated with one or more information resources.

A publisher may designate one resource as canonical for a particular representation or publishing context.

For example:

plan:H5521-290-0
  ↓
representedBy
  ↓
https://example.org/plans/H5521-290-0/

A resolver may use that relationship to move from entity identity to the appropriate information resource.

Canonical resource relationships should preserve the distinction between:

the entity;
the resource describing the entity;
the Dataset associated with that resource;
and the SDT representing the resource’s machine-facing knowledge.

This separation allows canonical resources to change without unnecessarily changing the identity of the represented entity.

Identity and Provenance of Identity

Identity declarations themselves may require provenance.

A publisher may obtain an entity identifier, canonical name, entity type, parent relationship, or other identity attribute from an external authority.

For example:

CMS
→ Contract ID H5521
→ Contract Entity

CMS
→ Plan ID 290 under Contract H5521
→ Plan Entity

CMS
→ Segment ID 001
→ Segment Entity

Other identity attributes may be publisher-defined:

Publisher
→ canonical WebMEM entity ID
→ plan:H5521-290-001

The publisher-defined identity may map to authoritative external identifiers without implying that the external authority created the publisher’s internal identifier.

Identity provenance can therefore establish:

who assigned an external identifier;
where an entity name originated;
what source establishes a parent-child relationship;
who created a publisher-defined canonical identity;
and when an identity mapping was established or changed.

This is particularly important when identity resolution depends on mappings among multiple identification systems.

Identity Resolution

Identity resolution is the process of determining what entity an identifier, name, resource, or other reference represents.

A simplified identity-resolution path may be:

Observed Reference
        ↓
Determine Reference Type
        ↓
Determine Namespace or Identification System
        ↓
Determine Entity Scope
        ↓
Resolve Canonical Entity
        ↓
Verify Applicable Relationships
        ↓
Continue Resolution

For example:

H5521
↓
CMS Contract ID
↓
Contract Scope
↓
contract:H5521

or:

H5521-290-001
↓
CMS Contract + Plan + Segment Identifier
↓
Segment Scope
↓
segment:H5521-290-001

Identity resolution should stop at the entity actually represented by the reference rather than silently generalizing upward or downward in the hierarchy.

Further traversal belongs to relationship or resolution logic.

Identity as the Entry Point to Resolution

Many WebMEM resolution paths begin with identity.

For example:

Identifier
→ Entity
→ Relationships
→ Applicable Context
→ Knowledge Object
→ Canonical Resource

Consider a Contract ID resolver:

H5521
→ contract:H5521
→ carrier relationship
→ plan membership
→ plan identities
→ canonical plan resources

The identifier provides the entry key.

Identity establishes the subject.

Relationships establish what connects to that subject.

Resolution traverses those relationships toward the applicable knowledge or resource.

This is why identity must precede reliable resolution.

A resolver that matches an identifier without establishing what the identifier identifies is performing retrieval, not complete entity resolution.

Identity Failure Can Survive Perfect Provenance

Identity failure is especially dangerous because every other part of an assertion may appear correct.

Consider:

value: 18.50 USD
source: authoritative source
retrieved: correct date
plan_year: 2026
derived: false

If the assertion is attached to:

plan:H5521-290

when the source actually establishes:

segment:H5521-290-001

then the provenance may be perfect and the value may be exact.

The assertion is still semantically wrong because its subject is wrong.

This produces an important architectural distinction:

Provenance Failure
→ correct or plausible assertion
→ unrecoverable or misleading lineage

Identity Failure
→ correct or plausible value
→ wrong subject

Neither can be repaired by the other.

Machine knowledge requires both recoverable lineage and correct subject identity.

Identity Is Not Authority

Identifying an entity does not establish that the publisher is authoritative about that entity.

For example, a publisher may correctly identify:

contract:H5521

without being the organization responsible for issuing, administering, or regulating that contract.

Identity establishes what object is being represented.

Provenance establishes where knowledge about that object came from.

Authority may then be evaluated from the provenance and other available evidence.

WebMEM does not convert correct entity identification into authority over the entity.

Identity Is Not Ownership

Representing an entity through WebMEM does not imply ownership, control, endorsement, affiliation, or authorization.

A publisher may represent public entities, products, organizations, geographic areas, policies, datasets, or other subjects it does not own.

The identity model exists to establish what the knowledge describes.

Ownership and affiliation are separate relationships that should be represented only when they actually exist.

Identity Is Not Truth

A stable identity anchor does not make every assertion attached to that identity true.

Identity answers:

What is this assertion about?

It does not answer:

Is the assertion correct?

A consuming system may still evaluate provenance, source authority, methodology, recency, corroboration, and other evidence.

Identity ensures that the evaluation is performed against the correct subject.

Minimum Conformance Requirements

A conforming WebMEM representation must preserve identity sufficient to determine what its knowledge objects describe.

Specifically, a conforming implementation must:

identify or make resolvable the subject of assertions and structures where subject identity is necessary for interpretation;
preserve entity type when different entity types could otherwise be confused;
preserve identifier type or namespace when the identifier is not globally self-describing;
preserve identity scope when related identifiers represent different levels of entity hierarchy;
distinguish entity identity from fragment identity, Dataset identity, SDT identity, and web-resource identity;
distinguish canonical entity identity from names, aliases, classifications, roles, and resource URLs;
preserve parent-child or other identity relationships when those relationships are necessary to interpret the entity correctly;
avoid generalizing child-specific assertions to parent identities without evidence that the assertion applies at the parent scope;
avoid treating parent-level assertions as child-specific without applicable evidence;
preserve historical or temporal identity distinctions when changes over time materially affect interpretation;
avoid declaring identity equivalence merely from lexical similarity or shared labels;
and preserve enough identity information for applicable relationships and resolution paths to operate on the intended entity.

Conformance does not require every entity reference to reproduce a complete IdentityFragment.

Identity may be referenced or inherited when the resulting subject remains explicit and unambiguous.

Relationship to WebMEM 1.x

Identity was present throughout WebMEM 1.x, but its architectural role was distributed across fragment headers, entity attributes, glossary identifiers, digest identities, related-fragment references, canonical URLs, and later the IdentityFragment class.

The introduction of IdentityFragment made explicit an important concept: machine-facing publishing sometimes requires identity itself to become structured knowledge.

WebMEM 1.x also associated identity with retrieval hints, memory stabilization, classification weighting, reclassification workflows, and other assumptions about how AI systems might retain or interpret entity representations.

The current protocol preserves the durable identity model while separating it from those consumption assumptions.

Identity is now defined as a cross-cutting semantic concern of the entire WebMEM architecture.

The current protocol clarifies that:

an entity is distinct from its identifiers;
an entity is distinct from its names and labels;
an entity is distinct from the resources that describe it;
identifiers have types, namespaces, and semantic scope;
related entities are not necessarily equivalent entities;
parent-child relationships do not erase identity boundaries;
entity continuity can persist through changes in names, roles, classifications, or resources;
fragment identity is distinct from subject identity;
Dataset and SDT identity are distinct from the identities represented within them;
IdentityFragment is a defined Fragment Class for representing identity knowledge, not the definition of identity itself;
and identity provides the semantic anchor required for reliable relationships and resolution.

The current model therefore moves identity from a collection of identifiers and classification hints to a foundational architectural principle.

Identity is the semantic anchor that determines what WebMEM knowledge is actually about.

Identity and Protocol Integrity

Identity is one of the conditions that allows the WebMEM knowledge model to remain coherent when knowledge is extracted from its human-facing document context.

Without stable identity:

facts can migrate to the wrong subjects;
relationships can connect the wrong objects;
collection membership can become ambiguous;
provenance can be associated with the wrong entity;
parent and child entities can collapse together;
historical and current states can become indistinguishable;
and resolution can begin from or terminate at the wrong object.

The resulting representation may remain syntactically valid while becoming semantically unreliable.

Without identity, the protocol can preserve values while losing the subjects that make those values knowledge.

Overview

Why Identity Is Structural

Identity Is Part of Meaning

Entity, Identifier, Name, and Resource

Names Are Not Identities

Identifiers Are Not Entities

Identifier Type

Identity Scope

Hierarchical Identity

Canonical Identity

Multiple Identifiers

Composite Identity

Aliases and Alternate Names

Identity Across Time

Historical and Retired Identity

Entity Identity and Resource Identity

Web Resource, Dataset, SDT, Fragment, and Entity

Dataset and SDT Identity

Fragment Identity and Entity Identity

Identity and Assertions

Identity and Fragment Classes

Identity and IdentityFragment

Identity and Provenance

Identity and Relationships

Identity and Resolution

Identity and Resolvers

Identity Is Not sameAs

Identity Is Not a URL

Identity Is Not Classification

Identity Is Not String Matching

Identity Failure Modes

Entity Collapse

Identifier Scope Loss

Label Matching

Resource/Entity Conflation

Parent-to-Child Generalization

Temporal Identity Collapse

Alias Proliferation

False Equivalence

Minimum Identity Model

Identity Granularity

Identity and Applicability

Identity and Collection Membership

Identity and Canonical Resources

Identity and Provenance of Identity

Identity Resolution

Identity as the Entry Point to Resolution

Identity Failure Can Survive Perfect Provenance

Identity Is Not Authority

Identity Is Not Ownership

Identity Is Not Truth

Minimum Conformance Requirements

Relationship to WebMEM 1.x

Identity and Protocol Integrity

Related Protocol Documents

Identity Is Not `sameAs`