• 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

Conclusion: The Visibility Code

I started this investigation trying to recover something I thought I had lost.

Visibility.

The pages still existed. Many still ranked. The information was still accurate. The domain had not suddenly forgotten thirteen years of accumulated authority.

Yet the outcomes had changed.

At first, I treated that as a search problem because search was where publishers had learned to look when visibility changed. Rankings, traffic, content, links, competitors, algorithms—somewhere in that familiar machinery there had to be an explanation.

There was.

But it was larger than search.

The relationship between the publisher, the machine, and the person had changed.

For most of the Web’s commercial history, publishers created information products and machines helped people find them. The page was the destination. The machine found. The human interpreted.

That arrangement made the document the natural object around which publishers organized their work. We wrote pages, optimized pages, linked pages, measured pages, updated pages, and accumulated increasingly large inventories of them.

When people asked new questions, we created more.

That model produced an extraordinary Web. It still produces useful publishing.

But answer engines introduced another consumer of what we publish.

The machine no longer has to stop after locating the document. It can retrieve information from it, compare that information with other sources, follow relationships, apply context, perform calculations, and synthesize an answer that the publisher never wrote.

Once that became possible, the question I had been asking about visibility was incomplete.

It was no longer enough to ask:

Can the machine find my page?

Another question followed:

What can the machine understand and use when it gets there?

That question took us beneath the document.

We found that the number of questions people could ask was vastly larger than the body of knowledge required to support many of them. We found that machine-readable data was not necessarily machine-usable knowledge. We found that facts needed identity, context, relationships, provenance, and sometimes conditions governing their valid application.

We found that a page was not necessarily the natural boundary around that knowledge.

And we found something more troubling.

A machine could retrieve the correct facts from an authoritative source and still produce the wrong answer.

Retrieval was not resolution.

Those discoveries eventually forced us to define what we had actually been trying to preserve: a coherent and bounded representation of something the publisher knows.

The Knowledge Object.

KNOL gave that object a publishing architecture.

But the most important consequence of KNOL is not the architecture itself.

It is what happens when the publisher begins thinking from the knowledge outward rather than from the page inward.

The publisher starts asking different questions.

What do we actually know?

What does this fact describe?

Where does it apply?

When does it apply?

Where did it come from?

Did the source make this assertion, or did we derive it?

What other things does it relate to?

What must be known before it can safely be applied?

And only then:

How should we publish it?

Sometimes the answer is wonderfully ordinary.

A table.

A list.

A definition.

A link.

A well-structured section.

A paragraph that explains something a table cannot.

The investigation began with the assumption that communicating with machines might require an increasingly separate machine Web. Instead, much of the work brought us back to technologies the Web already had.

The architecture became more sophisticated.

The page often became simpler.

That may be one of the more useful outcomes of the entire experiment.

Knowledge engineering does not require publishers to write more.

In our experience, it can produce the opposite result.

Once the factual foundation is maintained coherently, writers no longer have to reconstruct it every time another question becomes an article. The same fact does not need to become twenty-seven independently maintained facts because twenty-seven Medicare dental articles happen to mention it.

Some of those articles may still deserve to exist.

People need explanation.

They need expertise, judgment, instruction, analysis, comparison, and narrative.

Write those things.

But the factual reality beneath them does not need to be reinvented every time we communicate it.

That changes what the publisher is building.

The content library remains valuable.

But beneath it is another asset: the maintained Knowledge Space from which those publications draw and against which future questions can operate.

That asset behaves differently.

Correct one authoritative fact and multiple future uses can improve.

Add one meaningful relationship and new questions become possible.

Preserve provenance and the assertion carries more of its authority with it.

Represent an applicability condition and a future system has a better opportunity to recognize when it does not yet know enough to answer.

The value compounds through the knowledge rather than merely through the number of artifacts containing it.

And that finally brings me back to visibility.

Publishers still need to be discovered.

Search still matters. Distribution matters. Authority matters. Links matter. Brand matters. Human experience matters. Traffic certainly matters to businesses whose economics depend on people arriving.

Knowledge engineering replaces none of those things.

It addresses what happens after discovery.

If a machine reaches the publisher, is there something coherent enough to retrieve?

If it retrieves a fact, can it identify what that fact describes?

Can it preserve the context that gives the fact meaning?

Can it understand where the assertion came from?

Can it distinguish what the publisher knows from what the publisher merely inferred?

And when several facts are all true, can it recognize what still must be known before one of them becomes the answer?

Those are now visibility questions too.

Not because a publisher can control what an external system does with the knowledge.

It cannot.

The machine owns its retrieval system, its index, its models, its reasoning, its interface, and ultimately its decision about whether and how to use a source.

The publisher owns the other side of the relationship.

What it knows.

What it publishes.

And how faithfully one represents the other.

That is the Visibility Code.

It is not a ranking formula.

It is not a markup trick.

It is not a prediction about which answer engine will dominate or which representation tomorrow’s models will prefer.

It is a publisher-side response to a Web in which information increasingly has two consumers.

Make the publication worth finding.

Make the knowledge worth using.

Write what humans need written.

Engineer what the organization knows.

And then allow something publishers have spent decades trying to anticipate:

Let the question arrive later.

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