WebMEM™

The Protocol for Structuring, Delivering, and Conditioning Trust-Scored AI Memory on the Open Web

Relationships

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

Overview

Relationships define how identifiable entities, fragments, assertions, sources, collections, resources, policies, procedures, and other knowledge objects connect within the WebMEM Protocol.

Relationships are not merely navigational links or descriptive metadata.

They are structural components of the knowledge model.

Identity establishes the objects.

Provenance establishes their evidentiary lineage.

Relationships establish how the objects fit together.

Consider:

plan:H5521-290
segment:H5521-290-001

Both entities may be perfectly identified.

But their identities alone do not establish how they are related.

WebMEM may preserve the relationship:

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

The relationship adds knowledge that neither identity communicates independently.

Without relationships, WebMEM can represent identifiable knowledge objects but cannot preserve the structure connecting them.

Why Relationships Are Structural

A machine knowledge representation is more than a collection of identifiable objects.

Consider:

county:04015
plan:H5521-290-0
contract:H5521
carrier:example-health

These identities may all participate in the same SDT.

But the machine does not yet know whether:

  • the carrier operates the contract;
  • the contract contains the plan;
  • the plan is available in the county;
  • the county merely appears in unrelated metadata;
  • or the objects have no meaningful relationship at all.

Relationships make those connections explicit:

carrier:example-health
→ operatesContract
→ contract:H5521

contract:H5521
→ hasPlan
→ plan:H5521-290-0

plan:H5521-290-0
→ availableIn
→ county:04015

The identities did not change.

The structure among the identities became explicit.

Relationships Are Part of Meaning

A relationship is itself a semantic assertion.

It identifies:

  • a source object;
  • a relationship predicate;
  • and a target object.

Conceptually:

Source
  ↓
Relationship Predicate
  ↓
Target

For example:

contract:H5521
→ hasPlan
→ plan:H5521-290

can be understood as:

source: contract:H5521
predicate: hasPlan
target: plan:H5521-290

Changing any one of those components changes the relationship.

For example:

plan:H5521-290
→ hasPlan
→ contract:H5521

uses the same two identities but expresses a different and likely incorrect relationship.

Likewise:

plan:H5521-290
→ relatedTo
→ formulary:12345

is semantically weaker than:

plan:H5521-290
→ usesFormulary
→ formulary:12345

The relationship predicate carries meaning.

A relationship is not merely the existence of a connection. It is an assertion about the nature of that connection.

The Anatomy of a Relationship

A WebMEM relationship can be understood conceptually through several components:

Component Question Answered
Source What identifiable object does the relationship begin from?
Predicate What kind of relationship is being asserted?
Target What identifiable object does the relationship connect to?
Scope Where, when, or under what conditions does the relationship apply?
Provenance What evidence establishes the relationship?
Direction Does the relationship have a meaningful source-to-target direction?
Cardinality Can one source relate to one target, many targets, or another defined set?

Not every relationship requires every component to be represented independently.

As elsewhere in WebMEM, context may be inherited when it remains explicit and unambiguous.

Relationship Predicates

The predicate determines what the relationship means.

Generic predicates such as:

relatedTo

may be appropriate when no more precise relationship is known or required.

But where the publisher knows the nature of the relationship, a more specific predicate preserves more knowledge.

For example:

Contract → relatedTo → Plan

communicates less than:

Contract → hasPlan → Plan

Likewise:

Plan → relatedTo → County

communicates less than:

Plan → availableIn → County

And:

Derived Assertion → relatedTo → Source Dataset

communicates less than:

Derived Assertion → derivedFrom → Source Dataset

The most useful relationship is generally the most specific relationship the publisher can support accurately.

Relationship Direction

Many relationships have meaningful direction.

For example:

Contract
→ hasPlan
→ Plan

may have an inverse relationship:

Plan
→ belongsToContract
→ Contract

These statements describe the same structural association from different directions.

Other relationships may be naturally symmetric:

Entity A
→ equivalentTo
→ Entity B

when genuine identity equivalence has been established.

WebMEM should preserve direction when direction contributes to meaning.

A consuming system should not be required to infer that every relationship is reversible.

Structural Relationships

Structural relationships describe how entities or knowledge objects are organized.

Examples may include:

Carrier
→ operatesContract
→ Contract
Contract
→ hasPlan
→ Plan
Plan
→ hasSegment
→ Segment
Glossary
→ containsTerm
→ Defined Term
Directory
→ containsEntry
→ Directory Entry

Structural relationships are especially important where entities exist in hierarchies.

The hierarchy should be represented through relationships among distinct identities rather than by collapsing the identities into one object.

Membership Relationships

Membership relationships establish that an identifiable object participates in a defined collection.

For example:

