Project Knowledge Base
A knowledge base where nothing is believed until proven.
Every entry carries a trust level. Every answer cites the evidence behind it. A chat rumor and a fourteen-times-verified build command are visibly different kinds of knowledge, and the difference is recorded rather than assumed.
Where this stands
Knowledge capture and evidence records ship inside CodeLead today, and the application shown on this page is a working preview running on real project data.
This page details both our current enterprise functionality and some of our upcoming future-state roadmap.
The core idea
The trust ladder
Most knowledge tools treat everything you feed them as equally true, which is why they confidently repeat a runbook that stopped being accurate two years ago. Here, knowledge earns its way up, and its promotion history stays visible.
-
evidence_backedProven by verified change evidence: a validation command that has passed a recorded number of runs, an invariant confirmed by a governed change.
The trust anchor. Only this level feeds future changes automatically.
-
confirmedVouched for by an accountable source: a named expert’s attributed answer, or a fact from a completed, recorded step.
A person stands behind it, and the record says who.
-
reportedA claim, honestly labeled as one: extracted from documents, comments, chat, or model inference.
Useful fuel. Never a foundation until evidence promotes it.
-
downgradedContradicted by evidence: the document that lies, the build command that quietly stopped working.
Flagged on the conflict radar instead of silently misleading the next reader.
Updates are promote-only, and a downgrade is explicit rather than a silent overwrite, so you can see what a claim used to be and what changed its mind.
What ships today
Knowledge capture, inside the tool that proves it
Local knowledge capture
The workspace knowledge store ships in CodeLead: the entry schema, the four trust levels with promote-only updates and explicit downgrades, and automatic capture hooks. A validation command that passes on a landed run becomes evidence-backed knowledge. A gate or validation stop becomes a recorded failure pattern.
No model calls happen in the capture path, and a corrupt store can never break a pipeline. Verified on real runs, including one against the seventeen-year-old C# benchmark codebase.
Evidence records
Every governed change closes into a typed record: the request, the context retrieved, the change surface, every gate verdict including refusals with their reasons, the validation results, and the outcome, linked to the knowledge entries it produced.
This is what "cites its proof" means mechanically. A third party can walk the chain from requirement to approval without asking anyone what happened.
Working preview
Six scenes, running on real data
A browsable application, offline and self-contained, showing what the knowledge base does with a project's history. One of its two projects is seeded from real artifacts: hundreds of benchmarked sessions, loaded by a generator built to fail rather than invent a figure it cannot source.
- Ask Decision archaeology with cited answers, ending in a pre-filled work item you can hand back to CodeLead.
- Knowledge ledger Every entry across all four trust levels, with its promotion history.
- Staleness radar Claims contradicted by verified evidence. The demo catches a real configuration fossil.
- Capability profile Which local models actually work for this stack, sized by evidence from your own runs.
- Audit pack Requirement to change to validation to approval, assembled from the chain.
- Sources Where knowledge came from and how much each source is trusted.
Why it compounds
The knowledge base makes the next change better
This is not a wiki bolted onto a coding tool. CodeLead's sessions produce verified knowledge, and that knowledge feeds back into the next change. This section is what the knowledge base is designed to do next: specified in full, and coming rather than shipped.
- Trusted context injection
- Context packages prefer proven entries over re-deriving facts, which means better output and smaller prompts. A double win when the model is running on your own hardware.
- Failed changes stay out
- A change that failed validation is recorded but kept out of future context, or retained as an explicit negative example, so the same dead end is not proposed twice.
- Diagnosis archaeology
- Past diagnoses, failure patterns and waivers for an area prime the model before it reasons from scratch.
- Plan versus decision check
- A plan that contradicts a recorded architecture decision is flagged at approval, with the decision cited.
- Clarification suppression
- Questions the knowledge base already answers are answered with the citation shown. Only genuinely new questions reach a person.
- Audit and compliance packs
- Release evidence generated from the chain rather than assembled by hand the week before an audit.
For legacy systems
Tribal knowledge, captured before it retires.
In the sample portfolio, each system's core was one person's work, and the code recorded what it does and never why. No comment explains why a price cap is 1000 on one path and 10000 on another, or why a turn times out at thirty seconds.
Those answers exist only in people, and the survey ranks capturing them as the cheapest and most perishable item in the whole plan. Attributed testimony enters the knowledge base as confirmed knowledge, with the name of whoever vouched for it attached.
Your documents will lie to you
Every codebase carries runbooks that were accurate once. The problem is not that they are wrong, it is that nothing tells you which ones.
Because verified evidence outranks a written claim, a document contradicted by a command that has actually run gets flagged rather than quietly believed. That is the staleness radar, and the fossil it caught is shown above: an ignore rule left by a 2019 refactor that had been hiding a live source file from analysis ever since.
Where knowledge stays
The boundary is the point.
Capture is local and stays local. The knowledge store lives in your repository, beside the code it describes, and nothing is transmitted.
The design for sharing knowledge across a team keeps that property: an upload would be an explicit, policy-gated act written to a disclosure log, and enterprise deployments would run the service themselves. The trust boundary expands from one machine to one organization, never to a third party.
