Sources Overview

A board is only as good as what feeds it. Sources are the raw material your boards are built from — your code, your docs, your tickets, the page you scribbled at 2am. The richer and truer your sources, the sharper every board, every insight, and every answer Chat gives you.

Here's the model that makes this scale: you register a source once in your workspace catalog, then bind it to as many boards as you want. Add Confluence once, point it at your platform board, your billing board, and your onboarding board. No re-authenticating, no duplicate config. The catalog is the inventory; binding is how you wire a source into a specific board.

This page is the map — every kind of source, how the two delivery models differ, how binding roles work, and how a source moves through its sync lifecycle. For the click-by-click of adding and binding, head to Connecting Sources.

Two ways a source reaches your boards

Not all sources work the same way, and the difference matters for what you can expect.

Push sources do the analysis on your machine and push a finished graph to the board — nodes and edges, already structured. There's no AI extraction on the platform side; the work happened locally before anything arrived. Today that's Cartograph, the Claude Code plugin: it reads your repo, detects the architecture, and pushes the result when you run /sync.

Pull sources are everything else. You point at the content — a Confluence space, a pasted note — and we fetch it, then use AI to extract architectural structure into nodes and edges. You bring the source; we do the interpreting.

The practical takeaway: if you have a codebase, push it with Cartograph — the structure comes straight from the code, no interpretation guesswork. For docs, tickets, and prose, pull sources read and map them for you.

The source catalog

These are the sources you can add today, grouped by family.

Quick-add sources need no setup — paste and go. Providers connect once via OAuth, then you pick the pages, spaces, or projects to bring in. See Quick-Add Sources and Provider Sources for the details of each.

Coming soon

These are on the way but not yet addable. You'll see them in the picker when they ship — don't expect a working add flow until then.

Binding sources to boards

Binding is where a catalog source meets a board. Every binding has a role that decides whether the source shapes the board or just informs it.

Governing sources are the ones building your diagram. Reference sources are the supporting cast — extra context that informs answers and insights without ever redrawing the board.

So a typical board might be governed by Cartograph (the code) plus Confluence (the docs), with a couple of Jira projects and a Note bound as reference. That's a fully wired board.

How a source syncs

Once a source is governing a board, it moves through five states. Watching this lifecycle tells you exactly where a source is — and whether the board reflects the latest truth yet.

Pull sources are fetched and AI-extracted on a schedule — you set it up, and it stays current. Cartograph pushes on demand: the board updates when you run /sync in Claude Code, not before.

Source health

Every source carries a health status so you can tell a working source from a broken one at a glance.

Picking the right source

A few opinions to save you some trial and error:

• Got a codebase? Use Cartograph. Code-derived structure beats AI-extracted structure every time — it comes straight from the source of truth, not an interpretation of a doc that describes the code.
• Start a source as reference, promote to governing when you trust it. Bind it as reference first, see what context it adds to Chat and insights, then make it governing once you're confident it should shape the graph.
• Match the source family to the board's purpose. A code-architecture board wants Cartograph; a decisions-and-process board wants Confluence, Notion, or Jira. Mixing reference sources across families is fine — that's the whole point of context.

What's next