Capture project knowledge by harvesting it from work that already happens, the partner calls, the decision moments, the working drafts, and organise what you collect around cohorts: the people who produced it and those who need it next. Give every section a named maintainer and every entry a visible date of last verification. Do it while the project is running: the default outcome is knowledge sitting in deliverables written for reviewers and in the heads of people whose contracts end with the funding.
EU projects produce a great deal of text, and very little of it is written for the person who will need it later. A deliverable answers the question the Grant Agreement asked, in the register reviewers expect: complete, defensive, formatted for assessment. The person who needs the knowledge later wants to know what the pilot partner actually did when recruitment stalled, or why the consortium quietly changed its approach after the mid-term review. The answer may exist deep in a long PDF, phrased so carefully that it no longer commits to anything.
The second cause is contract structure. Project staff are hired for the project, and when it ends, the researcher who ran the pilots, the coordinator who remembers why a work package was restructured, and the communications lead who knows which channels produced real signups all move on. What they knew was never in the deliverables. The organisation keeps the PDFs and loses the knowledge.
When a project knowledge base dies, the autopsy rarely shows a lack of content; it shows one of two failures.
The first is retrieval. The material exists, but it is organised the way the archive grew, by work package and file type, not the way questions arrive: "how did we handle consent for the youth participants?" When the base cannot meet a question in its own shape, people ask a colleague instead, or ask nobody, and a base that is never queried is storage with a better name.
The second is ownership. A page with no name on it has no reason to stay correct: it was accurate the day it was written and has drifted every day since. After the first confidently stale answer, readers stop trusting the whole base. The fix is structural rather than editorial: design for the question and for the owner, not for the volume of the archive.
A cohort is a group that went through the same experience together: the partners in one pilot wave, the grantees of a single call, the members who joined a community programme in the same season. Organising knowledge by cohort means keeping two indexes, who produced this, and who needs it next. The choice sounds small, but it changes what gets captured: it replaces the impossible question "what should we document?" with a concrete one, "what does the next cohort need from this one?"
The second index does most of the work. The next pilot wave does not need the full history of the last one. It needs the decisions that would otherwise be re-litigated, the mistakes that cost weeks, the templates that survived contact with reality, and the names of the people who can explain the rest. Every cohort transition becomes a capture deadline with an obvious audience, something a generic "please document your learnings" request never has.
Asking busy project staff to "document things" produces guilt, not documentation. What works is harvesting from artifacts the work already generates. Three sources cover most of it.
The role this creates is an editor, not a writer: someone who spends a little time each week turning what happened into entries. The role must sit in a job description or in the coordination budget of the next proposal; it will not happen as a favour.
Entries should be small: one question, one answer, the context that makes the answer safe to reuse, and links to the underlying material. Long synthesis documents feel authoritative and age badly. Small entries can be individually corrected, retired, and found.
Two fields matter more than any taxonomy. The first is the maintainer, a named person rather than a partner organisation. "WP4 owns this" means nobody owns it. The second is a freshness signal: the date the entry was last verified and, where relevant, the condition under which it expires. A stale entry that admits it is stale remains useful. A stale entry that looks current is how a base loses its readers.
Two events test the design. The first is a partner leaving mid-project, planned or otherwise. Their sections need a new named maintainer immediately, and the leaving team's exit conversation should be run against the base: what here is wrong, what is missing, who else knows. An hour of that while people are still under contract is worth more than any archaeology afterwards.
The second is project end. The final funded months are the only period in which the people who know are still paid to spend time telling. This is where cohort thinking meets sustainability planning: before the funding ends, the base should move into the platform of whichever organisation will operate it afterwards, with maintainers who survive the project. That is what dissemination infrastructure that outlives the grant looks like in practice, and a stronger sustainability argument than a promise to keep a website online. Designing that handover is part of the platform work described at what we do.
The honest trade-off: dedicated knowledge tools have better editing, versioning and search, while the community platform has readers. Retrieval begins with being present where the question occurs. Our consistent observation from operating Impactful, the community impact platform we run for the Founders community in Cyprus: knowledge placed inside the member area, next to events and discussions, gets read; material exported to a separate wiki gets an initial burst of attention and then silence. If your consortium or community already lives somewhere, put the base there and accept the weaker tooling. If it lives nowhere, that is the prior problem to solve, and the kind of problem a membership platform exists to answer.
A well-kept cohort base is also the precondition for what many consortia now ask about first: an AI assistant that answers members' questions with sources. An assistant retrieves before it answers, and it retrieves from whatever base exists. Small owned entries with freshness signals give it something honest to stand on; a pile of reviewer-facing PDFs gives it confident answers citing a page nobody has verified since the mid-term review. An assistant amplifies whatever base it stands on, including its neglect. Ownership, freshness and question-shaped entries, the properties argued for above, are exactly what grounded retrieval needs.
You do not need a tool decision to begin. After the next consortium call, harvest the decisions from the notes into a handful of small entries, put a name and a verification date on each, and show them to whoever joins the project next. Everything else scales up from that habit.
This article draws on operating community and knowledge platforms for EU-facing communities, Impactful among them, and on building cohort-based knowledge bases inside the platforms we run. The structural view of EU consortia comes from our consortium graph, built from CORDIS and Erasmus+ open data covering 2014-2027, with 114,731 organisations and 83,490 projects. The failure modes here are ones we have watched happen, not read about.