See how your pages, documents and records connect, and what is missing.

Where the problem shows up

Most organisations store knowledge as documents. A policy sits in a file, a decision sits in a thread, and an explanation sits in a page that was written for another purpose. A person who knows where to look finds what they need, and everyone else searches, asks a colleague or writes the answer again.

The weakness is that documents describe their own content and record very little about how they relate to each other. Two pages cover the same topic without either knowing about the other, a policy depends on a process that has changed, and one question is answered in three places in three slightly different ways. On a website, overlapping pages compete for the same searches and internal links follow habit instead of meaning.

What happens to search, to onboarding and to decisions when a business cannot tell what it already knows? And how can a team decide what to write or merge next if the relationships between its pages cannot be measured?

The better principle is to record the relationships as data in a knowledge graph, so that overlap, gaps and isolated content can be seen and queried. That is the work I do.

What I have changed for others

Website architecture: from page-by-page review to a semantic knowledge graph

A large website had grown by addition and could only be reviewed one URL at a time, so overlap, gaps and isolated pages stayed invisible. I built an application that reads a sitemap, finds recurring themes with LDA topic modelling, scores page similarity with TF-IDF and cosine similarity, and draws an interactive network of related pages.

The site can now be examined as a whole, and the analysis exports as similarity matrices, topic assignments and graph edges. Read the case study: Building a semantic analysis tool for content architecture and internal linking.

Organisation memory: weekly reports built on connected context

Important context in a 100+ person organisation was spread across Slack, Gmail and team activity. I combined those signals with organisational memory in a system that generates a weekly report for each employee and a company-level summary. The organisation now sees how individual work connects to what is happening across the company. Read the case study: How I turned Slack, Gmail, and team activity into an organization-wide intelligence system.

How does a knowledge graph project work?

A knowledge graph project has 5 steps, and I use the same sequence for a website and for a document set.

• Collect: I read your sitemap or document set and extract the text of every page or record.
• Model: I define the entities and relationships that matter to your business, such as pages, topics, customers or policies.
• Measure: I find recurring themes with LDA topic modelling and score similarity with TF-IDF and cosine similarity.
• Visualise: I draw the result as an interactive network and report on gaps, overlaps and isolated content.
• Export: You receive similarity matrices, topic assignments and graph edges in open formats, so the structure is not locked inside one tool.

What changes for your business with a knowledge graph

You see which pages or documents overlap, which topics have no coverage, and which content has no connection to anything else. Internal linking follows meaning, merging and writing decisions rest on measurements, and the structure is exported in open formats. The work can include an entity and relationship model, similarity analysis, a queryable graph, reports on gaps and silos, and exports.

Where this leads next

A knowledge graph is most useful when the content and data beneath it are consistent, so it often follows work on information systems and feeds the automation that keeps the structure current. If your content is already well organised, we can begin with the graph itself: send me a sitemap or a document set and I will tell you what can be measured.