WebMEM™

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

WebMEM Resolution Model

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

Overview

Resolution is the process of moving from an identifier, entity, context, or information need through known identity, relationships, and applicability constraints to the specific knowledge object or resource required to satisfy that need correctly.

Resolution addresses a fundamental problem in machine-mediated information systems:

The existence of a correct fact does not mean that fact is the correct answer.

A publisher may possess accurate, well-sourced, correctly identified knowledge while still requiring additional context before determining which knowledge applies.

For example:

Plan
├── Segment A → premium = 0 USD
├── Segment B → premium = 18.50 USD
└── Segment C → premium = 32.00 USD

All three premium assertions may be correct.

If the information need is:

What is the premium for this plan?

the correct answer cannot necessarily be determined from the plan identity alone.

Additional context may be required:

Plan
→ Segments
→ Geographic Context
→ Applicable Segment
→ Premium Assertion

Resolution is the mechanism by which available knowledge becomes applicable knowledge.

Why Resolution Is Structural

WebMEM separates several semantic concerns:

Semantic Concern Question Answered
Identity What entity or object does this knowledge describe?
Provenance Where did the knowledge come from, and how was it produced?
Relationships How do the identifiable objects connect?
Context Where, when, for whom, or under what conditions does the knowledge apply?
Resolution Which knowledge object or resource satisfies the information need under the applicable identity and context?

Identity, provenance, relationships, and context may all be correct while the final answer remains unresolved.

Resolution is therefore not another name for any one of those components.

It is the process through which those components converge on applicable knowledge.

Correct Knowledge and Applicable Knowledge

WebMEM distinguishes between knowledge that is correct within its own scope and knowledge that is applicable to the current information need.

Consider:

segment:H5521-290-001
monthly_premium = 18.50 USD

segment:H5521-290-002
monthly_premium = 32.00 USD

Both assertions may be:

  • correct;
  • current;
  • properly identified;
  • supported by authoritative provenance;
  • and represented within conforming WebMEM fragments.

But only one may apply to a particular geography.

If the information need concerns Mohave County, the machine may need to resolve:

Plan
→ hasSegment
→ Candidate Segments
→ appliesIn
→ Mohave County
→ Applicable Segment
→ monthly_premium

The non-applicable premium is not necessarily false.

It is simply not the answer to the current information need.

A fact can be true and still be inapplicable.

Resolution Context

A resolution process begins with the information already known or supplied.

This is the resolution context.

Resolution context may include:

  • an identifier;
  • an identified entity;
  • an entity type;
  • a requested property or information need;
  • geographic context;
  • temporal context;
  • jurisdiction;
  • population;
  • program or policy context;
  • eligibility conditions;
  • collection membership;
  • or another condition necessary to determine applicability.

For example:

identifier: H5521-290
requested_property: monthly_premium
geography: county:04015
plan_year: 2026

The resolution context does not need to exist as a separate WebMEM Fragment Class.

It is a conceptual description of the known information against which represented knowledge can be resolved.

The Resolution Path

A resolution path is the sequence of identifiable objects, relationships, and applicability conditions connecting the initial context to the resolved knowledge object or resource.

A generalized path may resemble:

Information Need
        ↓
Known Identifier or Entity
        ↓
Identity Resolution
        ↓
Candidate Knowledge or Related Entities
        ↓
Relationship Traversal
        ↓
Applicability Constraints
        ↓
Applicable Knowledge Object
        ↓
Canonical Resource, if required

Not every resolution requires every stage.

A simple resolution may be:

Plan ID
→ Plan
→ Canonical Resource

A more complex resolution may be:

Plan ID
→ Plan
→ Segments
→ Geography
→ Applicable Segment
→ Benefit Assertion

And another domain may require:

Program
→ Policy
→ Eligibility Criteria
→ User Context
→ Applicable Procedure
→ Application Resource

The architecture is the same even though the domain and relationships differ.

Resolution Begins With Identity

A resolution process cannot reliably proceed until the initial reference has been interpreted at the correct identity scope.

For example:

H5521

may resolve as:

identifier_type: CMS Contract ID
entity_type: Contract
entity: contract:H5521

while:

H5521-290

may resolve as:

identifier_type: CMS Contract + Plan ID
entity_type: Plan
entity: plan:H5521-290

If the first step resolves an identifier to the wrong entity type or scope, every subsequent relationship traversal may operate on the wrong object.

Resolution cannot be more precise than the identity on which it begins.

Read the Identity specification →

Resolution Uses Relationships

Once identity has been established, relationships provide the structure through which resolution can continue.

For example:

contract:H5521
→ hasPlan
→ plan:H5521-290

or:

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

or:

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

or:

plan:H5521-290
→ usesFormulary
→ formulary:00012345

The machine does not need to infer these connections from URL patterns, names, document proximity, or repeated identifiers when the publisher has represented the relationships explicitly.

Relationships provide the traversable structure of resolution.

Read the Relationships specification →

Resolution Uses Applicability

Relationship traversal may produce multiple candidate knowledge objects.

Applicability determines which candidate satisfies the current context.

For example:

Plan
├── hasSegment → Segment A
├── hasSegment → Segment B
└── hasSegment → Segment C

The resolution context contains:

geography: county:04015

The candidate relationships may establish:

Segment A
→ appliesIn
→ county:04015

Segment B
→ appliesIn
→ county:04013

Segment C
→ appliesIn
→ county:04025

The geography eliminates the non-applicable candidates.

Resolution continues with Segment A.

Applicability may depend on:

  • geography;
  • time;
  • jurisdiction;
  • population;
  • entity subtype;
  • program eligibility;
  • policy conditions;
  • collection membership;
  • or another domain-specific constraint.

Temporal Resolution

Time may determine which otherwise valid knowledge object applies.

For example:

plan:H5521-290-0

2025
monthly_premium = 0 USD

2026
monthly_premium = 18.50 USD

The question:

What is the premium for H5521-290-0?

is temporally ambiguous unless the applicable plan year can be determined.

The resolution path may require:

Plan
→ Requested Property
→ Applicable Plan Year
→ Current Assertion

The most recently published assertion is not necessarily the assertion applicable to the requested period.

Resolution should therefore preserve the distinction between:

  • publication time;
  • retrieval time;
  • effective time;
  • applicability time;
  • and the time context of the information need.

Geographic Resolution

Geography is a common resolution constraint when entities, services, products, benefits, or policies vary by location.

For example:

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

Given:

plan: H5521-290
geography: county:04015

the represented relationships support:

Plan
→ Candidate Segments
→ Geographic Applicability
→ segment:H5521-290-001

The geographic context does not modify the identities of the segments.

It determines which identified segment is applicable to the information need.

Jurisdictional Resolution

Policies, procedures, eligibility requirements, legal definitions, and public programs may vary by jurisdiction.

For example:

Policy A
→ appliesIn
→ Jurisdiction X

Policy B
→ appliesIn
→ Jurisdiction Y

An information need concerning Jurisdiction X should not resolve to Policy B merely because both policies address the same topic.

Jurisdiction may therefore operate as an applicability constraint:

Topic
→ Candidate Policies
→ Jurisdiction
→ Applicable Policy
→ Applicable Procedure

This is another example of correct knowledge that may nevertheless be inapplicable outside its scope.

Eligibility Resolution

Some resolution paths depend on conditions associated with a person, organization, program, or other context.

For example:

Program
→ EligibilityFragment
→ Eligibility Criteria
→ Context
→ Eligible / Not Eligible
→ Applicable Procedure

The WebMEM representation may publish the eligibility structure and its relationships.

A consuming system may evaluate those conditions according to its own capabilities and policies.

WebMEM does not require the publisher to execute the eligibility decision.

The protocol’s responsibility is to preserve:

  • the program identity;
  • the applicable policy;
  • the eligibility criteria;
  • the relationships among them;
  • and the procedures or resources associated with applicable outcomes.

This preserves a resolution path without defining a universal agent-execution model.

Resolution and Provenance

Provenance may constrain or inform resolution when candidate knowledge objects differ by source, source version, derivation, publication period, or evidentiary lineage.

For example:

Assertion A
  plan_year: 2025
  source: CMS PBP 2025

Assertion B
  plan_year: 2026
  source: CMS PBP 2026

Temporal context may resolve the applicable assertion.

In another case:

Assertion A
  sourcedFrom: Authoritative Dataset

Assertion B
  derivedFrom: Secondary Dataset

WebMEM exposes the provenance distinction.

The consuming system may use that distinction as part of its own evaluation.

WebMEM does not prescribe which source must be preferred merely because one provenance path differs from another.

Provenance makes the candidate lineages explicit. Resolution determines applicability; the consuming system determines how it evaluates authority.

Read the Provenance specification →

Resolution and Fragment Classes

Resolution may traverse knowledge represented by several Fragment Classes.

For example:

IdentityFragment
→ establishes entity

IndexFragment
→ exposes candidate members

DirectoryFragment
→ describes candidate entries

PolicyFragment
→ establishes applicable rule

EligibilityFragment
→ establishes qualification conditions

DataFragment
→ provides source-observed facts

DerivedStatsFragment
→ provides derived context

ProcedureFragment
→ provides applicable process

No Fragment Class owns resolution.

Resolution operates across the knowledge represented by the SDT.

This is why Resolver is not a Fragment Class.

Resolution and SDT Composition

SDT composition brings the knowledge objects required for resolution into a coherent page-level representation.

For example:

County SDT
│
├── IdentityFragment
│   └── county identity
│
├── IndexFragment
│   └── available plans
│
├── DirectoryFragment
│   └── plan entries
│
├── DataFragment
│   └── market facts
│
└── DerivedStatsFragment
    └── county statistics

The SDT establishes that these objects participate in the same resource knowledge.

Relationships establish how they connect.

Resolution uses those connections and the applicable context to move toward the requested knowledge or resource.

Read SDT Composition →

Resolution and Collections

A collection may represent an option space from which resolution continues.

For example:

County
→ hasAvailablePlan
→ Plan A
→ Plan B
→ Plan C

The IndexFragment establishes the applicable collection.

Resolution may then continue based on additional context:

County
→ Available Plans
→ Plan Type
→ Applicable Plans
→ Plan Identity
→ Canonical Resources

The collection itself may be the resolved answer when the information need asks for the option space:

What Medicare Advantage plans are available in this county?

In another information need, the collection may only be an intermediate resolution state.

Resolution and Canonical Resources

Resolution does not always terminate at a factual assertion.

It may terminate at an identifiable resource.

For example:

Plan ID
→ Plan Entity
→ canonicalResource
→ Plan Resource

or:

Formulary ID
→ Formulary Entity
→ canonicalResource
→ Formulary Resource

or:

Policy
→ Applicable Procedure
→ applicationResource
→ Official Application

A canonical-resource relationship allows WebMEM to distinguish the resolved entity from the resource through which additional knowledge about that entity can be accessed.

The entity and resource remain distinct:

Resolved Entity
≠
Canonical Resource

Resolution may therefore terminate at either:

  • the applicable knowledge object itself;
  • an identifiable entity;
  • a collection or option space;
  • or a canonical resource through which the applicable knowledge can be accessed.

The appropriate terminal state depends on the information need.

Resolution Completeness

Resolution is complete when the available identity, context, relationships, and applicability constraints are sufficient to identify the knowledge object or resource required by the information need without unresolved ambiguity material to that need.

For example:

Information Need:
What is the premium for H5521-290
in county:04015 for plan year 2026?

Known:
plan:H5521-290
county:04015
plan_year:2026

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

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

Resolved:
segment:H5521-290-001

Applicable Assertion:
monthly_premium = 18.50 USD

No unresolved ambiguity remains that would materially affect the requested premium.

The resolution is complete.

Incomplete Resolution

Resolution is incomplete when the represented knowledge contains multiple materially different candidate outcomes and the available context is insufficient to determine which one applies.

For example:

plan:H5521-290
│
├── segment:H5521-290-001
│   └── monthly_premium = 18.50 USD
│
└── segment:H5521-290-002
    └── monthly_premium = 32.00 USD

If the information need provides only:

plan:H5521-290

and segment applicability depends on geography, then the premium is unresolved.

The correct state is not:

premium = 18.50 USD

or:

premium = 32.00 USD

The correct state is conceptually:

UNRESOLVED

required_context:
  geography

When material ambiguity remains, unresolved is a valid and preferable result.

Resolution Should Preserve Ambiguity

WebMEM does not require a publisher to manufacture a single answer when the represented knowledge does not support one.

Consider:

Information Need
        ↓
Candidate A
Candidate B
Candidate C
        ↓
Insufficient Context

If the candidates remain materially different after all available constraints have been applied, the resolution process should preserve that ambiguity.

A machine-facing representation may identify:

  • the remaining candidates;
  • the context required to distinguish among them;
  • the relationship or applicability condition that remains unresolved;
  • or the canonical resources through which additional resolution may occur.

Unsupported certainty is not successful resolution.

Resolution Failure Modes

Resolution can fail at several different stages.

Identity Failure

The initial identifier, name, or reference cannot be resolved to a sufficiently specific entity.

Observed Identifier
→ unknown identifier type
→ unresolved entity

Relationship Failure

The entity is known, but the relationship required to continue the resolution path is unavailable or ambiguous.

Plan
→ known identity
→ segment relationship unavailable
→ unresolved applicability

Context Failure

The candidate knowledge is known, but required contextual information is missing.

Plan
→ Segments
→ geography required
→ geography unknown
→ unresolved

Applicability Failure

Available context does not uniquely determine which candidate applies.

Candidate A
Candidate B
→ both satisfy known constraints
→ unresolved

Temporal Failure

Multiple knowledge objects apply to different periods, but the relevant time context cannot be determined.

Relationship Conflict

Represented relationships produce materially incompatible resolution paths.

Knowledge Conflict

Multiple apparently applicable assertions remain materially inconsistent after identity, context, and applicability have been resolved.

Terminal Failure

The resolution path succeeds structurally, but the requested knowledge object or resource is not represented or available.

Entity
→ correctly resolved
→ applicable context resolved
→ requested property absent

These failure states are semantically different and should not automatically be collapsed into a generic “not found” result.

Resolution Is Not Retrieval

Retrieval and resolution are related but distinct processes.

Retrieval generally asks:

What information appears relevant to this query?

Resolution asks:

What does the known reference represent, and which knowledge object or resource applies under the current context?

For example:

Query:
H5521

Retrieval may produce:

Pages mentioning H5521

Resolution may establish:

H5521
→ CMS Contract ID
→ contract:H5521
→ related carrier
→ related plans
→ canonical resources

Retrieval may provide candidate information for resolution.

Resolution may identify resources that can subsequently be retrieved.

But the two processes should not be treated as equivalent.

Retrieval finds candidate information. Resolution determines what the candidate represents and whether it satisfies the information need.

Resolution Is Not Search

Search generally operates by matching, ranking, or discovering resources in response to an information need.

Resolution begins from a known or partially known identity, entity, context, or semantic requirement and attempts to reach the applicable knowledge object.

For example:

Search:
"Medicare plans Mohave County"

Possible result:
ranked web resources

versus:

Resolution:
county:04015
→ hasAvailablePlan
→ applicable plan collection

Search may discover a resolver.

The resolver may then expose the structured resolution model associated with the county.

Resolution Is Not Model Reasoning

The WebMEM Resolution Model does not prescribe how a language model, search engine, agent, crawler, or other consuming system must reason.

WebMEM operates on the publisher side.

The publisher may know that:

Plan
→ hasSegment
→ Segment

Segment
→ appliesIn
→ County

Segment
→ hasBenefit
→ Benefit

WebMEM allows that known structure to be published explicitly.

A consuming system may traverse, compare, validate, rank, ignore, or otherwise evaluate that structure according to its own architecture and policies.

WebMEM publishes known resolution structure. It does not prescribe a reasoning algorithm.

Resolution Is Not Agent Execution

A resolution path may include policies, eligibility conditions, procedures, or other structures that a capable agent could potentially evaluate or act upon.

That does not make WebMEM an execution framework.

For example:

Program
→ Eligibility Criteria
→ Applicable Procedure
→ Application Resource

represents a resolution structure.

It does not require the consuming system to:

  • make an eligibility determination;
  • submit an application;
  • execute a procedure;
  • make a purchase;
  • enroll a user;
  • or perform another external action.

