Part 5: Resolution and Resolver Architecture

From Retrieval Interfaces to Publisher-Defined Resolution Surfaces

The original WebMEM framework assumed that structured machine knowledge would eventually require a specialized interface capable of consuming it.

That idea produced the Vertical Retrieval Interface: a proposed system that would interpret structured knowledge, apply user context, traverse relationships, rank candidate objects, and deliver conversational answers within domains such as healthcare, real estate, finance, and law.

The proposal anticipated several capabilities that are now common in AI-mediated information systems:

natural-language querying;
structured retrieval;
persistent user context;
multi-turn interaction;
cross-domain reasoning;
background monitoring;
and answer delivery rather than lists of links.

But the Vertical Retrieval Interface combined two architectural responsibilities that the current WebMEM Protocol deliberately separates.

Publisher Responsibility
→ represent knowledge

Consumer Responsibility
→ retrieve, rank, reason, personalize, and answer

The current protocol remains on the publisher side of that boundary.

WebMEM does not need to provide the interface that consumes the knowledge.

It needs to provide a representation from which different consuming systems can determine what the knowledge is, how it connects, and where it applies.

That distinction led to two of the most important concepts in the current protocol:

Resolution and Resolvers.

5.1 The Problem Was Larger Than Retrieval

The original Vertical Retrieval Interface was built around a reasonable assumption:

If publishers create structured machine knowledge, a retrieval system can find the appropriate objects and return them to the user.

Production implementation exposed a harder problem.

Retrieving the correct objects does not necessarily determine the correct answer.

Consider:

Plan
├── Segment A
│   ├── appliesIn → County X
│   └── premium → 18.50 USD
│
└── Segment B
    ├── appliesIn → County Y
    └── premium → 32.00 USD

A retrieval system may successfully retrieve:

the correct Plan;
both correct Segments;
both correct premiums;
and the correct source data.

It still has not answered:

Which premium applies?

The missing operation is resolution.

Retrieval
→ What knowledge might be relevant?

Resolution
→ Which knowledge applies?

This distinction became increasingly important as WebMEM was implemented against real-world information systems containing parent-child identities, geographic variation, temporal variation, collections, policy conditions, and related resources.

5.2 The Resolution Model

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

Conceptually:

Known Identifier / Entity / Context
        ↓
Identity
        ↓
Candidate Knowledge
        ↓
Relationships
        ↓
Applicability
        ↓
Resolved Knowledge / Entity / Resource

Resolution addresses a fundamental problem in machine-mediated information:

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

A fact can be:

accurate;
current;
properly sourced;
attached to a valid entity;
and still be inapplicable to the current information need.

This is why resolution cannot be reduced to retrieval relevance.

5.3 Resolution Begins With Identity

The original Vertical Retrieval Interface assumed that structured objects could be matched to queries.

The current model asks an earlier question:

What object are we actually dealing with?

Consider:

H5521

Within the applicable domain, this may resolve to:

identifier_type:
CMS Contract ID

entity_type:
Contract

entity:
contract:H5521

Now consider:

H5521-290

This may identify a different structural object:

identifier_type:
CMS Contract + Plan ID

entity_type:
Plan

entity:
plan:H5521-290

Resolution cannot proceed reliably if the entry identifier has been interpreted at the wrong entity scope.

Before a machine can determine what applies, it must know what the thing is.

5.4 Relationships Create the Traversable Space

Once identity is established, relationships expose how resolution can continue.

For example:

contract:H5521
→ hasPlan
→ plan:H5521-290

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

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

These relationships may already exist in the publisher’s database, application logic, source data, or routing architecture.

Conventional publishing may expose them indirectly through:

links;
tables;
filters;
URL patterns;
navigation;
or application behavior.

WebMEM allows the publisher to represent them explicitly.

The consuming system may then traverse those relationships according to its own architecture.

5.5 Applicability Narrows the Resolution Space

Relationship traversal may produce several valid candidate objects.

Applicability determines which candidate is relevant to the current context.

For example:

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

Given:

geography:
county:04015

the represented knowledge may establish:

Segment A
→ appliesIn
→ county:04015

Segment B
→ appliesIn
→ county:04013

Segment C
→ appliesIn
→ county:04025

The geographic context resolves Segment A as the applicable candidate.

Other domains may depend on different applicability constraints:

time;
jurisdiction;
population;
eligibility;
product compatibility;
policy conditions;
membership;
or another domain-specific context.

The underlying principle is the same.

Resolution turns available knowledge into applicable knowledge.

5.6 Resolution Does Not Always Produce One Answer

The original retrieval model tended to assume that a query would produce ranked candidate objects.

The Resolution Model allows another important outcome:

the correct resolved object may be a collection or option space.

Consider a geographic Medicare information need:

Mohave County, Arizona
        ↓
Applicable Medicare Coverage Space
│
├── Original Medicare
├── Medicare Advantage
├── Special Needs Plans
├── Part D
└── Medigap

The correct resolution is not necessarily:

Choose Plan A

It may simply be:

These are the applicable coverage paths.

Likewise:

Contract ID
→ Contract
→ Related Plans

may correctly resolve to a collection of plans rather than one selected plan.

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

5.7 Resolution Must Preserve Ambiguity

There are also cases in which the available context is insufficient to resolve the applicable knowledge.

For example:

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

Required Context:
geography

Known Geography:
none

The correct resolution state is not:

premium = 18.50 USD

or:

premium = 32.00 USD

It is:

UNRESOLVED

required_context:
geography

This is an important departure from systems designed primarily to return an answer at all costs.

Ambiguity is information.

If the publisher’s knowledge does not support unique resolution, the machine-facing representation should not manufacture it.

5.8 From Vertical Retrieval Interface to Resolver

The original framework attempted to solve retrieval and resolution inside a specialized consuming interface.

Production publishing revealed another possibility.

If the publisher repeatedly knows the structure required to resolve a particular identifier or context, the publisher can expose that structure directly.

This produces a Resolver.

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.

Conceptually:

Known Identifier / Context
        ↓
Resolver
        ↓
Published Resolution Structure
        ↓
Applicable Entity / Collection / Option Space / Resource

This is the publisher-side descendant of the original Vertical Retrieval Interface.

The crucial difference is architectural responsibility.

Vertical Retrieval Interface

Publisher / Application
→ consumes knowledge
→ stores user context
→ retrieves candidates
→ ranks candidates
→ reasons
→ delivers answer


WebMEM Resolver

Publisher
→ exposes known resolution structure

Consumer
→ decides how to retrieve,
  traverse, rank, reason,
  personalize, or answer

5.9 The Original Observation Behind Resolvers

Resolver architecture emerged from a recurring publishing observation:

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

A county is useful:

county:04015

but may merely be the entry point to:

What Medicare options are available here?

A Contract ID is useful:

H5521

but may merely be the entry point to:

What is this?
Who operates it?
What plans belong to it?
What historical information applies?
Where are the canonical resources?

A Formulary ID may similarly be an entry point to:

What formulary is this?
Which plans use it?
What relationships apply?
Where can resolution continue?

These appear to be different information problems.

Structurally, they share the same pattern:

Known Thing
        ↓
Insufficient By Itself
        ↓
Known Surrounding Structure
        ↓
Applicable Information Space

The publishing response is straightforward:

If the publisher already knows the resolution structure, publish it.

5.10 Resolver Entry Keys

A Resolver begins from an identifiable entry key.

That key may be:

a geographic entity;
a contract identifier;
a plan identifier;
a formulary identifier;
a product identifier;
a model number;
a legal citation;
a case number;
a policy identifier;
a collection;
or another stable domain context.

The entry key establishes where resolution begins.

It does not determine where resolution must end.

Entry:
Contract ID

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

5.11 Resolver Profiles

Recurring resolution problems can be described through Resolver Profiles.

An Identifier Resolver may follow:

Identifier
→ Identifier Type
→ Entity Identity
→ Related Knowledge
→ Canonical Resources

A Geographic Resolver may follow:

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

A Collection Resolver may follow:

Collection
→ Membership
→ Member Identities
→ Member Knowledge
→ Canonical Resources

A Relationship Resolver may follow:

Entity
→ Defined Relationship
→ Related Entities
→ Related Resources

These profiles are architectural patterns rather than new Fragment Classes.

A real Resolver may combine more than one profile.

5.12 Example: Geographic Medicare Resolver

Consider a county-level Medicare resource.

The entry context is:

county:04015
Mohave County, Arizona

The publisher knows the applicable information landscape.

A Resolver can expose:

Mohave County
        ↓
Medicare Coverage Option Space
│
├── Original Medicare
│
├── Medicare Advantage
│   └── Applicable Plans
│
├── Special Needs Plans
│   └── Applicable Plans
│
├── Part D
│   └── Applicable Prescription Coverage Context
│
└── Medigap
    └── Applicable Supplemental Coverage Context

The Resolver does not recommend one coverage path.

It resolves the geographic context into the applicable option space.

5.13 Example: Contract Resolver

An identifier such as:

H5521

may be meaningless outside its domain.

A Contract Resolver first establishes:

H5521
→ CMS Contract ID
→ Contract
→ contract:H5521

