# Knowledge Base

> Upload runbooks, architecture notes, and context documents so AI recommendations reflect how your systems actually work.

Source: https://latchkey.dev/documentation/knowledge-base

## Summary

- Upload runbooks, architecture docs, and conventions (`.md`, `.yaml`, `.yml`, `.txt`, `.json`, up to 500KB) to ground AI recommendations.
- Monitored repositories index themselves: READMEs, docs folders, workflow files, and other CI configs.
- A curated **System** library of CI/CD knowledge is included out of the box; it is read-only.
- Better grounding means recommendations that respect how your systems actually work.

The **Knowledge Base** page lets you give Latchkey's AI context that is not visible in your workflow files: runbooks, architecture docs, deployment conventions, naming standards, and anything else an engineer would want to know before proposing a change to your CI.

## How it works

Monitored repositories are indexed automatically when you enable monitoring, so the AI already knows your workflow layout; the Knowledge Base is for everything beyond that.

## What gets indexed automatically

When you enable monitoring on a repository, Latchkey indexes its documentation on its own:

- `README.md`, `CONTRIBUTING.md`, and root-level docs such as `SECURITY.md` and `CHANGELOG.md`.
- Markdown in `docs/`, `doc/`, and `documentation/` folders.
- GitHub Actions workflow files.
- `CODEOWNERS` plus issue and PR templates.
- CI configs from other systems, including CircleCI, Jenkins, Travis, GitLab CI, Bitbucket Pipelines, and Azure Pipelines.

Unchanged files are skipped on re-index, so the index stays current without repeat work. The AI knows your real workflows and docs without anyone uploading a thing.

## The built-in System library

Latchkey also ships a curated library of CI/CD knowledge covering languages, frameworks, CI/CD tooling, and runner patterns. These documents appear in the table with a **System** badge; they are read-only and cannot be deleted. The practical effect: recommendations are well-grounded from day one, even before you upload anything.

## Uploading documents

Click **Upload Document** to add your own. Type or paste content directly, or load a file by drag-and-drop or browse. Each document needs a title (up to 200 characters) and content, with a live character count as you type. Accepted file types are `.md`, `.yaml`, `.yml`, `.txt`, and `.json`, up to 500KB per document; the dialog flags unsupported types and oversized files before anything is saved.

## How grounding changes recommendations

Think of it as the difference between advice from a skilled contractor and advice from the engineer who has worked in your codebase for a year. Both can read your workflow files; only one knows which pipeline is deploy-critical, which failure is a known issue, and why your caching is set up the way it is.

The payoff shows up across Latchkey's AI surfaces, including [AI Insight](/documentation/optimization-insights): what you upload here is part of the ground truth Latchkey reasons from, so what gets proposed respects how your systems actually work.

## High-leverage uploads

- **Incident runbooks** The playbook for your flakiest pipeline teaches the AI what "known issue" looks like for you.
- **Deploy-critical map** A doc describing which workflows are deploy-critical changes how aggressive recommendations dare to be.
- **Conventions** Internal standards for caching, artifacts, and naming keep proposed changes idiomatic to your team.

### What a good upload looks like

You do not need polished documentation; you need documents that carry decisions. Some concrete shapes that work well (these are suggestions, not requirements):

- **A flaky-pipeline runbook** that names the workflow as it appears in CI, describes the failure signatures your team considers "known", and states the accepted workaround.
- **A deploy map** that lists which workflows gate production and which must never be modified without human review.
- **A conventions doc** that spells out how you name caches and artifacts, and crucially, why those rules exist.
- **Architecture notes** that explain the relationships an outsider could not infer: which services build together, what depends on what, where the load-bearing weirdness lives.

The common thread: write down the **why**, not just the what. The AI can already see what your workflows do; what it cannot see is the reasoning and the constraints behind them.

**A quick self-check before uploading**
- [ ] It is current: a stale doc grounds the AI in how things used to work
- [ ] It names workflows and repositories the way they appear in CI
- [ ] It explains why each rule exists, not only what the rule is
- [ ] It says what must not change, not only what could be improved

## See what the AI knows

Every indexed document appears in a sortable table with its title, source badge, path, and indexed time. A summary line shows the document count, the number of repositories represented, and when the most recent indexing ran. The table paginates at 10 documents per page, includes a fullscreen view, and a source filter narrows the list to one slice: All Sources, README, Workflow, Docs, Manual, or System.

| Source badge | What it marks |
| --- | --- |
| README | Repository README files |
| Workflow | GitHub Actions workflow files |
| Docs | Markdown from repository documentation folders |
| Manual | Documents your team uploaded |
| System | Latchkey's curated CI/CD library (read-only) |

You can delete any non-System document from its row. Latchkey asks for confirmation first, and deletion cannot be undone.

> **Self-healing reads it too, safely**
> When a [self-healing](/documentation/self-healing) runner works out a fix, it consults Latchkey's curated knowledge through a restricted, rate-limited, audited query channel. A heal never stalls waiting on a knowledge lookup, and your knowledge base is never exposed to the build environment.

### What file types can I upload to the Knowledge Base?

Markdown, YAML, plain text and JSON (`.md`, `.yaml`, `.yml`, `.txt`, `.json`) up to 500KB each. Runbooks, architecture notes and team conventions are the highest-leverage uploads because they encode decisions the repository itself does not.

### Do I have to upload anything for this to work?

No. Monitored repositories index themselves, covering READMEs, docs folders, workflow files and other CI configuration, and a curated read-only System library of CI/CD knowledge ships with the product. Uploads add your context on top of that baseline.

### What does grounding actually change?

It changes whether a recommendation respects how your systems really work. Without your runbooks the model reasons from general CI practice; with them it can account for the constraint that made you do something unusual, which is the difference between a suggestion you apply and one you dismiss.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt