Part 10: Query-to-Resolution Mapping

Using Information Needs to Design Machine-Resolvable Knowledge

The original Memory-First framework proposed Query-Scoped Memory Conditioning: a method for associating particular queries with particular entities, definitions, or publisher resources through repeated semantic exposure.

The objective was to create an Entity-Query Bond strong enough that an AI system would retrieve or prefer the publisher’s knowledge when a target question was asked.

The current WebMEM framework does not retain that conditioning model.

But the original concept contained an important observation:

Different information needs require different knowledge structures.

A publisher should therefore study the questions people and machines are attempting to answer.

Not to repeat those questions until a model associates them with the publisher.

But to determine:

What must be resolved in order to answer this information need correctly?

This produces a new practice:

Query-to-Resolution Mapping.

Information Need
        ↓
Required Identity
        ↓
Required Knowledge
        ↓
Required Relationships
        ↓
Required Context
        ↓
Required Resolution
        ↓
Publisher Representation

10.1 From Query Targeting to Information-Need Analysis

Traditional SEO begins with a query and asks:

What page should rank for this query?

The original Memory-First framework began with a query and asked:

How do we become the answer the machine remembers for this query?

Query-to-Resolution Mapping asks something different:

What knowledge would a machine need in order to answer this question correctly?

Consider:

“What is H5521?”

The answer requires identity resolution:

Input:
H5521

        ↓

Identifier Type:
CMS Contract ID

        ↓

Entity Type:
Contract

        ↓

Entity:
contract:H5521

Now consider:

“Which plans belong to H5521?”

The same identifier begins the query, but the resolution requirement is different:

H5521
        ↓
Contract Identity
        ↓
hasPlan
        ↓
Plan Collection

The query changed.

The entity did not.

The required resolution path did.

10.2 Queries Are Evidence of Resolution Demand

Search queries, answer-engine prompts, site-search logs, support questions, call-center questions, FAQ patterns, and user interviews can all reveal recurring information needs.

For example:

"What is H5521?"

"Who owns H5521?"

"What plans are under H5521?"

"What is the star rating for H5521?"

"Is H5521 an Aetna contract?"

These queries may look different linguistically.

Structurally, they reveal a recurring demand around one entry identity:

contract:H5521
│
├── Identity
├── Carrier Relationship
├── Plan Membership
├── Performance
└── Canonical Resources

That pattern can inform the design of a Contract Resolver.

The publisher is no longer creating separate pages optimized around every wording variation.

The publisher is identifying the knowledge structure underlying the family of information needs.

10.3 Query Language and Resolution Structure Are Different Layers

Users may express the same information need in many ways.

For example:

"What Medicare plans are available
in Mohave County?"

"What Medicare choices do I have
in Mohave County?"

"What Medicare coverage can I get
in Mohave County?"

"Medicare plans near me"

"What are my Medicare options?"

These are not identical queries.

But given the same applicable geography, they may map to substantially the same underlying resolution problem:

Geographic Context
        ↓
Medicare Coverage Option Space
│
├── Original Medicare
├── Medicare Advantage
├── Special Needs Plans
├── Part D
└── Medigap

This distinction matters because publishers should not confuse language variation with knowledge variation.

Many prompts can resolve through one coherent knowledge structure.

10.4 From Keywords to Resolution Requirements

Query-to-Resolution Mapping does not eliminate keyword or query research.

It changes what the publisher does with the result.

Traditional workflow:

Query
→ Keyword Cluster
→ Content Brief
→ Page
→ Ranking

Query-to-Resolution workflow:

Query / Information Need
        ↓
Intent
        ↓
Entry Identity / Context
        ↓
Required Knowledge Objects
        ↓
Required Relationships
        ↓
Applicability Conditions
        ↓
Resolution Target
        ↓
Resource / Resolver Architecture

The query becomes an input to information architecture rather than merely an input to copywriting.

10.5 The Resolution Requirement

For each important information need, the publisher can define a Resolution Requirement.

A Resolution Requirement describes what must be known or traversed to produce an applicable answer.

For example:

“What is the premium for Plan X in Mohave County?”

may require:

1. Resolve Plan X identity.

2. Determine whether the Plan
   has geographic Segments.

3. Resolve Mohave County identity.

4. Find the Segment applicable
   to Mohave County.

5. Retrieve the premium assertion
   attached to that Segment.

6. Confirm applicable plan year.

7. Preserve provenance.

The resulting resolution path is:

Plan
        ↓
Segment
        ↓
Geography
        ↓
Applicable Segment
        ↓
Premium Assertion
        ↓
Provenance

This is considerably more useful than placing the exact query phrase next to a premium value.

10.6 Query Decomposition

Complex information needs can be decomposed into semantic requirements.

Consider:

“Which 2026 Medicare Advantage plans in Mohave County have a $0 premium?”

The query contains several constraints:

Domain:
Medicare Advantage

Time:
2026

Geography:
Mohave County

Entity Type:
Plan

Condition:
monthly_premium = 0 USD

The publisher can then ask whether its knowledge representation supports each requirement:

Can we identify the county?
        ↓
Can we identify applicable plans?
        ↓
Can we preserve plan year?
        ↓
Can we identify the applicable
plan or segment-level premium?
        ↓
Can we evaluate premium = 0?

If one of these structures is missing, the query has exposed a knowledge-model gap.

10.7 Query-to-Fragment Mapping

Different portions of an information need may be supported by different Fragment Classes.

For example:

“What Medicare Advantage plans are available in Mohave County, and what is the average premium?”

may map to:

IdentityFragment
→ Mohave County identity

IndexFragment
→ applicable Medicare Advantage plans

DataFragment
→ source-observed plan premiums

DerivedStatsFragment
→ average premium

MetaFragment
→ source datasets

Relationships
→ County → Plans

Provenance
→ source and derivation lineage

The query does not determine the Fragment Classes mechanically.

It reveals the kinds of knowledge required to satisfy the information need.

10.8 Query-to-Relationship Mapping

Some queries are fundamentally relationship questions.

For example:

“Which plans belong to H5521?”

requires:

contract:H5521
→ hasPlan
→ Plan

while:

“Which formulary does Plan X use?”

requires:

Plan X
→ usesFormulary
→ Formulary

and:

“Where is this plan available?”

may require:

Plan
→ hasSegment
→ Segment
→ appliesIn
→ Geography

Query analysis can therefore expose relationships that exist inside publisher systems but have never been explicitly published.

A recurring relationship question is evidence that the relationship may deserve explicit representation.

10.9 Query-to-Applicability Mapping

Many information needs contain hidden applicability requirements.

Consider:

“Does this plan cover dental?”

The apparent request is factual:

dental_coverage = ?

But the correct answer may depend on:

Which Plan?
Which Segment?
Which Geography?
Which Plan Year?
Which Benefit Category?

Query-to-Resolution Mapping therefore asks not only what fact is requested, but what context must be known before that fact becomes applicable.

This is one of the clearest differences between retrieval and resolution.

10.10 Query-to-Provenance Mapping

Some information needs explicitly or implicitly require evidence.

For example:

“Where did this number come from?”

or:

“Does CMS report this average premium?”

The second question may expose an important provenance distinction:

CMS
→ published source records

Publisher
→ calculated average

Therefore:

CMS did NOT directly publish
the derived average

A publisher that expects provenance-sensitive information needs should represent enough lineage to answer them correctly.

10.11 Query-to-Resolution Target Mapping

Not every information need resolves to the same kind of target.

A query may resolve to:

• an entity;
• a factual assertion;
• a definition;
• a collection;
• an option space;
• a relationship;
• a procedure;
• a policy;
• a recommendation;
• a canonical resource;
• or an unresolved state requiring additional context.

For example:

"What is H5521?"
→ Entity


"What plans belong to H5521?"
→ Collection


"What is the premium for Plan X?"
→ Assertion


"What are my Medicare options?"
→ Option Space


"How do I enroll?"
→ Procedure


"Am I eligible?"
→ Eligibility Resolution


"Which plan is best for me?"
→ Recommendation Problem


"Which premium applies?"
→ Applicability Resolution

Correctly identifying the resolution target helps prevent publishers from forcing every information need into the same page or data structure.

10.12 Some Queries Should Remain Unresolved

Query-to-Resolution Mapping can also reveal when the available information is insufficient.

Consider:

“What is the premium for H5521-290?”

Suppose:

Plan H5521-290
├── Segment 001 → $18.50
└── Segment 002 → $32.00

and geography determines the applicable Segment.

If no geography is known, the correct resolution requirement is:

Need:
geographic context

The publisher should not redesign the knowledge to make one premium appear universally applicable merely because the query asks for one answer.

The query does not have authority to erase ambiguity in the underlying knowledge.

10.13 Clarification Is Part of Resolution

A consuming system may respond to an unresolved information need by requesting additional context.

For example:

User:
"What is the premium for H5521-290?"

System:
"Which county are you in?"

WebMEM does not prescribe that conversational behavior.

But the publisher can expose:

Resolution State:
unresolved

Required Context:
geography

This gives the consuming system a semantic basis for recognizing that more information is required.

10.14 Query Families

Publishers should generally avoid building machine knowledge around every literal query string.

Instead, related queries can be organized into query families based on shared resolution requirements.

For example:

QUERY FAMILY:
Contract Identity

"What is H5521?"
"What does H5521 mean?"
"Who is H5521?"
"Is H5521 a Medicare contract?"

        ↓

RESOLUTION REQUIREMENT:

Identifier
→ Identifier Type
→ Contract Identity

Another family:

QUERY FAMILY:
Contract Membership

"What plans are under H5521?"
"Which plans belong to H5521?"
"What plan IDs use H5521?"

        ↓

RESOLUTION REQUIREMENT:

Contract
→ hasPlan
→ Plan Collection

The language varies.

The resolution structure remains stable.

10.15 Query Families Can Reveal Resolver Opportunities

When many high-value information needs begin from the same identifier, entity, or context, the publisher may have discovered a Resolver opportunity.

For example:

Queries:

"What is H5521?"
"Who owns H5521?"
"What plans are in H5521?"
"What is H5521's star rating?"
"Where can I find H5521 plans?"

        ↓

Shared Entry:
contract:H5521

        ↓

Potential:
Contract Resolver

Likewise:

Queries:

"What Medicare plans are in Mohave County?"
"What Medicare options are available here?"
"What SNP plans are available?"
"What Part D options do I have?"

        ↓

Shared Entry:
county:04015

        ↓

Potential:
Geographic Medicare Resolver

This is one of the most practical uses of Query-to-Resolution Mapping.

Recurring questions reveal recurring resolution demand.

10.16 Resolver Design Begins With the Information Need

A Resolver should not be created merely because an identifier exists.

The publisher should be able to identify a meaningful resolution problem around it.

For example:

Identifier Exists:
yes

Recurring Information Need:
none

Useful Surrounding Relationships:
none

Canonical Continuation:
none

may not justify a Resolver.

By contrast:

Identifier:
H5521

Recurring Questions:
many

Entity Ambiguity:
meaningful

Related Objects:
Plans, Carrier, Performance

Canonical Resources:
available

provides a strong architectural case.

10.17 Query Language Still Matters

Moving from query targeting to resolution architecture does not mean publishers should ignore how people actually ask questions.

Natural language remains valuable for:

• understanding user intent;
• identifying terminology;
• discovering synonyms;
• finding ambiguous concepts;
• designing human-facing explanations;
• creating FAQ knowledge;
• and constructing realistic observation tests.

But query language should inform the representation rather than dictate it mechanically.

For example:

User Language:
"out of pocket max"

Canonical Term:
maximum_out_of_pocket

Common Abbreviation:
MOOP

A DefinedTermFragment can preserve the canonical concept while the human-facing resource uses natural language appropriate to the reader.

10.18 Exact-Match Prompt Embedding Is Not Required

The original Query Conditioning Workflow recommended embedding target query phrasing into headings, definitions, structured content, and distributed representations.

The objective was to increase semantic proximity between a query and the entity or answer the publisher wanted a machine to retrieve.

The current framework does not require exact-match prompt embedding.

Consider:

User Query:
"What plans are under H5521?"

Publisher Knowledge:

contract:H5521
→ hasPlan
→ plan:H5521-001

contract:H5521
→ hasPlan
→ plan:H5521-002

contract:H5521
→ hasPlan
→ plan:H5521-003

The machine-facing representation does not need to contain the literal sentence:

"What plans are under H5521?"

The knowledge required to resolve the information need is already represented.

Likewise, several natural-language variants may map to the same structure:

"What plans are under H5521?"

"Which plans belong to H5521?"

"What plans does H5521 include?"

"Show me H5521 plans."

        ↓

contract:H5521
→ hasPlan
→ Plan Collection

The durable object is the resolution structure, not the query wording.

Publish the answerable knowledge, not every possible way someone might ask for it.

10.19 Query Phrasing Still Belongs in Human Publishing

There are legitimate reasons to use natural question language in human-facing content.

A heading such as:

Which Medicare Advantage plans
are available in Mohave County?

may be useful because that is how people naturally think about the subject.

An FAQ may legitimately represent:

Question:
"What is a Medicare Advantage MOOP?"

Answer:
...

A ProcedureFragment or EligibilityFragment may likewise correspond closely to recurring user questions.

The distinction is one of purpose.

Natural-language questions should be used because they improve communication or accurately represent question-and-answer knowledge—not because repetition of the query is presumed to create an internal machine association.

10.20 From Entity-Query Bonds to Resolution Paths

The original framework defined an Entity-Query Bond as a learned association between a target query and a target entity or content object.

The current framework does not treat such bonds as publisher-created protocol objects.

The more useful publisher-side structure is a resolution path.

For example:

Query:
"Who operates H5521?"

        ↓

Entry Identifier:
H5521

        ↓

Identity Resolution:
contract:H5521

        ↓

Relationship:
operatedBy

        ↓

Target:
Carrier Entity

or:

Query:
"What is the premium for Plan X
in Mohave County?"

        ↓

Plan Identity
        ↓
Segment Relationship
        ↓
County Applicability
        ↓
Applicable Segment
        ↓
Premium Assertion

The publisher can represent these identities, relationships, and applicability conditions explicitly.

Whether a consuming system chooses that path is its own implementation decision.

WebMEM publishes resolution structure. It does not attempt to manufacture query associations inside the consumer.

10.21 Resolution Paths May Cross Resources

A complete resolution path does not need to exist inside one SDT or one web resource.

For example:

Query:
"Which carrier operates the contract
for this plan?"

        ↓

Plan Resource
→ belongsToContract
→ Contract

        ↓

Contract Resource
→ operatedBy
→ Carrier

Stable identity and canonical-resource relationships allow resolution to continue across publisher surfaces.

This reinforces the cross-surface architecture established in Part 8:

The publisher does not need to duplicate the entire resolution graph on every page. The publisher needs to make the path coherent.

10.22 Resolution Paths May Require Several Fragment Classes

A complex information need may traverse several kinds of knowledge.

For example:

“Which Medicare Advantage plans are available in Mohave County, and which has the lowest premium?”

may require:

IdentityFragment
→ Mohave County

        ↓

IndexFragment
→ Applicable Plans

        ↓

DataFragment
→ Premium Assertions

        ↓

Identity / Applicability
→ Ensure Comparable Plan or Segment Scope

        ↓

Derived Comparison
→ Lowest Applicable Premium

The information need crosses fragment boundaries because the knowledge itself performs several semantic roles.

This is why WebMEM composition is more useful than attempting to build one query-specific object containing everything.

10.23 Query Analysis Can Reveal Missing Identity

Some questions expose identity problems that remain invisible when publishers inspect only their own page structures.

Consider recurring questions such as:

"Is H5521 a plan?"

"Who owns H5521?"

"What's the difference between
H5521 and H5521-290?"

"Is H5521-290 the same everywhere?"

These questions reveal that users or machines may encounter several identifier levels without sufficient structural explanation.

The publisher may discover a need to represent:

H5521
→ Contract

H5521-290
→ Plan

H5521-290-001
→ Segment

and the relationships among them.

The queries did not create the identity model.

They exposed the need for one.

10.24 Query Analysis Can Reveal Missing Provenance

Likewise, recurring questions may expose weak provenance.

For example:

"Where did this number come from?"

"Is that a CMS statistic?"

"Did CMS calculate that average?"

"How was this value determined?"

These questions indicate that the distinction among:

Source Data
Publisher
Transformation
Derived Assertion

is material to the information need.

If the publisher cannot answer those questions from its machine-facing representation, the provenance model may be incomplete.

10.25 Query Analysis Can Reveal Missing Relationships

Relationship questions are especially valuable because they often expose structure trapped inside application logic.

Examples include:

"Which plans use this formulary?"

"Which carrier owns this contract?"

"Which counties does this segment cover?"

"Which plans belong to this contract?"

"What formulary does this plan use?"

If the publisher can answer these questions from its internal systems but the relationships are absent from the published knowledge, the final-mile publishing process has discarded useful structure.

Query-to-Resolution Mapping makes that loss visible.

10.26 Query Analysis Can Reveal Missing Applicability

Queries containing words such as:

here
near me
this year
for me
in my county
in this state
for this plan
for this segment
currently
historically

often signal applicability requirements.

The publisher should ask what those expressions resolve against.

For example:

"available here"
→ geography

"this year"
→ temporal scope

"for this plan"
→ entity identity

"for me"
→ potentially private consumer context

"currently"
→ current effective period

This analysis helps distinguish public publisher context from private consumer context.

10.27 Public Context and Private Context

Some resolution requirements can be represented publicly by the publisher.

For example:

Plan
→ availableIn
→ Mohave County

Other context belongs to the consuming system or user:

User
→ preferred doctor

User
→ prescriptions

User
→ household budget

User
→ private eligibility information

Query-to-Resolution Mapping should preserve that boundary.

The publisher represents the public knowledge necessary for resolution.

The consuming system may combine it with private context according to its own authorization and privacy model.

10.28 Query Analysis Can Reveal Resolver Boundaries

Query families can also help determine how broad or narrow a Resolver should be.

Suppose a Contract ID produces recurring questions about:

identity
carrier
plans
performance
historical performance

Those concerns may form one coherent Contract Resolver.

But suppose users also ask:

Does Drug X appear on
the formulary used by Plan Y?

That may require resolution into a different resource:

Contract Resolver
        ↓
Plan
        ↓
Formulary
        ↓
Formulary Resource / Resolver
        ↓
Drug Knowledge

The query reveals where one resolution surface should stop and another should begin.

A Resolver should expose enough structure to continue resolution without attempting to absorb the entire domain.

10.29 Query-to-Resolution Mapping as a Design Tool

A practical mapping exercise can be represented as a table.

Information Need	Entry Context	Required Knowledge	Resolution Target
What is H5521?	Contract ID	Identifier type + identity	Contract
Which plans belong to H5521?	Contract	hasPlan relationships	Plan collection
What is Plan X’s premium here?	Plan + geography	Segment + applicability + premium	Applicable premium assertion
What Medicare options are available here?	Geography	Applicable coverage categories and collections	Option space
Where did this average come from?	Derived assertion	Source + transformation + responsible publisher	Provenance lineage
Which formulary does this plan use?	Plan	usesFormulary relationship	Formulary

This kind of mapping turns query research into a knowledge-engineering input.

10.30 The Query-to-Resolution Gap

For any important information need, the publisher can compare:

What the query requires

versus

What the publisher currently represents

The difference is the Query-to-Resolution Gap.

For example:

Query Requires:
Plan
→ Segment
→ County
→ Premium

Publisher Represents:
Plan
→ Premium

Missing:
Segment
County Applicability

The publisher has discovered a structural gap.

Another example:

Query Requires:
Derived Statistic
→ Source Data
→ Calculation Method

Publisher Represents:
Derived Statistic
→ CMS

Missing:
Publisher Derivation

Again, the problem is visible.

The Query-to-Resolution Gap identifies what the machine would otherwise need to infer because the publisher failed to publish it explicitly.

10.31 Closing the Gap

Closing a Query-to-Resolution Gap may require:

• adding stable entity identity;
• representing a missing parent-child relationship;
• adding provenance;
• separating source-observed and derived knowledge;
• adding temporal or geographic context;
• creating a DefinedTermFragment;
• creating an IndexFragment;
• creating an EligibilityFragment;
• creating a ProcedureFragment;
• adding a canonical-resource relationship;
• or creating a Resolver where a recurring resolution problem warrants one.

It does not necessarily require creating more prose.

Sometimes the human-facing resource already explains the subject perfectly well.

The missing layer is structural.

10.32 Query-to-Resolution Mapping and the Publisher Feedback Loop

Query-to-Resolution Mapping also provides the observation queries used in the Publisher Feedback Loop.

Conceptually:

Query Research
        ↓
Resolution Requirement
        ↓
Publisher Representation
        ↓
Published Reference
        ↓
Same Query Family
        ↓
Observed Reflection
        ↓
Fidelity Measurement

This creates continuity between:

• information-need research;
• knowledge architecture;
• publishing;
• measurement;
• and improvement.

The query is no longer merely a traffic target.

It becomes both a design input and a measurement instrument.

10.33 Query-to-Resolution Mapping and SEO

This framework does not require publishers to abandon conventional query research or SEO.

The same query may legitimately inform two different publishing activities.

QUERY:
"Medicare plans in Mohave County"


SEARCH PUBLISHING

What page should satisfy
the search intent?

How should the page be titled,
structured, linked, and explained?


MACHINE KNOWLEDGE PUBLISHING

What identities, collections,
relationships, and applicability
must be represented so the
information need can be resolved?

The activities complement one another.

One improves the human-facing document and its discoverability.

The other improves the machine-facing representation of the underlying knowledge.

This is two-tier publishing applied directly to query research.

10.34 From Becoming the Answer to Representing the Answer Space

The original Query-Scoped Memory Conditioning model asked:

“How do I become the answer to this query?”

The revised framework asks:

“What answer space does this information need require the publisher to represent?”

Sometimes that answer space contains one object:

H5521
→ Contract

Sometimes it contains a collection:

H5521
→ Plans

Sometimes it contains several legitimate options:

Mohave County
→ Medicare Coverage Options

Sometimes it requires a factual assertion:

Applicable Segment
→ Premium

And sometimes the correct state is:

UNRESOLVED
→ additional context required

The publisher’s job is not to force every information need toward a preferred answer.

It is to represent the applicable information space faithfully enough that resolution can occur.

10.35 The End of Entity-Query Bond Engineering

The current framework therefore retires Entity-Query Bond as a WebMEM optimization target.

A publisher may observe that a particular query frequently produces a particular entity or resource.

That is an observable association.

It should not be treated as a publisher-controlled bond inside machine memory.

Instead, WebMEM focuses on durable publisher-side structures:

Entity Identity
Relationships
Assertions
Provenance
Applicability
Resolution

Those structures remain useful even when:

• query wording changes;
• search behavior changes;
• answer interfaces change;
• models change;
• retrieval systems change;
• or new consumer architectures emerge.

10.36 From Query Conditioning to Query Coverage

A useful publisher-side measurement is not whether a query has been conditioned, but whether the publisher’s knowledge model provides resolution coverage for important information needs.

For a defined query family, the publisher can ask:

Identity available?
        YES / NO

Required relationships represented?
        YES / NO

Required facts available?
        YES / NO

Provenance available?
        YES / NO

Applicability represented?
        YES / NO

Resolution target identifiable?
        YES / NO

Unresolved state supported if needed?
        YES / NO

This creates a practical coverage model without making claims about machine memory.

For example:

QUERY FAMILY:
Contract Identity

Resolution Coverage:
COMPLETE


QUERY FAMILY:
Plan Geographic Premium

Resolution Coverage:
INCOMPLETE

Missing:
Segment → Geography relationship

Now query analysis can reveal concrete publishing work.

10.37 Resolution Coverage Is Not Retrieval Probability

A resource with complete resolution coverage is not guaranteed to be retrieved.

Likewise, a resource with incomplete resolution coverage may still be retrieved and may even produce a correct answer in some circumstances.

These are different properties.

Resolution Coverage
→ Does the publisher represent the knowledge
  required to resolve the information need?


Retrieval Probability
→ Will a particular consuming system
  retrieve or use that representation?

The first can be evaluated against the publisher’s knowledge model.

The second depends on the architecture and behavior of the consuming system.

WebMEM addresses the first.

It does not claim to predict the second.

10.38 Resolution Coverage Can Be Partial

An information need may be only partially supported by the publisher’s current knowledge representation.

For example:

Query:
"Which 2026 plans in Mohave County
use Formulary F123?"

Publisher Represents:

County
→ Available Plans

Plan
→ Formulary

Plan Year
→ 2026

Missing:

Formulary Identity
→ stable canonical representation

The publisher may have enough information to produce a useful result while still lacking part of the semantic structure necessary for complete resolution.

Resolution coverage can therefore be evaluated by component:

Entry Identity:
COMPLETE

Entity Relationships:
COMPLETE

Temporal Context:
COMPLETE

Geographic Applicability:
COMPLETE

Formulary Identity:
INCOMPLETE

Canonical Continuation:
INCOMPLETE

This is more useful than labeling the entire resource simply “optimized” or “not optimized.”

10.39 Resolution Coverage Can Be Tested Before Publication

Unlike observed machine visibility, resolution coverage does not require waiting for an external system to produce an answer.

The publisher can test it directly.

For a defined information need:

Information Need
        ↓
Resolution Requirement
        ↓
Required Identities
        ↓
Required Assertions
        ↓
Required Relationships
        ↓
Required Applicability
        ↓
Required Provenance
        ↓
Required Resolution Target

The publisher can compare those requirements against the proposed WebMEM representation before publication.

This creates a design-time test:

Can the information need be resolved
from the knowledge we intend to publish
without requiring the consumer to infer
a semantic distinction we already know?

If the answer is no, the publisher has identified a representation gap before the machine ever encounters the resource.

10.40 Query Coverage and Conformance Are Different

A WebMEM representation may conform fully to the protocol while providing no resolution coverage for a particular information need outside its intended scope.

For example, a Plan resource may conform perfectly while containing no information about:

provider network participation

If the resource was never intended to represent provider-network knowledge, that absence is not necessarily a conformance failure.

It does mean that the resource cannot independently resolve:

“Does my cardiologist accept this plan?”

Therefore:

Conformance
→ Did the representation honor
  the applicable WebMEM requirements?


Resolution Coverage
→ Does the represented knowledge
  support this information need?

A publisher needs both concepts because they answer different questions.

10.41 Query Coverage and Completeness Are Also Different

Resolution coverage should not be interpreted as a requirement to publish everything the publisher knows.

A resource may deliberately represent only the knowledge appropriate to its semantic scope.

For example:

Contract Resolver

Appropriate:
→ Contract Identity
→ Carrier
→ Plans
→ Performance
→ Canonical Resources

Not Necessarily Appropriate:
→ Every Benefit of Every Plan
→ Every Drug on Every Formulary
→ Every Provider Relationship

The Resolver may still provide coverage for its intended query families by exposing canonical continuation resources.

For example:

Contract
→ hasPlan
→ Plan

Plan
→ canonicalResource
→ Plan Resource

Resolution can continue without requiring the Contract Resolver to duplicate the Plan resource.

Coverage means that a coherent resolution path exists. It does not mean every answer must exist on one page.

10.42 Query-to-Resolution Mapping Supports Distributed Knowledge

This makes Query-to-Resolution Mapping useful across an entire publisher knowledge system.

A complex information need may traverse several resources:

Query:
"Which formulary is used by the plan
available in my county?"

        ↓

County Resolver
→ Available Plan

        ↓

Plan Resource
→ usesFormulary

        ↓

Formulary Resource
→ Formulary Identity

The resolution requirement can therefore be mapped across resource boundaries.

The publisher can test:

• whether each intermediate entity has stable identity;
• whether each relationship is explicit;
• whether canonical continuation resources are available;
• whether applicability survives each transition;
• and whether the final resolution target is reachable.

This turns the publisher’s collection of pages into a connected resolution architecture rather than a set of isolated documents.

10.43 Query-to-Resolution Mapping Can Expose Dead Ends

A resolution path may begin correctly and then terminate because the publisher has not exposed the next relationship or resource.

For example:

County Resolver
→ Plan
→ Formulary ID
→ ???

The Formulary ID may be present but unresolved.

The machine knows that an identifier exists.

It does not know:

What does this identify?

What entity type is it?

Which plans use it?

Where is its canonical resource?

Where can resolution continue?

This is a resolution dead end.

Query-to-Resolution Mapping can expose these dead ends before they become user-facing answer failures.

10.44 Resolution Dead Ends Are Architectural Signals

A dead end does not automatically mean that another resource must be created.

The publisher should ask whether the unresolved object is material to recurring information needs.

For example:

Dead End:
Formulary ID

Recurring Demand:
high

Known Relationships:
Plan → Formulary
Formulary → Plans

Canonical Data:
available

Potential Response:
Formulary Resolver

By contrast:

Dead End:
Internal processing identifier

Recurring Public Demand:
none

Semantic Value Outside Publisher:
minimal

Potential Response:
No public Resolver needed

This prevents Resolver architecture from degenerating into automatic page generation for every identifier in a database.

10.45 Query Demand Does Not Define Truth

Publishers should also resist allowing popular query phrasing to distort the underlying knowledge model.

Suppose users frequently ask:

“Who owns Medicare contract H5521?”

But the technically correct relationship in the publisher’s domain is:

contract:H5521
→ operatedBy
→ Organization

rather than:

contract:H5521
→ ownedBy
→ Organization

The human-facing resource may explain the distinction using natural language.

The machine-facing representation should preserve the semantically correct relationship.

User language informs the publishing problem. It does not redefine the underlying facts.

10.46 Query Intent Does Not Override Provenance

The same principle applies to source expectations.

A user may ask:

“What does CMS say the average premium is?”

Suppose CMS publishes the underlying plan-level premiums but does not publish the requested average.

The publisher may calculate:

CMS Source Records
        ↓
Publisher Calculation
        ↓
average_monthly_premium = 15.26 USD

The answer should not be represented as:

CMS says:
average_monthly_premium = 15.26 USD

merely because that framing matches the user’s question.

The correct resolution preserves the distinction:

Source:
CMS

Derived Statistic:
Publisher

Method:
Defined Calculation

Resolution should satisfy the information need without falsifying the lineage.

10.47 Query Intent Does Not Override Identity

Likewise, users may ask questions at an entity level that is too broad for the requested fact.

For example:

“What is the premium for H5521-290?”

If premiums exist only at geographic Segment scope, the publisher should not flatten:

Segment Premium
        ↓
Plan Premium

merely because the user asked at the Plan level.

The resolution model should preserve:

Plan
→ hasSegment
→ Segment
→ Premium

and identify the additional context necessary to determine the applicable Segment.

The information need determines what must be resolved. It does not grant permission to collapse the knowledge model.

10.48 Query Intent Does Not Override Ambiguity

A user may ask a question that grammatically assumes one answer exists.

The underlying knowledge may not support that assumption.

For example:

“What is the Medicare Advantage plan available in this county?”

when the represented option space contains:

County
├── Plan A
├── Plan B
├── Plan C
└── Plan D

The correct resolution is not to choose one Plan merely because the question uses the singular.

The representation should preserve the legitimate option space.

A consuming system may clarify, summarize, compare, or ask for additional preferences.

WebMEM preserves what is actually true about the available knowledge.

10.49 Query-to-Resolution Mapping and Recommendations

Some information needs explicitly ask for judgment:

“Which Medicare Advantage plan is best for me?”

This is not merely a retrieval or resolution problem.

It may require:

Resolve Applicable Plans
        ↓
Apply User-Specific Context
        ↓
Evaluate Preferences / Criteria
        ↓
Recommendation

The publisher-side knowledge may support the first stage:

County
→ Applicable Plans

Plan
→ Benefits

Plan
→ Premium

Plan
→ Network

Plan
→ Formulary

But private user context may include:

Doctors
Prescriptions
Budget
Preferences
Eligibility
Risk Tolerance

The current WebMEM Protocol does not require those private factors to be published.

Where a publisher itself makes a recommendation, a RecommendationFragment may represent the recommendation and its basis.

Resolution and recommendation remain distinct operations.

10.50 Query-to-Resolution Mapping and Procedures

Other information needs resolve to ordered action rather than an entity or fact.

For example:

“How do I enroll in Medicare?”

The appropriate knowledge may be procedural:

Information Need
        ↓
ProcedureFragment
        ↓
Ordered Steps
        ↓
Eligibility / Preconditions
        ↓
Canonical Action Resources

Query-to-Resolution Mapping therefore applies beyond factual databases and directories.

The same principle holds:

Identify what kind of knowledge the information need actually requires.

10.51 Query-to-Resolution Mapping and Policy

A policy question may require:

“Can I change plans outside the annual enrollment period?”

The resolution requirement may include:

Policy
        ↓
General Rule
        ↓
Exceptions
        ↓
Eligibility Conditions
        ↓
Applicable Time
        ↓
Canonical Source

A flat answer such as:

yes

or:

no

may be inadequate if exceptions determine applicability.

Again, the information need exposes the semantic structure required for a correct answer.

10.52 Query-to-Resolution Mapping and Definitions

Definition queries may appear simple:

“What is MOOP?”

But even definitions may require domain scope.

For example:

MOOP
        ↓
Maximum Out-of-Pocket
        ↓
Domain:
Medicare Advantage

If another domain uses the same abbreviation differently, the domain context becomes part of resolution.

A DefinedTermFragment can preserve:

• canonical term identity;
• preferred label;
• abbreviation;
• definition;
• domain;
• and related terminology.

The query reveals a terminology need.

The publisher responds with a defined knowledge object rather than repeated prompt phrasing.

10.53 Query-to-Resolution Mapping as Publisher Research

This practice creates a different relationship between query research and publishing.

Queries are no longer valuable only because they represent traffic opportunities.

They reveal where people and machines encounter unresolved knowledge.

A recurring question may indicate:

• an identity gap;
• a relationship gap;
• a provenance gap;
• an applicability gap;
• a terminology gap;
• a collection gap;
• a procedural gap;
• or a missing Resolver.

This turns query analysis into a form of knowledge architecture research.

Queries reveal where the information environment is asking the publisher to resolve something.

10.54 The Query Becomes a Test Case

Once an information need has been mapped to a resolution requirement, the original query family can become a test case.

For example:

QUERY FAMILY

"What is H5521?"
"What does H5521 identify?"
"Is H5521 a contract?"

        ↓

EXPECTED RESOLUTION

identifier:
H5521

identifier_type:
CMS Contract ID

entity_type:
Contract

entity:
contract:H5521

The publisher can test:

Before Publication:
Does our representation support this resolution?

After Publication:
Does the observed machine reflection
preserve this resolution?

The same query family therefore participates in:

Research
        ↓
Architecture
        ↓
Validation
        ↓
Publication
        ↓
Observation
        ↓
Fidelity Measurement

10.55 Query-to-Resolution Mapping Completes the Loop

This connects Part 10 directly to the Publisher Feedback Loop.

Observe Real Information Needs
        ↓
Map Resolution Requirements
        ↓
Design Publisher Knowledge
        ↓
Publish WebMEM Representation
        ↓
Observe Machine Answers
        ↓
Compare Against Resolution Requirements
        ↓
Identify Gaps
        ↓
