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 goes from bound to synced. 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 the ContextDX plugins — Cdx Code for a codebase, Cdx Work for a document set — running locally in your editor: each reads its source, detects the structure, and pushes the result when you run /sync. The channel runs the other way too: the same binding pulls the platform's build context down into the repo — compiled skills, architect intents, aspect contracts — which the plugin implements with /build and /intents.

Pull sources are everything else. You point at the content — a Confluence space, a pasted note — and the platform fetches it; Chat reads it on demand, and when a document governs a board, it builds the nodes and edges from it when you ask. You bring the source; we do the interpreting.

The practical takeaway: if you have a codebase, push it with Cdx Code — the structure comes straight from the code, no interpretation guesswork. For docs, tickets, and prose, Chat reads and maps them for you on request.

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 Cdx Code (the code) plus Confluence (the docs), with a couple of Jira projects and a Note bound as reference. That's a fully wired board.

Reference reading is on demand and whole-document: when you ask Chat something, you can pin the sources it should use, and it can pull the full content of any bound document — the payments PRD, an ADR, a runbook — into the conversation as it works. Chat can even draft a spec from one ("draft a spec from the payments PRD"), with your confirmation before anything is created.

How a source syncs

Once a plugin source (Cdx Code / Cdx Work) is governing a board, its binding carries one of two states. Watching it tells you whether the board reflects the latest push yet.

Document sources carry no sync state — Chat reads them on demand, and you build or refresh a board from a governing document by asking Chat to do it (a connected model provider is required). Cdx Code pushes on demand: the board updates when you run /sync in your editor, not before. Reference bindings never sync — their content is read on demand instead.

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 Cdx Code. 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, switch it 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 Cdx Code; 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