The job
The team is starting a new project and they need to know: have we done something like this before. What did we learn. What did we propose. What did we charge. Right now the answer lives somewhere in someone’s email, a shared folder that hasn’t been organized since 2022, or in people’s heads. They spend two hours hunting and still don’t find the answer.
When the station runs this dish well, the team asks a question and gets relevant past work in 30 seconds. Previous proposals on similar projects. Lessons learned from past failures. Pricing we used before. Customer feedback on similar work. The team doesn’t reinvent. They build on what they’ve done.
The difference between retrieval that’s useful and retrieval that’s empty is the corpus. If your internal knowledge lives in five different places and is partially organized, the station will return nothing or confabulation. If your knowledge is in one searchable place and the station is pointed at it, the station returns exactly what you need.
The recipe
All seven ingredients still apply. The leverage on this dish is Context (Ingredient #2). The station is only as good as the source library it’s pointed at. Without a curated, searchable, dated knowledge corpus, the station is empty. Get the source data right first.
Training matters. The station learns your naming conventions, your project structure, how you organize knowledge. Context matters. The station needs to read the full project folders and past proposals, not just summaries. Examples matter. Show the station what good retrieval looks like: answering a question with three relevant past pieces.
How to build it
- Audit where your internal knowledge lives. Email archives. Google Drive folders. Slack channels. Confluence pages. Project management tools. OneNote notebooks. Create a list of all the places.
- Pick one source of truth for the knowledge you want the station to retrieve from. Google Drive folder with all proposals. Slack channel with lessons learned. Wiki with project playbooks. It should be one place that’s relatively organized and searchable.
- Organize the source library if it isn’t already. Create a naming convention for projects or efforts so they’re findable. If proposals are scattered across five folders with five different naming schemes, organize them first. The station can’t retrieve from chaos.
- Define what kinds of questions the station should answer. Previous proposals on X type of project. Lessons learned from Y failure. Pricing we’ve charged for Z service. Customer feedback on A category of work. Write these down.
- Feed the station a sample of your knowledge library. A folder with five successful past proposals. A folder with three lessons-learned documents. A folder with customer feedback. Let the station index this.
- Test with real questions. “Have we done a project like this before.” “What did we charge for X service last year.” “What went wrong the last time we tried Y approach.” Does the station return relevant past work.
- Go live. When the team asks a question, they get back three relevant past pieces with sources cited. When the answer is wrong or incomplete, you add more source material or organize existing material better.
What breaks it
- Corpus is scattered. Proposals are in five different Google Drive folders with three different naming schemes. Email archives aren’t searchable. Slack is full of side conversations with no structure. The station returns nothing because there’s no library to search. Centralize first. One source of truth for each knowledge category.
- Source library is incomplete. The station knows about successful projects but has never seen the three projects that failed. When a team asks “what went wrong the last time,” the station doesn’t have that history because you never archived failures. Archive everything. Wins and losses teach equally.
- Knowledge is dated and unclear. The station retrieves a proposal from 2021 that looks perfect for this new project. The team uses it as a template. In month two, they realize the approach doesn’t work with current tool versions and customer expectations have shifted. Date everything in your source library. Archive outdated knowledge so the station knows not to retrieve it.
- Context window is too small. The station retrieves the first paragraph of an old proposal but doesn’t have the full context of what the project actually entailed. The team tries to replicate it and gets confused. When feeding the station your library, give it full documents and context, not summaries.
- The station is never fed new material. The team finishes a successful project. Learns lessons. Writes a final summary. Never adds it to the knowledge library. The station doesn’t improve because the new knowledge never enters the corpus. When a project completes, archive the output and lessons learned immediately.
When it’s working
At week four, when a team member asks “have we done X before,” the station returns three relevant past projects or proposals in 30 seconds. The team reviews them and decides if they’re applicable. Sixty percent of new projects reuse something from the past. Proposals draft faster because templates exist. Pricing is consistent because the team sees what was charged before.
The signal that the recipe is sharp: the team uses past work as a starting point instead of starting from scratch.
Monday Move
Pick one knowledge category that would help your team (past proposals, lessons learned, pricing precedent). Create a folder with all the relevant past work organized and dated. Point the station at the folder. Test retrieval with one real question. The station is running on Monday.
Dish 5 of 10 on the Research Station. Build-note leverage: Context (Ingredient #2).