Knowledge pipeline
A knowledge pipeline that pages someone
Every organisation has a knowledge base nobody reads. I built the version that reads itself, notices a slipping deadline or a budget breach, and messages a person — and exposes the same data to the assistant in the editor.
- Wiki, time-logging portal and files, normalised into one corpus
- 3 sourcesWiki, time-logging portal and files, normalised into one corpus
- Deadline risk, delay, budget and compliance
- 4 alert classesDeadline risk, delay, budget and compliance
- Exposed to the assistant so it queries the corpus rather than guessing
- 7 toolsExposed to the assistant so it queries the corpus rather than guessing
The client
A delivery management function whose project truth was scattered across a documentation wiki, a time-logging portal and loose files, with no way to notice a problem until someone happened to open the right page.
The engagement
A working pipeline with scheduled ingestion, an alert engine and a tool server exposing the same corpus to an AI assistant inside the editor.
The problem
Knowledge bases fail passively. The content is there, it is even reasonably current, and nobody looks at it until after the thing it warned about has happened. Adding an AI assistant on top does not fix that — an assistant with no access to the live corpus produces confident answers from training data, which is worse than no answer.
What I did
I built it as a pipeline with two outputs rather than as a repository. The first output is alerts: the same corpus that answers questions also evaluates itself on a schedule against rules for deadline risk, delay, budget and compliance, and when a rule fires it messages a person in the channel they actually read. That inverts the usual relationship — the knowledge base contacts you. The second output is tooling: rather than hoping an assistant infers project reality, the pipeline exposes explicit tools for search, retrieval, recency, ingestion status and alerts, so the assistant in the editor queries real data and can say where an answer came from. Configuration for both schedules and alert rules is declarative, so adding a source or a rule is an edit rather than a development task, and content is scoped between shared knowledge and per-project data so a query cannot silently cross a project boundary.
What was built
Connectors pulling from the documentation wiki, the time-logging portal and the filesystem; normalisation and deduplication into a document store with full-text search; a scheduler driven by declarative configuration; an alert engine with rules for deadline risk, delays, budget and compliance; notification into chat and email; and a tool server exposing search, retrieval, recency, ingestion runs and alert listing directly to the AI assistant in the editor.
On the table at the end
- Ingestion connectors for wiki, time-logging portal and files
- Normalised, deduplicated store with full-text search
- Declarative schedule and alert configuration
- Alert engine covering deadline, delay, budget and compliance risk
- Chat and email notification
- Tool server exposing the corpus to the assistant in the editor
What it changed
Turned a passive document store into an active one: the corpus keeps itself current on a schedule, evaluates itself against alert rules for schedule, delay, budget and compliance risk, and pushes a message to a person rather than waiting to be consulted.
How it ran
- 01
Connect the sources that already exist
Documentation wiki, time-logging portal and files — meeting the organisation where its truth already lives.
- 02
Normalise and deduplicate
One store, full-text searchable, so the same fact arriving from two places does not become two answers.
- 03
Make the rules declarative
Schedules and alert conditions in configuration, so a new rule is an edit rather than a release.
- 04
Alert into a channel people read
Deadline, delay, budget and compliance conditions pushed to chat and email — the knowledge base contacts the human.
- 05
Expose tools, not vibes
Explicit search, retrieval, recency and alert tools for the assistant, so answers are queried and attributable rather than recalled.
Other work
All case studies →- Knowledge operations
Turning sixty-five gigabytes of drive dumps into context an assistant can use
AI assistants are only as good as the context you can hand them, and the context was spread across drives, chats and mailboxes. I turned it into a structured base where every past engagement is a self-contained dossier.
- Professional services
A project office that lives in a git repository
Project knowledge lived in people's heads and chat threads, and AI tools were producing confident documents with no provenance. I made the repository the single source of truth and gave every project management role a written protocol.
- Document operations
When the prototype needs a database
Most presale demos are a front end pretending. This one had to survive a login, an upload and a restart — so I built the backend too.
Something similar on your plate?
Thirty minutes, no deck. I will tell you whether it is worth doing at all.