Those capabilities belong to the consuming system and its applicable authorization, safety, and execution model.

Resolution Is Not Recommendation

Resolution determines which knowledge or option space applies.

Recommendation expresses a publisher-defined judgment about what option, action, or resource should be preferred under some stated basis.

For example:

Resolution:
county:04015
→ available plans
→ Plan A
→ Plan B
→ Plan C

does not imply:

Recommendation:
Choose Plan A

A RecommendationFragment may operate on knowledge reached through resolution, but the two semantic functions remain distinct.

Resolution determines applicability. Recommendation expresses preference or guidance.

Resolution Is Not Inference by Proximity

A consuming system should not need to infer a resolution path merely because objects appear near one another in a document.

For example:

Plan Name
County Name
Premium
Formulary Link

may visually imply relationships to a human reader.

A machine-facing representation can preserve:

Plan
→ availableIn
→ County

Plan
→ usesFormulary
→ Formulary

Applicable Segment
→ hasPremium
→ Premium Assertion

The publisher is representing known structure rather than forcing the consuming system to reconstruct it from presentation.

Resolution Is Not Forced Uniqueness

Some information needs legitimately resolve to more than one object.

For example:

What Medicare Advantage plans are available in county:04015?

may correctly resolve to:

Available Plan Collection
├── Plan A
├── Plan B
├── Plan C
└── Plan D

The collection is the resolved result.

Resolution does not require selecting one plan merely because one result would be simpler.

Likewise, an identifier may legitimately resolve to an entity with several related resources or options.

Successful resolution means reaching the correct semantic result, not necessarily reducing the result to one object.

Resolution Targets

A resolution target is the knowledge object, entity, collection, or resource that satisfies the information need.

Possible targets include:

  • a factual assertion;
  • an identifiable entity;
  • a Fragment;
  • a collection represented by an IndexFragment;
  • a directory or directory entry;
  • a policy;
  • an eligibility structure;
  • a procedure;
  • a defined term;
  • a recommendation;
  • a canonical resource;
  • or another applicable WebMEM knowledge object.

The information need determines what counts as successful resolution.

Resolution Depth

Resolution should continue only as far as necessary to satisfy the information need correctly.

For example:

Question:
Who operates contract H5521?

H5521
→ contract:H5521
→ operatedBy
→ carrier:example-health

STOP

There is no need to continue into plans, segments, counties, formularies, or benefits.

Another question may require deeper traversal:

Question:
What premium applies to plan H5521-290 in county:04015?

H5521-290
→ Plan
→ Segments
→ Geographic Applicability
→ Applicable Segment
→ Premium Assertion

STOP

Resolution depth is determined by the information need, not by the maximum depth of the available knowledge graph.

Resolution and Option Spaces

An important resolution target is an option space: the set of applicable entities or choices available within a defined context.

For example:

county:04015
→ Medicare coverage option space
    ├── Medicare Advantage
    ├── Special Needs Plans
    ├── Part D
    └── Medigap

or:

contract:H5521
→ plan option space
    ├── Plan 290
    ├── Plan 291
    └── Plan 292

or:

formulary:00012345
→ related plan option space
    ├── Plan A
    ├── Plan B
    └── Plan C

Resolution to an option space is especially useful when the information need occurs before a specific decision path has been chosen.

The publisher can expose the applicable landscape without prematurely selecting one option.

Resolution and the Publisher

The publisher occupies a unique position in the resolution architecture because the publisher often already knows relationships that are difficult for an external consuming system to reconstruct reliably.

The publisher may know:

  • which identifier type is represented;
  • which entity the identifier resolves to;
  • which parent and child entities exist;
  • which geographic or temporal relationships apply;
  • which collections contain the entity;
  • which source establishes those relationships;
  • which canonical resources represent the entity;
  • and where material ambiguity remains.

WebMEM allows the publisher to expose that known structure rather than leaving every consuming system to reconstruct it independently.

This is a central architectural principle:

If the publisher already knows the resolution structure, the machine-facing publication should not unnecessarily force the consuming system to rediscover it.

The Resolution Boundary

WebMEM does not claim that every information need can be fully resolved from one resource.

A resource may expose only part of a larger resolution path.

For example:

County Resolver
→ Plan Identity
→ Canonical Plan Resource

The county resolver may terminate at the plan resource.

The plan resource may then expose:

Plan
→ Formulary
→ Provider Network
→ Benefits

Another resolver may expose:

Formulary
→ Related Plans
→ Canonical Plan Resources

These resources can participate in a larger resolution architecture without requiring one page to contain the entire knowledge graph.

Stable identity and explicit relationships allow resolution to continue across resource boundaries.

Resolver Architecture

A resolver is a publisher-defined information surface designed around a known identifier, entity, or context from which a useful resolution path or option space can be exposed.

Examples include:

County Resolver
County
→ available option space
→ plans
→ canonical resources
Contract Resolver
Contract ID
→ Contract
→ Carrier
→ Plans
→ historical context
→ canonical resources
Formulary Resolver
Formulary ID
→ Formulary
→ related plans
→ applicability
→ canonical resources

The resolver is an implementation pattern built on the Resolution Model.

Resolution is the protocol concept. A resolver is a publisher-side architecture that operationalizes that concept around a defined entry point.

Read the Resolvers specification →

Resolution Failure Should Remain Visible

A machine-facing knowledge representation should not hide unresolved conditions merely to produce a cleaner output.

For example:

Known:
Plan

Required:
Geography

Available:
Multiple geographically scoped segments

Result:
UNRESOLVED

is semantically stronger than selecting one segment without sufficient evidence.

Likewise:

Known:
Program

Required:
Jurisdiction

Available:
Multiple jurisdiction-specific policies

Result:
UNRESOLVED

preserves the actual state of the knowledge.

Ambiguity is information. A conforming resolution model should not erase material ambiguity.

Resolution Failure Modes and Protocol Integrity

Several forms of resolution collapse can produce incorrect answers even when the underlying knowledge objects are individually correct.

Premature Resolution

A candidate is selected before all material applicability constraints have been evaluated.

Parent-Level Generalization

A child-specific assertion is treated as though it applies to the parent entity.

Child-Level Assumption

A parent-level assertion is treated as though it necessarily applies to every child.

Context Loss

Geographic, temporal, jurisdictional, population, or other applicability context is discarded before resolution is complete.

Relationship Shortcut

A machine skips an intermediate relationship necessary to determine applicability.

For example:

Plan
→ Premium

is used when the represented structure actually requires:

Plan
→ Segment
→ Geography
→ Applicable Segment
→ Premium

Option-Space Collapse

A valid collection of applicable options is incorrectly reduced to one option even though the information need does not support that selection.

Temporal Collapse

The newest, most recently retrieved, or most recently published assertion is assumed to be applicable without resolving the time period relevant to the information need.

Geographic Collapse

Knowledge valid in one geographic scope is generalized to another without a relationship establishing that applicability.

Jurisdictional Collapse

A policy, eligibility rule, definition, or procedure applicable in one jurisdiction is applied to another.

Retrieval Substitution

The most relevant retrieved object is treated as the resolved object without establishing identity and applicability.

Relationship Inference

A resolution path depends on a relationship inferred from naming, URL structure, document proximity, or another indirect signal even though the relationship has not been established by the represented knowledge.

False Terminal State

Resolution stops at an intermediate object even though the information need requires further traversal.

For example:

Question:
What is the applicable premium?

Resolution stops at:
Plan

Required:
Plan
→ Segment
→ Geography
→ Applicable Segment
→ Premium

Unsupported Certainty

Material ambiguity remains, but one candidate is nevertheless presented as uniquely resolved.

These failures share a common characteristic:

The knowledge may be correct while the path used to apply that knowledge is not.

Minimum Resolution Model

The exact resolution structure required by a WebMEM implementation depends on the domain and information need.

At minimum, a resolution model should make it possible to determine or preserve:

  • Entry Context: the identifier, entity, context, or information need from which resolution begins;
  • Identity: the entity or object represented by the entry context when identity is material;
  • Resolution Target: the type of knowledge object, entity, collection, or resource required to satisfy the information need;
  • Candidate Set: the potentially applicable objects when more than one candidate exists;
  • Relationships: the semantic connections through which resolution proceeds;
  • Applicability Constraints: geographic, temporal, jurisdictional, population, eligibility, entity-scope, or other conditions necessary to distinguish applicable candidates;
  • Terminal State: the knowledge object, entity, option space, or resource that satisfies the information need;
  • Unresolved State: remaining material ambiguity when the available context does not support complete resolution;
  • and Missing Context: information required to continue resolution when that requirement is known.

These components do not require a universal serialized Resolution object.

They may be represented through identities, fragments, relationships, assertions, collections, applicability context, and canonical-resource references already present within the WebMEM knowledge model.

The Resolution Model defines the semantic process. It does not require another universal object layer.

Resolution Granularity

Resolution should occur at the level of identity and context required by the information need.

For example:

Question:
Who operates contract H5521?

Required resolution:
Contract ID
→ Contract
→ Carrier

Segment-level resolution would add unnecessary depth.

But:

Question:
What premium applies to H5521-290 in county:04015?

Required resolution:
Plan
→ Segments
→ Geography
→ Applicable Segment
→ Premium

stopping at the parent plan would provide insufficient granularity.

The correct resolution boundary is therefore determined by the semantic requirements of the information need.

Resolution should be neither shallower nor deeper than necessary to remove ambiguity material to the requested knowledge.

Resolution and Provenance Integrity

Resolution should not destroy provenance while selecting among candidate knowledge objects.

For example:

Candidate A
→ source: CMS PBP 2025

Candidate B
→ source: CMS PBP 2026

If temporal context resolves Candidate B, the resulting assertion should retain the provenance of Candidate B.

The resolution process should not flatten the two candidates into:

source: CMS

merely because they share an originating organization.

Likewise, if resolution reaches a publisher-derived assertion, its derivation lineage should remain intact.

Resolution selects applicable knowledge. It does not rewrite the lineage of that knowledge.

Resolution and Identity Integrity

Resolution should preserve the identity boundaries traversed along the path.

For example:

Contract
→ Plan
→ Segment
→ Benefit

does not transform the Contract, Plan, Segment, and Benefit into one entity merely because they participate in one resolution path.

If the resolved assertion applies to the Segment, its subject remains the Segment.

The parent Plan may provide the entry point, but it does not acquire the Segment-specific assertion merely because resolution began there.

Resolution traverses identities. It does not collapse them.

Resolution and Relationship Integrity

Resolution should preserve the semantic meaning of the relationships through which it proceeds.

For example:

Contract
→ hasPlan
→ Plan

Plan
→ hasSegment
→ Segment

Segment
→ appliesIn
→ County

should not be reduced to:

Contract
→ relatedTo
→ County

if the intermediate relationships are necessary to explain how the applicable Segment was reached.

A consuming system may summarize or optimize traversal internally.

The publisher-side representation should preserve the actual known structure.

Resolution uses relationships. It should not erase the relationships that made the resolution possible.

Resolution as a Publisher-Side Responsibility

WebMEM does not require publishers to predict every question a machine may ask.

It does require publishers to consider whether the knowledge they already possess contains material resolution structure that would otherwise remain implicit.

If the publisher knows:

Plan
→ has multiple Segments

Segments
→ vary by Geography

Benefits
→ vary by Segment

then publishing only:

Plan
→ Benefit

may remove information necessary to apply the benefit correctly.

Likewise, if the publisher knows:

Contract ID
→ Contract
→ Plans

then exposing the Contract ID merely as text leaves a known resolution structure unpublished.

The WebMEM Resolution Model therefore asks publishers to preserve the distinctions they already know are necessary to move from general context toward applicable knowledge.

Resolution and Machine Uncertainty

Resolution does not eliminate uncertainty from machine systems.

Instead, it allows the publisher to distinguish uncertainty caused by missing or ambiguous knowledge from ambiguity that has already been resolved by the publisher’s own information model.

For example:

Publisher knows:
Segment A applies to County X
Segment B applies to County Y

There is no reason to force the consuming machine to infer those geographic relationships.

But if the publisher does not know which segment applies to County Z, WebMEM should not fabricate that relationship merely to complete the resolution path.

The distinction is:

Known Structure
→ publish explicitly

Unknown Structure
→ preserve as unresolved

WebMEM reduces avoidable ambiguity without pretending to eliminate legitimate uncertainty.

