KNOL changes publishing before it changes markup.
That may be its most practical consequence.
Once the publisher begins with the Knowledge Object rather than the anticipated answer, familiar publishing decisions start to look different. The first question is no longer necessarily what article to write, what template to use, which keyword to target, or which structured-data type to add.
The publisher has another decision to make first.
What does the organization actually know, and what part of that knowledge is it trying to publish?
That change sounds subtle. In practice, it moves important decisions much earlier in the publishing process. Identity, boundaries, context, relationships, provenance, and applicability can be considered before they are scattered across prose, tables, database fields, application logic, and metadata.
The result is not a rigid construction sequence. Real knowledge modeling is iterative. Discovering a relationship may change the boundary of the object. Examining provenance may reveal that two apparently comparable values mean different things. Testing a question may expose context that should have been modeled from the beginning.
What changes is the publisher’s orientation.
The work begins with the knowledge.
14.1 Start With What You Intend to Know
Suppose a publisher wants to create a resource about Medicare coverage in Mohave County, Arizona.
A conventional publishing process might begin with the page.
What should the title be? Which questions should it answer? Which keywords matter? Which sections should the template contain? Which tables should appear?
Those questions may eventually be useful.
They do not yet tell us what the publisher intends to represent.
Several very different Knowledge Objects could produce pages that appear to concern the same subject.
The publisher could represent a particular Medicare plan available in Mohave County. It could represent the county itself. It could represent a carrier operating there. Or it could represent the Medicare coverage environment available in that county during a particular plan year.
Those are not different ways of writing the same page.
They are different knowledge objectives.
For example:
Represent the 2026 Medicare coverage environment in Mohave County, Arizona.
That objective establishes something before the page exists. Geography matters. Time matters. The object concerns the coverage environment rather than one individual plan or the county in general.
The same distinction applies to the camera retailer.
“Create an Apex X5 page” is a publishing task.
A knowledge objective might be:
Represent the Apex X5 Mark II, including the knowledge necessary to understand its identity, specifications, capabilities, compatibility, provenance, and distinctions from other variants in the product family.
The objective does not prescribe an article.
It does not prescribe a table.
It does not prescribe HTML, Schema.org, RDFa, or any other implementation mechanism.
It establishes what the publisher intends to know publicly and coherently.
That distinction helps prevent the Question Space from quietly taking control of the architecture again.
A knowledge objective such as answer whether the Apex X5 shoots 4K/120 is already shaped around one anticipated question. The resulting publication may answer that question perfectly while failing to represent the larger body of product knowledge from which many other questions could be answered.
The Knowledge Object should exist before those projections.
The knowledge objective gives the publisher a place to begin.
14.2 Model Before You Publish
Once the objective is clear, the publisher can begin determining what the Knowledge Object actually contains.
This is not yet an exercise in markup.
For the Apex X5 Mark II, the publisher first needs to establish the Primary Subject and decide which knowledge belongs within its semantic boundary. Specifications, video capabilities, compatibility, availability, and provenance may belong naturally to the camera object. Detailed knowledge about the manufacturer or the Apex Z lens mount may belong elsewhere, connected through relationships rather than absorbed into the camera KNOL.
Then the assertions themselves need attention.
The publisher may know that the camera weighs 658 grams, that the Mark II supports 4K/120 video, and that it uses the Apex Z lens mount. Those apparently simple statements raise many of the questions developed throughout this book.
Whose fact is this? What context governs it? Is the measurement specific to a particular configuration? Where did the specification come from, and which source version supports it? Does the assertion apply to every Apex X5 or only the Mark II? What would need to be known before safely applying it to a particular camera?
The Medicare publisher encounters the same questions in a more conditional domain. A premium may describe a segment rather than its parent plan. A performance rating may describe the contract rather than the plan. A benefit may depend on network status. Availability may depend on geography. A county statistic may be calculated from CMS records without ever having been asserted by CMS itself.
Sometimes context goes even deeper than governing an assertion. It can help constitute the identity of the Knowledge Object.
Consider 2026 Medicare coverage options in Mohave County, Arizona. That object is not simply about Mohave County with a year attached as metadata. Change the geography and the object describes a different coverage environment. Change the plan year and the state being represented changes again. Geography and time participate in defining what the publisher is representing.
These are the kinds of distinctions that should be discovered while modeling the knowledge rather than after a page has already imposed its structure.
The publisher does not need to turn them into a giant KNOL checklist. The objective is to develop the habit of asking the questions before publication choices obscure the answers.
That is the difference between modeling knowledge and arranging content.
The distinction also prevents KNOL from becoming another template system.
Templates are useful. A publisher maintaining thousands of cameras, Medicare plans, facilities, or other recurring objects should not model each one independently from scratch. Once the publisher understands the recurring knowledge architecture, a production template can make that architecture repeatable.
But the order matters.
A template begins with predefined fields and asks the subject to fit them. Knowledge modeling begins with the subject and asks what must be preserved for that subject to remain meaningful.
The template should emerge from repeated knowledge modeling rather than substitute for it.
The same principle applies to boundaries. A bounded Knowledge Object does not need to contain everything to which it relates.
The Apex X5 Mark II can relate to its manufacturer without containing everything the publisher knows about the manufacturer. It can relate to the Apex Z lens mount without absorbing the entire lens-mount Knowledge Object. A Medicare plan can relate to its carrier and contract while allowing each to remain a coherent object in its own right.
Relationships allow Knowledge Objects to remain bounded without becoming isolated.
Once the model is reasonably clear, the publishing decisions become much easier.
Knowledge that is genuinely tabular can become a table. A collection can become a list. A concept that readers need to understand can be defined. Relationships can connect to other public resources. Explanatory knowledge can remain prose. Important semantic distinctions can be made explicit where native HTML leaves them ambiguous. Recognizable public resources can use established vocabulary where that vocabulary fits.
The technologies come after the decisions about meaning.
That order also gives the publisher permission not to use a technology.
A table does not need additional annotation simply because annotation is available. A Knowledge Aspect does not need its own Schema.org identity merely because one can be created. A straightforward product resource does not need to become technically elaborate to qualify as knowledge-native publishing.
The implementation should grow only when the knowledge requires it.
The publisher is not trying to produce the most sophisticated representation.
The publisher is trying to preserve what it knows.
14.3 Publish the Knowledge, Not the Architecture
There is a danger in spending this much time discussing knowledge architecture.
The publisher can begin to think the architecture itself is what the reader should experience.
It is not.
The photographer visiting an Apex X5 page does not need to learn that the publisher has established a Primary Subject, divided the Knowledge Object into Knowledge Aspects, modeled assertion subjects, and considered provenance boundaries.
The photographer needs a good camera resource.
Likewise, a Medicare beneficiary does not need an interface labeled Identity Aspect, Resolution State, or Assertion Provenance. The beneficiary needs understandable information about coverage.
KNOL should improve that experience rather than impose its internal terminology upon it.
This returns us to an important discovery from Chapter 6. Modeling knowledge can simplify human communication.
Once a publisher knows what it is trying to communicate, prose no longer has to carry everything.
A table can communicate a set of comparable facts efficiently. A list can make a collection easier to scan. A definition can explain a term once rather than forcing every later sentence to compensate for ambiguity. A relationship can lead to another resource rather than requiring the current page to reproduce everything known about the related subject.
And prose can concentrate on what prose does particularly well: explanation, qualification, interpretation, judgment, and instruction.
On the Web, and especially on small screens, that can make a substantial difference.
A page organized around the knowledge can be easier to scan because its structure reflects what the reader is trying to understand. Important facts do not have to be excavated from paragraphs written primarily to satisfy a content format. Explanations can be shorter because the factual structure around them is doing more of the work.
The machine benefits from many of the same decisions.
That does not mean the page was written for the machine.
It means the publisher communicated the knowledge clearly enough that more than one consumer can use it.
The architecture should remain underneath that experience.
The finished HTML is not the objective. Neither is the semantic annotation or the resource graph.
They are representations.
The durable asset is the maintained knowledge they express.
14.4 Test With Questions You Never Authored
If the publisher is no longer attempting to manufacture the entire Question Space, a different testing problem appears.
How do we know whether the Knowledge Space is any good?
One answer is to ask questions the publisher never independently authored answers for.
This returns us to the camera catalog from Chapter 2.
Suppose the publisher has represented a catalog of cameras through consistent identities, specifications, capabilities, relationships, and context.
Testing only the obvious questions proves relatively little.
What does the Apex X5 Mark II weigh?
What lens mount does it use?
What is its maximum 4K frame rate?
Those questions mostly retrieve individual assertions the publisher already knew would be useful.
More revealing questions combine the knowledge in ways the publisher did not specifically prepare:
Which full-frame cameras under 700 grams support in-body stabilization and 4K recording above 60 frames per second?
Or:
Which cameras use the Apex Z mount but weigh less than the Apex X5 Mark II?
Now the question is probing the Knowledge Space.
The same approach can be used with Medicare. A test can combine costs, benefits, geography, plan type, and performance relationships without requiring the publisher to have authored that exact answer beforehand.
Some questions should be answerable directly.
Some should require derivation across several assertions.
Some should traverse relationships.
And some should deliberately omit information required for resolution.
The failures become useful.
If a comparison fails because the same property was represented inconsistently across products, the question has exposed a comparability problem.
If an answer attaches a contract rating to a plan, the question has exposed a subject problem.
If a county statistic cannot be reproduced, the problem may be provenance or methodology.
If the system confidently selects a segment-specific premium without knowing the geography, the test has exposed a resolution problem.
And if the requested conclusion simply cannot be supported by the knowledge available, that is useful information too.
Questions become probes of the knowledge architecture.
That is a very different use of information demand.
Under Question-Space publishing, the newly discovered question becomes another candidate content artifact.
Under Knowledge-Space publishing, the question can reveal whether the existing knowledge is sufficient.
If it exposes genuinely missing knowledge, the publisher can improve the model.
If the knowledge already exists but the relationship among its parts is unclear, the publisher can improve the structure.
If the question requires context that has not been supplied, the correct outcome may be recognition of that boundary rather than another answer.
The cycle becomes less about producing more pages and more about improving the underlying knowledge:
Model → Publish → Query → Observe → Diagnose → Correct → RepublishNo Knowledge Object will support every conceivable question. Nor should that be the objective.
The more useful test is whether it supports the legitimate projections its knowledge ought to support and preserves the boundary when it does not.
That brings us back to the asymmetry that began this architecture.
The publisher does not need to write every future answer.
It needs to build and maintain sufficiently coherent knowledge that future questions can reveal what that knowledge supports.
The question can arrive later.