Medicare was not selected as a laboratory for knowledge engineering.
It became one because publishing Medicare information kept exposing problems that simpler domains could hide.
At first glance, Medicare appears to be an unusually favorable publishing environment. The Centers for Medicare & Medicaid Services publishes substantial amounts of authoritative information about plans, benefits, enrollment, performance, geography, and other aspects of the program. Much of that information is already structured. Plans and contracts have identifiers. Geographic areas can be identified precisely. Source datasets are updated on recurring schedules.
If the publishing problem were simply getting machine-readable data onto webpages, much of the architecture developed in this book would have been unnecessary.
The difficulty appeared between the source data and the information people actually needed.
A beneficiary does not think in terms of joining CMS datasets. Someone wants to know what plans are available where they live, what a particular plan costs, what a benefit covers, which organization offers a plan, or what an unfamiliar Medicare term means.
Answering those questions requires the publisher to understand what the source data describes, which pieces belong together, which conditions govern their use, and how far a particular assertion can safely travel from its original context.
Medicare happened to concentrate many of those problems in one domain.
Just as importantly, it did so at production scale.
15.1 Authoritative Data Was Only the Beginning
One of the advantages of working with Medicare was that we could often begin with an authoritative factual foundation.
When we worked with a plan premium, enrollment value, benefit, geographic service area, or performance measure, the first problem was not usually finding a random webpage that appeared trustworthy. Authoritative federal sources were available.
That removed one uncertainty and exposed another.
Authoritative data is not the same thing as a finished knowledge model.
CMS datasets exist to serve administrative, regulatory, and operational purposes. Their structures reflect the systems they support: contracts, plans, segments, service areas, benefit packages, enrollment records, reporting periods, performance measures, and other program concepts.
Those structures can be highly precise.
They are not necessarily organized around the information product a beneficiary needs.
Suppose a publisher wants to represent one Medicare plan coherently.
The knowledge may need to come from several sources. One establishes plan identity and availability. Another provides benefits. Another contributes performance information. Enrollment may come from another recurring dataset.
Those sources can also describe different subjects.
A premium may belong to a plan or segment. A performance measure may belong to a contract. Enrollment may describe a particular entity during a particular reporting period. Availability may depend on geography.
The publisher therefore has to perform a translation from source structure to knowledge structure.
That distinction became increasingly important.
A source record did not define the natural boundary of the public Knowledge Object merely because the record was where a fact happened to be stored.
Nor did a source file define that boundary.
One Knowledge Object could depend on several authoritative datasets. One authoritative dataset could contribute assertions to thousands of Knowledge Objects.
The source architecture and the publishing architecture were related.
They were not the same architecture.
Medicare made that difficult to ignore because the data was already machine-readable.
The remaining problem was understanding what it meant.
15.2 Identity, Context, and Applicability Were Entangled
Medicare also gave us unusually strong identity signals.
Contracts have identifiers. Plans have identifiers. Segments can distinguish variants beneath a plan. Geographic areas have established identities of their own.
That precision was useful.
It also revealed the limits of identity.
A Plan ID could correctly identify the parent plan while a particular question required a more specific segment. A plan could be correctly identified while its availability still depended on geography. The same identifier could legitimately participate in different assertions during different plan years.
Identity therefore did not eliminate context.
It made the interaction between identity and context easier to see.
Geography was particularly important.
A county was not merely a word inserted into a page title so the publisher could create a local resource. It could determine which plans were available and, in some cases, which variant of a plan applied.
A correct fact associated with the wrong geography was still the wrong fact for the question.
Time behaved similarly.
Plan years mattered. Benefits changed. Premiums changed. Enrollment changed monthly. Performance measures could describe reporting or measurement periods different from the date on which a page was published.
That forced us to distinguish kinds of time that ordinary publishing often compresses into one label:
Last updated.
A source might be published in August while describing July enrollment. A resource published in September might describe benefits effective the following January. A quality measure displayed today might summarize observations from an earlier measurement period.
Those dates do not mean the same thing.
Nor does an assertion become false merely because it stops describing the current state. A 2026 premium remains a valid historical assertion about 2026 after the 2027 plan year begins.
Medicare therefore kept presenting us with facts whose meaning depended on identity, geography, time, hierarchy, or another contextual condition.
That became especially consequential when the facts were all correct.
A parent plan could have several segment-specific premiums. Every premium could come from authoritative data. Every value could be current for the relevant period.
Only one might apply to the person asking the question.
Medicare did not merely contain exceptions.
It contained structural applicability.
That distinction eventually became one of the central lessons of the work:
All the facts can be true and the answer can still be wrong.
15.3 The Publisher Had to Create Knowledge
Authoritative source data also did not contain every useful public assertion.
Suppose CMS publishes individual plan records and their premiums.
A beneficiary may want to know:
How many Medicare Advantage plans are available in this county?
Or:
What is the average monthly premium among the qualifying plans?
The source contains the records necessary to answer those questions.
It may not contain the answers.
The publisher has to derive them.
That introduces decisions.
Which records count as available? How are segments handled? Which plan types qualify? Are zero-premium plans included in the average? How are missing values treated? Which geographic and temporal boundaries define the population?
A derived number can be mathematically correct while still depending on a publisher-defined methodology.
This made provenance impossible to treat as a source URL pasted beneath a table.
If CMS supplied the records and the publisher calculated the average, CMS did not make the resulting assertion.
The publisher did.
Medicare publishing constantly crossed this boundary between source assertions and publisher knowledge. We filtered, joined, normalized, counted, classified, and aggregated authoritative records to produce information useful to people.
Terminology created another form of publisher responsibility.
A maximum out-of-pocket limit is not simply a number. Understanding the number requires understanding the concept. PPO is not merely a three-character value in a source field. It represents a domain concept whose meaning affects how other assertions are interpreted.
The publisher therefore had to preserve more than values.
It had to preserve meaning.
This is one reason Medicare became such a productive laboratory. It gave us authoritative data without allowing us to pretend that possession of the data completed the publishing task.
The source could tell us what it recorded.
The publisher still had to construct a coherent representation of what those records meant.
15.4 Production Scale Made the Architecture Necessary
Many of these problems can be hidden in a small publishing project.
Five pages can be maintained manually.
A developer can hard-code special handling for one unusual identifier.
An editor can notice that a number changed and correct it in several places.
A methodology can live in one person’s head.
Medicare publishing does not stay small for long.
There are thousands of geographic areas, thousands of plan configurations, multiple product categories, recurring source datasets, changing enrollment values, annual plan cycles, large benefit packages, carrier relationships, contract relationships, and substantial amounts of performance information.
The resources are also public.
People use them.
Search systems crawl them.
External generative systems encounter them.
The source data changes, and the publication has to change with it.
At that scale, repetition becomes an architectural problem.
If the same fact is independently authored into hundreds of pages, every occurrence becomes a maintenance obligation. If provenance is manually attached to individual outputs, changing source versions becomes fragile. If resolution depends on application logic that exists nowhere in the published knowledge, the same ambiguity can reproduce across an entire class of resources.
Scale pushed us away from solving pages one at a time.
The question gradually changed from:
How do we make this page work?
to:
What model allows this class of knowledge to remain coherent across thousands of resources and recurring source updates?
That was the question that mattered.
Medicare was unusually effective at forcing it because the domain combined nearly everything that would eventually become important to KNOL: authoritative source data, stable identifiers, hierarchical entities, geography, time, multiple datasets, derived knowledge, specialized terminology, applicability, provenance, relationships, and resolution.
And it combined them in production.
That made Medicare unforgiving.
It also made it useful.
A simpler domain might have allowed us to conclude that structured data was enough. A flatter entity model might have allowed us to assume that a stable identifier solved applicability. A smaller publication might have allowed repeated facts to remain manually synchronized. A less conditional domain might have allowed successful retrieval to masquerade as successful resolution.
Medicare kept producing counterexamples.
Each one exposed another requirement.
That does not make Medicare a universal proof of how external machines consume the Web.
Our observations remained publisher-side. We could know what we published. We could know which facts and structures were present. We could ask questions and observe generated answers and public citations. We could compare outcomes after publication changes.
We could not see proprietary parsers, retrieval indexes, ranking systems, internal representations, or reasoning processes. We could not prove that a particular HTML structure caused a particular citation or that behavior observed in one external system would generalize to another.
That limitation matters.
The Medicare laboratory was useful not because it revealed the internal architecture of answer engines.
It was useful because it repeatedly exposed weaknesses in our own publishing architecture.
And that was the side of the problem we could actually engineer.