It can then expose:

contract:H5521
│
├── operatedBy
│   └── Carrier
│
├── hasPlan
│   ├── Plan A
│   ├── Plan B
│   └── Plan C
│
├── hasPerformance
│   └── Current Performance
│
├── hasHistoricalPerformance
│   └── Historical Records
│
└── canonicalResource
    └── Contract Resource

The value of the resource is not primarily prose explaining the identifier.

Its value is the resolution structure surrounding it.

5.14 Example: Formulary Resolver

A Formulary Resolver may begin from:

formulary:00012345

and expose:

Formulary
│
├── usedBy → Plan A
├── usedBy → Plan B
├── usedBy → Plan C
└── canonicalResource → Formulary Resource

The Formulary ID becomes useful because the publisher exposes what it identifies and how it participates in the surrounding information space.

5.15 Cross-Domain Resolution Revisited

The original Vertical Retrieval Interface used a deliberately difficult example:

“Find homes under $500K near cardiologists who accept my Medicare plan.”

The example remains useful because it exposes the difference between retrieval and resolution.

A retrieval system may independently locate:

homes priced below $500,000;
cardiologists;
provider locations;
the user’s Medicare plan;
and provider-network information.

Every retrieved object may be correct.

The information need is still unresolved.

The machine must establish relationships across several identifiable domains:

User Context
│
├── Medicare Plan
│   └── Provider Network
│       └── Participating Cardiologists
│
├── Geographic Context
│   ├── Cardiologist Locations
│   └── Home Locations
│
└── Purchase Constraint
    └── price < 500000 USD

The problem then becomes:

Homes
→ satisfying price constraint

Cardiologists
→ satisfying specialty constraint

Cardiologists
→ participatingIn
→ User's Medicare Plan Network

Homes
→ satisfying geographic relationship
→ Participating Cardiologists

No single retrieved object answers the question.

The answer emerges from resolving identities, relationships, constraints, and applicability across several information spaces.

The original framework proposed a Multi-Vertical Coordination Layer to perform that work.

The current WebMEM Protocol does not define such a consumer-side orchestration system.

Instead, it asks what each publisher can contribute to make the resolution problem less dependent on inference.

For example:

Real Estate Publisher
→ Property Identity
→ Price
→ Location
→ Canonical Property Resource

Healthcare Publisher
→ Provider Identity
→ Specialty
→ Practice Location
→ Network Relationships
→ Canonical Provider Resource

Medicare Publisher
→ Plan Identity
→ Network Identity / Relationships
→ Geographic Applicability
→ Canonical Plan Resource

A consuming system may then coordinate those representations according to its own reasoning and retrieval architecture.

WebMEM does not need to solve the compound query. It needs to make the publisher-known pieces of the query more resolvable.

5.16 Cross-Domain Resolution Depends on Stable Identity

Cross-domain resolution becomes especially fragile when different information systems refer to the same real-world object using different names or identifiers.

For example:

Provider Directory:
Dr. Jane Smith

Practice Directory:
Jane A. Smith, MD

Plan Network:
SMITH JANE A

External Identifier:
NPI 1234567890

A consuming system may need to determine whether these references identify the same provider.

Where the publisher possesses a stable canonical identifier, publishing that identity reduces unnecessary ambiguity:

provider:npi:1234567890

The same principle applies across domains:

Property
→ stable property identity

Provider
→ stable provider identity

Plan
→ stable plan identity

Geography
→ stable geographic identity

Cross-domain reasoning becomes more tractable when the participating domains expose stable identities and explicit relationships rather than requiring the consuming system to perform entity reconciliation from names alone.

5.17 Cross-Domain Resolution Does Not Require a Universal Schema

The original Multi-Vertical Coordination Layer assumed that schemas and scoring logic might need to be synchronized across domains.

The current architecture does not require one universal vocabulary capable of describing every domain.

Each domain may preserve its own knowledge model while exposing the semantic elements necessary for interoperability:

stable identity;
typed assertions;
defined terminology;
provenance;
explicit relationships;
applicability;
and canonical resources.

For example:

Real Estate Vocabulary
→ price
→ property_type
→ bedrooms
→ location

Healthcare Vocabulary
→ specialty
→ provider_type
→ network_participation
→ practice_location

Medicare Vocabulary
→ plan_id
→ contract_id
→ segment_id
→ service_area

The vocabularies do not need to become one vocabulary.

The objects need enough identity and relationship structure to participate in resolution.

Interoperability does not require semantic uniformity. It requires recoverable meaning at the boundaries between domains.

5.18 User Context Belongs to the Consumer

