WebMEM™

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

Resolvers

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

Overview

A WebMEM Resolver is a publisher-defined information resource organized around a known identifier, entity, or context that exposes the identities, relationships, option space, applicability structure, and canonical resources necessary to continue or complete machine resolution.

Resolvers emerged from a recurring publishing problem:

The identifier or context available to a machine is often not the object required to answer the information need.

Correct resolution may require traversing identities, relationships, collections, applicability conditions, or resources that the publisher already knows but that conventional web publishing leaves distributed across pages, databases, application logic, navigation, and human-facing presentation.

A WebMEM Resolver makes that known structure explicit.

When a meaningful identifier or context repeatedly requires the same resolution work, the publisher can publish the resolution structure itself.

The Original Observation

The Resolver architecture began with a simple observation.

Many information needs begin with something that is useful but insufficient.

For example:

County

identifies a geographic context but does not itself answer:

What options are available here?

A Contract ID:

H5521

provides an identifier but does not itself explain:

What does H5521 identify?
Who operates it?
What plans belong to it?
What historical information applies?
Where are the related resources?

A Formulary ID may identify another object while leaving unresolved:

What formulary is this?
Which plans use it?
Where do those plans apply?
Where are the applicable resources?

At first, these may appear to be different publishing problems.

Structurally, they share the same pattern:

Known Identifier / Entity / Context
        ↓
Insufficient by itself
        ↓
Known surrounding structure
        ↓
Applicable information space

The initial object is not necessarily the answer.

It is the entry point to resolution.

The Conventional Publishing Problem

Conventional web publishing often distributes resolution structure across several systems.

The database may know:

Contract
→ Plans

The application may know:

County
→ Available Plans

The data pipeline may know:

Formulary
→ Plans Using Formulary

The routing system may know:

Entity
→ Canonical Resource

The source data may know:

Plan
→ Segment
→ Geography

And the human-facing site may expose portions of those relationships through:

  • navigation;
  • tables;
  • filters;
  • search interfaces;
  • links;
  • application state;
  • or explanatory prose.

A human user can often move through those interfaces incrementally.

A machine attempting to answer directly may instead need to reconstruct the underlying information structure.

The publisher already possesses much of that structure.

The problem is that the structure has not necessarily been published as knowledge.

The Publishing Response

The Resolver architecture is the publisher-side response to that problem.

CONVENTIONAL STATE

Known Identifier / Context
        ↓
Scattered Pages + Links + Data + Application Logic
        ↓
Machine Reconstructs Structure
        ↓
Possible Resolution


WEBMEM RESOLVER

Known Identifier / Context
        ↓
Publisher Exposes Known Structure
        ↓
Resolver
        ↓
Applicable Entity / Option Space / Knowledge / Resource

The Resolver does not require the publisher to predict the consuming system’s reasoning process.

It requires the publisher to expose the resolution structure it already knows.

Stop forcing the machine to reconstruct the information space. Publish the information space.

From Descriptive Page to Resolution Surface

The first response to an important identifier is often to create a page about the identifier.

For example:

H5521
→ Article about Contract H5521

That may be useful to a human reader.

But the machine-resolution problem is different.

The useful structure may be:

H5521
→ identifies
→ contract:H5521
→ operatedBy
→ Carrier
→ hasPlan
→ Plan A
→ hasPlan
→ Plan B
→ hasPlan
→ Plan C
→ hasHistoricalRecord
→ Performance History
→ canonicalResource
→ Contract Resource

The architectural transition is:

Descriptive Page
→ explains the object

Resolution Surface
→ exposes what the object is,
  how it connects,
  what belongs to it,
  what applies,
  and where resolution can continue

A Resolver may still contain human-facing explanation.

Its defining purpose, however, is resolution rather than narrative description.

Resolver Definition

A WebMEM Resolver has four defining characteristics.

1. A Defined Entry Point

The Resolver begins from a known identifier, entity, or context.

For example:

county:04015

or:

CMS Contract ID: H5521

or:

Formulary ID: 00012345

2. A Known Resolution Structure

The publisher knows meaningful identities, relationships, collections, applicability conditions, or resources connected to the entry point.

3. A Resolution Space

The Resolver exposes the applicable knowledge, entities, collections, option space, or resources reachable from the entry point.

4. A Continuation or Terminal Path

The Resolver allows resolution to terminate at the appropriate knowledge object or continue toward another canonical resource or resolution surface.

The Resolver Entry Key

A Resolver is organized around an explicit entry key.

The entry key may be:

  • an authoritative external identifier;
  • a publisher-defined identifier;
  • a geographic entity;
  • a product identifier;
  • a policy identifier;
  • a collection identity;
  • a program;
  • a legal citation;
  • a model number;
  • or another stable context with meaningful resolution demand.

The entry key does not need to be globally unique if its type, namespace, and scope make its meaning unambiguous.

For example:

value: H5521
identifier_type: CMS Contract ID
entity_scope: Contract

is substantially more useful than:

value: H5521

because the Resolver can begin from an established identity context.

The Entry Key Is Not Necessarily the Resolution Target

The object used to enter a Resolver may differ from the object required to satisfy the information need.

For example:

Entry:
Contract ID

Possible Targets:
├── Contract Identity
├── Carrier
├── Plans
├── Historical Performance
└── Canonical Resources

or:

Entry:
County

Possible Targets:
├── Available Plans
├── Coverage Categories
├── Applicable Statistics
└── Canonical Plan Resources

or:

Entry:
Formulary ID

Possible Targets:
├── Formulary Identity
├── Plans Using Formulary
├── Applicable Markets
└── Canonical Resources

The entry point establishes where resolution begins. It does not predetermine where resolution must end.

Resolvers Can Expose an Option Space

A WebMEM Resolver does not necessarily resolve one input to one output.

In many publishing contexts, the correct result is an option space.

For example:

County
        ↓
Medicare Coverage Resolver
        ↓
Applicable Option Space
├── Original Medicare
├── Medicare Advantage
├── Special Needs Plans
├── Part D
└── Medigap

The Resolver has successfully answered:

What is the applicable option space for this geographic context?

It has not attempted to decide which option the user should choose.

This distinction is fundamental.

A Resolver may resolve uncertainty about the information space without resolving the user’s eventual decision.

Resolvers Can Expose an Entity Space

Some Resolvers begin with an identifier and expose the entities structurally connected to it.

For example:

H5521
        ↓
Contract Resolver
        ↓
Contract Entity
│
├── operatedBy → Carrier
├── hasPlan → Plan 290
├── hasPlan → Plan 291
├── hasPlan → Plan 292
└── canonicalResource → Contract Resource

The Resolver turns an otherwise opaque identifier into a structured entity and relationship space.

The machine can then continue resolution according to the information need.

Resolvers Can Expose a Relationship Space

Other Resolvers are useful because the relationships around an entity are more important than descriptive facts about the entity itself.

For example:

Formulary ID
        ↓
Formulary Entity
        ↓
├── usedBy → Plan A
├── usedBy → Plan B
├── usedBy → Plan C
└── canonicalResource → Formulary Resource

The central value of the Resolver is not simply:

This formulary exists.

It is:

This is the formulary,
these are the entities related to it,
this is the nature of those relationships,
and these are the resources through which resolution can continue.

Resolver and Resolution Model

A Resolver and the WebMEM Resolution Model are related but distinct concepts.

The Resolution Model defines the semantic process:

Identity
+
Context
+
Relationships
+
Applicability
        ↓
Resolved Knowledge / Entity / Option Space / Resource

A Resolver is a publisher-created information architecture that exposes a useful portion of that resolution structure around a defined entry point.

The relationship is:

Resolution Model
        ↓
Resolver Architecture
        ↓
Resolver Resource
        ↓
SDT
        ↓
Fragments + Identity + Relationships + Provenance + Context
        ↓
Resolution Targets

Resolution is the protocol concept. A Resolver is the publishing pattern.

Read the WebMEM Resolution Model →

Resolver and Semantic Data Template

A Resolver is a web-resource architecture.

The SDT is the machine-facing knowledge representation associated with that resource.

For example:

Contract Resolver Resource
│
├── Human-Facing Representation
│
├── Dataset Declaration
│
└── SDT
    ├── IdentityFragment
    ├── IndexFragment
    ├── DataFragment
    ├── DerivedStatsFragment
    ├── MetaFragment
    └── other applicable fragments

The Resolver is not itself an SDT.

The SDT represents the Resolver’s machine-facing knowledge.

Likewise, an SDT does not automatically become a Resolver merely because it contains relationships.

A Resolver is defined by resolution purpose, not merely by the presence of structured data.

Resolver Is Not a Fragment Class

Resolver is not one of the 15 WebMEM Fragment Classes.

A Resolver may compose several Fragment Classes according to the knowledge required by its resolution purpose.

For example:

Resolver
└── SDT
    │
    ├── IdentityFragment
    │   └── establishes entry entity
    │
    ├── IndexFragment
    │   └── exposes related collection
    │
    ├── DirectoryFragment
    │   └── describes related entries
    │
    ├── DataFragment
    │   └── exposes source-observed knowledge
    │
    ├── DerivedStatsFragment
    │   └── exposes derived context
    │
    └── MetaFragment
        └── describes source resources

The Fragment Classes retain their own semantic roles.

The Resolver provides the larger resolution-oriented resource architecture within which those objects participate.

Resolver and Identity

Resolver architecture depends on stable identity.

The entry key must identify or resolve to an entity at the correct semantic scope.

For example:

H5521
→ CMS Contract ID
→ contract:H5521

not:

H5521
→ some Medicare thing

Once the entity has been established, additional identities can participate in the resolution space:

contract:H5521
→ hasPlan
→ plan:H5521-290

contract:H5521
→ operatedBy
→ carrier:example-health

If the Resolver begins from incorrect or ambiguous identity, the entire resolution space may be wrong.

A Resolver must know what its entry key resolves to before it can reliably expose what surrounds that entity.

Read the Identity specification →

Resolver and Relationships

Relationships provide the structure exposed by a Resolver.

For example:

Contract
→ operatedBy
→ Carrier

Contract
→ hasPlan
→ Plan

Plan
→ hasSegment
→ Segment

Plan
→ usesFormulary
→ Formulary

Plan
→ availableIn
→ County

Entity
→ canonicalResource
→ Resource

The Resolver should preserve the semantic meaning of those relationships rather than flattening them into a generic list of related objects.

For example:

Related:
Carrier
Plan
Formulary
County

is weaker than:

operatedBy:
Carrier

hasPlan:
Plan

usesFormulary:
Formulary

availableIn:
County

A Resolver is useful because it exposes structured relationships, not merely because it aggregates related links.

Read the Relationships specification →

Resolver and Provenance

The identities, relationships, membership assertions, facts, and derived knowledge exposed by a Resolver may originate from different sources.

For example:

Contract Identity
→ source: CMS contract data

Plan Membership
→ source: CMS Landscape

Star Rating
→ source: CMS performance data

Enrollment
→ source: CMS enrollment data

Historical Trend
→ publisher derivation from annual source data

The Resolver should not flatten those lineages into a generic statement such as:

Source: CMS

when the distinctions materially affect the represented knowledge.

Resolver composition does not erase provenance boundaries.

The Resolver exposes one resolution space. Provenance preserves the different evidentiary paths through which that space was constructed.

Read the Provenance specification →

Resolver and Applicability

A Resolver may need to expose applicability conditions rather than merely relationships.

For example:

Plan
├── Segment A
│   └── appliesIn → County X
│
└── Segment B
    └── appliesIn → County Y

A Resolver should preserve that structure when segment-level applicability affects the information that can be resolved.

Flattening the structure to:

Plan
→ availableIn
→ County X
→ County Y

may be insufficient if benefits or other assertions differ by segment.

The Resolver should expose enough structure to allow the applicable segment, benefit, policy, resource, or other knowledge object to be resolved without erasing the conditions that determine applicability.

A Resolver should expose applicability structure, not merely enumerate possible targets.

Resolver and Canonical Resources

A Resolver frequently connects resolved entities to the canonical resources through which additional knowledge can be accessed.

For example:

Contract ID
→ Contract
→ hasPlan
→ Plan
→ canonicalResource
→ Plan Resource

or:

Formulary ID
→ Formulary
→ usedBy
→ Plan
→ canonicalResource
→ Plan Resource

The Resolver does not need to reproduce every fact available on every related resource.

It should expose enough knowledge to establish the resolution space and provide meaningful paths toward the resources appropriate to further resolution.

This allows resolution to continue across independently published resources:

Resolver A
→ Entity
→ Canonical Resource
→ Resolver or Resource B
→ Additional Knowledge

Stable identity and explicit relationships preserve continuity across those resource boundaries.

Resolver Boundaries

A Resolver should have a coherent resolution boundary.

It does not need to represent every fact, relationship, or resource reachable from its entry key.

For example, a Contract Resolver may reasonably expose:

Contract
├── Carrier
├── Plans
├── Current Performance
├── Historical Performance
└── Canonical Plan Resources

It does not necessarily need to reproduce:

every plan benefit
every formulary drug
every provider
every pharmacy
every county-level statistic

Those knowledge domains may belong to other resources or resolvers.

The Resolver boundary should be determined by the resolution problem the resource exists to solve.

A Resolver should expose enough surrounding structure to make the entry key useful without attempting to become the entire knowledge graph.

Resolver Continuation

Resolution may continue beyond the Resolver.

For example:

Contract Resolver
→ Plan Identity
→ Canonical Plan Resource
→ Plan SDT
→ Segment
→ Applicable Benefit

or:

County Resolver
→ Available Plan
→ Canonical Plan Resource
→ Formulary Identity
→ Formulary Resolver

The first Resolver has still performed useful resolution even though it did not terminate at the final knowledge object eventually required by the consuming system.

A Resolver may therefore terminate at:

  • a resolved entity;
  • a collection;
  • an option space;
  • a factual or derived knowledge object;
  • a canonical resource;
  • another Resolver;
  • or an unresolved state requiring additional context.

The appropriate boundary depends on the Resolver’s defined purpose.

Resolver Profiles

Different classes of resolution problems may produce recurring Resolver patterns.

WebMEM refers to these patterns as Resolver Profiles.

A Resolver Profile describes the expected entry context, resolution structure, and likely resolution targets for a class of Resolver.

A profile is not a Fragment Class.

It does not replace the SDT or prescribe a universal page template.

It describes a recurring resolution architecture.

Identifier Resolver Profile

An Identifier Resolver begins from a domain identifier whose entity meaning must first be established.

Conceptually:

Identifier
        ↓
Identifier Type
        ↓
Entity Scope
        ↓
Canonical Entity
        ↓
Related Entities / Knowledge / Resources

Examples may include:

  • contract identifiers;
  • plan identifiers;
  • formulary identifiers;
  • product identifiers;
  • model numbers;
  • case numbers;
  • policy identifiers;
  • or other domain-specific keys.

The defining problem is:

What does this identifier identify, and what useful information space surrounds that entity?

Geographic Resolver Profile

A Geographic Resolver begins from an identifiable geographic context.

Conceptually:

Geographic Entity
        ↓
Applicable Domain Context
        ↓
Collections / Option Spaces
        ↓
Applicable Entities
        ↓
Canonical Resources

For example:

county:04015
        ↓
Medicare Coverage Context
        ↓
Coverage Option Space
        ↓
Available Plans
        ↓
Canonical Plan Resources

The defining problem is:

What entities, options, policies, services, or resources apply within this geographic context?

Collection Resolver Profile

A Collection Resolver begins from a defined collection or category and exposes its applicable membership.

Conceptually:

Collection
        ↓
Membership
        ↓
