• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

The Visibility Code™

Knowledge Engineering for Answer Engines™

  • The Visibility Code
  • Publisher’s Job Description
  • About
    • Press

Chapter 22: KNOL Came After the Requirements

The architecture in this book looks considerably more orderly than the work that produced it.

That is what happens when a discovery is explained after the fact. We can begin with the Question Space and Knowledge Space, define the Knowledge Object, establish its semantic boundary, introduce KNOL, and then work through structure, semantics, provenance, and resolution in an intelligible sequence.

We did not have that sequence when the work began.

We had Medicare data, production websites, changing source files, search systems, generative systems, questions we wanted the published information to support, and failures we did not initially know how to explain.

The architecture accumulated one requirement at a time.

Medicare Options exposed the first major shift. We had been accustomed to treating information demand as a publishing queue. A new question suggested another answer, another passage, another page, or another optimization opportunity.

But many apparently different questions were operating against the same underlying county knowledge.

Once the geography, plan year, plan inventory, classifications, premiums, carrier relationships, and provenance were represented coherently, the questions no longer looked like independent factual publications. They looked like different projections across a smaller body of maintained knowledge.

That gave us the distinction between the Question Space and the Knowledge Space.

It also changed the economic logic of publishing.

The durable asset did not have to be every answer we could anticipate. It could be the knowledge from which those answers were produced.

Then Plan-ID broke another assumption.

We had become increasingly concerned with making authoritative facts explicit and retrievable. A query containing a precise identifier seemed like the ideal case. Identify the plan, retrieve the requested attribute, return the answer.

Instead, we encountered cases in which the identifier was correct, the sources were authoritative, and every candidate fact was true.

The answer could still be wrong.

The missing requirement was applicability.

A parent Plan ID could contain several child segments with different premiums. Geography could determine which segment applied. Retrieving all three premiums did not resolve the question, and summarizing them into a range did not make the ambiguity disappear.

That forced us to recognize that the publisher knew more than the facts.

The publisher knew the relationships among the variants. It knew that the attribute varied. It knew which contextual discriminator determined applicability.

Some of that knowledge had been living in application logic rather than in the public representation.

Resolution therefore became part of the publishing problem.

The representation experiments exposed another assumption.

Because we were trying to communicate more effectively with machines, we naturally experimented with structures designed specifically for machine consumption. Some were elegant. Some were more formally structured than ordinary HTML. From our side of the publishing boundary, several looked like representations a machine ought to prefer.

The external observations did not consistently reward that intuition.

Some experiments produced little observable use. Others worked better than expected. Canaries helped us distinguish facts available through non-prose structures from facts already stated in explanatory text. Tables repeatedly proved useful as factual and comparative surfaces. Native HTML kept doing more work than we had assigned to it.

We could not see inside the consuming systems, so those observations had limits. We did not discover a universal parser architecture or a secret answer-engine preference. We could not establish that one representation would behave the same way across every model or remain favored as external systems changed.

But we did learn enough to change our own architecture.

The public HTML document did not need to be treated as a human wrapper around the real machine representation.

It could carry substantial knowledge structure itself.

That produced Native First.

Not as an article of faith, but as a practical response to uncertainty. Model the knowledge correctly. Use the Web’s existing structures where they represent that knowledge honestly. Make additional meaning explicit where native structure leaves consequential ambiguity. Do not add another abstraction merely because one is available.

These discoveries did not arrive together.

Neither did the requirements they exposed.

Identity mattered.

But identity was not enough.

Facts needed subjects, and the Primary Subject of the Knowledge Object was not necessarily the subject of every assertion within it.

Context mattered because a value could remain numerically correct while becoming inapplicable when geography, time, configuration, network status, or another condition changed.

Relationships mattered because knowledge about one thing often depended on its connection to another without belonging inside the same semantic boundary.

Provenance mattered because an authoritative source could supply the evidence for an assertion without having made the assertion the publisher ultimately published.

Definitions mattered because values could not always be interpreted correctly without stable domain meaning.

Resolution mattered because possessing every candidate fact did not establish which one applied.

Structure mattered because a publisher could model the knowledge correctly and still expose it poorly.

None of these began as features on a KNOL requirements list.

There was no KNOL requirements list.

Each requirement appeared because something failed, became ambiguous, proved difficult to maintain, or could not be explained adequately by the publishing model we had at the time.

Eventually, the individual problems began pointing toward the same abstraction.

We were no longer merely trying to structure data for machines.

We were trying to preserve a coherent representation of what the publisher knew about something.

That representation had a subject.

It had a semantic boundary.

Within that boundary were assertions and relationships. Those assertions could have different subjects, contexts, provenance, temporal conditions, and limits on their valid application.

The representation existed conceptually before we decided whether a particular part of it belonged in a table, a definition, semantic annotation, a public resource graph, or any other technical form.

The thing we were trying to preserve had become more important than the syntax carrying it.

That was the Knowledge Object.

KNOL came afterward.

The Knowledge-Native Object Layer gave architectural form to requirements that production work had already forced us to discover. It did not create the need for semantic boundaries, provenance, context, relationships, or resolution. Those needs were already there.

KNOL gave us a way to understand why they belonged together.

That distinction matters because it changes the claim being made by this book.

We did not invent KNOL and then search for evidence that justified it.

Nor did the Medicare experiments prove that external machines require KNOL, prefer KNOL, or will reward publishers for implementing it.

The experiments established something more useful on the side of the information relationship we actually control.

We could publish what we knew more precisely than we had been publishing it before.

We could stop assuming that the question defined the publication.

We could stop assuming that the page defined the natural boundary of the knowledge.

We could distinguish a source fact from a publisher derivation.

We could preserve the context that made an assertion applicable.

We could represent when a definitive conclusion required information not yet available.

And we could use existing Web technologies to express much of that knowledge without sacrificing the human publication.

The architecture emerged because those requirements accumulated until they needed a common home.

That is why KNOL came last.

We first had to discover what needed an architecture.

Primary Sidebar

  • The Visibility Code:
  • Preface
  • Introduction
  • Chapter 1: The Answer Engine Changes the Publishing Problem
  • Chapter 2: The Question Space Is Larger Than the Knowledge Space
  • Chapter 3: From Data to Knowledge
  • Chapter 4: The Knowledge Object
  • Chapter 5: Retrieval Is Not Resolution
  • Chapter 6: Two Consumers, One Knowledge Object
  • Chapter 7: From Knowledge Object to KNOL
  • Chapter 8: HTML Is Already a Knowledge Language
  • Chapter 9: When Structure Is Not Enough
  • Chapter 10: Schema.org and the KNOL
  • Chapter 11: Provenance Is Part of the Knowledge
  • Chapter 12: Publishing the Limits of Knowledge
  • Chapter 13: Beyond the Visible Page
  • Chapter 14: Thinking Like a Knowledge Publisher
  • Chapter 15: Why Medicare Was an Effective Laboratory
  • Chapter 16: Publishing the Knowledge Beneath the Questions
  • Chapter 17: When Correct Facts Produced the Wrong Answer
  • Chapter 18: What We Learned About Representation
  • Chapter 19: What Visibility Means Now
  • Chapter 20: The Publisher’s New Asset
  • Chapter 21: Engineer the Knowledge Space
  • Chapter 22: KNOL Came After the Requirements
  • Conclusion: The Visibility Code

Copyright © 2026 · David W Bynon · Log in