Conformance

A conforming WebMEM representation that exposes a resolution path must preserve enough identity, context, relationships, and applicability information to prevent materially ambiguous candidates from being represented as uniquely resolved without support.

Specifically, a conforming implementation must:

  • preserve the identity scope required to begin resolution correctly;
  • preserve material relationships required to traverse from the entry context toward the resolution target;
  • preserve geographic, temporal, jurisdictional, population, eligibility, entity-scope, or other applicability constraints when those constraints affect the result;
  • preserve multiple applicable candidates when the information need legitimately resolves to an option space or collection;
  • preserve an unresolved state when available context is insufficient to distinguish among materially different candidates;
  • avoid selecting a child-specific assertion at the parent level without resolving the applicable child;
  • avoid assuming that parent-level knowledge necessarily applies to every child;
  • avoid substituting retrieval relevance, document proximity, URL structure, lexical similarity, or ranking for semantic resolution;
  • preserve the provenance of knowledge reached through resolution;
  • preserve the identity boundaries of entities traversed during resolution;
  • preserve the semantic meaning of relationships used during resolution;
  • avoid continuing resolution beyond the depth necessary to satisfy the information need when further traversal would change the semantic target;
  • and avoid claiming complete resolution when material ambiguity remains.

Conformance does not require a consuming system to follow a particular traversal algorithm.

The requirement applies to the publisher-side knowledge representation: the structure necessary for correct resolution must be preserved where the publisher represents that resolution structure.

Relationship to WebMEM 1.x

Resolution existed implicitly throughout WebMEM 1.x but was not yet isolated as a distinct architectural concern.

Earlier mechanisms attempted to support machine navigation and retrieval through:

  • fragment relationships;
  • related_fragments references;
  • inherits_from relationships;
  • digest membership;
  • retrieval hints;
  • glossary alignment;
  • directory structures;
  • conditional logic;
  • follow-up references;
  • and machine-oriented endpoint structures.

Those mechanisms revealed a broader problem: structured knowledge may still require traversal through identity, context, and relationships before the applicable knowledge can be determined.

The current protocol makes that problem explicit through the WebMEM Resolution Model.

The current architecture clarifies that:

  • resolution is distinct from retrieval;
  • resolution is distinct from search;
  • resolution is distinct from model reasoning;
  • resolution is distinct from agent execution;
  • resolution is distinct from recommendation;
  • resolution may terminate at a fact, entity, collection, option space, or canonical resource;
  • resolution may require identity, relationship, geographic, temporal, jurisdictional, eligibility, or other applicability constraints;
  • correct knowledge may remain inapplicable until those constraints are resolved;
  • material ambiguity should remain unresolved rather than be converted into unsupported certainty;
  • and resolvers are publisher-side implementations of resolution architecture rather than a new Fragment Class.

The current model therefore elevates resolution from an implicit retrieval concern to a first-class architectural concept.

Resolution is the process by which identity, context, relationships, provenance, and applicability converge on the knowledge object or resource appropriate to the information need.

Resolution and Protocol Integrity

Resolution is one of the conditions that allows WebMEM to preserve correctness after knowledge has been separated from the human-facing document context in which a person might otherwise infer applicability.

Without resolution:

  • correct facts may be applied to the wrong geographic context;
  • current and historical assertions may be confused;
  • parent and child entities may be traversed without determining which level actually governs the requested property;
  • multiple valid candidates may be collapsed into one unsupported answer;
  • policies may be applied outside their jurisdiction;
  • eligibility rules may be applied outside their intended population;
  • collections may be mistaken for recommendations;
  • retrieved resources may be mistaken for resolved resources;
  • and machines may be forced to reconstruct applicability relationships that the publisher already knows.

The resulting answer may contain a correct value from a correct source attached to a correctly identified entity and still be wrong for the information need.

This produces the fourth major integrity condition of the WebMEM knowledge model:

Identity
→ preserves the correct subject

Provenance
→ preserves the correct lineage

Relationships
→ preserve the correct connections

Resolution
→ preserves the correct applicability

Machine knowledge is not complete merely because the facts are correct. The applicable fact must be resolved for the applicable context.

Related Protocol Documents