county:04015
→ hasAvailablePlan
→ plan:H5521-290-0

or, from the collection perspective:

Mohave County Plan Index
→ containsMember
→ plan:H5521-290-0

An entity may participate in multiple collections without changing its identity:

plan:H5521-290-0
│
├── memberOf → Mohave County Plan Index
├── memberOf → Arizona PPO Plans
└── memberOf → Contract H5521 Plans

Membership establishes context.

It does not create a new identity for the member.

IndexFragment is commonly used to represent structured collection membership within an SDT.

Applicability Relationships

Applicability relationships establish where, when, for whom, or under what conditions knowledge or an entity applies.

Examples may include:

Plan
→ availableIn
→ County
Policy
→ appliesTo
→ Program
Eligibility Rule
→ appliesTo
→ Population
Procedure
→ appliesTo
→ Application Process

Applicability relationships are important because a valid knowledge object may become incorrect when applied outside the scope in which the relationship holds.

For example:

plan:H5521-290-0
→ availableIn
→ county:04015

does not imply:

plan:H5521-290-0
→ availableIn
→ every county in Arizona

The relationship itself has scope.

Geographic Relationships

Geographic relationships are a particularly important form of applicability and structural relationship.

Examples may include:

County
→ locatedIn
→ State
Plan
→ availableIn
→ County
Segment
→ appliesIn
→ Service Area
Provider
→ serves
→ Geographic Area

Geography should be represented as relationships among identifiable geographic entities where those distinctions affect meaning or resolution.

A geographic label embedded in a string should not be the only mechanism through which a machine must infer the relationship when the publisher already knows the underlying geography.

Semantic Relationships

Semantic relationships connect knowledge objects according to meaning.

Examples may include:

Assertion
→ definedBy
→ DefinedTerm
DefinedTerm
→ memberOf
→ Glossary
DefinedTerm A
→ broaderThan
→ DefinedTerm B
DefinedTerm A
→ relatedTerm
→ DefinedTerm B

Semantic relationships allow factual assertions, policies, procedures, and other knowledge structures to connect to the terminology necessary to interpret them.

They can also preserve distinctions among related terms without declaring false identity equivalence.

Identity Relationships

Some relationships exist primarily to describe identity structure.

Examples may include:

Identifier
→ identifies
→ Entity
Entity
→ representedBy
→ Canonical Resource
Alias
→ alternateNameOf
→ Entity
Former Name
→ previousNameOf
→ Entity
Child Entity
→ parentEntity
→ Parent Entity

Identity relationships should preserve the distinction between genuine equivalence and other forms of association.

For example:

Plan
→ belongsToContract
→ Contract

does not mean:

Plan
→ equivalentTo
→ Contract

Relationship precision protects identity boundaries.

Read the Identity specification →

Evidentiary Relationships

Evidentiary relationships connect published knowledge to its sources, transformations, derivations, or responsible actors.

Examples may include:

Assertion
→ sourcedFrom
→ Source Record
Normalized Assertion
→ normalizedFrom
→ Source Value
Derived Assertion
→ derivedFrom
→ Source Dataset
Derived Assertion
→ generatedBy
→ Publisher Process

These relationships form part of WebMEM provenance.

The relationship predicate matters because:

sourcedFrom

communicates something materially different from:

derivedFrom

and:

generatedBy

communicates something different again.

Provenance is expressed in part through relationships among identifiable knowledge objects and sources.

Read the Provenance specification →

Representational Relationships

Representational relationships connect entities and knowledge objects to the resources that describe or represent them.

For example:

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

or:

dataset:cms-pbp-2026
→ describedBy
→ https://example.gov/pbp/documentation/

or:

contract:H5521
→ canonicalResource
→ https://example.org/contracts/H5521/

These relationships preserve the distinction between the entity and the resource representing the entity.

They are particularly important for resolution because a machine may begin with an entity identity and need to locate the canonical resource through which additional knowledge is published.

Policy Relationships

Policies frequently participate in relationships with programs, populations, eligibility criteria, procedures, jurisdictions, and exceptions.

For example:

Policy
→ governs
→ Program
Policy
→ establishes
→ Eligibility Requirement
Policy
→ hasException
→ Exception Condition
Policy
→ appliesIn
→ Jurisdiction

A PolicyFragment represents the policy knowledge.

Relationships establish what that policy governs, where it applies, and what other knowledge objects participate in its interpretation.

Eligibility Relationships

Eligibility knowledge often depends on relationships among programs, criteria, populations, policies, and procedures.

For example:

Program
→ governedBy
→ Policy
EligibilityFragment
→ determinesEligibilityFor
→ Program
Eligibility Requirement
→ appliesTo
→ Population
Eligible Outcome
→ enables
→ Procedure

These relationships allow eligibility knowledge to participate in a larger resolution path rather than exist as an isolated logic block.

Procedural Relationships

Procedural knowledge may contain relationships among steps, prerequisites, resources, decisions, and outcomes.

Examples may include:

Step A
→ precedes
→ Step B
Step B
→ requires
→ Document X
Step C
→ resultsIn
→ Application Submission
Procedure
→ governedBy
→ Policy

Ordering is itself a relationship.

A list of procedural steps without preserved sequence may contain all of the original text while losing the structure necessary to execute or explain the procedure correctly.

Recommendation Relationships

A recommendation should remain connected to the knowledge supporting it.

For example:

Recommendation
→ basedOn
→ DataFragment
Recommendation
→ supportedBy
→ DerivedStatsFragment
Recommendation
→ appliesTo
→ Persona
Recommendation
→ subject
→ Plan

The recommendation remains a publisher-defined knowledge object.

The relationships preserve its basis, subject, and applicability.

Merely placing a recommendation next to supporting facts does not necessarily establish why those facts support the recommendation.

Relationships Within an SDT

Many relationships connect objects represented within the same Semantic Data Template.

For example:

SDT
│
├── IdentityFragment
│   └── county:04015
│
├── IndexFragment
│   └── county:04015
│       → hasAvailablePlan
│       → plan:H5521-290-0
│
├── DataFragment
│   └── plan:H5521-290-0
│       → availableIn
│       → county:04015
│
├── MetaFragment
│   └── dataset:cms-landscape-2026
│
└── DerivedStatsFragment
    └── derivedFrom
        → dataset:cms-landscape-2026

The fragments remain distinct knowledge objects.

The relationships establish how the objects represented by those fragments participate in the same knowledge structure.

Co-membership in an SDT may establish a broad composition context, but it does not automatically establish every relationship among the objects within that SDT.

Where the nature of a connection materially affects interpretation, the relationship should be explicit.

Composition establishes participation. Relationships establish connection.

Relationships Across SDTs and Resources

Not every meaningful relationship terminates within the same SDT.

A knowledge object may relate to an entity, dataset, definition, policy, or canonical resource represented elsewhere.

For example:

County SDT
  plan:H5521-290-0
      ↓
  canonicalResource
      ↓
Plan Resource
  https://example.org/plans/H5521-290-0/

or:

Plan SDT
  formulary:00012345
      ↓
  canonicalResource
      ↓
Formulary Resolver
  https://example.org/formularies/00012345/

or:

Assertion
  → definedBy
  → DefinedTerm represented in another resource

Cross-resource relationships allow independently published knowledge surfaces to participate in a larger machine-resolvable information architecture.

The relationship should preserve stable identity at both ends so that the connection does not depend solely on human-readable labels or URL patterns.

Relationships and Composition

Composition and relationships perform complementary functions.

An SDT may contain:

IdentityFragment
DataFragment
DerivedStatsFragment
IndexFragment
MetaFragment

Their presence within one SDT establishes that they participate in the machine knowledge representation of the same resource.

It does not necessarily establish:

which DataFragment describes which entity

which source supports which assertion

which IndexFragment contains which entity

which DerivedStatsFragment depends on which source knowledge

which resource represents which entity

Those connections are represented through identity, provenance, context, and explicit relationships where necessary.

SDT composition tells the machine which knowledge objects belong together. Relationships tell the machine how they belong together.

Read SDT Composition →

Relationships and Assertions

A relationship may itself be an assertion, or it may provide context necessary to interpret another assertion.

For example:

plan:H5521-290-0
→ availableIn
→ county:04015

is a relationship assertion.

Now consider:

monthly_premium = 0 USD

If the premium is valid only for a particular segment or geography, relationships may participate in determining the correct subject or applicability:

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

segment:H5521-290-001
→ appliesIn
→ county:04015

segment:H5521-290-001
→ monthly_premium
→ 18.50 USD

The factual assertion and the relationships perform different semantic jobs.

Together they preserve the structure necessary to interpret the value correctly.

Relationships and Provenance

Provenance depends heavily on relationships.

A provenance chain is not merely a list of source objects.

It is a set of meaningful relationships among sources, transformations, responsible actors, and published knowledge.

For example:

Derived Assertion
→ derivedFrom
→ CMS Landscape

Derived Assertion
→ generatedBy
→ Publisher Calculation

Publisher Calculation
→ usedPopulation
→ Applicable County Plan Set

Changing derivedFrom to sourcedFrom would materially change the lineage being asserted.

This is why relationship semantics are essential to provenance.

Identity establishes the objects in the lineage.

Relationships establish how the lineage connects.

Provenance gives that connected structure evidentiary meaning.

Read the Provenance specification →

Relationships and Identity

Relationships require distinguishable identities.

Consider:

