# Your docs rot. Here's a codebase that documents itself.

Hand-written architecture docs go stale the moment the code moves. A living knowledge base writes and maintains them for you — from structure, never your source.

Everyone knows the docs are out of date. The `ARCHITECTURE.md` describes a system from six months ago; the onboarding guide references a service that got renamed. Documentation rots because it's manual, and manual work loses to a moving codebase every time.

## What if the docs wrote themselves — and stayed current?

That's the [living knowledge base](/docs/knowledge-base). Bring a project into SecondOS and it writes a whole family of readable docs from the code's structure and your team's recorded notes — then keeps them current on every push, rewriting *only* the sections whose underlying code or memory changed.

Eleven documents, auto-written:

- **Overview** — what the project is, key decisions, where things live
- **Architecture** — the module map and how a request flows
- **Modules** — per-module: purpose, exports, dependencies, routes, and the tables it touches (big modules break into sub-modules)
- **Dependencies** — which modules are foundational vs leaf
- **API** — every route, grouped by area
- **Data model** — the database schema, table by table
- **Knowledge / Learnings** — the team's decisions, conventions, gotchas and lessons, as prose
- **Onboarding**, **Changes**, **Glossary**

## The part no other tool can do

A doc generator can summarize files. SecondOS can write the **dependency map**, the **API reference** and the **data model** because it has the call/import graph, the routes and the parsed DB schema — structure other tools don't extract. So the docs describe how the system actually fits together, not just what each file says at the top.

## It maintains itself

You don't click "generate." On the first sync the applicable docs appear; on every push they refresh incrementally, so an unchanged section costs nothing and a changed module rewrites just its own section. Memory-derived docs (knowledge, learnings) fill in as your team records decisions.

And it's all written from the **structural map** — never your source (K-S23).

## Read more

See the [living knowledge base docs](/docs/knowledge-base), or the [product overview](/product) for how memory and the graph fit together.