Trust Publishing Institute

Can AI Systems Resolve Knowledge Serialized Natively in Human-Facing HTML?

Study Track: HTML as Structured Memory Surfaces
Publication Date: September 8, 2026
Status: Active Controlled Field Test
Study ID: TPI-HSM-2026-05

Abstract

Web publishing systems increasingly expose structured information to search engines, answer engines, artificial intelligence systems, and autonomous agents. One approach is to publish a separate machine-readable representation of the knowledge contained within or associated with a human-facing webpage. Another possibility is to bind machine-readable semantic state directly to the existing HTML elements through which the same knowledge is presented to people.

This controlled field study examines the second approach.

MedicarePlans.com is modifying a county-level Medicare Options publication so that selected facts, relationships, contextual constraints, provenance references, and presentation transformations are serialized directly into the human-facing HTML using semantic data-* attributes. Existing HTML tables are additionally assigned stable fragment identifiers and described using Schema.org Table metadata that resolves to the corresponding visible HTML table.

The experimental implementation is referred to in this study as native KNOL serialization.

Unlike an earlier MedicarePlans.com implementation in which machine-facing knowledge was separately encapsulated in HTML elements, the native KNOL implementation binds machine-readable semantic state directly to the document elements that constitute the human publication.

The primary experiment asks:

Can an AI retrieval system resolve machine-only knowledge serialized natively into the semantic attributes of a human-facing HTML document without requiring a separately encapsulated machine-readable knowledge fragment?

A controlled validation canary is included exclusively within the native KNOL serialization. The canary value is not published in visible prose, table content, JSON-LD, HTML comments, or a separate representation. Successful retrieval of the exact canary therefore provides evidence that the published machine-readable state was accessible to the observed retrieval system.

The study does not claim access to, or knowledge of, the internal retrieval, indexing, parsing, ranking, or inference mechanisms of any external AI system. Results are limited to observable outputs produced in response to controlled queries.

Research Question

The public web traditionally uses HTML elements to communicate information through human-readable documents.

Structured-data systems provide additional machine-readable representations, commonly through formats such as JSON-LD, RDFa, Microdata, linked resources, APIs, or separately embedded machine-readable structures.

This study examines a narrower architectural question:

Can the human-facing HTML manifestation itself serve simultaneously as an addressable machine-readable knowledge surface?

More specifically, the study asks whether an external AI retrieval system can resolve semantic state expressed through attributes attached directly to ordinary HTML elements, including:

  • knowledge-object identity;
  • subject identity;
  • geographic and temporal context;
  • fragment and assertion-group identity;
  • assertion identity;
  • machine-readable values;
  • datatypes and units;
  • presentation transformations;
  • semantic relationships;
  • provenance bindings; and
  • machine-only validation state.

The distinction being tested is between knowledge represented separately from the human document and knowledge represented through the human document itself.

Relationship to the Prior Dual-Publishing Study

This experiment follows the MedicarePlans.com field study TPI-HSM-2026-03, “A Field Study of Dual Human-and-Machine Publishing on MedicarePlans.com.”

That study examines an architecture in which people receive explanatory content while machines receive a parallel structured representation containing facts, relationships, context, scope, membership, and source attribution.

The earlier implementation uses WebMEM® HTML-in-HTML serialization in which machine-facing knowledge can be separately encapsulated within HTML elements.

The present study changes one architectural variable.

Instead of:

HUMAN-FACING HTML
        +
SEPARATELY ENCAPSULATED
MACHINE KNOWLEDGE
        |
        v
HTML <template> SERIALIZATION

the experimental publication uses:

HUMAN-FACING HTML
        |
        +-- Knowledge identity
        +-- Context
        +-- Assertion identity
        +-- Typed values
        +-- Relationships
        +-- Transformations
        +-- Provenance
        |
        v
NATIVE KNOL SERIALIZATION

The human-facing document therefore becomes both the presentation surface and the carrier of machine-readable semantic state.

Why This Distinction Matters

Separately encapsulated machine representations have several useful characteristics. They can expose information that has no desirable human presentation, preserve normalized values independently of display formatting, and organize complex machine-facing structures without requiring changes to the visible document.

They also create a second manifestation of knowledge.

For example, a publisher may visibly publish:

Total Medicare Advantage plans | 16