Improve Publisher Knowledge

The query is no longer a phrase to be conditioned into machine memory.

It is evidence about what the information system needs to be able to resolve.

10.56 From Query-Scoped Conditioning to Resolution Engineering

The original Query-Scoped Memory Conditioning framework proposed:

Target Query
        ↓
Repeated Semantic Exposure
        ↓
Entity-Query Bond
        ↓
Preferred Retrieval

The current framework replaces that model with:

Information Need
        ↓
Resolution Requirement
        ↓
Knowledge Architecture
        ↓
WebMEM Representation
        ↓
Resolution Coverage
        ↓
Observable Fidelity

The difference is fundamental.

The first attempts to alter machine behavior around a query.

The second improves the publisher’s ability to represent the knowledge required by the query.

10.57 The New Precision Discipline

Query-Scoped Memory Conditioning was described as the precision tool of Memory-First Optimization.

Query-to-Resolution Mapping can legitimately occupy that role in the current framework.

It gives publishers a disciplined way to move from:

People ask this.

to:

Have we represented it explicitly?

to:

Can the information need be resolved
from what we have published?

and finally:

When machines attempt that resolution,
does the meaning survive?

This is a precision discipline because it connects real information demand directly to knowledge architecture.

It does not require the publisher to predict every future prompt.

It requires the publisher to understand the recurring resolution problems its knowledge should be capable of supporting.

10.58 The New Query Workflow

The revised workflow can now be stated completely:

1. Observe Information Needs
   Identify recurring questions through search behavior, answer-engine observations, site search, support interactions, research, domain expertise, or other legitimate evidence.
2. Group Query Families
   Separate superficial wording differences from genuinely different information needs.
3. Identify the Entry Context
   Determine what identifier, entity, geography, term, policy, collection, or other context begins resolution.
4. Define the Resolution Target
   Determine whether the information need should resolve to an entity, assertion, collection, option space, definition, procedure, policy, recommendation, canonical resource, or unresolved state.
5. Map the Resolution Requirements
   Identify the identities, assertions, relationships, provenance, applicability, and other semantic structures required to reach that target correctly.
6. Compare Against Publisher Knowledge
   Determine whether the publisher actually possesses the required knowledge.
7. Compare Against Published Knowledge
   Determine whether the required knowledge is represented explicitly or remains trapped inside databases, application logic, routing systems, prose, or presentation.
8. Identify the Query-to-Resolution Gap
   Document the semantic structure the consuming system would otherwise need to infer.
9. Design the Representation
   Add or improve the appropriate SDT composition, Fragment Classes, identities, assertions, provenance, relationships, applicability, canonical resources, or Resolver architecture.
10. Validate Resolution Coverage
    Confirm that the information need can be resolved through the published knowledge without requiring unnecessary reconstruction of publisher-known semantics.
11. Publish
    Expose the resulting representation through the appropriate canonical resource.
12. Observe
    Use representative queries from the original query family to inspect downstream machine behavior.
13. Measure Fidelity
    Compare the observed reflection against the expected resolution.
14. Improve
    Feed material findings into the Publisher Feedback Loop.

Conceptually:

Information Need
        ↓
Query Family
        ↓
Resolution Requirement
        ↓
Publisher Knowledge
        ↓
Query-to-Resolution Gap
        ↓
Knowledge Architecture
        ↓
WebMEM Representation
        ↓
Resolution Coverage
        ↓
Publication
        ↓
Observed Reflection
        ↓
Semantic Fidelity
        ↓
Publisher Learning

10.59 The Query Is No Longer the Object of Optimization

This is perhaps the most important departure from Query-Scoped Memory Conditioning.

The query itself is not the thing being optimized.

The query reveals a demand placed upon the information system.

For example:

Query:
"What plans are available in Mohave County?"

does not primarily tell the publisher:

Use these words more often.

It tells the publisher:

A machine or human needs to move from:

Mohave County

to:

Applicable Plan Collection

Likewise:

Query:
"What is H5521?"

reveals:

Identifier
→ Identifier Type
→ Entity Identity

And:

Query:
"Where did this average come from?"

reveals:

Derived Assertion
→ Source Data
→ Transformation
→ Responsible Publisher

The query is evidence of a resolution requirement.

10.60 The Publisher Does Not Need to Predict Every Prompt

One weakness in query-conditioning strategies is the enormous variability of natural language.

The same information need may be expressed through hundreds of formulations.

For example:

"What is H5521?"

"What does H5521 mean?"

"Tell me about H5521."

"H5521 Medicare"

"Who is H5521?"

"Is H5521 an insurance company?"

"What kind of Medicare identifier
is H5521?"

Attempting to optimize a publisher representation around every possible formulation is neither necessary nor scalable.

If the publisher has represented:

Identifier:
H5521

Identifier Type:
CMS Contract ID

Entity Type:
Contract

Entity:
contract:H5521

Carrier Relationship:
...

Plan Relationships:
...

Canonical Resource:
...

then the publisher has created a reusable knowledge structure capable of supporting many different information needs.

The consumer remains responsible for mapping natural language to that structure.

10.61 Resolution Architecture Outlives Query Language

Query vocabulary changes.

User behavior changes.

Interfaces change.

Voice queries differ from typed queries.

Agents may generate information needs that no human ever phrased explicitly.

The underlying knowledge relationships may remain stable.

For example:

contract:H5521
→ hasPlan
→ plan:H5521-290

remains meaningful regardless of whether the information need is expressed as:

"Which plans belong to H5521?"

or generated internally by an agent as:

resolve_plans(contract:H5521)

This is why the current framework prioritizes resolution architecture over prompt-specific conditioning.

Natural language is variable. Semantic relationships are durable.

10.62 Query-to-Resolution Mapping Applies to Agents

Not every future information need will originate as a human-written question.

An agent may need to determine:

Entity:
contract:H5521

Goal:
enumerate related plans

or:

Entity:
plan:H5521-290

Goal:
resolve applicable premium

Context:
county:04015
plan_year:2026

The same publisher-side architecture applies.