contract:H5521
→ hasPlan
→ plan:H5521-290

If the contract and plan identities are collapsed into one object, the relationship disappears.

Likewise:

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

requires the parent plan and child segment to remain separately identifiable.

This produces an important architectural dependency:

Identity
→ establishes nodes

Relationships
→ establish edges

But WebMEM should not be reduced to a generic graph abstraction.

The identities and relationships participate within Fragment Classes, provenance, applicability, resolution, and other semantic structures that establish what those nodes and edges actually mean.

Read the Identity specification →

Relationship Scope

A relationship may itself have temporal, geographic, jurisdictional, population, or other scope.

For example:

plan:H5521-290-0
→ availableIn
→ county:04015
→ plan_year: 2026

The relationship does not necessarily assert that the plan was available in the county in 2025 or will remain available there in 2027.

Likewise:

Person
→ holdsRole
→ Organization Role
→ effective: 2026

may describe a relationship that did not exist previously.

And:

Policy
→ appliesIn
→ Jurisdiction

may be valid only during a defined effective period.

Relationships can change even when the identities at both ends remain stable.

When scope materially affects the truth of a relationship, that scope is part of the relationship’s meaning.

Temporal Relationships

Some relationships exist primarily to represent change or continuity over time.

Examples may include:

Former Name
→ previousNameOf
→ Current Entity
Historical Resource
→ replacedBy
→ Current Resource
Old Policy
→ supersededBy
→ Current Policy
Version 1
→ previousVersionOf
→ Version 2

Temporal relationships allow WebMEM to preserve history without representing obsolete states as current.

They also allow a machine to traverse from historical identifiers, resources, or policies toward their current equivalents where such continuity is known.

Inverse Relationships

Some relationships have useful inverse forms.

For example:

Contract
→ hasPlan
→ Plan

may correspond to:

Plan
→ belongsToContract
→ Contract

Likewise:

County
→ hasAvailablePlan
→ Plan

may correspond to:

Plan
→ availableIn
→ County

A serialization does not necessarily need to publish both directions when one direction and its semantics are sufficient to recover the inverse unambiguously.

However, implementations should not assume that every relationship has a valid inverse or that an inverse can always be inferred from lexical similarity.

The inverse relationship must preserve the same underlying semantic connection.

One-to-One, One-to-Many, and Many-to-Many Relationships

Relationship cardinality may affect interpretation.

For example:

Contract
→ hasPlan
→ many Plans

while:

Plan
→ belongsToContract
→ one Contract

may be the applicable model within a particular domain and time period.

Other relationships may be many-to-many:

Plan
→ availableIn
→ many Counties

County
→ hasAvailablePlan
→ many Plans

or:

Plan
→ usesFormulary
→ Formulary

Formulary
→ usedBy
→ many Plans

WebMEM does not require every relationship to declare cardinality explicitly.

But when cardinality is necessary to interpret, validate, or resolve the relationship correctly, the model should preserve it.

Relationships and Collections

A collection is not merely a list of identifiers.

The relationship between the collection and its members gives the list semantic meaning.

For example:

County Plan Index
→ containsMember
→ plan:H5521-290-0

communicates something different from:

Contract Plan Index
→ containsMember
→ plan:H5521-290-0

The plan identity may be identical in both cases.

The relationship to the collection establishes a different context.

This is central to the role of IndexFragment.

An IndexFragment does not merely expose identifiers. It represents membership within a defined collection or option space.

Relationships and Directories

Directory structures frequently depend on relationships among:

  • the directory;
  • directory entries;
  • canonical entities;
  • geographic scope;
  • eligibility or availability;
  • and canonical resources.

For example:

County Directory
→ containsEntry
→ Directory Entry

Directory Entry
→ represents
→ Plan

Plan
→ availableIn
→ County

Plan
→ canonicalResource
→ Plan Resource

These distinctions allow a directory entry to function as a representation within a collection without becoming a duplicate identity for the underlying plan.

Relationships and Definitions

Terminology often depends on relationships among definitions and the knowledge that uses them.

For example:

Assertion
→ usesTerm
→ Maximum Out-of-Pocket

Maximum Out-of-Pocket
→ definedBy
→ DefinedTermFragment

DefinedTerm
→ memberOf
→ Medicare Glossary

This allows the assertion to remain concise while preserving a path to the meaning of specialized terminology.

Definitions should not be duplicated into every assertion merely to make the relationship explicit.

A stable identity and relationship can connect the assertion to the applicable definition.

Relationships and Resolution

Relationships provide the traversable structure required by the WebMEM Resolution Model.

Consider:

Known Identifier
→ Identity
→ Relationship
→ Related Entity
→ Relationship
→ Applicable Knowledge
→ Canonical Resource

For example:

H5521
→ contract:H5521
→ hasPlan
→ plan:H5521-290
→ hasSegment
→ segment:H5521-290-001
→ appliesIn
→ county:04015
→ hasBenefit
→ applicable premium

Each step depends on a relationship whose meaning is known.

Without those relationships, a machine may possess all of the participating objects but lack the structure necessary to move among them safely.

Resolution is relationship traversal constrained by identity, context, applicability, and provenance.

This does not require a consuming system to follow a prescribed reasoning algorithm.

It means the publisher has made the known structure available rather than requiring the machine to reconstruct it from document proximity or naming patterns.

Read the WebMEM Resolution Model →

Relationships and Resolvers

Resolvers operationalize relationships around a known identifier, entity, or context.

For example:

Contract ID
→ Contract
→ Carrier
→ Plans
→ Canonical Plan Resources

or:

County
→ Available Plans
→ Plan Identities
→ Plan Resources

or:

Formulary ID
→ Formulary
→ Plans Using Formulary
→ Applicable Plan Resources

A resolver is useful because the relationships among those objects have been represented explicitly enough to expose a coherent option space or resolution path.

A resolver is therefore not simply a page containing many links.

It is a publishing surface organized around identifiable relationships that allow a machine to move from known context toward applicable knowledge.

Read the Resolvers specification →

Relationships Are Not Navigation

A hyperlink establishes a navigational path between resources.

It does not necessarily establish the semantic relationship between the objects those resources describe.

For example:

<a href="/plans/H5521-290/">View Plan</a>

allows navigation.

It does not necessarily state:

contract:H5521
→ hasPlan
→ plan:H5521-290

or:

county:04015
→ hasAvailablePlan
→ plan:H5521-290

Navigation and semantic relationships may complement one another, but they should not be treated as equivalent concepts.

A link says where a machine can go. A relationship says why the destination is connected to the source.

Relationships Are Not Document Proximity

Two objects appearing near one another on a page does not establish a specific semantic relationship.

For example:

Plan Name
Premium
Formulary Link
County Name

may allow a human reader to infer relationships from layout.

A machine-facing representation should not depend solely on that proximity when the publisher already knows the relationships.

WebMEM can instead make the structure explicit:

Plan
→ hasPremium
→ Premium Assertion

Plan
→ usesFormulary
→ Formulary

Plan
→ availableIn
→ County

This is one of the central purposes of machine-facing knowledge representation: preserve relationships that human presentation otherwise leaves implicit.

Relationships Are Not Shared Labels

Objects should not be treated as related merely because they share a name, keyword, category, or other textual label.

For example, two plans containing the same carrier brand in their marketing names may have different contracts, service areas, benefits, formularies, or canonical identities.

Likewise, two policies using the same term may apply to different jurisdictions or time periods.

Relationships should be based on identifiable semantic connections rather than lexical similarity alone.

Relationships Are Not Identity Equivalence

One of the most important relationship distinctions is the difference between association and equivalence.

For example:

Plan
→ belongsToContract
→ Contract

does not imply:

Plan
→ equivalentTo
→ Contract

Likewise:

Entity
→ representedBy
→ Web Resource

does not imply:

Entity
→ equivalentTo
→ Web Resource

And:

Assertion
→ sourcedFrom
→ Dataset

does not make the assertion identical to the dataset.

Equivalence relationships should be used only where genuine semantic identity has been established at the applicable scope.

Relationships Are Not Automatically Transitive

A relationship should not be assumed to propagate through a chain unless the semantics of that relationship support transitivity.

For example:

Carrier
→ operatesContract
→ Contract

Contract
→ hasPlan
→ Plan

does not mean:

Carrier
→ operatesContract
→ Plan

The carrier may have a meaningful relationship to the plan, but that relationship is not the same relationship asserted between the carrier and contract.

Likewise:

Plan
→ availableIn
→ County

County
→ locatedIn
→ State

may support a broader conclusion that the plan participates in a market within that state, but it does not automatically establish that every semantic property of availableIn can be propagated from county to state.

And:

Assertion
→ derivedFrom
→ Dataset A

Dataset A
→ sourcedFrom
→ Dataset B

does not automatically mean:

Assertion
→ derivedFrom
→ Dataset B

Dataset B may participate in the assertion’s extended provenance lineage, but the direct relationship remains different.

Relationship chains may support reasoning. They should not silently rewrite the predicates that connect their objects.

Relationships Are Not Automatically Inherited

A relationship associated with one entity should not automatically be inherited by related entities.

For example:

Contract
→ hasPlan
→ Plan A

Contract
→ hasPlan
→ Plan B

does not imply that every relationship associated with Plan A also applies to Plan B.

Likewise:

Plan
→ hasSegment
→ Segment A

Segment A
→ appliesIn
→ County X

does not necessarily imply:

Plan
→ appliesIn
→ County X

unless the domain model establishes that the segment-level relationship can be generalized safely to the parent plan.

This is particularly important when child entities exist precisely because applicability differs among them.

Parent-child structure creates a path between entities. It does not automatically propagate every relationship across that path.

Relationship Context

A relationship may depend on context established outside the relationship itself.

For example:

SDT
  plan_year: 2026
  geography: Mohave County, Arizona

  IndexFragment
    county:04015
    → hasAvailablePlan
    → plan:H5521-290-0

The relationship may inherit the applicable plan year and geographic context from the containing structure when that context is unambiguous.

If the relationship has a more specific scope, that scope must remain explicit.

For example:

Plan
→ hasSegment
→ Segment A

Segment A
→ appliesIn
→ County X

Segment B
→ appliesIn
→ County Y

The different geographic relationships should not be flattened into a generic plan-level relationship if doing so would erase the distinction that the segments were created to preserve.

Relationship Provenance

Relationships are assertions and may themselves require provenance.

For example:

plan:H5521-290-0
→ availableIn
→ county:04015

may be supported by a CMS Landscape dataset.

Another relationship:

plan:H5521-290-0
→ usesFormulary
→ formulary:00012345

may be supported by a different CMS source.

And:

contract:H5521
→ operatedBy
→ carrier:example-health

may have another evidentiary source.

Membership in the same SDT does not give these relationships identical provenance.

Where the source of a relationship materially affects its interpretation or reliability, WebMEM should preserve the applicable lineage.

Provenance applies to relationships for the same reason it applies to factual assertions: the publisher should be able to distinguish what relationship is asserted from how the publisher knows that relationship exists.

Relationship Granularity

Relationship granularity should preserve the distinctions necessary for interpretation and resolution.

Too little granularity may collapse several meaningful relationships into a generic association:

Plan
→ relatedTo
→ Contract

Plan
→ relatedTo
→ County

Plan
→ relatedTo
→ Formulary

A more useful representation may preserve:

Plan
→ belongsToContract
→ Contract

Plan
→ availableIn
→ County

Plan
→ usesFormulary
→ Formulary

Too much granularity can create unnecessary relationship objects where ordinary structural containment or inherited context already preserves the meaning adequately.

The goal is not to maximize the number of edges in the knowledge model.

The goal is to preserve the relationships necessary to understand how identifiable knowledge objects actually connect.

Relationship Vocabulary

WebMEM does not require one universal relationship vocabulary for every domain.

Different domains may require predicates appropriate to their own entities and structures.

A healthcare implementation may require relationships such as:

hasPlan
hasSegment
availableIn
usesFormulary
operatedBy

A regulatory implementation may require:

governs
appliesTo
hasException
supersedes

A procedural implementation may require:

requires
precedes
follows
resultsIn

And provenance may require:

sourcedFrom
normalizedFrom
derivedFrom
generatedBy

The protocol may define common relationship semantics where interoperability benefits from standardization while allowing domain-specific vocabularies where the domain requires greater precision.

Domain-specific predicates should remain understandable, consistently applied, and sufficiently scoped to avoid ambiguous interpretation.

Relationship Types Do Not Replace Fragment Classes

Relationships and Fragment Classes perform different semantic functions.

A Fragment Class establishes what kind of knowledge object a fragment represents.

A relationship establishes how that object connects to another identifiable object.

For example:

PolicyFragment
→ governs
→ Program

EligibilityFragment
→ determinesEligibilityFor
→ Program

ProcedureFragment
→ appliesTo
→ Program

The predicates do not turn the fragments into policies, eligibility structures, or procedures.

The Fragment Classes establish those semantic roles.

The relationships connect the resulting knowledge objects.

Minimum Relationship Model

The exact relationship information required by a WebMEM representation depends on the knowledge being represented.

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

  • Source: the identifiable object from which the relationship originates;
  • Predicate: the semantic nature of the relationship;
  • Target: the identifiable object to which the relationship points;
  • Scope: applicable temporal, geographic, jurisdictional, population, or other context when that context materially affects the relationship;
  • Provenance: the evidentiary basis of the relationship when source lineage is material;
  • Direction: the source-to-target direction when direction contributes to meaning;
  • and Identity Resolution: enough identity information to distinguish the objects connected by the relationship.

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

The requirement is not that every relationship become an independently addressable object.

The requirement is that the connection and its semantic meaning remain recoverable.

Relationship Failure Modes

Several common patterns cause relationship meaning to collapse.

Generic Relationship Collapse

Specific relationships are reduced to:

relatedTo

even when the publisher knows whether the relationship means membership, availability, derivation, representation, governance, or another more precise connection.

Direction Collapse