while separately publishing a machine-oriented structure asserting that the plan count is 16.

Native serialization introduces another possibility.

The existing visible table row can itself carry the semantic identity and machine-readable state:

<tr data-knol-assertion="ma.plan_count">
    <td data-knol-role="label">
        Total Medicare Advantage plans
    </td>
    <td
        data-knol-role="value"
        data-knol-value="16"
        data-knol-type="integer">
        16
    </td>
</tr>

The human reader still sees:

Total Medicare Advantage plans: 16

The machine-readable representation additionally identifies what the value means, its datatype, the assertion to which it belongs, and the broader context inherited from the document.

The experiment asks whether that second, separately encapsulated manifestation is necessary for machine resolution, or whether semantic state bound directly to the human-facing manifestation can itself function as a machine-consumable knowledge surface.

Experimental Surface

The test is conducted on the MedicarePlans.com Medicare Options county resolver.

The initial test page represents:

Entity: Mohave County, Arizona
County FIPS: 04015
Plan year: 2026
Publication type: Medicare Options
Knowledge-node identity: medicare-options:county:04015:2026

At the document root, the experimental implementation establishes the publication identity and inherited context:

<main
    data-knol
    data-knol-id="medicare-options:county:04015:2026"
    data-knol-type="medicare-options"
    data-knol-subject="county:04015"
    data-knol-context-geography="county:04015"
    data-knol-context-plan-year="2026">

This establishes a machine-readable boundary around the publication and identifies the subject, geography, publication type, and applicable plan year.

Native KNOL Serialization Architecture

The implementation uses hierarchical semantic binding.

Conceptually:

KNOWLEDGE-NODE PUBLICATION
medicare-options:county:04015:2026
        |
        +-- FRAGMENT
        |     Medicare Advantage
        |
        +-- ASSERTION GROUP
        |     Medicare Advantage Snapshot
        |
        +-- ASSERTION
        |     ma.plan_count
        |
        +-- VALUE
        |     16
        |
        +-- TYPE
        |     integer
        |
        +-- PROVENANCE
              CMS Landscape source record

The same architecture is applied to multiple portions of the document, including Medicare Advantage, Part D, Medigap, Special Needs Plans, local assistance, and provenance resources.

Knowledge-Node Identity

The <main> element identifies the overall knowledge-bearing publication.

The node identity is scoped to:

  • publication type;
  • county FIPS;
  • plan year;
  • subject entity; and
  • geographic applicability.

This context can be inherited by subordinate semantic structures rather than repeated on every assertion.

Fragments

Major document sections are identified as semantic fragments, including:

medicare-options.overview
medicare-options.ma
medicare-options.pdp
medicare-options.medigap
medicare-options.snp
medicare-options.local-support
medicare-options.provenance

The fragment boundary corresponds to an existing human-facing document section.

No separate machine-facing fragment is required for the native serialization under test.

Assertion Groups

Existing HTML tables and related structures are identified as assertion groups.

Examples include:

medicare-options.ma.snapshot
medicare-options.ma.ppo.enrollment-leaders
medicare-options.pdp.basic.enrollment-leaders
medicare-options.medigap.plan-g.carrier-pricing
medicare-options.snp.snapshot
medicare-options.local-support.options

The group provides semantic organization while the individual assertions remain represented by subordinate HTML elements.

Assertion Identity and Values

Individual assertions are identified using data-knol-assertion.

For example:

<tr data-knol-assertion="ma.plan_count">

The associated value is identified separately:

<td
    data-knol-role="value"
    data-knol-value="16"
    data-knol-type="integer">
    16
</td>

This separates:

ASSERTION IDENTITY
ma.plan_count

        from

ASSERTION VALUE
16

while preserving the ordinary human table presentation.

Presentation Transformations

Some human representations differ from their associated machine-readable values.

The implementation declares those presentation relationships explicitly.

For example:

<td
    data-knol-role="value"
    data-knol-value="280.70"
    data-knol-type="decimal"
    data-knol-unit="USD"
    data-knol-transform="currency-display">
    $280.70
</td>

Other implemented transformation classes include:

boolean-yes-no
categorical-natural-language
zero-count-natural-language

The purpose is not to require human presentation to use a machine-oriented lexical representation.
Instead, the semantic attributes identify the machine state associated with the human manifestation.

Relationships

Existing human hyperlinks can also function as semantic relationship manifestations.

For example:

<a
    href="/medicare-advantage/arizona/mohave/"
    data-knol-role="relationship"
    data-knol-predicate="has_medicare_advantage_collection"
    data-knol-target="medicare-advantage:county:04015:2026">
    See Medicare Advantage plans in Mohave County
</a>

The visible hyperlink continues to provide human navigation.
The semantic attributes separately identify:

  • the relationship role;
  • the relationship predicate; and
  • the target knowledge entity.

Schema.org Table Discovery Layer

The experiment also uses Schema.org Table metadata as a conventional discovery layer over selected HTML tables.

Each described table receives a stable HTML fragment identifier.

For example:

<script type="application/ld+json">
{
    "@context": "https://schema.org",
    "@type": "Table",
    "@id": "#table-ma-snapshot",
    "name": "Medicare Advantage Snapshot",
    "description": "Medicare Advantage plan availability and cost characteristics for the county.",
    "url": "#table-ma-snapshot"
}
</script>

The corresponding human table is:

<table
    id="table-ma-snapshot"
    data-knol-group="medicare-options.ma.snapshot"
    data-knol-provenance="#source-cms-landscape">

The Schema.org representation does not duplicate the factual contents of the table.
Its function in this experiment is limited to identifying and describing the HTML table as a structured publication resource.

Conceptually:

SCHEMA.ORG TABLE
        |
        v
HTML TABLE
        |
        v
KNOL ASSERTION GROUP
        |
        v
ASSERTIONS
        |
        v
VALUES / RELATIONSHIPS / PROVENANCE

This permits conventional structured metadata and experimental native semantic serialization to coexist without requiring the same factual payload to be published twice.

Provenance Binding

Selected assertion groups identify provenance resources through internal document references.

For example:

data-knol-provenance="#source-cms-landscape"

The referenced source record contains information including source identity, publisher, source version, and source URL.
This permits multiple assertions within an applicable group to inherit the same source binding.

The implementation currently identifies primary CMS source families including:

  • Medicare Advantage and Special Needs Plan Landscape source files;
  • Medicare Part C & D Performance Data; and
  • Medicare Advantage & Part D Contract and Enrollment Data.

This study does not attempt to establish a complete provenance ontology or validation system.

The purpose is to determine whether machine-readable provenance relationships can coexist with and be resolved from the native human publication.

The Controlled Validation Canary

The central experimental control is a machine-only validation canary.

The canary is published within the Medicare Options Data Sources & References section of the test document.

For the initial Mohave County test, the canary is:

<meta
    name="knol-validation-canary"
    data-knol-id="medicare-options:county:04015:2026"
    data-knol-assertion="publication.validation_canary"
    data-knol-role="machine-only-value"
    data-knol-value="knoltest:v1:county:04015:2026:9e4c7b2f6a813dc4"
    data-knol-type="test-token"
    data-knol-purpose="controlled-validation"
    data-knol-test-profile="knol-v1-canary">

The expected canary value is:

county:04015:2026:9e4c7b2f6a813dc4

The canary is intentionally:

  • not visible as human-facing text;
  • not stated in explanatory prose;
  • not contained in an HTML table cell;
  • not duplicated in Schema.org JSON-LD;
  • not contained in an HTML comment;
  • not published in a separate WebMEM “ fragment; and
  • not derivable from the underlying CMS datasets.

The value exists solely as machine-oriented semantic state associated with the native HTML publication.

Why a Canary Is Necessary

Ordinary factual queries cannot by themselves establish whether a consuming system accessed native KNOL attributes.

For example, the question:

How many Medicare Advantage plans are available in Mohave County?

could potentially be answered from:

  • visible table content;
  • page prose;
  • another MedicarePlans.com page;
  • another publisher;
  • CMS source data;
  • a search index;
  • previously retrieved information; or
  • model inference.

Even if the answer is correct, the retrieval path remains ambiguous.

The validation canary is designed to reduce that ambiguity.

The exact token:

county:04015:2026:7F3A91C2

has no consumer meaning and is not expected to exist independently in Medicare source data.

Therefore, successful retrieval of the exact token from the identified publication provides substantially stronger evidence that machine-oriented state associated with the native HTML representation was accessible to the observed system.

It does not establish how that system obtained, indexed, stored, parsed, or reasoned over the value.

Experimental Intervention

The principal intervention is a change in machine serialization strategy.

Prior state:

Human-facing Medicare Options HTML
        +
Separately encapsulated WebMEM
HTML-in-HTML <template> fragments

Experimental state:

Human-facing Medicare Options HTML
        +
Native KNOL semantic attributes
        +
Schema.org Table discovery metadata
        +
Machine-only KNOL validation canary
        -
Separately encapsulated WebMEM
<template> knowledge fragments

The explanatory human content is intentionally left substantially unchanged.
This is important to the experimental design.

The study is not intended to test whether rewritten prose, additional answer blocks, different headings, or altered editorial content change AI retrieval behavior.

It is intended to examine the effect of changing the machine-readable publication architecture.

Controlled Variables

Where practical, the experiment holds the following elements constant:

  • canonical page URL;
  • page topic;
  • human-facing explanatory prose;
  • visible factual table values;
  • page title and major headings;
  • CMS source datasets;
  • plan year;
  • county geography;
  • internal navigation;
  • publisher/domain;
  • visible provenance disclosures; and
  • general page layout.

The primary changed variable is the machine-facing serialization mechanism.

Primary Test Query

After the experimental page has been published and sufficient opportunity has been provided for external retrieval systems to discover the updated representation, the primary query will ask for the validation canary.

The preferred query form is:

What KNOL validation canary is declared for the 2026 Medicare Options publication for Mohave County, Arizona?

A more explicit diagnostic form may also be used:

What machine-readable validation token is associated with the KNOL publication identified as medicare-options:county:04015:2026?

The expected response is the exact value:

county:04015:2026:7F3A91C2

The second query is intentionally more explicit than the primary query. It supplies the machine-readable publication identifier while asking the external system to resolve a value that is not present in visible prose.
Neither query should include the expected canary value.

Secondary Test Queries

The study will also issue queries directed at ordinary knowledge represented through the same native KNOL publication.

These queries serve a different purpose from the validation canary.

For example:

How many standard Medicare Advantage plans are available in Mohave County, Arizona, for 2026?

Expected value:

16

Additional queries may examine assertions including:

  • number of $0-premium Medicare Advantage plans;
  • number of HMO plans;
  • number of PPO plans;
  • number of plans including prescription drug coverage;
  • lowest maximum out-of-pocket amount;
  • highest maximum out-of-pocket amount;
  • highest Part B giveback;
  • total Special Needs Plans;
  • D-SNP count;
  • C-SNP count; and
  • I-SNP count.

These secondary queries test whether ordinary factual knowledge remains resolvable after removal of the separately encapsulated machine-facing representation.

They do not independently establish that an external system consumed data-knol-* attributes because the same values may also be recoverable from visible HTML tables or other sources.

The validation canary therefore remains the principal diagnostic for native machine-state retrieval.

Two-Level Success Test

The experiment distinguishes between two different forms of successful resolution.

Level 1 — Human-Visible Knowledge Resolution

The external system correctly resolves factual information represented visibly in the human-facing document.

For example:

ma.plan_count = 16

A successful result at this level establishes that removal of the separately encapsulated representation did not prevent resolution of the ordinary page fact.

It does not establish that native KNOL attributes were consumed.

Level 2 — Machine-Only KNOL Resolution

The external system correctly returns:

county:04015:2026:7F3A91C2

in response to a query requesting the publication’s validation canary.

Because the complete token exists only in the native machine-oriented serialization under the experimental design, this result would provide stronger evidence that machine-readable state associated with the HTML publication was accessible to the observed system.

Conceptually:

VISIBLE FACT RESOLVED?
        |
        +-- NO
        |    |
        |    v
        |  No evidence of successful
        |  page-level resolution
        |
        +-- YES
             |
             v
      CANARY RESOLVED?
             |
        +----+----+
        |         |
       NO        YES
        |         |
        v         v
 Visible HTML   Evidence consistent
 resolution    with native machine-
 demonstrated  state retrieval

Interpretation Matrix

Visible Fact Validation Canary Interpretation
Resolved Resolved exactly Strongest experimental result. The system can resolve ordinary page knowledge and a machine-only value published through the native KNOL representation.
Resolved Not resolved The system can resolve human-visible page information, but the test provides no evidence that the native machine-only KNOL state was consumed.
Not resolved Resolved exactly Unusual but significant result. The machine-only value was accessible even though the selected visible fact was not successfully resolved. Additional replication would be required.
Not resolved Not resolved No evidence from the tested query set that the experimental publication was successfully resolved.

Canary Match Criteria

The strongest positive result requires retrieval of the complete expected token:

county:04015:2026:7F3A91C2

Results should be classified separately as:

  • Exact match — the complete token is returned correctly;
  • Partial match — only a portion of the token is returned;
  • Incorrect match — a different token or value is returned;
  • Non-resolution — the system states that the value cannot be found or does not provide one; or
  • Unsupported response — the system provides a value without sufficient evidence to determine whether it corresponds to the published canary.

An exact match is materially more probative than a partial match because the county FIPS, plan year, and fixed validation suffix are encoded together in the machine-only value.

Cross-County Replication

The canary design permits replication across multiple county publications without changing the validation profile.

The structure is:

county:{county_fips}:{plan_year}:7F3A91C2

Accordingly, different county pages produce different complete values while preserving the same experimental convention.

For example:

Mohave County
county:04015:2026:7F3A91C2

Yavapai County
county:04025:2026:7F3A91C2

Maricopa County
county:04013:2026:7F3A91C2

Cross-county testing provides an important additional control.

If an external system correctly returns the county-specific value for multiple independently identified county publications, the result is more informative than retrieval of a single universal token shared by every page.

A system returning the Mohave value when queried about Yavapai County would constitute a failed county-resolution test even though the common validation suffix was correct.

Serialization Isolation

The experimental canary must remain isolated to preserve its diagnostic value.

During the test period, the complete canary value should not be intentionally published in:

  • visible page prose;
  • headings;
  • table cells;
  • Schema.org JSON-LD;
  • HTML comments;
  • WebMEM “ fragments;
  • XML or RSS feeds;
  • sitemaps;
  • linked methodology documents;
  • social posts;
  • press materials;
  • study pages accessible to the retrieval system before the test is completed; or
  • other publicly crawlable documents.

This last condition is particularly important.

The public study report itself must not expose the expected canary value before the retrieval experiment is completed.

A pre-registered internal study record may preserve the exact value and experimental protocol before testing, but publication of that record should occur only after the primary observation has been captured.

Otherwise, successful retrieval could potentially originate from the study documentation rather than the experimental Medicare Options page.

Pre-Registration and Evidence Preservation

Before the first primary canary query is issued, the study should preserve a timestamped record containing:

  • the study ID;
  • the research question;
  • the test URL;
  • the publication identity;
  • the exact canary value;
  • the HTML element containing the canary;
  • the primary and diagnostic query wording;
  • the expected result;
  • the classification criteria;
  • the machine systems to be tested; and
  • the date and time at which the experimental representation became publicly accessible.

The test page source should also be preserved before querying.

Where practical, screenshots or source captures should document that:

  1. the canary exists in the experimental HTML;
  2. the canary does not appear visibly on the rendered page;
  3. the complete canary is absent from the separately published JSON-LD;
  4. the prior HTML-in-HTML knowledge fragments have been removed for the experimental state; and
  5. the ordinary human-facing content remains substantially unchanged.

Each external query result should then be captured with:

  • system or product tested;
  • query wording;
  • date and time;
  • response;
  • citations or source references shown by the system;
  • whether MedicarePlans.com was identified as a source;
  • canary match classification; and
  • any relevant screenshots.

Testing Sequence

To reduce post-result interpretation, the study uses a predetermined sequence.

Phase 1 — Pre-Publication Verification

Confirm that the experimental HTML contains the intended KNOL serialization and validation canary.

Confirm that the complete canary does not occur elsewhere in the publication stack being tested.

Confirm that human-facing content remains substantially unchanged.

Phase 2 — Publication

Publish the native KNOL representation at the existing Medicare Options URL.

Remove the corresponding separately encapsulated knowledge representation from the experimental surface.

Record the deployment timestamp.

Phase 3 — Discovery Observation

Observe crawling, indexing, cached representations, and other publicly observable evidence that the updated page has been rediscovered where such evidence is available.

The absence of such evidence does not establish that the page has not been retrieved.

Phase 4 — Visible-Fact Queries

Issue selected factual queries whose expected answers are present in the human-facing HTML.

Record whether those facts remain resolvable after the serialization change.

Phase 5 — Canary Query

Issue the predetermined validation-canary query without including the expected value.

Record the response exactly.

Phase 6 — Diagnostic Query

If the primary canary query does not resolve the value, issue the more explicit diagnostic query identifying the KNOL publication ID.

The diagnostic query is recorded separately and is not treated as equivalent to an unprompted primary-query success.

Phase 7 — Replication

Where practical, repeat the protocol on additional county publications using their county-scoped canary values.

Primary Outcome

The primary outcome is:

Whether an external AI retrieval system returns the exact county-scoped validation canary published exclusively as machine-oriented semantic state in the native HTML representation.

This is a retrieval observation.

It is not, by itself, evidence of any particular internal parsing architecture, indexing system, model behavior, memory mechanism, or reasoning process.

Secondary Outcomes

Secondary observations include:

  • whether visible factual assertions remain resolvable after removal of separately encapsulated knowledge fragments;
  • whether the system cites or identifies the experimental MedicarePlans.com page;
  • whether the system can distinguish county-specific canaries across otherwise structurally similar pages;
  • whether machine-only retrieval differs across AI products;
  • whether results change after subsequent crawling or indexing cycles;
  • whether explicit publication identity improves diagnostic retrieval; and
  • whether native semantic attributes appear sufficient for machine resolution without factual duplication in JSON-LD.

What a Positive Result Would Establish

An exact canary retrieval would support a narrow conclusion:

Machine-only semantic state published in association with native HTML was externally resolvable under the tested conditions.

If the result is replicated across county-specific values, the observation becomes stronger because the system must distinguish between multiple structurally similar publications and return the value associated with the requested county.

A positive result would justify additional study of native semantic publishing as a machine-consumable web architecture.

It would not establish that KNOL is required, optimal, standardized, universally supported, or causally responsible for unrelated search or answer-engine behavior.

What a Negative Result Would Establish

Failure to retrieve the canary would not establish that external systems categorically ignore HTML data-* attributes.

Possible explanations include:

  • the updated page has not yet been crawled;
  • the retrieved representation excludes the relevant attributes;
  • the system does not index arbitrary `data-*` state;
  • the system indexes the state but does not expose it through the tested query;
  • the query does not trigger retrieval of the relevant page;
  • the system retrieves a transformed or sanitized representation;
  • the system does not treat the “ element as relevant knowledge;
  • the system has not refreshed a previously stored representation; or
  • another unobserved retrieval-stage behavior prevents resolution.

A negative result is therefore a result about the tested publication, system, query, and observation period—not a universal statement about machine consumption of semantic HTML.

Important Experimental Limitation: The Meta Element

The validation canary is serialized in a element using a conventional name attribute together with experimental data-knol-* attributes.

Accordingly, a positive result would demonstrate accessibility of the complete machine-oriented record under the tested representation.

It would not isolate which attribute or HTML mechanism caused the value to become retrievable.

For example, the system may recognize the presence of:

name="knol-validation-canary"

while obtaining the actual value from:

data-knol-value="..."

or may process the element through a more general HTML metadata extraction mechanism.
This is acceptable for the first experiment.

The initial question is whether native machine-oriented state can be resolved from the human document at all.

Subsequent controlled tests may isolate individual serialization features by varying the element type, name attribute, data-* namespace, location within the document, or presence of conventional metadata cues.

Study Limitations

No access to internal retrieval systems

The study cannot observe how an external system crawls, parses, transforms, indexes, embeds, stores, ranks, retrieves, or reasons over the experimental HTML.

Only externally observable responses can be documented.

Retrieval does not prove mechanism

Even an exact canary match cannot establish the internal path by which the value became available.

The study therefore describes such a result as evidence consistent with native machine-state retrieval, not proof of a specific internal implementation.

Search and answer systems change continuously

Models, retrieval infrastructure, indexes, crawling behavior, ranking systems, source corpora, and response-generation systems may change during the study.

Single publisher

The initial implementation is controlled by MedicarePlans.com. Independent replication would be required before generalizing results to other publishers or domains.

Domain characteristics

Medicare is highly structured, identifier-rich, geographically scoped, and temporally versioned. Results may differ in less structured information environments.

Schema.org is present

The test page includes conventional Schema.org Table metadata pointing to the HTML tables. The JSON-LD does not contain the canary, but its presence means the page is not testing KNOL attributes in complete isolation from other structured-data mechanisms.

Public-document contamination

Once the canary value appears in publicly accessible study documentation, search indexes, screenshots, social posts, archives, or third-party discussions, subsequent retrieval tests become less diagnostically useful because the value may be recoverable from sources other than the experimental page.

Follow-On Experiments

If the initial canary is successfully resolved, subsequent tests may examine progressively narrower questions.

These may include:

  • removing the conventional “ cue while retaining `data-knol-*` attributes;
  • moving the canary from a “ element to an ordinary HTML element;
  • testing an attribute-only value on a visible table element;
  • testing values attached to links, rows, cells, and section elements;
  • comparing native KNOL serialization with HTML-in-HTML “ serialization;
  • testing identical knowledge using JSON-LD, native attributes, encapsulated HTML, and linked resources;
  • testing county-specific canaries across multiple pages;
  • testing whether provenance references can be resolved;
  • testing whether relationship predicates and targets can be resolved independently of visible anchor text; and
  • testing whether presentation transformations preserve machine resolution when visible and machine values differ.

A particularly important follow-on experiment would compare three controlled representations of the same machine-only value:

REPRESENTATION A
HTML-in-HTML <template>

REPRESENTATION B
Native data-knol-* attributes

REPRESENTATION C
JSON-LD

        |
        v

SAME VALUE
SAME PAGE TYPE
SAME QUERY PROTOCOL
SAME OBSERVATION SYSTEMS

That comparison would help distinguish whether machine retrieval behavior is associated with the knowledge itself or with the serialization through which the knowledge is exposed.

Relationship to Future Manifest-Controlled Validation

The present study deliberately stops short of implementing a complete canonical assertion store, Serialization Manifest, invariant profile, fidelity classifier, or manifestation validator.

The native KNOL markup being tested provides the semantic publication substrate upon which those systems may subsequently operate.

A later implementation may separately maintain:

  • canonical assertion records;
  • manifestation bindings;
  • serialization modes;
  • transformation references;
  • invariant profiles;
  • effective manifestation records;
  • validation states;
  • presentation-state classifications; and
  • change-propagation rules.

That is a separate research question.

This study asks the more fundamental question first:

Before building a system to preserve and validate native machine-readable knowledge, can external machine systems resolve that knowledge from the publication surface at all?

Research Status

Protocol Defined — Pre-Observation

As of September 8, 2026, the native KNOL serialization architecture, controlled validation canary, query protocol, outcome classifications, and interpretation criteria have been defined.

The primary canary observation has not yet been recorded.

This distinction is intentional. The experimental protocol is being documented before the result is known so that the interpretation of a positive or negative observation is not constructed retrospectively around the observed response.

The initial experimental sequence is:

1. Complete native KNOL serialization
        |
        v
2. Verify county-scoped validation canary
        |
        v
3. Preserve pre-test source and protocol
        |
        v
4. Remove separately encapsulated
   WebMEM <template> representation
        |
        v
5. Publish experimental representation
        |
        v
6. Permit external rediscovery
        |
        v
7. Test ordinary visible facts
        |
        v
8. Query machine-only validation canary
        |
        v
9. Record result
        |
        v
10. Replicate where practical

The study record will be updated as observations are collected.

Research Hypothesis

The experiment is organized around a falsifiable proposition:

Machine-readable semantic state bound directly to a human-facing HTML publication can be externally resolved without requiring a separately encapsulated machine-facing representation of that knowledge.

The strongest initial evidence supporting this hypothesis would be exact retrieval of a county-specific machine-only validation canary that exists exclusively in the native KNOL serialization.

Failure to retrieve the canary would not falsify native semantic HTML as a general architecture. It would establish only that the machine-only value was not successfully resolved under the tested combination of publication state, external system, query, and observation period.

Experimental Decision Rule

For the initial Mohave County observation:

EXPECTED CANARY county:04015:2026:7F3A91C2

The primary outcome will be classified as follows:

Positive observation — the external system returns the complete expected canary without the value having been supplied in the query.