The consumer supplies an information need and available context.

The publisher representation supplies:

• identity;
• assertions;
• relationships;
• provenance;
• applicability;
• and canonical continuation resources.

Resolution does not depend on the information need having originated as a search keyword or conversational prompt.

10.63 Query-to-Resolution Mapping Is Not Answer Manipulation

A publisher may be tempted to use information-need research to structure knowledge toward a preferred commercial, political, editorial, or strategic outcome.

That is not the purpose of Query-to-Resolution Mapping.

The mapping process should preserve the legitimate information space.

For example:

Information Need:
"What Medicare options are available?"

Legitimate Resolution:
Applicable Coverage Option Space

should not become:

Preferred Commercial Product
→ represented as the only option

unless the underlying information need and represented scope genuinely support that result.

Likewise:

Information Need:
"Which plans belong to this contract?"

Legitimate Resolution:
Complete Applicable Plan Collection

should not become:

Only Plans the Publisher
Wants the Machine to See

when the resource claims to represent the complete collection.

Resolution architecture should clarify the information space, not covertly narrow it.

10.64 Resolution Coverage Creates a Publisher-Side KPI

The original framework searched for metrics such as Memory Fitness and Entity-Query Bond strength.

Resolution coverage provides a more defensible publisher-side measure.

For a defined set of important query families, a publisher can measure:

Total Query Families:
100

Complete Resolution Coverage:
72

Partial Resolution Coverage:
18

No Resolution Coverage:
10

The publisher can then identify why coverage is incomplete:

Missing Identity:
4

Missing Relationships:
7

Missing Provenance:
3

Missing Applicability:
8

Missing Canonical Resource:
2

Missing Knowledge:
4

These numbers describe the publisher’s own information architecture.

They do not pretend to measure hidden machine preference.

10.65 Resolution Coverage Can Be Risk-Weighted

Not every information need carries equal importance.

A publisher may prioritize query families according to:

• frequency;
• business importance;
• public-interest importance;
• regulatory significance;
• potential harm from incorrect resolution;
• or strategic value.

For example:

High Risk:
"Am I eligible for this program?"

High Risk:
"Does this plan cover this service?"

Moderate Risk:
"What plans are available?"

Lower Risk:
"What does this abbreviation mean?"

A high-risk unresolved gap may deserve attention even if the corresponding query volume is small.

This moves prioritization beyond traffic alone.

10.66 Query-to-Resolution Mapping Supports Conformance Testing

Although resolution coverage and conformance are distinct, real information needs can provide useful conformance test cases.

For example:

Test:
Resolve premium for Plan X
in County Y

Expected Path:

Plan
→ Segment
→ County
→ Applicable Segment
→ Premium

If the representation instead produces:

Plan
→ Premium

while the premium is actually segment-specific, the test may expose an identity or applicability conformance failure.

Query-derived tests therefore provide a practical way to exercise the semantic requirements of the protocol.

10.67 Query-to-Resolution Mapping Supports Resolver Conformance

A Resolver should be capable of supporting the resolution purpose for which it claims to exist.

If a Contract Resolver claims to expose:

Contract Identity
Carrier
Related Plans
Canonical Resources

then representative query families can test those claims:

"What is H5521?"
→ Contract Identity

"Who operates H5521?"
→ Carrier

"Which plans belong to H5521?"
→ Related Plans

"Where can I learn about Plan X?"
→ Canonical Resource

If the Resolver cannot support one of its declared resolution functions, the implementation should be examined.

10.68 Query-to-Resolution Mapping and the Two-Tier Web

The same information need may shape both publishing layers differently.

Consider:

“What Medicare coverage options are available in Mohave County?”

The human-facing representation may respond with:

• an explanation of Original Medicare;
• a Medicare Advantage comparison;
• Part D guidance;
• Medigap explanation;
• Special Needs Plan information;
• tables;
• links;
• and guidance about what to consider next.

The machine-facing representation may expose:

county:04015
        ↓
Applicable Coverage Option Space
│
├── Original Medicare
├── Medicare Advantage
├── Special Needs Plans
├── Part D
└── Medigap

The human page explains the choices.

The machine representation identifies the option space and its structure.

One information need informs both.

The outputs are different because their interpreters are different.

10.69 From Ranking Targets to Resolution Responsibilities

The evolution of query thinking across the three publishing models can now be stated clearly.

TRADITIONAL SEO

Query
→ Ranking Target
→ Page


MEMORY-FIRST 2025

Query
→ Conditioning Target
→ Entity-Query Bond


WEBMEM 2026

Information Need
→ Resolution Requirement
→ Publisher Knowledge Architecture

Each model asks a different question.

SEO asks:

What should rank?

The original Memory-First model asked:

What should the machine remember?

The current WebMEM model asks:

What must the publisher represent so the information need can be resolved correctly?

10.70 The New Precision Tool

Query-to-Resolution Mapping is therefore the precision tool of the current publisher-side framework.

It connects:

Real Questions
        ↓
Real Information Needs
        ↓
Required Knowledge
        ↓
Publisher Architecture
        ↓
Machine-Facing Representation
        ↓
Observable Resolution

It replaces speculative Entity-Query Bond engineering with something the publisher can inspect, design, validate, and improve.

The result is not a promise that the publisher will “become the answer.”

It is a stronger publishing objective:

When an information need reaches the publisher’s knowledge, the structure required to resolve it should already be there.

Conclusion

The original Query-Scoped Memory Conditioning model attempted to lock publisher entities into the retrieval paths of specific prompts.

The current framework does not attempt to lock anything into machine memory.

Instead, it treats queries as evidence.

They reveal what people and machines are trying to resolve.

They reveal which identities matter.

They reveal which relationships matter.

They reveal where applicability matters.

They reveal where provenance matters.

And they reveal where the publisher’s current information architecture leaves machines to reconstruct knowledge the publisher already possesses.

That changes the objective from:

How do we become the answer?

to:

What does a correct answer require?

and then:

Have we published the knowledge
required to resolve it?

The query is not something to condition.

It is something to understand.