Skip to main content
The Knowledge Base is a searchable store of your organization’s engineering knowledge — decisions, guides, pitfalls, and process docs — that both people and AI assistants can search. This is the foundation of Engineering Framework’s agentic memory layer: instead of an AI assistant re-deriving an answer your team already worked out six months ago, it can search the Knowledge Base and find the actual decision, with the reasoning behind it.

​
Why this matters

Most engineering knowledge lives in people’s heads, old Slack threads, or documents nobody can find again. That means the same questions get re-litigated, the same mistakes get repeated, and new team members (human or AI) have no way to learn from what’s already been figured out. The Knowledge Base gives that knowledge a permanent, searchable home.

​
What lives in the Knowledge Base

Each piece of content is a Document — a title, written content, a type (decision, guide, pitfall, or process), and some organizing information:
  • Domains — the subject areas a Document belongs to (e.g. “Backend”, “Auth”). Each domain has its own reviewers, who approve content for that area.
  • Project — a Document can optionally be tied to a specific project, instead of or in addition to a domain.
  • Tags and related links — additional ways to filter and connect Documents to each other.
Every Document starts as a draft and must be approved by a reviewer before it becomes visible to general search — see The Document Review Workflow for that process.

​
How content gets added

There are three ways content enters the Knowledge Base today. Whichever way it comes in, every new Document goes through the same steps automatically:
  1. It’s checked against your organization’s projects and domains, so it’s filed correctly.
  2. It’s indexed for semantic search — meaning people and AI assistants can find it by describing what they’re looking for, not just by matching exact keywords.
  3. It’s checked for a few basic content-health signals (see The Document Review Workflow) and given a starting confidence score, so reviewers know what needs the most attention.

​
Automatically, from completing a checklist item

This is the path most people will actually use, and it requires nothing extra from you. A handful of framework checklist items — the ones that produce a real artifact, like architecture decision records, operational runbooks, and documented design trade-offs — automatically create a draft Knowledge Base Document when you mark them complete, using the item’s name, your notes, and any artifact link you provided. This happens best-effort, in the background: marking a checklist item complete never fails or waits on the Knowledge Base, and there’s currently no confirmation in the dashboard that a Document was actually created. If you’re relying on this and want to confirm it worked, check the review queue or ask your admin, rather than assuming it always succeeds.
For more control than the automatic trigger gives you — or to script ingestion from outside the dashboard — see the engframe CLI, a command-line tool you install and run yourself.

​
By hand, for engineering and operations use

Content can also be added directly by someone with engineering access to the Knowledge Base’s underlying systems, or through a service-level connection used internally by Engineering Framework itself (for example, the automatic checklist trigger above uses this path under the hood). Both of these are internal/engineering capabilities today, not something a general user sets up or uses directly.

​
Where content goes next

Once added, a Document sits as a draft until a reviewer approves it. From there: