The Plan-ID work forced us to become more precise about what we were publishing.
Correct facts were not enough. Identity could have depth. Applicability could depend on context. The publisher could know several valid facts and still need another discriminator before knowing which one applied.
Once we understood that, another question remained.
Even if the knowledge itself was modeled correctly, did the form in which we published it matter?
We had been experimenting with that question almost from the beginning. Because the problem involved machine consumption, it seemed reasonable that increasingly explicit machine-oriented representations would give machines the strongest access to what we knew.
That assumption was worth testing.
Some of the results supported our expectations.
Others did not.
The failures were at least as useful as the successes.
18.1 We Expected Machines to Prefer Machine Structures
Our early work explored several ways of making publisher knowledge more explicit.
The implementations evolved as the architecture evolved. We experimented with structured machine-facing representations, HTML-based structures embedded within public resources, and later more formally data-oriented approaches.
From an engineering perspective, the attraction of a dedicated structured representation was obvious.
Fields could be explicit. Records could be regular. Values could be typed. Collections could have predictable structure. Context and provenance could be represented systematically. A machine would not have to extract a value from a paragraph or reconstruct the relationship between cells in a visually presented document.
If the consumer was a machine, a representation designed around structured data seemed like a natural advantage.
We did not begin these experiments believing ordinary HTML would prove superior.
In several respects, the more specialized representations looked cleaner to us.
That made the results more interesting.
One approach we tested used Frictionless-style data structures. The model was attractive because it treated structured data as structured data. From the publisher’s perspective, it appeared closer to what a machine ought to want than an ordinary webpage.
Our observable results did not consistently support that expectation.
In the tests we conducted, the Frictionless-style representations produced little or no comparable observable answer-engine use, while knowledge represented through our HTML-based structures repeatedly appeared to participate in generated answers.
That was a failure of the experiment in one sense.
It was also useful research.
It did not establish that Frictionless representations cannot be consumed by answer engines. We had tested particular implementations against particular external systems during a particular period. Another system might process the same representation differently. The same systems might behave differently after changes to their crawlers, indexes, or retrieval architectures.
But the result challenged an assumption we had been carrying into the work.
A representation that appears more machine-native to the publisher is not necessarily more useful to machines consuming the public Web.
Theoretical elegance and observable utility were not necessarily the same thing.
That realization made us pay more attention to the representations that were producing useful results rather than the ones we expected to produce them.
Increasingly, that brought us back to HTML.
18.2 We Needed Better Evidence
Observing an answer was not enough.
Suppose a county page states in ordinary prose that sixteen Medicare Advantage plans are available. The same number also appears in a table and in a deeper structured representation.
We ask:
How many Medicare Advantage plans are available in this county?
The system responds:
Sixteen.
What did we learn?
Very little about representation.
The fact could have come from the prose. It could have come from the table. It could have come from another structure on the page. It could have been obtained from another public source entirely.
A correct answer did not tell us which representation had made the knowledge available.
We needed better probes.
That led us to experiment with canaries.
The idea was simple. Place a distinctive fact or value in the structured knowledge without repeating it in the ordinary explanatory prose. Then ask a question whose answer required that fact.
Conceptually:
Visible prose:
Fact X is absent
Structured knowledge:
Fact X is present
Question:
Requires Fact X
Observed answer:
Contains Fact XIf the system recovered Fact X correctly, the observation became more interesting.
We could no longer explain the result simply by pointing to a sentence in the ordinary prose containing the answer.
The canary had improved the experiment.
It had not opened the black box.
That distinction was important.
Even when a canary appeared in a generated response, we could not see the path through which it traveled. A crawler might have parsed the original document and transformed it during indexing. The information might have been normalized into an internal representation. Retrieval might have operated against a processed or cached version of the resource. The model generating the final response might never have encountered the original markup at all.
What we could observe was narrower:
The fact was not present in the ordinary explanatory prose, yet information published through another structure became available enough to participate in the answer.
That was useful evidence.
It was not evidence about the internal architecture of the consuming system.
This distinction became increasingly important as the experiments produced more interesting results. It would have been easy to move from we observed this behavior to we know why the system behaved this way.
We did not.
Our instrumentation ended where the external system began.
We could control and inspect the publisher side. We could vary representations, publish facts, hold other parts of a resource relatively stable, wait for indexing, ask questions, and record what came back.
The machinery on the other side remained proprietary.
The canaries gave us a better flashlight.
They did not give us a window.
18.3 HTML Kept Working
Among the representations we tested, one structure kept producing particularly useful observations.
The HTML table.
There was nothing exotic about it.
Tables had been used on the Web for decades because they solved a human communication problem well. Rows and columns allow people to scan information, compare values, and understand repeated dimensions without reconstructing those relationships from prose.
Consider a simple plan table:
| Plan | Type | Monthly Premium |
|---|---|---|
| Plan A | HMO | $0 |
| Plan B | PPO | $18 |
| Plan C | PPO | $27 |
The table is doing more than arranging text visually.
It establishes a common model across the observations.
Each row represents a comparable record. Each column establishes a shared dimension. The values occupy predictable relationships to their labels and to one another.
That structure can support many questions.
Which plans are PPOs?
Which have a $0 premium?
Which has the lowest premium?
How many plans belong to each type?
The table establishes the comparison surface before any of those questions is asked.
In retrospect, that should not have been surprising.
What surprised us was that we had been trying to produce similar regularity through more specialized machine-facing structures while overlooking how much structure ordinary HTML already provided.
Across repeated testing, tables were among the most consistently useful structures we observed for factual extraction, comparison, and projection.
Again, the conclusion needs to remain within the evidence.
We did not discover that answer engines have a universal table-processing mode. We did not establish that tables receive privileged retrieval or ranking treatment. We did not show that every model interprets every table correctly.
What we observed was enough to affect our publishing decisions:
A structure already excellent for human comparison also appeared repeatedly useful for machine consumption.
That was a valuable alignment.
Other native structures produced more nuanced observations.
Definition lists were particularly interesting because, architecturally, they made a great deal of sense. Definitions are knowledge. A term and its meaning belong together, and both people and machines may need that meaning to interpret other assertions correctly.
Our less-consistent downstream observations concerned definition-list structures inside the experimental <template> serialization. They did not establish that visible <dl> structures were ineffective or that definitions were somehow less useful than tables.
That distinction mattered.
There were now two separate questions:
Does this structure honestly represent the knowledge?
And:
How do current external systems appear to use this particular representation?
The first is an architectural question.
The second is an empirical question.
Its answer can change.
If we redesigned the knowledge architecture every time one external system appeared to favor one representation over another, KNOL would become an elaborate attempt to predict current parser behavior.
That was precisely what we wanted to avoid.
The experiments were useful because they informed the architecture.
They did not get to define reality.
18.4 Native First Was an Experimental Conclusion
As the observations accumulated, our interpretation of HTML changed.
We had been treating the public document primarily as the human surface surrounding the machine-facing knowledge.
But HTML was already doing more than we had assigned to it.
Sections could preserve coherent divisions within the subject.
Headings could label those divisions and establish hierarchy.
Tables could represent comparable observations.
Definition structures could associate terms with their meanings.
Lists could represent collections and sequence.
Links could connect addressable resources.
Temporal elements could distinguish dates and times from surrounding text.
Prose could preserve explanation, qualification, and interpretation where reducing the knowledge to fields would make it worse rather than better.
HTML did not express everything we needed.
A section could not necessarily identify its formal semantic role. A link could connect two resources without stating precisely what relationship joined them. A table could establish labels and values without necessarily identifying canonical predicates, datatypes, or assertion subjects.
Those limitations were real.
But we had been asking the wrong question.
The question was not whether HTML could replace every specialized machine representation.
It was how much of the knowledge HTML already expressed honestly before another mechanism became necessary.
That changed the order of the architecture.
We had started with something resembling:
Human Page
+
Machine RepresentationThe experiments pushed us toward a different sequence:
Knowledge Model
↓
Native HTML
↓
Explicit Semantics
↓
Additional Structure
where neededThe important change was not the diagram.
It was the order of responsibility.
First determine what the knowledge means.
Then use the Web’s native structures where those structures represent that knowledge honestly.
Make additional meaning explicit where native structure leaves an important distinction ambiguous.
Extend the representation only when the knowledge gives you a reason to.
This became the Native-First Principle.
We did not begin with it.
The experiments led us there.
That history matters because Native First is not an ideological claim that HTML is inherently superior to newer or more specialized technologies. Nor is it a prediction that future machines will continue behaving like the systems we happened to test.
It is a publishing decision made under uncertainty.
External systems will change.
Parsers will change.
Models will change.
Retrieval systems will change.
A table that communicates a comparison clearly to a person remains a useful table even if tomorrow’s answer engine processes it differently. A well-organized document remains a well-organized document. A meaningful link remains useful navigation. A definition remains useful knowledge.
That gives native structure a durability that does not depend on our correctly predicting the next machine.
The failures helped us see that.
We had begun by asking how to create a machine-facing representation of information already published for people.
The experiments led us somewhere more useful.
We started asking how to make the public page itself a better expression of the knowledge.