Visibility. Traffic. Revenue.
One day I had it. The next day I didn’t.
This book does not tell that story. It documents what I learned because of it.
My investigation began with a simple question:
What happened?
Where did the visibility, traffic, and revenue stream I had built over thirteen years go—and why?
At first, nothing appeared broken. The pages still ranked. The content was still accurate. The domain was still trusted. By the traditional signals I had learned to watch, the system should have been working.
And yet the outcomes no longer followed.
Traffic patterns diverged from rankings. Questions that once sent people looking for pages increasingly produced answers before those pages were ever visited. Something had changed between the publisher and the person seeking information.
I did not set out to study artificial intelligence, and I certainly did not set out to develop a theory of knowledge engineering. I was a publisher trying to understand a failure that did not behave like a failure.
There was no single update to blame, no obvious penalty to recover from, and no familiar lever to pull. So I stopped looking for fixes and started looking for explanations.
That shift changed the direction of the work.
For most of the Web’s history, the division of labor between machines and humans was relatively straightforward. The machine found information. The human interpreted it.
Search returned documents. People read them, reconciled ambiguity, understood context, compared facts, and decided what applied to them.
Generative answer engines began moving some of that work upstream. Machines increasingly participated in interpreting published information before the human ever encountered the source.
That raised a question I had never needed to ask as a web publisher:
If the machine is going to interpret what I publish, what do I need to tell the machine?
The Web already had a mature language for communicating with people. We had documents, headings, tables, lists, links, images, navigation, typography, and prose. Structured data provided additional ways to make particular entities and facts explicit.
But the information we needed to communicate was often richer than an isolated fact.
We needed to preserve what a collection of facts described. We needed geography and time. We needed relationships between entities. We needed provenance. We needed terminology to retain consistent meaning.
Eventually, we encountered a more difficult problem.
Several facts could all be true while the available information remained insufficient to determine which one applied.
That was not simply a markup problem.
It was a meaning problem.
We began experimenting with ways to make more of that meaning explicit. Early work produced what we called a Semantic Data Template, an attempt to organize machine-facing information according to what it meant rather than merely how it appeared on a page. As the structures became more sophisticated, different semantic functions separated into fragments. Those fragments became modular, eventually producing an architecture we called WebMEM®.
At the time, I was not trying to define a new publishing discipline.
I was trying to communicate more clearly to a second consumer.
The first was human.
The second was machine.
Production changed the questions again.
One coherent body of published knowledge began participating in questions for which we had never written corresponding answers. The number of questions people could ask appeared vastly larger than the body of underlying knowledge required to support them.
That exposed another assumption inherited from traditional web publishing.
The page was not necessarily the natural boundary of knowledge.
Neither was the paragraph, keyword, database row, or individual answer.
The production work repeatedly required facts to remain connected to the identity, context, relationships, provenance, and temporal conditions necessary to preserve their meaning when retrieved and reused.
Then the Plan-ID work exposed something more consequential.
An answer engine could retrieve the correct information and still produce the wrong answer. The source could be authoritative. Every retrieved fact could be true.
The unresolved question was which true fact applied.
Retrieval was not resolution.
If a publisher knows that a fact applies only within a particular geography, time period, configuration, jurisdiction, population, or product variant, that condition is part of what the publisher knows.
If additional information is required before one of several valid facts can safely be selected, that requirement is also knowledge.
Leaving those conditions implicit asks the consuming machine to infer something the publisher already knows.
By then, the original question had changed considerably.
It was no longer simply:
How do we optimize content for AI?
It became:
What does the machine need to know?
And ultimately:
How should a publisher represent what it knows so that humans and machines can use the same authoritative knowledge?
Following that question downward brought the work into territory where publishing, information architecture, data architecture, semantics, provenance, and machine reasoning intersect.
I needed a name for the publisher-side problem we were encountering.
The most accurate one I could find was Knowledge Engineering for Answer Engines.
The phrase is not a claim to the invention of knowledge engineering, nor does this book attempt to redefine the established discipline that carries that name. It describes the practical problem that emerged from the publishing work:
How should authoritative facts, concepts, relationships, context, provenance, and resolution requirements be organized and published so that external machines can use them without sacrificing the human experience of the Web?
The investigation eventually led toward a different way of thinking about the unit of publication itself.
A document is constructed to communicate.
An answer is constructed to satisfy a question.
But the underlying knowledge can exist independently of either.
It can exist before the question is asked. It can support questions the publisher never anticipated. It can be represented differently for different consumers while remaining grounded in the same authoritative reality.
That realization eventually led us to the knowledge object and, later, to the architecture this book calls KNOL, the Knowledge-Native Object Layer.
KNOL is not where this book begins.
It is where the investigation leads.
This book follows that path because the path matters. The architecture makes more sense when its requirements are understood as solutions to problems encountered in production rather than features selected in advance.
Throughout that journey, the claim remains deliberately publisher-side. We cannot see inside proprietary retrieval systems, ranking systems, or generative models. We cannot dictate how an external machine will use what we publish.
What publishers control is the knowledge they make available and how faithfully they represent it.
That leads to the proposition underlying everything that follows:
A machine should not be forced to infer what an authoritative publisher already knows and can explicitly publish.
I started this investigation because I wanted to understand what had happened to visibility.
I ended up asking what it means to publish knowledge on a Web with two consumers.
That is why we are here.