← Back to Blog

The Confluence Graveyard: How to Turn Scattered Data into AI Intelligence

Posted on May 2026
  • AI
  • Claude
The Confluence Graveyard: How to Turn Scattered Data into AI Intelligence

We are drowning in data but starving for knowledge. In most organizations, the "source of truth" doesn't exist in one place. It’s a fragmented puzzle scattered across JIRA tickets, chat threads, outdated Confluence pages, and email chains.

Standard RAG (Retrieval-Augmented Generation) attempts to solve this by dumping raw data into a vector database. But there’s a flaw: If the input is messy, the AI’s reasoning will be too. To unlock the real potential of LLMs, we need to move from Retrieval to Structured Synthesis.

Two Skills, One Source of Truth

I am currently developing a workflow that bypasses the "Documentation Debt" by using two specialized AI roles: The Archaeologist and The Librarian.

Skill 1: The Archaeologist (The Synthesizer) 🦴

The Archaeologist doesn't just read; it reconstructs. Using the Model Context Protocol (MCP), it connects directly to JIRA, Confluence, and other documents to "dig" through history.

Instead of just returning a search result, it performs a Temporal Synthesis:

  • Merging History: It identifies different versions of a project plan and merges them into a single "Current Truth" file.
  • The "Why" Factor: It extracts the rationale behind decisions that are often lost when a ticket is closed.
  • Source Integrity: Every claim is back-linked to the original data source for human verification.

The output is a clean, domain-specific Markdown file that represents the state of a topic right now - and includes a change log with important milestones.

Skill 2: The Librarian (The Architect) 📚

A collection of files is just a digital pile. To make knowledge actionable, the AI needs to understand relationships. The Librarian processes the Archaeologist’s files and builds a Knowledge Graph.

It identifies business-critical links, for example:

  • Product A is the successor to Product B.
  • Feature X is an add-on that requires Service Y.
  • Sales Campaign Z targeted the users of Product B.

By interlinking these topics in a structured Markdown Wiki, the AI can navigate the business ecosystem like a seasoned employee, not a blind search engine.

By using tools like Obsidian you can easily navigate through these files - and also generate visualizations to see, how topic related to each other.

Real-World Value: From Search to Reasoning

Imagine asking an AI: "Why did our sales for Product B dip in Q3?" A standard RAG might just give you a sales report. An AI backed by properly structured information knows:

  • Which changes happened during Q3
  • Which sales campaigns happened
  • Which products were effected - incl. which products are related and might be effected indirectly
  • ...

This is the shift from "Finding Information" to "Explaining Effects" - not stopping at the obvious findings but digging deeper.

The Road Ahead

This isn’t a one-time cleanup; it’s a continuous, automated process. As new tickets are created and docs are updated, the "Current Truth" evolves. The same skills can continuously process new information and keep the knowledge base intact.

Over the coming weeks, I’ll be refining the automation of these skills and exploring the best storage architectures. Right now we are consuming the linked Markdown files directly. As agents get more and more skilled in scanning through filesystems (a typical scenario for coding tasks), this works pretty well right now. We'll investigate options how we share this knowledge across teams, e.g. utilizing graph databases or by sticking to version-controlled Markdown repositories.

I’m curious: How are you ensuring your AI assistants are looking at the "Current Truth" rather than just the "first doc it can find"?

Have thoughts on this? I'd love to hear them — comment or share on LinkedIn.

Comment on LinkedIn