Partial observation — the external system returns a recognizable portion of the canary but not the complete county-scoped value.

Negative observation — the external system does not resolve the canary or states that the requested value cannot be identified.

Incorrect observation — the external system returns a different value as the validation canary.

The classification will be recorded independently of whether the result supports the research hypothesis.

Why the Result Matters

The architectural question being tested is more fundamental than whether a particular markup convention improves rankings, citations, or traffic.

If the machine-only canary is resolvable, then a public HTML document can potentially carry two forms of information simultaneously:

HUMAN PRESENTATION
        |
        | visible text
        | tables
        | links
        | explanations
        |
        +
        |
MACHINE SEMANTIC STATE
        |
        | identity
        | assertions
        | values
        | relationships
        | context
        | provenance
        | transformations
        |
        v
SAME PUBLICATION SURFACE

That would materially change the design question.

Instead of asking only:

How should a publisher create a separate machine representation of a document?

another question becomes possible:

When the human document already manifests the knowledge, can the publisher make that manifestation machine-resolvable directly?

If so, separate encapsulation may remain useful where the human representation is incomplete, insufficient, inappropriate, or absent—but it would no longer necessarily be the default mechanism for every machine-readable assertion.

Native Versus Encapsulated Serialization

The experiment therefore does not assume that native serialization should replace encapsulated serialization.

The two modes solve different publication problems.

NATIVE SERIALIZATION

Knowledge already has
a suitable human manifestation
        |
        v
Annotate / bind that manifestation


ENCAPSULATED SERIALIZATION

Knowledge has no suitable
human manifestation
        |
        v
Publish a separate
machine-readable manifestation

A hybrid publication may use both.

For example, a visible table cell may be sufficient to manifest a plan count, premium, deductible, or enrollment value.

A provenance record, derivation description, machine-only relationship, validation state, or other knowledge element may require a different representation.

The broader architectural question is therefore not:

Native or encapsulated?

It is:

Which manifestation preserves the required semantic state with the least unnecessary duplication?

The present study evaluates whether native serialization is a viable member of that serialization model.

Study Significance

If successful, the experiment would provide evidence for a web-publishing architecture in which the traditional boundary between human content and machine-readable knowledge becomes more flexible.

The webpage would remain a human publication.

But selected elements within that page could also function as independently identifiable manifestations of machine-readable knowledge.

Conceptually:

PAGE
 |
 +-- prose
 |
 +-- heading
 |
 +-- table
 |    |
 |    +-- assertion
 |    |     |
 |    |     +-- value
 |    |     +-- type
 |    |     +-- unit
 |    |     +-- provenance
 |    |
 |    +-- assertion
 |
 +-- relationship
 |
 +-- provenance resource
 |
 +-- machine-only semantic state

The atomic machine-readable unit would therefore not have to be the page itself.

Nor would it necessarily have to be a duplicate structured-data object describing the page.

It could be an addressable assertion, relationship, value, or contextual element manifested directly through the publication.

Conclusion

This study tests a deliberately narrow proposition.

MedicarePlans.com already publishes a human-facing Medicare Options document containing explanatory prose, tables, links, source disclosures, and other conventional web content.

The experimental implementation does not replace that document.

It makes selected elements of the existing document semantically explicit.

The resulting publication associates ordinary HTML manifestations with knowledge-node identity, contextual scope, assertion identity, typed values, presentation transformations, semantic relationships, provenance resources, and a controlled machine-only validation token.

Schema.org Table metadata provides a conventional discovery path to selected structured HTML resources without duplicating their factual contents.

The separately encapsulated HTML-in-HTML knowledge representation is then removed from the experimental state.

The critical observation is intentionally simple:

Can an external AI retrieval system recover a value that exists only in the native machine-readable state of the human-facing HTML publication?

If the answer is yes, the result will not establish a universal standard, prove an internal retrieval mechanism, or demonstrate that every AI system consumes arbitrary semantic attributes.

It will establish something narrower and more useful:

Under the observed conditions, machine-only knowledge serialized directly into the human-facing HTML publication was externally resolvable.

If the answer is no, the experiment will still have established a controlled boundary for further testing of element types, attribute conventions, discovery mechanisms, serialization modes, and retrieval systems.

Either outcome advances the same research program:

determining how knowledge itself can become a first-class publication unit on the public web.