A directional relationship is reversed or treated as symmetric when its semantics do not support that interpretation.

Identity Collapse

The objects at both ends of a relationship are merged, eliminating the relationship itself.

Contract = Plan

instead of:

Contract
→ hasPlan
→ Plan

Scope Collapse

A relationship valid only for a particular geography, time period, jurisdiction, population, or other context is generalized beyond that scope.

Inheritance Leakage

A relationship associated with a parent, child, collection member, or neighboring object is assumed to apply to related objects without evidence.

False Transitivity

A relationship is propagated through multiple objects even though the predicate does not support transitive reasoning.

False Equivalence

An association, representation, parent-child relationship, or shared membership is incorrectly treated as identity equivalence.

Navigation Substitution

A hyperlink is treated as though it fully communicates the semantic relationship between the objects represented by the linked resources.

Proximity Substitution

Objects appearing near one another in a document are assumed to have a specific semantic relationship that the publisher never actually represented.

Provenance Collapse

Different relationships are assumed to share the same evidentiary source merely because they participate in the same SDT or fragment.

These failures may leave every participating object intact while destroying the structure that explains how those objects fit together.

Example: Medicare Entity Relationships

A simplified Medicare entity structure may include:

Carrier
  ↓ operatesContract
Contract
  ↓ hasPlan
Plan
  ↓ hasSegment
Segment
  ↓ appliesIn
County

Additional relationships may connect:

Plan
→ usesFormulary
→ Formulary

Plan
→ availableIn
→ County

Plan
→ canonicalResource
→ Plan Resource

Contract
→ canonicalResource
→ Contract Resolver

County
→ hasAvailablePlan
→ Plan

Each object has its own identity.

Each relationship has its own semantic meaning.

The resulting structure allows a machine to traverse the Medicare information space without treating contracts, plans, segments, counties, formularies, and resources as interchangeable objects.

Example: Relationship-Driven Resolution

Suppose a machine begins with:

Contract ID: H5521

Identity resolution establishes:

H5521
→ identifies
→ contract:H5521

Relationships then expose:

contract:H5521
→ operatedBy
→ carrier:example-health

contract:H5521
→ hasPlan
→ plan:H5521-290

contract:H5521
→ hasPlan
→ plan:H5521-291

Each plan may then expose:

plan:H5521-290
→ canonicalResource
→ /plans/H5521-290/

plan:H5521-291
→ canonicalResource
→ /plans/H5521-291/

The machine has moved from:

Identifier
→ Entity
→ Relationships
→ Related Entities
→ Canonical Resources

The resolver did not invent those relationships during retrieval.

The publisher represented them as part of the knowledge architecture.

Example: Geographic Resolution

Consider a parent plan whose applicable segment depends on geography:

plan:H5521-290
│
├── hasSegment
│   └── segment:H5521-290-001
│       └── appliesIn
│           └── county:04015
│
└── hasSegment
    └── segment:H5521-290-002
        └── appliesIn
            └── county:04013

If the information need is:

What is the premium for H5521-290 in Mohave County?

the relationship structure supports:

plan:H5521-290
→ hasSegment
→ segment:H5521-290-001
→ appliesIn
→ county:04015
→ resolve applicable segment
→ retrieve segment-specific premium

The correct answer depends on the relationships.

Without them, the machine may possess every plan, segment, county, and premium value while lacking the structure necessary to determine which value applies.

This is why relationships are foundational to resolution rather than merely descriptive connections among already-resolved objects.

Example: Provenance Relationships

Consider a county-level derived statistic:

zero_premium_percentage = 61.9 percent

The relationship structure may include:

Derived Assertion
→ derivedFrom
→ CMS Landscape Dataset

Derived Assertion
→ basedOnPopulation
→ Applicable County Plan Index

Derived Assertion
→ generatedBy
→ Publisher Calculation

Applicable County Plan Index
→ scopedTo
→ county:04015

The resulting structure preserves not only the source but the relationships connecting source, population, derivation, geography, and output.

This is the difference between attaching a citation and representing lineage.

Conformance

A conforming WebMEM representation must preserve relationships necessary to interpret how its identifiable knowledge objects connect.

Specifically, a conforming implementation must:

  • identify or make resolvable the source and target of a material relationship;
  • use a relationship predicate sufficiently precise to communicate the known semantic connection;
  • preserve direction when direction materially affects meaning;
  • preserve temporal, geographic, jurisdictional, population, or other scope when that scope materially affects the relationship;
  • preserve provenance when the evidentiary basis of the relationship is material;
  • avoid treating related entities as equivalent entities without evidence of genuine equivalence;
  • avoid propagating relationships through parent-child or other structures unless the relationship semantics support that propagation;
  • avoid assuming transitivity unless the predicate is defined or known to be transitive;
  • distinguish semantic relationships from navigation links;
  • distinguish explicit relationships from document proximity or shared labels;
  • preserve identity boundaries among the objects connected by the relationship;
  • and preserve enough relationship structure for applicable resolution paths to operate on the intended objects.

