Implementation Note — September 2026
Most Medicare websites publish one representation of information: the webpage.
That page must simultaneously serve the beneficiary reading it, the search engine indexing it, and increasingly, the AI system attempting to extract facts, understand relationships, and answer questions from it.
MedicarePlans.com is testing a different publishing architecture.
One public web surface can contain two coordinated publications: one for people and one for machines.
The human publication explains Medicare coverage in familiar language. The machine publication expresses the underlying entities, facts, relationships, context, provenance, and resolution paths needed to interpret that coverage as knowledge.
MedicarePlans.com implements this machine-facing tier using WebMEM®, a publishing protocol for expressing structured, attributable, resolution-ready knowledge on the public web.
The distinction becomes particularly important at the county level, where a seemingly simple Medicare question can depend on geography, plan classification, plan year, market membership, enrollment, and multiple underlying CMS datasets.
Before AI Can Recommend a Plan, It Must Resolve the Medicare Market
A beneficiary may ask a seemingly simple question:
What Medicare Advantage plans are available in my county?
For a person, the answer might reasonably be presented as a page containing explanatory text, plan counts, descriptions, tables, and links.
An AI system has a different problem.
It must determine what county is being discussed, which plan year applies, what kind of Medicare plans are represented, which plans belong to that market, which facts describe the market as a whole, which facts describe individual plans, and where additional authoritative information about each plan can be resolved.
A conventional webpage may contain much of that information. But the machine may still have to reconstruct the underlying knowledge from headings, prose, tables, links, structured data, and other page elements.
Two-tier publishing asks a different question:
If the publisher already knows the entities, facts, relationships, classifications, scope, and provenance, why require the machine to reconstruct them?
The machine is not merely trying to retrieve a document.
It is trying to resolve a knowledge domain.
Medicare Advantage and SNPs Are Not the Same Knowledge Set
This becomes especially important when standard Medicare Advantage plans and Special Needs Plans are available in the same geographic market.
A human reader can often infer the distinction from headings, explanations, tables, and surrounding context.
A machine should not have to.
MedicarePlans.com therefore treats standard Medicare Advantage plans and Special Needs Plans as distinct county-level knowledge populations.
The human-facing county pages explain those populations to beneficiaries. Alongside them, the WebMEM machine publication explicitly identifies what each population represents.
An AI system encountering a standard Medicare Advantage county publication therefore does not have to infer whether the reported plan population includes Special Needs Plans.
The publication tells it.
Likewise, an SNP county publication identifies itself as a Special Needs Plan population rather than leaving that distinction to extraction from human-oriented prose.
Classification becomes published knowledge instead of inferred meaning.
How WebMEM Implements the Machine Tier
WebMEM does not replace the human-readable Medicare page. Nor does it move the underlying knowledge into a private API or separate machine-only service.
The machine representation is published on the same public web surface as the human representation.
On the Medicare Advantage and Special Needs Plan county pages described in this Implementation Note, the WebMEM publication currently contains three complementary knowledge objects.
1. County Identity and Metadata
The first object establishes the subject and scope of the publication.
It identifies such things as:
- county and state
- geographic identifiers
- plan year
- Medicare plan population
- number of plans represented
- applicable CMS source data and versions
This gives the machine an explicit answer to:
What is this knowledge about?
2. Derived County-Market Facts
The second object expresses facts calculated from the underlying Medicare plan population.
For standard Medicare Advantage markets, for example, this can include aggregate characteristics and distributions across plan types such as HMO, PPO, HMO-POS, and PFFS.
These are not merely numbers placed somewhere in an article for a machine to discover.
They are published as facts associated with an identified subject, defined population, temporal scope, and source provenance.
The machine can therefore determine:
What is true about this Medicare market?
3. A Resolvable Plan Index
The third object defines membership in the county-level plan population.
It identifies the individual plans represented in that market and provides the identifiers needed to distinguish them.
Members can include the CMS contract ID, plan ID and segment ID, plan type, enrollment information, and a canonical continuation to the persistent Plan-ID resource describing the individual plan.
This answers a different question:
What entities make up this market, and where can I continue resolving each one?
The county publication therefore does not have to be a machine dead end.
It becomes a resolution surface.
From County Knowledge to Plan Knowledge
The county implementation is part of a larger resolution architecture on MedicarePlans.com.
It creates a machine-navigable knowledge path that conventional webpages generally leave implicit:
County → Medicare market → plan population → individual plan → Plan ID → plan attributes → benefits → performance → availability → provenance
The human reader does not need to see or understand that entire knowledge path to use a county page.
The machine does.
WebMEM makes that path explicit while allowing the human publication to remain focused on explanation.
People receive explanations. Machines receive resolution-ready knowledge.
Neither representation replaces the other. They describe the same underlying Medicare subject for consumers with fundamentally different information needs.
The Human Publication Did Not Have to Change
There is an important aspect of the Medicare Advantage county implementation that makes the current deployment particularly useful to observe.
The existing human-facing Medicare Advantage county prose was not rewritten as part of the WebMEM deployment.
The explanatory publication remained the explanatory publication.
A machine-facing knowledge publication was added alongside it.
That separation provides a cleaner opportunity to observe what happens when the machine representation of a Medicare market changes while the human editorial representation remains substantially constant.
It also illustrates a fundamental principle of two-tier publishing:
Improving machine understanding should not require distorting human communication for machine consumption.
Web publishers have spent decades adapting human-facing pages partly to satisfy the needs of retrieval systems.
Two-tier publishing asks whether the emerging answer-engine environment gives publishers an opportunity to separate those concerns.
Structured Data Is Not the Same Thing as Structured Knowledge
WebMEM also makes an important distinction between publishing structured data and publishing structured knowledge.
Publishing a county plan count as a machine-readable value is useful.
Publishing that value as a fact about a specifically identified county, for a specified plan year, representing a defined Medicare plan population, derived from identified CMS source data, and connected to the entities comprising that population is something more.
The value has acquired:
identity + meaning + scope + relationships + context + provenance.
The objective is not simply to make information easier to extract.
It is to make the knowledge easier to resolve.
Why This Matters for Medicare Publishing
Medicare is unusually well suited to this publishing model because seemingly simple consumer questions often depend on multiple dimensions simultaneously.
A Medicare Advantage plan exists within a contract. It has a Plan ID. It applies during a particular plan year. It serves defined geographic areas. It may be a standard Medicare Advantage plan or a Special Needs Plan. A Special Needs Plan may have additional eligibility characteristics.
Benefits, premiums, enrollment, availability, and performance can originate from different CMS datasets with different scopes and update cycles.
A human article can explain these things.
But asking an AI system to repeatedly reconstruct all of those relationships from human-oriented content introduces unnecessary ambiguity when the publisher already possesses the underlying structure.
A publisher can publish the relationships directly.
Two-Tier Publishing Is the Principle; WebMEM Is an Implementation
The Medicare Publishing Excellence Standards recognize an emerging principle for structured Medicare publishing:
When important Medicare knowledge can be expressed explicitly, publishers should not require machines to infer it from content created primarily for humans.
This principle does not require a particular protocol, markup language, vendor, or technology.
Two-tier publishing describes the publishing architecture. WebMEM is the protocol MedicarePlans.com currently uses to implement its machine-facing tier.
Other Medicare publishers may implement the same principle differently.
The important objective is that machine-facing Medicare knowledge can, where appropriate, make entities, facts, relationships, classifications, scope, temporal context, provenance, and resolution paths explicit.
The human publication remains responsible for explanation, accessibility, context, judgment, and consumer understanding.
The machine publication is responsible for exposing the underlying knowledge in a form intended for reliable machine resolution.
An Ongoing Public Implementation
MedicarePlans.com is currently applying this two-tier architecture across its Medicare Advantage and Special Needs Plan county resources using public CMS data, with WebMEM providing the machine-facing knowledge representation.
The implementation should not be interpreted as evidence that AI systems will necessarily discover, consume, trust, cite, or use WebMEM or any other particular machine-readable representation.
That is an empirical question.
And it is precisely why implementing the architecture on the public web is useful.
A live Medicare information environment allows us to observe whether machines discover the published knowledge, how they interpret it, whether they preserve important distinctions, whether they follow its resolution paths, and whether changes in knowledge representation produce observable differences in machine behavior.
Those observations can then inform future Implementation Notes without turning correlation into claims of causation.
The experiment is no longer simply whether a machine can read a Medicare webpage.
The more interesting question is:
What happens when the publisher stops making the machine reconstruct the knowledge in the first place?
What This Looks Like in Practice
On a Medicare Advantage county page, the machine-facing publication does not simply reproduce the human-readable page in another format.
WebMEM publishes distinct but related knowledge objects about the same Medicare market.
County Market Facts
One WebMEM fragment represents the derived facts about the county’s standard Medicare Advantage market:
- Entity: the identified county
- Population: standard Medicare Advantage plans; SNPs excluded
- Temporal scope: the applicable plan year
- Knowledge: derived statistics describing the county market
- Provenance: identified and versioned CMS source data
County Plan Membership
A second WebMEM fragment represents the plans that comprise that same market:
- Entity: the same identified county
- Population: the same standard Medicare Advantage plan population
- Temporal scope: the same plan year
- Knowledge: the individual plans belonging to the county market
- Resolution: persistent Plan-ID continuations for the individual plan entities
- Provenance: identified and versioned CMS plan and enrollment data
The two fragments describe different aspects of the same knowledge domain and are explicitly related to one another.
One tells the machine what is true about the market. The other tells it what belongs to the market.
Together, they allow the county to be represented not merely as a webpage containing Medicare information, but as a resolvable Medicare knowledge surface.