How Atlas generates a cited wiki from your codebase

The hard part of internal docs isn't writing them once — it's that they're wrong within a sprint. Code moves, the doc doesn't, and trust erodes until nobody reads the wiki. Atlas is tela's answer: it generates a wiki from your sources of truth — git repositories and Jira — keeps every claim cited back to where it came from, checks how much of the codebase is actually covered, and flags drift when the source changes underneath a page.

This post describes the real shape of how that works. It's deliberately not a magic "point it at your repo and get a perfect wiki" pitch — the value is in the citations, the coverage, and the drift detection, and those are concrete.

The inputs: git and Jira

Atlas reads two kinds of source:

Git repositories — the code itself, plus the structure around it (directory layout, module boundaries, READMEs, configs, commit history). Code is the most truthful documentation you have; it just isn't readable as docs.
Jira — the why. Tickets, epics, and their discussion carry intent and decisions that the code can't express on its own. Pairing the two lets a generated page say both what the system does and what it was for.

Chunking and structuring

Raw files aren't a wiki. Atlas breaks the sources into meaningful units — coherent spans of code, a module, a config block, a ticket — rather than arbitrary fixed-size slices, so that a generated section maps to something real you can point back to. From those units it builds wiki structure: an overview, per-area pages, and the relationships between them, written as tela's canonical markdown (so the output is plain, exportable, and editable like any hand-written page — not locked in a generated format).

The goal of this stage is a wiki shaped like how engineers think about the system, sourced from how the system is actually built.

Citations back to source

This is the core of why the output is trustworthy: claims carry citations. A statement in a generated page links back to the specific source it was derived from — the file (and region), the repo, the ticket. That does two things:

It's auditable. A reader who doubts a sentence can jump to the source and check, instead of trusting the generator.
It's the anchor for drift detection. Because a claim knows where it came from, Atlas can later re-check whether that source still says what the page says.

A generated wiki without citations is just a confident summary you can't verify. Citations are what make this a documentation tool rather than a one-shot summarizer.

Coverage checking

"We have docs" and "our system is documented" are different claims. Atlas does coverage checking: it tracks how much of the source material is actually represented in the wiki and surfaces the gaps — the modules, areas, or features that have code but no corresponding documentation. Instead of a binary "documented / not," you get a map of where the wiki is thin, so effort goes where it's missing rather than where it's already fine.

Drift detection

The part that addresses the original problem. Because each page is tied to specific sources via its citations, Atlas can compare the current state of those sources against what the page was generated from. When the code or ticket has moved on, the page is flagged as drifted — the doc and its source no longer agree.

This turns staleness from something you discover by being burned into a signal you can act on: review the drifted pages, regenerate or correct them, and move on. It's the difference between docs that rot silently and docs that tell you when they've gone stale.

What Atlas is — and isn't

Being honest about the shape matters more than a bold claim:

It is a way to bootstrap and maintain a cited, coverage-aware wiki from systems that are already your source of truth, with a real signal for when pages drift.
It isn't a replacement for human judgment. Generated pages are a strong starting point and a maintenance aid; the citations exist precisely so a human can verify and edit. tela pages stay canonical markdown, so you correct a generated page exactly like any other.
It doesn't claim to perfectly understand intent from code alone — which is why Jira is in the loop, and why citations and coverage are framed as tools for a human reviewer, not an oracle.

How it fits the rest of tela

Atlas writes into a normal tela wiki, which means the output immediately gets everything else tela offers: ranked full-text and semantic search, live collaborative editing (Yjs), and the built-in MCP server — so the cited wiki Atlas generates is itself agent-readable and agent-writable at https://telawiki.com/api/mcp. An agent can search the generated docs, and a human can edit them in the same editor as everything else.

tela is self-hostable with a free cloud tier, so you can run this against your own repos and keep both the code and the generated wiki on infrastructure you control.

The point

Auto-generated docs are easy to produce and easy to distrust. What makes a generated wiki usable is the boring, rigorous part: every claim cites its source, coverage tells you what's missing, and drift tells you what's gone stale. That's the shape Atlas is built around — turning the systems you already trust (git and Jira) into a wiki you can keep trusting.