Knowledge Boundary Manifest (KBM)
Draft Specification — Version 0.1
Part of the Open Specifications family, alongside the Governance Layer Manifest (GLM).
A declarative specification for the semantic boundaries of knowledge intentionally published by an organization, independent of who reads it.
The gap
Websites publish documents. They publish structured data. They publish metadata. They publish sitemaps.
What they do not publish is the boundary of their own knowledge: where one declared concept ends and an adjacent one begins, which terms are commonly and incorrectly treated as equivalent, and what the site explicitly does not claim to be or provide.
This is not a problem specific to any single reading system. It applies to a search engine today, to a different one in five years, to a human researcher, to an archive consulted a decade from now. Sitemaps solved discoverability of URLs. Structured data solved discoverability of entities. Nothing so far solves discoverability of a site’s own semantic boundaries.
The Knowledge Boundary
Existing disciplines describe adjacent problems, but not this one.
- Information Architecture organizes how content is structured and navigated within a site.
- Knowledge Graphs represent entities and their relationships.
- Taxonomies organize concepts into hierarchies.
- Ontologies formalize the relationships and properties of a domain.
None of them declare where a concept’s boundary sits relative to a neighboring one, or which confusions between them are foreseeable and already resolved. A Knowledge Boundary is that declaration: the explicit statement of where one concept’s declared meaning ends and another’s begins, independent of how the concepts are otherwise organized, graphed, ranked or classified.
A Knowledge Boundary should distinguish not only different concepts, but also different responsibilities published under related domains, subdomains or services, when those distinctions are semantically relevant. A parent site and a subdomain it links to, or two services under related infrastructure, are not automatically the same declared knowledge just because they share an owner or a namespace. If a reader could reasonably treat them as one thing without being wrong in an obvious way, the boundary between them needs declaring like any other.
The Knowledge Boundary Manifest is the format that lets an organization declare its own Knowledge Boundaries, in the same way the Governance Layer Manifest is the format that lets an organization declare the boundaries of a governance architecture.
The principle
Canonical meaning should be declared, not inferred.
A reading system that has to infer where one concept ends and another begins will sometimes infer correctly and sometimes will not. A declared boundary removes the guess.
Boundary validation
A Knowledge Boundary is adequately declared only if an independent reader can distinguish adjacent concepts without reconstructing publisher intent.
This is the test a KBM declaration must pass. If removing a declared boundary would let two independently existing concepts be treated as interchangeable, the boundary has not been declared precisely enough. This is not the same test GLM applies to a governance layer; it is the equivalent test for a different kind of boundary, published under the same design philosophy.
Scope
The KBM is a declarative specification for the semantic boundaries of knowledge intentionally published by an organization.
- It does not evaluate truth.
- It does not validate accuracy.
- It does not replace ontologies.
- It does not prescribe interpretation.
- It declares only what the publisher states as canonical.
Publisher authority
A KBM is authoritative only for the knowledge intentionally published by its declaring organization. It cannot be issued on behalf of a third party’s knowledge, and it does not confer authority over concepts the declaring organization did not itself publish.
See also: Known Limitations.
What the KBM is not
The KBM was not created for large language models. It was created to solve a knowledge-publishing problem that predates them and will outlast the current generation of AI systems. Search engines, AI systems, archives, researchers and other software are consumers of the declaration, not its reason for existing, in the same way GLM was not created because systems fail to interoperate, but because a certain kind of boundary information had no standard way to be declared.
The KBM does not grant special ranking treatment inside any search engine’s generative AI features. Google’s own optimization guidance, published in May 2026, states that its AI features are rooted in the same ranking and quality systems as classic Search, and that machine-readable files created specifically for AI systems, including files in the llms.txt style, receive no special treatment. What changes what gets cited is clear, indexed, on-page content. The KBM does not replace that. It is a second, structured surface for the same declarations, for the software capable of consuming it.
The KBM is not an extension of SKOS, of JSON Schema, or of Schema.org. It uses conventions from existing standards where they already solve part of the problem, in the same way GLM uses JSON Schema without becoming a JSON Schema Manifest.
What is genuinely new
Schema.org does not declare non-claims. SKOS does not declare boundaries between what a site provides and does not provide. llms.txt does not declare common confusions. robots.txt does not declare which terms are not equivalent to which. The following elements of the KBM are not covered by any existing published standard:
non_claims— what the site explicitly does not claim to be or provideboundary— what the site provides versus what it does notscope— what a specific concept includes and explicitly excludes, declared at the level of the concept itself, not only at the level of the whole siteadjacent_concepts— neighboring concepts named individually, each with the specific difference that separates them, not a bare list of confusable termscommon_confusions— explicit incorrect/correct pairs, stated by the site itselfforbidden_equivalences— pairs of concepts declared as never interchangeable, stated as a rule rather than a correction
These elements are intended to complement existing metadata standards, not replace them.
Design philosophy
The KBM follows the shared Open Specifications design philosophy. It does not restate it here.
Schema (draft)
The Knowledge Boundary Manifest (KBM) example for certifywebcontent.com can be viewed here:
KBM example for certifywebcontent.com.
For analisiforense.eu, an Italian-language KBM example is available here:
KBM example for analisiforense.eu.
The meta fields below are shared conventions across the Open Specifications family: a schema version separate from the instance version, an explicit validity window, and a structured digest object rather than a flat string.
{
"schema_version": "0.1",
"manifest_version": "<instance-version>",
"valid_from": "YYYY-MM-DD",
"valid_until": null,
"supersedes": null,
"boundary_test": "A Knowledge Boundary is adequately declared only if an independent reader can distinguish adjacent concepts without reconstructing publisher intent.",
"site": "https://example.com",
"primary_entity": {
"type": "Organization",
"name": "Organization Name"
},
"canonical_topics": [
"Topic A",
"Topic B"
],
"non_claims": [
"Thing this site is not",
"Thing this site does not provide"
],
"boundary": {
"this_site_provides": [
"..."
],
"this_site_does_not_provide": [
"..."
]
},
"concepts": [
{
"id": "concept-id",
"pref_label": "Canonical Concept Name",
"canonical_page": "https://example.com/page/",
"aliases": [
"Alternate term"
],
"confidence": "established",
"scope": {
"in_scope": [
"What this specific concept covers"
],
"out_of_scope": [
"What this specific concept explicitly excludes"
]
},
"adjacent_concepts": [
{
"id": "other-concept-id",
"difference": "One-sentence explanation of what separates the two concepts"
}
]
}
],
"common_confusions": [
{
"incorrect": "Term A treated as equivalent to Term B",
"correct": "Term A is a different concept from Term B, see: "
}
],
"forbidden_equivalences": [
{
"left": "Concept A",
"right": "Concept B"
}
],
"relationships": [
{
"from": "concept-id-a",
"relation": "different_from",
"to": "concept-id-b"
},
{
"from": "concept-id-a",
"relation": "requires",
"to": "concept-id-c"
}
],
"preferred_documents": [
{
"title": "Document Title",
"url": "https://example.com/doc/",
"priority": "primary"
}
],
"deprecated_documents": [
{
"title": "Old Document Title",
"url": "https://example.com/old-doc/",
"replaced_by": "https://example.com/doc/"
}
],
"manifest_digest": {
"algorithm": "SHA-256",
"value": "<computed-at-publish-time>"
}
}
Where it lives
Following the existing convention used by robots.txt and by unofficial files such as llms.txt, the manifest is expected at a well-known location, for example /.well-known/knowledge-boundary-manifest.json. This does not grant it special treatment by any search engine. It grants it a predictable, discoverable location for any system, human, or software that chooses to look for it.
Origin case
During development, a real-world case revealed that two adjacent services with clearly different purposes could still be interpreted as a single concept by an automated reading system:
- Certificazione Chat WhatsApp da Remoto, a service for certifying a WhatsApp conversation that already exists
- Messaggi Legali, an application for composing and sending a new legal message, with certification integrated into the process
Both pages already stated their own scope in prose. The case demonstrated that semantic boundaries expressed only through prose may still be reconstructed differently by automated readers. The KBM formalizes that same declaration into a structure a reading system does not have to reconstruct at all:
{
"id": "certificazione-whatsapp-remoto",
"pref_label": "Certificazione Chat WhatsApp da Remoto",
"canonical_page": "https://analisiforense.eu/servizi/certificazione-chat-whatsapp-da-remoto/",
"scope": {
"in_scope": [
"Forensic certification of a WhatsApp conversation that already exists"
],
"out_of_scope": [
"Composing a new message",
"Sending a new legal notice or formal request"
]
},
"adjacent_concepts": [
{
"id": "messaggi-legali",
"difference": "Messaggi Legali handles composing and sending a new message, before certification. This service certifies a conversation that has already taken place, after the fact."
}
]
}
A second example: programmatic advertising
The same ambiguity that misleads a search engine’s AI-generated answer can also mislead an automated bidding system. If a semantic system treats two concepts as similar enough to bid on the same audience, an advertiser’s budget gets spent on traffic that has nothing to do with what the business actually offers. A declared non_claims and forbidden_equivalences block gives a bidding engine the same signal it gives a reading system: what this brand is not, and which concepts should never be treated as equivalent to it, regardless of how statistically similar they may appear.
This is not a claim that KBM improves bid performance, in the same way it does not claim to improve search ranking. It is the same declaration, read by a different kind of consumer.
Relationship to the Governance Layer Manifest
The Governance Layer Manifest states that interoperability should emerge from independently readable boundary declarations, not from negotiated integration claims. The Knowledge Boundary Manifest applies the same principle to a different layer. GLM declares the boundaries of a governance architecture: what it does, what it does not do, and where it ends before another system’s claims begin. KBM declares the boundaries of a site’s published knowledge: what is canonical, what is not claimed, and where one concept ends before another begins.
Neither manifest asks a reading system to trust an inference. Both ask it to read a declaration.
Same term, different question
Where the same term appears in a GLM instance and a KBM instance published by the same organization, a layer type such as “formation,” for example, the two declarations are not in tension by construction. GLM states what that layer operationally does and does not do. KBM states what the term canonically means and what it is not equivalent to. These are different questions about the same term, not two competing answers to the same question, so no precedence between the two specifications is required.
This holds only as long as each declaration stays within its own declared scope. If a KBM instance ever states something about execution, or a GLM instance ever states something about canonical meaning, that instance is misusing the specification, not exposing a gap in how the two are designed to coexist.