The original Vertical Retrieval Interface included a persistent User Context Engine containing preferences, behaviors, exclusions, traits, and other information used to personalize retrieval.

That remains a legitimate capability for consuming systems.

It is no longer part of the WebMEM publisher-side protocol.

The architectural distinction is:

PUBLISHER

Publishes:
→ entity identity
→ factual assertions
→ provenance
→ relationships
→ applicability
→ option spaces
→ canonical resources


CONSUMER

May possess:
→ user location
→ preferences
→ budget
→ eligibility context
→ prior conversation
→ exclusions
→ goals
→ authorization

        ↓

Combines User Context
with
Published Knowledge

        ↓

Resolution / Recommendation / Action

This separation is important for both architecture and privacy.

WebMEM does not require publishers to encode persistent personal memory into public machine-facing resources.

A consuming system may apply private user context to public WebMEM knowledge without the publisher needing to know the user’s identity or history.

5.19 Resolution and Recommendation Are Different

The original Vertical Retrieval Interface combined retrieval, ranking, personalization, and answer delivery.

The current architecture distinguishes resolution from recommendation.

Consider:

User Context:
Mohave County

Resolution:
Available Plans
├── Plan A
├── Plan B
└── Plan C

This establishes the applicable option space.

Now consider:

User Context:
preferred doctors
prescriptions
budget
risk tolerance
coverage preferences

Recommendation:
Plan B

The second operation expresses a judgment or preference among resolved options.

WebMEM can represent a publisher-defined recommendation through a RecommendationFragment where appropriate.

But Resolver architecture does not require recommendation.

Resolution determines what applies. Recommendation determines what may be preferred.

5.20 Resolution and Execution Are Different

The original Vertical Retrieval Interface also anticipated background actions such as:

“Notify me if a PPO plan drops below $0 premium in my county.”

That request combines several operations:

Resolve Geography
        ↓
Resolve Applicable PPO Plans
        ↓
Evaluate Premium Condition
        ↓
Monitor for Change
        ↓
Trigger Notification

WebMEM may contribute the published knowledge necessary for the first portions of that workflow.

It does not define the monitoring scheduler, notification system, authorization model, or execution environment.

Those are consumer-side capabilities.

The same distinction applies to:

submitting an application;
booking an appointment;
purchasing a product;
changing an insurance plan;
filing a legal document;
or performing another external action.

WebMEM represents knowledge that may support action. It is not the action engine.

5.21 Multi-Turn Context Is a Consumer Capability

The original framework treated conversational continuity as part of the Vertical Retrieval Interface.

For example:

"Show me PPO plans."

"Only the ones covering my doctor."

"What about next year?"

A conversational system may maintain enough context to interpret the later questions.

That context belongs to the consuming system.

The publisher’s responsibility is different.

The publisher should expose enough stable structure that the consuming system can apply changing context without having to reinterpret the underlying knowledge from scratch.

For example:

Published Knowledge:

Plan A
→ plan_type → PPO
→ availableIn → County X
→ includesProvider → Provider Y
→ plan_year → 2026

The consumer may then apply:

Turn 1:
plan_type = PPO

Turn 2:
provider = Provider Y

Turn 3:
plan_year = 2027

WebMEM does not preserve the conversation.

It preserves the knowledge against which conversational context may be resolved.

5.22 The Resolver Is Not a Search Results Page

A Resolver should not be confused with a conventional search interface.

Search typically begins from an open-ended query:

"H5521 Medicare"

and may return:

Ranked Resource A
Ranked Resource B
Ranked Resource C

A Resolver begins from a defined semantic entry point:

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

and exposes known structure:

Contract
├── operatedBy → Carrier
├── hasPlan → Plan A
├── hasPlan → Plan B
└── canonicalResource → Contract Resource

Search discovers candidate resources.

The Resolver exposes publisher-known relationships around a resolved entry context.

5.23 The Resolver Is Not a Directory

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

A directory answers:

What entries belong to this directory?

A Resolver asks:

Starting from this known identifier, entity, or context, what information structure is required to make it useful?

For example:

County Resolver
→ Plan Directory

The directory may be one object inside the resolution space.

Likewise:

Contract Resolver
→ Related Plan Collection

does not make the entire Contract Resolver a directory.

A directory organizes entries. A Resolver organizes resolution.

5.24 Resolvers Are Publishing Surfaces

The important architectural shift from the original Vertical Retrieval Interface is that a Resolver is a publishing surface, not necessarily an interactive application.

A Resolver may be implemented as an ordinary canonical web resource.

For example:

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

The resource may contain:

Human-Facing Content
        +
Dataset Declaration
        +
WebMEM SDT
        ↓
