Knowledge & data

Knowledge catalog

What does that cost roughly? Does that fit us too? How does it work? Your business answers these questions every day – only none of the answers sit anywhere you could look them up.

Knowledge catalog

01Knowledge catalog

The knowledge catalog is your company's ordered knowledge base: services, prices or ranges, common questions, processes, references, particularities – as a clean structure instead of scattered across website copy, PDFs and heads. Built once, the same base works in several places: the website draws its content from it, search engines and AI assistants understand it, a companion can answer from it, and the team looks things up instead of asking. During the build the most valuable thing happens along the way: gaps, contradictions and outdated items become visible for the first time.

Straight up: this is structural work, not tech wizardry – "we'll just put RAG over it" is exactly the path I don't take. Order first, then the tools. And a catalog only lives if someone maintains it: owners and an update rhythm are set in the project, otherwise even the finest base ages.

02Demo

simulation · fictional signage firm

The catalogue of the fictional “Lichtwerk Signage” firm. Ask a question – and look under the answer to see where it comes from: each one stems from a maintained block, not out of thin air.

// building block in the catalogue

This is what the catalogue looks like from inside: knowledge blocks with clear fields – and three output channels fed from SEVERAL blocks. If a price changes, it changes everywhere it's needed.

// the building blocks ServicesDescription · for whom · duration · from-price FAQsQuestion · answer · applies to · updated Prices & rangesService · range · conditions · updated ProcessesSteps · duration · responsibility // the output channels Website Search & AI systems Team (internal)

Ask a question in the “try it out” tab – the block the answer came from lights up here along with its channels.

03How it works

  1. 01

    Gather the knowledge

    Website, PDFs, price lists, email replies, client questions: what exists where? Even the knowledge passed on only by word of mouth comes onto the table.

  2. 02

    Set the structure

    Which kinds of knowledge do you have – services, FAQs, prices, processes, references? Each gets clear fields: "it's somewhere in the text" becomes "it's in field X, maintained by Y".

  3. 03

    Fill it and tidy up along the way

    Filing it all reveals everything: the FAQ answer that contradicts the quote PDF, the price from two years ago, the service with no description. Exactly these finds make the catalog valuable.

  4. 04

    Connect what reads from it

    Website pages, structured data for search and AI, companion knowledge, an internal look-up view – the base is tapped wherever it creates value.

  5. 05

    Anchor the upkeep

    Who updates what, on what rhythm, with what review date? Small and realistic – better one area that holds true than ten that go stale.

04Stages

The catalog grows area by area – no one structures their whole company in one go.

Tier 1

Entry: one area of knowledge

Services plus FAQ as a clean structure document or CMS model – the core everything else aligns to.

Tier 2

Extended: the full catalog

All areas of knowledge structured, technically marked up on the website – closely interlocked with the AI-ready upgrade.

Tier 3

Full build: the living data base

The catalog feeds the companion, AI visibility and internal use – with a maintenance process and owners.

05Technical implementation

  • The store suits you: a Markdown structure, CMS collections, Airtable/Notion or a database – what matters is clear content types with fields.
  • Typical kinds of knowledge: services, FAQs, prices/ranges, references, target groups, processes, decision criteria.
  • The output is manifold: website pages, structured data (Schema.org), companion context, an internal knowledge file.
  • AI helps with sorting, gap-finding and phrasing – the factual accuracy you check.
  • Vector search (RAG) only comes in at genuinely large scale – usually the clean structure with direct context is enough.
  • Every area of knowledge carries an owner and a review date – upkeep is part of the model, not an afterthought.

for context · This shows how something like this usually gets built – not how it has to be built for you. What actually fits is worked out in the project: around your existing setup, your team, and what stays easy to maintain.

06Related building blocks

See all use cases