Conformance does not require every relationship to exist as an independent fragment or addressable resource.

Relationships may be represented within fragments, inherited from unambiguous context, or expressed through references to other identifiable objects.

The governing requirement is preservation of the semantic connection.

Relationship to WebMEM 1.x

Relationships were present throughout WebMEM 1.x through mechanisms including related_fragments, inherits_from, glossary references, provenance references, entity attributes, digest membership, follow-up references, directory structures, and class-specific logic.

Those mechanisms established an important principle: WebMEM fragments do not exist as isolated units. Their usefulness depends in part on the connections among entities, facts, sources, definitions, and other knowledge objects.

WebMEM 1.x, however, often coupled relationships to YAML-specific fields, semantic digests, retrieval behavior, memory reinforcement, or other implementation mechanisms.

The current protocol separates the durable relationship model from those earlier mechanisms.

The current architecture clarifies that:

  • relationships connect identifiable knowledge objects;
  • the relationship predicate carries semantic meaning;
  • relationship direction may be meaningful;
  • relationships may have their own applicability scope;
  • relationships may require provenance;
  • relationships do not erase identity boundaries;
  • relationships are not automatically inherited or transitive;
  • navigation links are not substitutes for semantic relationships;
  • document proximity is not a relationship model;
  • relationships may connect objects within one SDT or across multiple resources;
  • and relationship traversal provides much of the structure required by the WebMEM Resolution Model.

The current protocol therefore elevates relationships from fragment-linking mechanics to a cross-cutting semantic layer of the WebMEM architecture.

Identity establishes the objects. Provenance establishes their lineage. Relationships establish how the objects fit together.

Relationships and Protocol Integrity

Relationships are one of the conditions that allow the WebMEM knowledge model to remain coherent when knowledge is separated from the human-facing document structures that originally implied how its parts fit together.

Without explicit or recoverable relationships:

  • parent and child entities may remain identifiable without preserving their hierarchy;
  • collection members may remain identifiable without preserving what collection they belong to;
  • plans may remain identifiable without preserving where they are available;
  • formularies may remain identifiable without preserving which plans use them;
  • policies may remain identifiable without preserving what they govern;
  • procedures may retain their steps without preserving prerequisites, sequence, or applicable programs;
  • definitions may remain available without preserving which assertions depend on them;
  • sources may remain cited without preserving how they support or produce particular assertions;
  • entities may have canonical resources without preserving which resource represents which entity;
  • and all of the objects required for a resolution path may exist without preserving the path connecting them.

The result can be a collection of individually valid knowledge objects whose larger structure has disappeared.

This is the relationship equivalent of identity and provenance collapse.

Without Identity
→ the subject can collapse

Without Provenance
→ the lineage can collapse

Without Relationships
→ the structure connecting the knowledge can collapse

These failures are independent.

Perfect identity cannot reconstruct a relationship the publisher never represented.

Perfect provenance cannot establish that a plan belongs to a particular contract, uses a particular formulary, or is available in a particular county unless that relationship is supported by the represented knowledge.

And a complete collection of individually correct facts does not necessarily reveal how those facts participate together in a larger information structure.

Relationships preserve the connective meaning of WebMEM knowledge.

From Knowledge Objects to Resolvable Structure

Identity, provenance, and relationships together establish the structural foundation required for resolution.

Conceptually:

Identity
→ establishes what the objects are

Provenance
→ establishes where the knowledge came from

Relationships
→ establish how the objects connect

Resolution
→ uses identity, context, and relationships
  to reach the applicable knowledge or resource

Consider a Medicare information space containing:

Carrier
Contract
Plan
Segment
County
Formulary
Benefit
Canonical Resource

Merely publishing all eight objects does not create a resolvable information model.

The useful structure emerges from the relationships:

Carrier
→ operatesContract
→ Contract

Contract
→ hasPlan
→ Plan

Plan
→ hasSegment
→ Segment

Segment
→ appliesIn
→ County

Plan
→ usesFormulary
→ Formulary

Segment
→ hasBenefit
→ Benefit

Plan
→ canonicalResource
→ Canonical Resource

Now the publisher has represented not merely a collection of objects, but a traversable information structure.

A consuming system may choose its own reasoning or traversal strategy.

WebMEM’s responsibility is to preserve the known relationships so the machine does not have to reconstruct them from names, document proximity, URL patterns, or other indirect signals.

Relationships turn identifiable knowledge objects into resolvable knowledge structure.

Related Protocol Documents