Why I Developed DBRS and Context World

Abstract - What can a small and midsize business (SME) do to ensure it doesn't get lost in the flood of data and overlooked in the age of AI and information??

Author: Rainer Tolksdorf

This led to the guiding principle:

So that what matters is found – and what is meant is understood.

I didn't look for any SEO methods or tricks tailored to a specific search engine. It became clear to me early on that software would help. It also became clear that software alone wasn't enough.

We need reliable technical information, clear terminology, understandable contexts, and rules for using this information.

This led to the development of the Digital Business Relevance Suite (DBRS). The name is intentionally chosen to reflect its holistic approach. It encompasses texts, software, data, concepts, scientific foundations, services, and technology.

This is a complex issue. I don't think much of trying to gloss over this complexity with simplistic promises. My approach is to describe the essentials in a coherent and understandable way, without pretending to have explained every detail.

Anyone who would like to learn more or question certain statements is invited to join the professional discussion on the many details, experiments, and experiences.

AI has been a constant companion in this development from the very beginning. That was only natural:

It's almost impossible to develop something that AI is supposed to understand better without working with AI during the development process.

This led to the early development of methods such as Collaborative AI Supported Engineering (CAISE) and, later on, DBRS and Context World.

I will discuss my role and the various roles of the AI systems involved in a separate post. That would go too far in this context.

Today, there are numerous experiments, comparisons, observations, and documents available. They are increasingly reinforcing my original conviction.

At the same time, Google, Microsoft, and Brave are publicly providing increasingly detailed descriptions of how search and AI are changing and how web information is increasingly being used as context for machines.

To me, this manufacturer documentation isn't proof of DBRS. However, it does help me understand the direction in which the information ecosystem is evolving.

I am not familiar with the complete internal evaluation procedures for these systems.

I deliberately treat it as a black box.

My approach remains:

Design the controllable input as well as possible. Then observe what different systems do with it.

The initial question pertains specifically to young and small businesses

A small business can be outstanding in its field and yet remain virtually invisible online.

Perhaps it has decades of experience.

• Special Procedures.
• People with rare expertise.
• Own methods.​
• Technical solutions you won't find in a textbook.
• Lessons learned from projects and customer issues.
• Knowledge that larger, better-known companies may not even possess.
• Within the company, much of this is taken for granted.

On the Internet, often only a small portion is visible. A search engine or AI system initially sees what is digitally accessible: web pages, documents, data, images, links, and structured information. From this portion, an external system is supposed to reconstruct:

• Who is this company?
• What can it really do?
• What sets it apart from the rest?
• What do our terms mean?
• Which statements go together?
• Which sources are authoritative?
• What is a statement based on?
• Why should we trust her?

I believe these questions will become significantly more important in the age of AI. In my view, the answer cannot be: We simply need to publish more and speak up louder.

A small business is unlikely to win the race to have the largest amount of data. But it can do something else:

To be a particularly good source of information on relevant topics.

Finding and understanding are two different tasks

The original question therefore gave rise to the following sentence:

So that what matters is found – and what is meant is understood.

The two parts of the sentence belong together. However, they describe different problems.

So You Can Find What Matters

Information of professional value must be accessible.

If it is located only on an internal drive, hidden on an inaccessible page, or has not been published at all, an external system can do very little with it.

To make sure everyone understands what is meant

Being easy to find is not enough on its own.

A system must be able to detect the following as accurately as possible:

• which company is being referred to,
• which person is being referred to,
• what a term means in this context,
• which service is being described,
• which pieces of information belong together,
• which source is authoritative.

As a result, what had started as a question of discoverability quickly became a question of significance, unambiguity, and reconstructability.

Software alone cannot solve this problem

Software can store, organize, and link information.

• It can assign IDs.
• It can generate indexes.
• It can provide data in a machine-readable format.
• It can document relationships and make changes traceable.

But software cannot conjure up substantive content that no one has previously articulated. AI can derive meaning from context. However, a company should articulate and take responsibility for what it wants to say and convey about itself. Only then will the information remain authentic.

• If a company doesn't explain anywhere what its specific expertise is, even the best data structure won't be of much help.