IdentityFragment
IndexFragment
DataFragment
DerivedStatsFragment
MetaFragment
Relationships

The human reader receives an understandable resource.

The machine receives an explicit representation of the resolution space.

No conversational interface is required.

No proprietary agent runtime is required.

No user profile is required.

No WebMEM-specific search engine is required.

The resolver is useful because the publisher has made the resolution structure public.

5.25 The Publisher Already Knows More Than It Publishes

This is the observation that ultimately replaced the Vertical Retrieval Interface as a core WebMEM concern.

Consider what a mature information publisher may already know internally:

Database
→ entity identity

Source Pipeline
→ provenance

Application
→ parent / child relationships

Routing System
→ canonical resources

Business Logic
→ applicability

Directory Logic
→ collection membership

Analytics Pipeline
→ derived statistics

Traditional publishing may expose fragments of that structure through the user interface.

A machine attempting to answer directly may have to reconstruct it.

Resolver architecture asks a simple question:

Why?

If the publisher already knows:

H5521
→ Contract
→ Carrier
→ Plans

why publish only pages from which the machine must infer those relationships?

If the publisher already knows:

County
→ Available Plans

why require every consuming system to reconstruct the option space independently?

If the publisher already knows:

Formulary
→ Used By
→ Plans

why leave that relationship trapped inside application logic?

The publisher possesses resolution knowledge. The Resolver publishes it.

5.26 From Vertical Alignment to Domain Integrity

The original Part 5 emphasized vertical alignment: tailoring retrieval behavior to the expectations of healthcare, real estate, law, finance, and other specialized domains.

The current framework preserves the importance of domain specificity but moves the responsibility.

WebMEM does not attempt to create one AI retrieval experience optimized for every vertical.

Instead, each publisher preserves the semantics necessary for its own domain.

In healthcare, that may include:

Plan
Contract
Segment
Provider
Formulary
Service Area
Benefit
Plan Year

In real estate:

Property
Listing
Parcel
Location
Price
Status
Broker
Availability

In law:

Case
Court
Jurisdiction
Party
Decision
Citation
Subsequent History

The protocol supplies common architectural concerns:

Identity
Provenance
Assertions
Relationships
Applicability
Resolution

The domain supplies the vocabulary and rules necessary to represent its knowledge accurately.

WebMEM does not flatten vertical knowledge into a universal schema. It provides an architecture through which vertical knowledge can retain its integrity.

5.27 What Survived From the Vertical Retrieval Interface

The Vertical Retrieval Interface is no longer a required component of the WebMEM Protocol.

But several observations behind it proved foundational.

The original architecture recognized that machines would increasingly need to:

work with structured knowledge rather than only documents;
interpret natural-language information needs;
apply context;
traverse entity relationships;
coordinate information across domains;
preserve provenance;
and return structured answers rather than merely lists of links.

Those observations survive.

What changed is where WebMEM draws its boundary.

2025

WebMEM Knowledge
        ↓
Vertical Retrieval Interface
        ↓
User Context
        ↓
Ranking
        ↓
Reasoning
        ↓
Answer


2026

Publisher
        ↓
WebMEM Knowledge Representation
        ↓
Resolution Structure
        ↓
────────────────────────
Publisher Boundary
────────────────────────
        ↓
Any Capable Consumer
        ↓
Retrieval / Personalization /
Reasoning / Recommendation /
Action / Answer

The consuming system may still look very much like the Vertical Retrieval Interface envisioned in 2025.

It simply no longer needs to be part of WebMEM.

5.28 A More Durable Architecture

This separation makes the current protocol more durable.

Interfaces will change.

Models will change.

Retrieval architectures will change.

Agents will change.

User-memory systems will change.

Ranking systems will change.

Delivery modalities will change.

The publisher’s fundamental knowledge remains:

What is this?

What do we know about it?

Where did that knowledge come from?

How does it relate to other things?

Where and when does it apply?

Where can resolution continue?

Those are publisher-side questions.

WebMEM gives publishers a way to answer them explicitly.

5.29 From Retrieval Experience to Resolution Infrastructure

The original Vertical Retrieval Interface asked:

How can structured content power a better AI retrieval experience?

The revised framework asks a more fundamental question:

What structure should the publisher expose so that many different retrieval and answer systems can resolve the knowledge correctly?

That is the transition:

Vertical Retrieval Interface
→ one consuming architecture

Resolver
→ one publishing architecture
  available to many consumers

The first attempts to build the machine that answers.

The second improves the knowledge from which machines can answer.

WebMEM no longer tries to own the answer interface.

It publishes the structure the answer interface should not have to reinvent.