Member Identities
        ↓
Member Relationships / Attributes
        ↓
Canonical Member Resources

The defining problem is:

What belongs to this collection, and what can be resolved about its members?

An IndexFragment may play an important role in representing the collection membership exposed by this Resolver profile.

Relationship Resolver Profile

A Relationship Resolver begins from an identifiable entity and exposes a particular class of meaningful relationships around that entity.

For example:

Formulary
        ↓
usedBy
        ↓
Plans
        ↓
Canonical Plan Resources

or:

Product
        ↓
compatibleWith
        ↓
Components
        ↓
Component Resources

The defining problem is:

What identifiable objects participate in this relationship with the entry entity?

Resolver Profiles May Overlap

A real Resolver may exhibit characteristics of more than one profile.

For example, a Formulary Resolver may be both:

Identifier Resolver
+
Relationship Resolver

A county-level plan Resolver may be both:

Geographic Resolver
+
Collection Resolver

The profiles describe useful architectural patterns rather than mutually exclusive categories.

A publisher should choose or combine patterns according to the actual resolution problem rather than forcing a Resolver into an artificial classification.

Example: Geographic Option-Space Resolver

Consider a resource organized around a county-level Medicare context.

The entry point is:

county:04015
Mohave County, Arizona

The publisher knows that the relevant information space contains multiple Medicare coverage paths.

The Resolver may expose:

Mohave County
        ↓
Medicare Coverage Option Space
│
├── Original Medicare
│
├── Medicare Advantage
│   └── applicable plan collection
│
├── Special Needs Plans
│   └── applicable plan collection
│
├── Part D
│   └── applicable prescription coverage context
│
└── Medigap
    └── applicable supplemental coverage context

The Resolver does not choose a coverage path for the user.

It resolves the county context into the applicable option space.

Further resolution may continue through individual plan collections, entities, or canonical resources.

This demonstrates an important Resolver principle:

The resolved output may be the structured option space itself.

Example: Contract Identifier Resolver

Consider:

H5521

The identifier alone is opaque without domain context.

The Resolver first establishes:

H5521
→ identifier_type: CMS Contract ID
→ entity_scope: Contract
→ contract:H5521

It may then expose:

contract:H5521
│
├── operatedBy
│   └── Carrier
│
├── hasPlan
│   ├── Plan 290
│   ├── Plan 291
│   └── Plan 292
│
├── hasPerformance
│   └── Current Performance
│
├── hasHistoricalPerformance
│   ├── Prior Year
│   └── Earlier Year
│
└── canonicalResource
    └── Contract Resource

The page does not need large amounts of narrative prose to perform this function.

Its primary value is the explicit resolution structure surrounding the Contract ID.

Example: Formulary Resolver

A Formulary Resolver may begin from:

formulary_id: 00012345

and establish:

00012345
→ identifies
→ formulary:00012345

The relationship space may then expose:

formulary:00012345
│
├── usedBy
│   ├── Plan A
│   ├── Plan B
│   └── Plan C
│
├── applicableTo
│   └── applicable plan/year context
│
└── canonicalResource
    └── Formulary Resource

The machine can move from an otherwise opaque Formulary ID to the entities and resources through which that identifier becomes useful.

Resolvers Beyond Healthcare

The Resolver architecture is domain-independent.

For example, an automotive Resolver might expose:

VIN
→ Vehicle
→ Model
→ Configuration
→ Applicable Recall
→ Compatible Part
→ Service Resource

A product Resolver might expose:

SKU
→ Product
→ Variant
→ Compatible Accessories
→ Replacement Parts
→ Documentation

A legal Resolver might expose:

Case Number
→ Case
→ Court
→ Parties
→ Decisions
→ Subsequent History
→ Canonical Documents

A public-program Resolver might expose:

Program
→ Governing Policy
→ Eligibility
→ Applicable Procedure
→ Official Application Resource

The domain vocabulary changes.

The architectural pattern remains:

Known Entry Context
→ Identity
→ Relationships
→ Applicability
→ Resolution Space
→ Applicable Knowledge or Resources