• If the source and responsibility for a statement are unknown, JSON does not make it any less trustworthy.

• If two services cannot be distinguished linguistically, a technical ID alone will not solve the problem of understanding.

This led to two tasks for me:

We need better technical information.

and:

We need better systems for managing this technical information.

Today, I'll mention the two companies, Context Publishing and DBRS.

• Context Publishing provides the technical content.

• DBRS supports their unique identification, association, and traceability.

• Context World combines both.

AI has become a development partner

If I want to know whether an AI understands something, it's not enough to speculate about it in theory. I have to work with it. 

Misunderstandings, in particular, are valuable in this context.

• An AI might confuse one company with another.
• She may misclassify a service.
• It can construct a plausible but incorrect alternative context based on incomplete information.
• She can see a connection that we ourselves have overlooked.
• Or, despite supposedly good information, fail because of a surprisingly simple question.

As a result, AI becomes both the subject of study and a tool. Collaborative AI-Supported Engineering (CAISE) emerged early on from this experience.

More information about CAISE

In this process, people don't simply hand a task over to a machine.

People and AI systems bring different skills and perspectives to the table. Hypotheses can be developed, critiqued, implemented, and re-evaluated collaboratively. The breadth of their interconnected knowledge and their ability to process large amounts of text quickly and identify patterns within it are particularly valuable capabilities of AI.

This collaboration has shaped DBRS and Context World from the very beginning.

My Fundamental Belief About Information

One thought remained surprisingly consistent throughout.

If a software system finds an accessible, valid, and contextually relevant data record for a task, it can use it.

The fact that a piece of information was used earlier does not make it invalid from a technical standpoint.

Whether a system retrieves them again from a website, obtains them from a search index, uses them from a cache, or receives them via another interface is of secondary importance to this concept.

The key questions are:

• Is the information available?
• Is it clear enough?
• Is it relevant to the task?

This explicitly does not mean that republishing the same content carries additional weight.

Search engines like Google have their own systems for consolidating identical or very similar content (deduplication) and selecting representative content. I'm not concerned with redundancy, but rather with a

a reliable way to find relevant information.

Relevance and display come next

Just because information is accessible doesn't mean it's necessarily relevant to a specific question.

Google itself describes a distinction between identifying relevant content and subsequently prioritizing particularly helpful content.

For me, this leads to a simple distinction:

Finding

• Can a system access the information?

Understand and evaluate

• Does the information relate to the task? Is it clear and useful from a technical standpoint?

Use or play

• What determines what the respective system actually does with this information?

The third level belongs to the system.

Google uses numerous signals and various systems. Microsoft makes decisions based on its own methods. So does Brave. AI systems may also use their own retrieval, retrieval-augmented generation (RAG), and orchestration logic.

There is no need to replicate this black box.

Control the input, monitor the output

To me, that's a practical and honest approach.

• I can't tell Google how to make its decisions.
• I can't tell Bing how to make its decisions.
• I can't tell Brave how to make its decisions.

And I can't dictate to a future AI agent which sources of information it should use.

But we can influence what we provide to these systems.

That's why I focus on the factors I can control:

• subject-specific content,
• clear terms,
• distinct identities,
• traceable origin,
• Relationships between pieces of information,
• canonical sources,
• machine-readable representations,
• Rules for Use.

After that, I monitor the output.

• Will a company be found?
• Is the right company being identified?
• Are his abilities being accurately reconstructed?
• Are similar companies distinguished from one another?
• Are connections being recognized?
• What sources are used?
• What's missing?

This makes it possible to observe the impact without having to rely on internal ranking scores or the opaque evaluation models used by tool providers.

Manufacturer documentation and personal observation are not the same thing

This distinction is important to me.

I distinguish between four levels:

Controllable Input

• What we publish and organize ourselves.

Blackbox

• What an external system does with it internally.

Observable Output

• What we actually see in specific search queries and AI tests.

Documented Self-Disclosure

• What Google, Microsoft, Brave, and other providers say publicly about their systems, goals, and features.

Manufacturer documentation helps us contextualize developments and formulate hypotheses. However, it does not prove that a specific search result was caused by DBRS. Similarly, a single observation does not automatically prove a specific internal mechanism. I make a conscious effort to keep these levels separate.

E-E-A-T ist für mich eine Vorgabe zur Struktur von Fachinformation

Für die Erstellung von Inhalten orientiere ich mich an E-E-A-T:

Experience – Expertise – Authoritativeness – Trustworthiness

Nicht als Ranking-Hoffnung oder Versuch zur Beeinflussung. Ranking-Scores interessieren mich dabei nicht.

E-E-A-T ist für mich keine Google-Erfindung im Sinne einer neuen Theorie guter Inhalte, sondern eine sinnvolle Autorenregel. Es bündelt bewährte Anforderungen an belastbare Fachinformation: Erfahrung, Fachkompetenz, Autorität und Vertrauenswürdigkeit. Vergleichbare Prinzipien gibt es seit langem in Wissenschaft, Journalismus und Informationsbewertung.

Experience – Erfahrung

• Worauf beruht eine Aussage?

Welche eigene Arbeit, Beobachtung oder praktische Erfahrung steckt dahinter?

Expertise – Fachkompetenz

• Wer besitzt das Wissen und die Fähigkeiten, diese Aussage fachlich fundiert treffen zu können?

Authoritativeness – Autorität

• Warum ist diese Person, Organisation oder Quelle für genau dieses Thema relevant?

Trustworthiness – Vertrauenswürdigkeit

• Sind Herkunft, Verantwortlichkeit und gegebenenfalls Belege nachvollziehbar?

Google empfiehlt selbst unter anderem originäre Informationen, eigene Forschung und Analyse, erkennbare Erfahrung aus erster Hand, klare Quellen und nachvollziehbare Fachkompetenz. Google stellt gleichzeitig ausdrücklich klar, dass E-E-A-T kein einzelner Rankingfaktor ist. Beides passt zu meinem Verständnis.

• Ich nutze E-E-A-T nicht, weil ich damit einen Score erzeugen möchte.
• Ich nutze es, weil dadurch bessere Fachinformationen entstehen können.

Google: Hilfreiche, vertrauenswürdige, nutzerorientierte Inhalte erstellen

E-E-A-T + P: Für Agenten reicht Vertrauen allein nicht

Für Context World kommt eine zweite Dimension hinzu. Ich bezeichne sie als:

E-E-A-T + P

• Das P steht für Policies.

Es ist nicht einfach ein weiteres Qualitätsmerkmal neben E-E-A-T.
E-E-A-T fragt im Kern:

Kann ich mich auf diese Information verlassen?

Policy stellt eine andere Frage:

Was darf ich mit dieser Information tun?

Eine Information kann vollkommen richtig und vertrauenswürdig sein und trotzdem nicht für jede Verwendung freigegeben sein.

• öffentlich sein,
• nur intern bestimmt sein,
• geschützt sein,
• zitierbar sein,
• nur unter bestimmten Bedingungen weiterverwendet werden,
• eine menschliche Freigabe erfordern,
• durch eine neuere kanonische Quelle ersetzt worden sein.

Für Menschen sind solche Regeln in Organisationen häufig teilweise implizit. Für Agentic AI halte ich das für unzureichend.

Trust sagt, ob ich mich auf eine Information verlassen kann. Policy sagt, was ich mit ihr tun darf.

Ein Agent braucht beides.

Aus einzelnen Informationen wird ein sprechendes Bedeutungsnetz

Damit kommen wir zum Kern von DBRS.

Eine Sammlung guter Dokumente ist noch keine rekonstruierbare Unternehmenswelt. Zwischen Informationen bestehen Beziehungen.

• Eine Aussage gehört zu einem Thema.
• Ein Thema gehört zu einem Unternehmen.
• Ein Fachbegriff besitzt in einem bestimmten Zusammenhang eine konkrete Bedeutung.
• Eine Person hat eine Rolle.
• Ein Dokument belegt eine Aussage.
• Eine neue Information ersetzt eine alte.
• Ein bestimmter Datensatz ist die kanonische (verbindliche, massgebliche) Quelle.

Diese Beziehungen möchte DBRS möglichst explizit machen. Der dbrs_frontmatter_index ist dabei für mich der:

zentrale Nervenstrang des Bedeutungsnetzwerks.

Er ist Navigationspfad und Datenquelle zugleich. Er verbindet Identitäten, Themen, Dokumente, Beziehungen und kanonische Quellen. Mein Ziel ist dabei mehr als ein technisches Linknetz. Ich nenne es ein:

sprechendes Bedeutungsnetz.

Die Knoten sollen nicht nur miteinander verbunden sein, sondern sollen möglichst deutlich folgendes ausdrücken:

• was sie bedeuten,
• zu wem sie gehören,
• worauf ihre Aussagen beruhen,
• welche Fachkompetenz dahintersteht,
• womit sie verbunden sind,
• welche Quelle verbindlich ist,
• welche Regeln für ihre Verwendung gelten.

Damit greifen die Bestandteile ineinander:

E-E-A-T + P unterstützt die Aussagekraft der einzelnen Informationen.

DBRS macht Identitäten und Beziehungen expliziter.

Das sprechende Bedeutungsnetz verbindet die Informationen.

Context World macht daraus eine möglichst gut rekonstruierbare Unternehmenswelt.

Strukturierte Daten sind Mittel, nicht Zweck

Strukturierte Daten sind dabei ein Werkzeug.

Google beschreibt sie als Möglichkeit, explizite Hinweise über die Bedeutung einer Seite zu geben und Informationen über Dinge wie Menschen und Organisationen besser einzuordnen.

Bei bestimmten Organisationsdaten beschreibt Google sogar Eigenschaften, die im Hintergrund zur Unterscheidung von Organisationen verwendet werden können.

Das passt zur Problemstellung von Context World.

• Es bedeutet aber nicht, dass Google DBRS "braucht".
• Und es bedeutet auch nicht, dass mehr Markup automatisch mehr Wirkung erzeugt.

Struktur ist für mich dann sinnvoll, wenn sie Bedeutung klarer, Identität eindeutiger oder Beziehungen besser rekonstruierbar macht.

Google: Einführung in strukturierte Daten

Google: Strukturierte Daten für Organisationen

Was Google ausdrücklich nicht braucht

Gerade weil ich keine geheimen Mechanismen behaupten möchte, gehört auch diese Seite der Google-Dokumentation dazu.

Google sagt für seine generative Suche ausdrücklich:

• Es ist kein spezielles AI-Markup erforderlich.
• llms.txt wird von Google Search nicht für Sichtbarkeit oder Ranking verwendet.
• Inhalte müssen nicht künstlich in winzige Abschnitte zerlegt werden.
• Texte müssen nicht für jede denkbare Synonym- oder Longtail-Variante umgeschrieben werden.
• Strukturierte Daten sind keine Voraussetzung für die generative Suche.

Google sagt zugleich ausdrücklich, dass es völlig in Ordnung ist, Dateien wie llms.txt für andere Dienste und Systeme bereitzustellen, die sie verwenden. Auch DBRS unterstützt diese Seite. 

Mehr erfahren über llms.txt

Das halte ich für eine wichtige Abgrenzung.

DBRS wurde nicht entwickelt, weil Google DBRS braucht.

DBRS wurde entwickelt, weil Unternehmen eine möglichst verlässliche und systemübergreifend rekonstruierbare Informationswelt brauchen.

Google und Microsoft sind mögliche Konsumenten, aber nicht die einzigen.

Google: Website für generative KI-Funktionen optimieren

Wohin sich das Informationsökosystem entwickelt

Ich sehe die öffentlichen Dokumentationen von Google, Microsoft und Brave nicht als Bestätigung von DBRS.

Sie zeigen mir etwas anderes:

Webinformationen werden zunehmend nicht nur für Menschen gesucht und angezeigt. Sie werden als Kontext für Maschinen verwendet.

Das ist die für mich interessante Entwicklung.

Google: Suche liefert Kontext für generative Antworten

Google beschreibt für seine generativen Suchfunktionen inzwischen ausdrücklich Retrieval-Augmented Generation – RAG.

Dabei werden relevante und aktuelle Webseiten aus dem Suchindex abgerufen. Anschliessend werden konkrete Informationen auf diesen Seiten zur Fundierung einer Antwort verwendet.

Google beschreibt zusätzlich eine parallele Anfrageverarbeitung.

Aus einer ursprünglichen Frage können mehrere zusammenhängende Suchanfragen entstehen, um zusätzliche relevante Informationen zu finden.

Für mich ist daran weniger die interne Google-Technik interessant als die Konsequenz:

Eine komplexe Frage kann dazu führen, dass sehr spezielle Informationen aus unterschiedlichen Quellen benötigt werden.

Genau darin liegt eine Chance für Nischenanbieter. Denn grosse und bekannte Websites sind nicht automatisch für jede Teilfrage die beste Quelle. Je spezieller die benötigte Information wird, desto grösser kann der Vorteil eines Nischenanbieters sein, der genau dazu eigenes Wissen, Erfahrung oder Daten veröffentlicht hat.

Google: Website für generative KI-Funktionen optimieren

Microsoft: Sichtbarkeit besteht zunehmend auch aus Zitationen

Microsoft zeigt seit Februar 2026 in Bing Webmaster Tools, wenn Inhalte einer Website in Microsoft Copilot, KI-generierten Bing-Antworten und ausgewählten Partnerintegrationen als Quelle zitiert werden.

Microsoft stellt ausdrücklich klar, dass diese Messwerte kein Ranking, keine Autorität und keine Rolle einer Seite innerhalb einer konkreten Antwort ausdrücken.

Das ist eine wichtige Einschränkung.

Gleichzeitig empfiehlt Microsoft unter anderem:

• Inhalte klar zu strukturieren,
• Aussagen mit Belegen zu unterstützen,
• Inhalte aktuell zu halten,
• Mehrdeutigkeit über unterschiedliche Formate hinweg zu reduzieren,
• Text, Bilder und Videos so aufeinander abzustimmen, dass sie dieselben Entitäten, Produkte und Konzepte konsistent darstellen.

Das ist keine DBRS-Bestätigung.

Es zeigt aber sehr deutlich eine Problemrichtung, die auch Context World beschäftigt:

Wenn Maschinen Informationen als Quellen verwenden sollen, werden Klarheit, Eindeutigkeit und konsistente Bedeutung wichtiger.

Bereits 2018 beschrieb Microsoft strukturierte Daten als einen Hinweis, den Bing beim Verständnis von Seiten verwendet, und hob bei JavaScript Object Notation for Linked Data (JSON-LD) ausdrücklich die Möglichkeit hervor, Beziehungen zwischen Daten und Entitäten zu definieren.

Microsoft Bing: AI Performance in Bing Webmaster Tools

Microsoft Bing: JSON-LD Support

Brave: Websuche wird direkt zum Kontext für andere KI-Systeme

Brave zeigt dieselbe Entwicklung aus einer anderen Perspektive.

Die Brave Search Application Programming Interface (API) wird ausdrücklich für Agenten, Chatbots und RAG-Anwendungen angeboten. Neben normaler Websuche bietet Brave einen eigenen LLM Context an. Dazu kommen zusätzliche Snippets, Metadaten und teilweise schema-angereicherte Resultate.

Auch daraus leite ich nicht ab, dass Brave DBRS benötigt oder DBRS-Strukturen in einer bestimmten Weise interpretiert. Brave zeigt aber sehr anschaulich:

Eine Suchmaschine kann selbst zum Kontextlieferanten für andere Maschinen werden.

Damit verändert sich die Rolle des Webs.

Eine Website wird nicht mehr nur von Menschen besucht oder in einer Ergebnisliste angezeigt. Ihre Informationen können Teil eines maschinell zusammengestellten Kontexts für einen anderen Agenten oder ein anderes KI-System werden.

Brave Search API

Die Hersteller beschreiben die Bewegung – nicht den Beweis

Diese Unterscheidung möchte ich ausdrücklich festhalten.

Weder Google, noch Microsoft oder Brave bestätigen DBRS. Ihre Dokumentationen zeigen aber, dass sich das Informationsökosystem in eine Richtung bewegt, in der:

• Maschinen Inhalte abrufen,
• unterschiedliche Quellen kombiniert werden,
• Informationen zitiert werden,
• Entitäten unterschieden werden,
• Kontext für andere KI-Systeme bereitgestellt wird,
• autonome Agenten mit Websites interagieren.

Das ist das Umfeld, für das Context World gedacht ist.

Ob und wie gut ein bestimmtes System ein DBRS-Bedeutungsnetz tatsächlich interpretiert, untersuchen wir experimentell.

Context Publishing liefert das, was nicht austauschbar ist

Die technische Struktur allein ist wertlos, wenn die Inhalte austauschbar sind.

Die eigentliche Chance kleiner Fachunternehmen liegt für mich deshalb in ihrem eigenen Wissen. Google formuliert diesen Gedanken in seinem aktuellen Leitfaden für generative Suche ungewöhnlich deutlich. Einzigartige, ansprechende und nützliche Inhalte werden dort als langfristig wahrscheinlich besonders wichtig für die Präsenz in generativer Suche beschrieben.Google empfiehlt ausdrücklich:

• eigene Perspektiven,
• eigene Erfahrungen,
• eigenes Fachwissen,

statt nur das zu wiederholen, was ohnehin bereits im Internet steht oder problemlos von einer generativen KI erzeugt werden könnte. Das halte ich für eine wichtige Botschaft an kleine Unternehmen. Sie müssen nicht mehr allgemeines Wissen publizieren als grosse Plattformen.

Sie sollten das sichtbar machen, was sie tatsächlich wissen und andere nicht ohne Weiteres wissen können.

Google: Website für generative KI-Funktionen optimieren

Eine kleine Website kann eine grosse Fachquelle sein

Damit kehre ich zur Ausgangsfrage zurück.

Eine kleine Website muss nicht für jeden Begriff die stärkste Website des Internets sein. Sie kann für eine sehr spezielle Frage eine besonders wertvolle Quelle sein. Generative Suche macht diese Möglichkeit aus meiner Sicht noch interessanter.

Wenn eine komplexe Frage in mehrere Teilfragen zerlegt wird und unterschiedliche Quellen zur Fundierung einer Antwort verwendet werden, kann ein hoch spezialisiertes Unternehmen gerade dort relevant werden, wo sein besonderes Wissen gebraucht wird.

Deshalb lautet eine meiner zentralen Überzeugungen:

Eine Nischenwebsite muss nicht die stärkste Domain sein. Sie muss für einen relevanten Teil des Bedeutungsraums eine besonders gute rekonstruierbare Quelle sein.

Wenn Wissen verwendet wird, ohne dass die Quelle genannt wird

Mit der Sichtbarkeit von Fachwissen entsteht eine berechtigte Sorge:

Was geschieht, wenn eine KI mein Wissen verwendet, aber mich oder mein Unternehmen nicht als Quelle nennt?

Diese Möglichkeit besteht.

Generative Systeme können Informationen aufnehmen, zusammenfassen und mit anderen Informationen verbinden. Dabei ist für den Nutzer nicht immer sichtbar, woher jede einzelne Aussage stammt.

Context World kann eine Namensnennung nicht erzwingen. DBRS kann einem fremden System ebenfalls nicht vorschreiben, welche Quelle es nennt.

Die Alternativen sind aber ebenfalls keine Lösung.

• Wissen gar nicht zu veröffentlichen schützt zwar vor öffentlicher Verwendung, macht es zugleich aber auch für Suchmaschinen, KI-Systeme und potenzielle Kunden unsichtbar.
• Wissen absichtlich unklar oder schwer verständlich zu publizieren, erhöht dagegen das Risiko, falsch eingeordnet oder gar nicht berücksichtigt zu werden.

Für mich liegt die vernünftige Antwort deshalb zwischen Offenlegung und Schutz:

Nicht alles veröffentlichen. Aber das, was veröffentlicht wird, so eindeutig wie möglich veröffentlichen.

Dazu sollte möglichst klar erkennbar sein:

• wer die Information veröffentlicht hat,
• wer fachlich dafür steht,
• zu welchem Unternehmen sie gehört,
• wo die kanonische Quelle liegt,
• wann sie veröffentlicht oder aktualisiert wurde,
• unter welchen Regeln sie verwendet werden darf.

Genau deshalb sind eindeutige Identitäten, nachvollziehbare Autorenschaft, kanonische Quellen und Policies wichtig. Sie garantieren zwar auch keine Zitation, schaffen aber bessere Voraussetzungen dafür, dass Herkunft und Verantwortung rekonstruierbar bleiben.

Dabei muss jedes Unternehmen selbst entscheiden, welche Informationen öffentlich sein sollen, welche nur intern verwendet werden dürfen und welche geschützt bleiben müssen.

Hier wird das P in E-E-A-T + P praktisch:

Die Frage lautet nicht nur, ob eine Information gut und vertrauenswürdig ist. Ebenso wichtig ist, ob und unter welchen Bedingungen sie verwendet werden darf.

Context Publishing bedeutet deshalb nicht, alles preiszugeben.

Es bedeutet, bewusst das zu publizieren, was ein Unternehmen öffentlich als Teil seiner Fachkompetenz sichtbar machen möchte – und dieses Wissen dann klar, authentisch und mit nachvollziehbarer Herkunft zu veröffentlichen.

Auffindbarkeit lässt sich verbessern. Herkunft lässt sich deutlich machen. Zitation lässt sich begünstigen. Erzwingen lässt sie sich nicht.

Was wir inzwischen beobachten

DBRS und Context World sind inzwischen nicht mehr nur Gedankenmodelle.

Wir führen reale Versuche mit den Suchmaschinen von Google, Bing, Brave durch. Zusätzlich mit unterschiedlichen Sprachmodellen von Google, Copilot, Claude und Perplexity. Betrachtet wurden

• diese Website
• Mit Kunden- und Wettbewerbswebsites.

Dabei prüfen wir nicht nur, ob eine URL irgendwo erscheint. Wir untersuchen beispielsweise:

• Wird ein Unternehmen eindeutig erkannt?
• Werden seine Fähigkeiten richtig rekonstruiert?
• Werden Prozesse verstanden?
• Wird der Zweck eines Angebots erkannt?
• Können ähnliche Unternehmen unterschieden werden?
• Welche Zusammenhänge konstruiert ein System?
• Welche Quellen verwendet es?
• Welche Informationen bleiben unsichtbar?
• Was verändert sich, wenn Informationen klarer und eindeutiger publiziert werden?

Daraus sind inzwischen zahlreiche Testreihen, Vergleichsdokumente und Protokolle entstanden.

• Die Systeme verhalten sich unterschiedlich.
• Manche erkennen eine Beziehung, an der ein anderes System scheitert.
• Manche können eine Entität eindeutig zuordnen.
• Andere bleiben an einer allgemeineren Ebene hängen.
• Gerade diese Unterschiede sind interessant.

Und gerade deshalb sollte Context World aus meiner Sicht nicht für eine einzige Suchmaschine gebaut werden. Ausgewählte Versuchsreihen und Fallbeispiele werde ich separat dokumentieren.

Beobachtung ist kein Kausalitätsbeweis

Diese Grenze ist mir wichtig.

Wir beobachten bei Tolksdorf.digital Wirkungen, wie sie zu unseren Hypothesen passen. Zum Beispiel, dass eine kleine Fachwebsite bei spezifischen Themen bemerkenswert sichtbar werden kann. Wir beobachten auch, dass Systeme strukturierte Identitäten und Beziehungen unterschiedlich verarbeiten. Und wir beobachten, dass einzigartige Fachinformationen bei passenden Fragen gefunden und verwendet werden können.

Daraus folgt aber nicht automatisch:

Dieses einzelne Suchergebnis wurde durch DBRS verursacht.

Die Wirkung kann aus vielen Bestandteilen entstehen:

• eigenständigem Fachinhalt,
• Spezialisierung,
• E-E-A-T, bzw. E-E-A-T+P
• guter interner Verlinkung,
• eindeutigen Entitäten,
• strukturierten Daten,
• DBRS,
• Aktualität,
• Suchintention,
• weiteren bekannten oder unbekannten Faktoren.

