From content production to knowledge architecture

A content archive quickly becomes unusable without relationships

Companies should organize content not just as a sequence of individual publications, but as knowledge architecture.

A knowledge architecture connects technical terms, relevant questions, core statements, sources, pages, relationships, and maintenance responsibility. This makes knowledge findable, consistent, updatable, and reusable for different applications.

Starting situation in August 2023

Many companies had built up content over the years:

• Performance pages,
• Blog posts,
• Whitepaper,
• Presentations,
• Instructions,
• FAQ,
• Studies,
• Newsletter,
• internal documentation,
• Sales documents.

Each document could be factually correct on its own. Nevertheless, friction arose in the entirety.

A term was explained differently on several pages. A new service page contradicted an older brochure. A helpful specialist article was only findable via internal search. Sources were in an employee's personal file system. There was no clear owner for updates.

The widespread answer to this was additional production. A contribution, a format, or a campaign was allegedly still missing.

In fact, information was often not missing. What was missing was the architecture that made the existing information usable as coherent knowledge.

What a knowledge architecture achieves

It creates unambiguous terms

Companies use technical terms, product names, service designations, and internal abbreviations. Without conceptual order, variants arise that seem self-evident to employees but create different meanings externally.

Knowledge architecture documents:

• preferred designation,
• Definition,
• Synonyms and alternative spellings,
• superordinate and subordinate terms,
• related topics,
• impermissible or outdated terms,
• responsible department.

W3C standards like SKOS have shown for years how concepts, designations, and relationships can be modeled in knowledge organization systems. Companies do not necessarily need a semantic web project for this. However, the basic idea remains valuable: a term receives an identity and enters into understandable relationships.

It connects questions and statements

A topic tree alone is not enough. Users come with specific questions.

A robust architecture therefore not only assigns content to a topic but also connects:

• Question,
• Target audience,
• Situation,
• technical core message,
• Proof,
• in-depth content,
• next step.

This allows the same knowledge to be activated in different contexts without having to be reinvented each time.

It makes sources a component of the system

Sources are often added only at the end of a text. In a knowledge architecture, they are part of the statement.

For a central claim, it should be recognizable:

• what it is based on,
• how current the foundation is,
• which restriction applies,
• who is responsible for the transfer to the corporate context,
• in which content the statement is used.

If a source is changed or becomes invalid, it can be traced which content is affected.

It clarifies relationships between contents

Internal linking should not be treated as a subsequent SEO measure. It reflects subject matter relationships.

Possible relationships are:

• Foundation and deepening,
• Problem and solution,
• Definition and application,
• Thesis and counter-position,
• general principle and industry situation,
• Source and derived statement,
• current contribution and permanent reference.

These relationships help people understand and make the thematic connection clearer for search and processing systems.

It anchors responsibility and care

Every central knowledge area needs a subject matter owner. This person does not have to write or technically maintain all content themselves. However, they are responsible for validity and subject matter approval.

Additionally, the architecture requires:

• editorial responsibility,
• technical responsibility,
• Audit interval,
• Change log,
• Rules for merging and removal.

Without this layer, the knowledge architecture becomes a one-time cleanup operation.

Knowledge architecture is more than website navigation

The information architecture of a website organizes pages, sections, and navigation paths. It is an important visible part of the knowledge architecture.

The knowledge architecture extends further. It also connects content that does not appear as a public website:

• internal definitions,
• Source register,
• Product data,
• Conversation guides,
• Training knowledge,
• Release rules,
• confidential application information,
• machine-readable metadata.

A website can be visually clearly navigable and yet be based on a contradictory knowledge base.

Conversely, a company may be well-documented internally but fail to translate knowledge understandably and findably to the outside.

The architecture must connect both levels without uncontrollably mixing internal and public information.

The architecture model

Enlarge graphic

Level 1. Terms and Entities

Persons, organizations, products, services, methods, target groups, and technical terms receive unique designations and relationships.

Level 2. Questions and Situations

Real information and decision-making situations are documented. They form the access points to knowledge.

Level 3. Core statements and evidence

Recurring technical statements are linked to scope, source, experience, and responsibility.

Level 4. Content and formats

Pages, posts, documents, and media use the core messages in a form suitable for the respective context.

Level 5. Relationships and Navigation

Links, taxonomies, references, and hierarchical structures make connections visible.

Level 6. Maintenance and Governance

Owners, review intervals, approvals, and change rules ensure up-to-dateness and consistency.

Why the development of generative AI intensifies the architecture question

In 2023, generative language models were able to summarize content, rephrase it, and respond to questions. Technical approaches such as Retrieval-Augmented Generation have been connecting language models with external document repositories since 2020.

This did not lead to a simple rule of loading every company document into an AI system.

Rather, the research highlighted two requirements:

1. External knowledge can be more updatable and traceable than knowledge stored exclusively in the model.
2. The quality and origin of the retrieved content remain crucial.

An unordered collection of documents does not automatically become a reliable knowledge base through retrieval technology. The system may find outdated, contradictory, or irrelevant passages.

Therefore, reliable AI usage does not begin with the vector database. It begins with professional organization.

Perspective from practice

Content audits often reveal that companies answer the same questions multiple times without establishing a common core message.

An example pattern:

• The homepage promises a comprehensive solution.
• A service page narrows the scope more tightly.
• An older technical article uses an earlier product name.
• A sales presentation mentions different prerequisites.
• The internal team explains the performance differently again in conversation.

Every single formulation can be understood from its context of origin. Together, they create uncertainty.

The correction does not consist of using the same advertising slogan everywhere. First, the subject, scope, and core message are clarified. Then, the statement is translated appropriately for each usage context.

Framework of action

1. Define knowledge areas

Companies should define central areas, for example:

• Positioning and brand,
• Services and products,
• Target groups and applications,
• Methods and processes,
• Subject areas and standards,
• Evidence and sources,
• frequently asked questions,
• Risks and limitations.

2. Normalize terms

For each central term, preferred designation, definition, synonyms, and relationships are documented.

This does not reduce technical diversity. It prevents avoidable language variations from being understood as different services or statements.

3. Capture core statements

Recurring statements are not just stored as text modules. They receive:

• unique identifier,
• technical owner,
• Source or basis of experience,
• Scope,
• last check,
• content in use.

4. Assign content elements

Existing pages and documents are assigned to the knowledge areas, questions, and core messages.

This makes visible:

• Gaps,
• Duplications,
• contradictions,
• orphaned content,
• missing sources,
• unclear ownership.

5. Model Relationships

An article should not just link to "similar content." It should receive factually justified relationships.

6. Transfer maintenance to operations

Audit intervals and responsibilities are not set across the board. They depend on the dynamics of change and risk.

A timeless foundational article requires different care than regulatory instructions or product information.

What companies should not do

Not sensible are:

• to equate a knowledge architecture with a new file store,
• Developing taxonomies without real user questions,
• migrate all content before conceptual clarification,
• build the technical AI infrastructure before data and source verification,
• mixing internal and public information without a rights concept,
• prohibit every formulation variant,
• designing governance as the central approval for all minor details.

The architecture must facilitate orientation and reuse. It must not block professional work through unnecessary complexity.

Consequences for companies

Content becomes valuable in the long term when it is treated as an expression of a well-maintained knowledge structure.

The relevant key figure is then not just the number of published contributions. It is crucial whether a company can consistently answer its important questions, substantiate statements, track changes, and control the use of knowledge in multiple contexts.

This creates the basis for digital expertise, searchability, and later AI-supported applications.

Subject-matter connection

SDC Knowledge Core as an ordered knowledge base

An SDC Knowledge Core begins with the technical and editorial organization of terms, statements, sources, documents, and responsibilities. As part of SDC Discovery, it can first be clarified which knowledge areas are business-relevant, which contradictions exist, and which architecture is actually needed.

Structure knowledge architecture with the SDC Knowledge Core

Author

About Göke Frerichs

Göke Frerichs has been combining digital strategy, communication, technology, and implementation since 1999. As a digital strategist and Smart Digital Creative, he supports owner-managed B2B companies in developing clear and reliable digital systems from individual measures. His perspective is based on many years of consulting and implementation experience in the DACH region and North America.

More about Göke Frerichs