When a Resolver Is Appropriate

Not every web resource should be a Resolver.

A Resolver is especially appropriate when:

  • a meaningful identifier repeatedly serves as an information entry point;
  • the identifier is opaque without domain interpretation;
  • a geographic or other context determines an applicable option space;
  • the publisher possesses stable relationships that consuming systems would otherwise need to reconstruct;
  • an entity has a meaningful set of related entities or resources;
  • resolution requires traversing a recurring parent-child or membership structure;
  • the same resolution problem occurs repeatedly across many entities;
  • or the publisher can expose a substantially clearer resolution surface than ordinary search or document navigation provides.

The existence of structured data alone does not justify creating a Resolver.

The defining question is:

Is there a recurring resolution problem around this identifier, entity, or context that the publisher already knows how to structure?

When a Resolver Is Not Necessary

A Resolver may be unnecessary when:

  • the resource already directly represents the terminal knowledge object;
  • no meaningful relationship traversal is required;
  • the identifier already resolves unambiguously to the requested resource;
  • there is no recurring option space or surrounding entity structure to expose;
  • or creating a separate resolution surface would merely duplicate an existing canonical resource without adding resolution value.

Resolver architecture should solve a real information-structure problem rather than create additional pages for their own sake.

A Resolver Is Not a Search Results Page

A search results page generally responds to a query by ranking or listing resources believed to be relevant.

A Resolver begins from a defined entry context and exposes known semantic structure.

For example:

Search:
"H5521"

Possible output:
ranked pages containing or discussing H5521

versus:

Resolver:
H5521
→ CMS Contract ID
→ Contract
→ Carrier
→ Plans
→ Canonical Resources

The Resolver is not ranking candidates by textual relevance.

It is representing known relationships around the resolved entity.

A Resolver Is Not a Directory

A Resolver may contain or expose a directory, but the concepts are not equivalent.

A DirectoryFragment represents structured directory entries.

A Resolver represents a resolution-oriented resource architecture.

For example:

County Resolver
→ Available Plan Directory

The directory may be one resolution target within the Resolver.

Likewise:

Contract Resolver
→ Plan Collection

does not make the entire Contract Resolver a directory.

A directory organizes entries. A Resolver organizes a path from known context toward applicable knowledge.

A Resolver Is Not a Recommendation Engine

A Resolver exposes applicable entities, option spaces, relationships, or resources.

It does not necessarily determine what a user should choose.

For example:

County
→ Available Plans
→ Plan A
→ Plan B
→ Plan C

does not imply:

Recommended Plan
→ Plan A

A RecommendationFragment may represent a publisher recommendation where appropriate.

The Resolver itself remains focused on resolution.

Resolvers expose the applicable space. Recommendations express preference within or beyond that space.

A Resolver Is Not an Execution Engine

A Resolver may expose procedural, eligibility, or policy relationships that a capable consuming system could use as part of an action workflow.

That does not make the Resolver responsible for executing the workflow.

For example:

Program
→ Eligibility
→ Procedure
→ Application Resource

may be a valid resolution path.

The Resolver does not thereby:

  • determine eligibility on behalf of the user;
  • submit the application;
  • perform transactions;
  • or authorize external actions.

WebMEM exposes knowledge structure. Execution remains a separate concern.

A Resolver Is Not a Requirement for Machine Behavior

Publishing a Resolver does not require a search engine, answer engine, language model, agent, or other consuming system to follow the Resolver’s structure.

A consuming system may:

  • use the entire resolution space;
  • use only selected relationships;
  • retrieve a canonical resource directly;
  • compare the Resolver with other sources;
  • or ignore the Resolver entirely.

The WebMEM Protocol defines the publisher-side representation.

The Resolver makes known resolution structure available. It does not dictate how a machine must consume it.

Resolver Failure Modes

Several patterns can undermine the semantic purpose of a Resolver.

Opaque Entry Key

The Resolver exposes an identifier without establishing its type, namespace, or entity scope.

Descriptive-Page Substitution

The resource contains prose about the entry entity but fails to expose the relationships and option space that make it useful for resolution.

Relationship Flattening

Distinct relationships are reduced to a generic list of related entities or links.

Identity Collapse

Parent, child, member, or related entities are treated as though they share one identity.

Applicability Collapse

Geographic, temporal, jurisdictional, segment-level, or other applicability conditions are removed from the resolution structure.

Provenance Collapse

Knowledge from multiple sources and derivations is represented as though it has one undifferentiated lineage.

Option-Space Collapse

A legitimate set of applicable options is reduced to one object without a semantic basis for that selection.

Resolver Overreach

The Resolver attempts to reproduce every fact, relationship, or resource reachable from the entry entity rather than maintaining a coherent resolution boundary.

False Terminal State

The Resolver presents an intermediate entity or collection as though resolution is complete when the information need requires additional context or traversal.

Unsupported Resolution

The Resolver presents one candidate as uniquely applicable even though the represented knowledge does not support that conclusion.

Navigation Substitution

A collection of hyperlinks is presented as a Resolver even though the semantic relationships connecting the entry context to the destinations are not represented.

Retrieval Substitution

Search results, relevance-ranked resources, or textual matches are treated as though they constitute resolved relationships around the entry entity.

Duplicate Surface

A new Resolver resource duplicates an existing canonical resource without exposing additional identity, relationship, applicability, option-space, or resolution value.

These failure modes share a common problem:

The resource may contain useful information while failing to expose the structure that makes it a Resolver.

Minimum Resolver Model

The exact structure required by a Resolver depends on the domain and resolution problem.

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

  • Entry Key: the identifier, entity, collection, geography, or other context from which resolution begins;
  • Entry Type: what kind of identifier or context the entry key represents when that distinction is necessary;
  • Entry Identity: the canonical entity or context represented by the entry key when applicable;
  • Resolver Purpose: the resolution problem or information space the resource exists to expose;
  • Relationships: the semantic connections necessary to move outward from the entry context;
  • Applicability: geographic, temporal, jurisdictional, population, entity-scope, eligibility, or other constraints necessary to interpret the resolution space correctly;
  • Resolution Targets: the entities, collections, option spaces, knowledge objects, or resources that may satisfy or continue the resolution process;
  • Provenance: the evidentiary lineage supporting material identities, relationships, facts, membership, or derived knowledge exposed by the Resolver;
  • Canonical Resources: resources through which resolution may continue when applicable;
  • and Unresolved Conditions: material ambiguity or missing context that prevents further supported resolution when such ambiguity exists.

These requirements do not define a universal Resolver object or require a new Fragment Class.

The Resolver may represent these concepts through the SDT, applicable Fragment Classes, identities, relationships, assertions, collections, provenance, and canonical-resource references already defined by the WebMEM Protocol.

The Resolver is the composition of resolution-oriented knowledge, not another universal object layered on top of it.

Resolver Conformance

A conforming WebMEM Resolver must preserve the resolution structure necessary to fulfill its stated purpose without introducing unsupported semantic shortcuts.

Specifically, a conforming Resolver must:

  • identify or make resolvable its entry key;
  • preserve the identifier type, namespace, entity type, or identity scope necessary to interpret that entry key correctly;
  • establish a coherent resolution purpose;
  • represent the material relationships connecting the entry context to its resolution targets;
  • preserve the identities of distinct entities participating in the resolution space;
  • preserve geographic, temporal, jurisdictional, population, segment-level, or other applicability distinctions when they affect resolution;
  • preserve provenance necessary to understand the lineage of material identities, relationships, membership assertions, factual knowledge, or derived knowledge;
  • preserve legitimate option spaces rather than selecting one member without a semantic basis for doing so;
  • preserve unresolved conditions when the available knowledge does not support complete resolution;
  • distinguish canonical entities from the resources representing those entities;
  • provide or reference canonical resources when continuation beyond the Resolver is part of its resolution purpose;
  • avoid treating navigation links, search results, textual proximity, or lexical similarity as substitutes for represented semantic relationships;
  • avoid extending the Resolver beyond a coherent resolution boundary merely to accumulate additional content;
  • and represent its machine-facing knowledge through a conforming SDT and applicable WebMEM serialization.

Conformance does not require a Resolver to answer every possible information need associated with its entry entity.

It requires the Resolver to represent its defined resolution space accurately and coherently.

Resolver Architecture and Protocol Integrity

Resolvers provide the publication layer through which the WebMEM Resolution Model can become an explicit information surface.

Without a Resolver, the publisher may still possess all of the knowledge required for resolution:

Database
→ knows identity

Application
→ knows relationships

Pipeline
→ knows applicability

Routing
→ knows canonical resources

But those structures may remain distributed across systems that are not exposed as a coherent machine-facing resolution surface.

The Resolver changes the publication state:

Publisher Knowledge
│
├── Identity
├── Relationships
├── Applicability
├── Collections
├── Provenance
└── Canonical Resources
        ↓
      Resolver
        ↓
Published Resolution Structure

This is the architectural purpose of the Resolver.

The Resolver does not create the relationships. It publishes the resolution structure the publisher already knows.

From Documents to Resolution Surfaces

The Resolver architecture reflects a broader change in the publisher’s role.

Traditional web publishing primarily assumes that a publisher creates documents and navigation, a search system helps a user discover those documents, and the user performs much of the remaining interpretation and traversal.

Machine-mediated discovery changes that sequence.

A consuming system may attempt to identify an entity, determine applicable context, traverse relationships, compare options, and synthesize an answer before the user visits a source resource.

That creates a new publisher-side opportunity:

Old Publishing Model

Publisher
→ Documents
→ Navigation

Search
→ Discovery

Human
→ Interpretation
→ Traversal
→ Resolution

versus:

Resolution-Oriented Publishing

Publisher
→ Documents for Humans

Publisher
→ Resolution Structure for Machines

Machine
→ can inspect known identities,
  relationships,
  applicability,
  option spaces,
  and canonical resources

The human-facing document remains important.

The Resolver adds a machine-facing structure optimized for a different job.

The publisher is no longer limited to publishing the destination. The publisher can also publish the structure required to reach the correct destination.

Relationship to WebMEM 1.x

WebMEM 1.x contained several mechanisms that anticipated Resolver architecture without defining Resolver as a distinct publishing pattern.

These included:

  • IndexFragments;
  • DirectoryFragments;
  • entity-scoped fragments;
  • cross-fragment relationships;
  • semantic digests;
  • related-fragment references;
  • conditional logic;
  • follow-up references;
  • retrieval hints;
  • and machine-oriented endpoint structures.

Production implementation revealed that these mechanisms were addressing a larger architectural problem.

The recurring problem was not merely retrieval or fragment navigation.

It was resolution:

Known Identifier / Context
→ insufficient alone
→ surrounding identities and relationships required
→ applicable information space

The current protocol makes the publishing response explicit through Resolver architecture.

The current model clarifies that:

  • a Resolver begins from a defined identifier, entity, collection, geography, or other meaningful context;
  • the entry key is not necessarily the resolution target;
  • a Resolver may expose an entity space, relationship space, collection, option space, knowledge object, or canonical resource;
  • a Resolver is a resource architecture rather than a Fragment Class;
  • the Resolver’s machine-facing representation is an SDT;
  • Resolver structure depends on identity, relationships, applicability, provenance, and canonical resources;
  • resolution may continue across resource boundaries;
  • Resolver Profiles describe recurring resolution patterns without creating new Fragment Classes;
  • Resolvers do not prescribe machine reasoning or execution;
  • and a Resolver should preserve ambiguity when its represented knowledge does not support unique resolution.

This architecture turns an implementation observation into a general publishing pattern.

When the publisher already knows the structure required to resolve an identifier or context, WebMEM provides a way to publish that structure instead of forcing every consuming system to reconstruct it independently.

Related Protocol Documents