In dem Komplex Internet, Suchmaschinen und KI kann man den Anteil jedes einzelnen Bestandteils nicht isoliert angeben - die Blackbox darf Blackbox bleiben.

Wir gestalten den kontrollierbaren Input möglichst gut und prüfen empirisch den Output.

Was ich ausdrücklich nicht verspreche

DBRS garantiert kein Ranking, genauso wenig wie SEO- oder GEO-Optimierungen.

Context World garantiert keine Sichtbarkeit.

E-E-A-T ist für mich kein Punktesystem.

Strukturierte Daten machen schlechte Inhalte nicht wertvoll.

llms.txt ist kein geheimer Zugang zu Google.

Ein dbrs_frontmatter_index macht ein Unternehmen nicht automatisch zur Fachautorität.

Google, Microsoft und Brave bestätigen DBRS nicht dadurch, dass ihre Dokumentationen einzelne ähnliche Problemstellungen behandeln.

Und ich behaupte nicht, die vollständigen internen Verfahren dieser Systeme zu kennen.

Meine Überzeugung ist einfacher:

Wenn ein Unternehmen eigenständige und fachlich wertvolle Informationen publiziert, ihre Herkunft nachvollziehbar macht und ihre Identitäten, Beziehungen und Regeln möglichst eindeutig beschreibt, schafft es bessere Voraussetzungen dafür, dass Menschen und Maschinen seine Unternehmenswelt rekonstruieren können.

Was ein konkretes System daraus macht, entscheidet dieses System.

Wir können beobachten, was geschieht.

Warum ich DBRS und Context World weiterentwickle

Damit komme ich zurück zur ersten Frage:

Was kann ein kleines Unternehmen tun, damit es im KI- und Informationszeitalter nicht in der Datenflut verschwindet und übersehen wird?

Meine Antwort heute in drei Punkten:

1. Eigene Fachwelt sichtbar machen.

Nicht überall gross sein wollen, sondern dort stark sein, wo eigenes Wissen, Erfahrung und Können zählen.

2. Bedeutung und Herkunft eindeutig machen.

Gute Fachinformationen brauchen klare Begriffe, nachvollziehbare Quellen, Beziehungen und Regeln für ihre Verwendung.

3. Für Menschen und Maschinen rekonstruierbar publizieren.

Context Publishing schafft die Inhalte, DBRS verbindet sie zu einem sprechenden Bedeutungsnetz und Context World macht daraus eine verständliche Unternehmenswelt.

Darum entwickle ich DBRS und Context World.

So that what matters is found – and what is meant is understood.

Additional Resources

Executive Summary - Trusted Context World Publishing

https://tolksdorf.digital/executive-summary-trusted-context-world-publishing

Implementation of Digital Business Relevance Suite (DBRS) LLM Knowledge Hub

https://tolksdorf.digital/dbrs-llm-knowledge-hub

Google Search Central - Creating Helpful, Trustworthy, User-Centric Content

E-E-A-T: personal experience, originality, expertise, and trustworthiness.

Read documentation about Google Search Central

Google Search Central - Optimize a Website for Generative AI Features

Unique technical content, RAG, parallel query processing, and clear guidance on which so-called AI SEO measures Google does not need.

Open documentation about optimizing Websites for generative AI-Functions

Google Search Central - Ranking-Systems of Google Search

Page-level and site-wide signals, semantic systems, original content, and deduplication.

Read documentation about Ranking-Systems of Google Search

Google Search Central – Introduction to Structured Data

For explicit information about the meaning of pages and the entities described.

Read documentation about Introduction to Structured Data

Google Search Central – On Structured Information About Organizations and Their Identification.

Read documentation on Organization of Structured Data

Microsoft Bing Webmaster - AI Performance

On citing website content in Copilot and AI responses, as well as on clarity, evidence, and reducing ambiguity.

Read documentation on Bing Webmaster – AI Performance öffnen

Microsoft Bing Webmaster - JSON-LD Support

On structured data and relationships between data and entities.

Read documentation onMicrosoft Bing Webmaster

Brave Search API

Web search and curated context for agents, chatbots, and RAG applications.

Read documentation about Brave Search API