Last updated July 20, 2026
Sources
Architecture diagrams rot fast when they're disconnected from reality. Sources are how your boards stay grounded — they connect to the actual systems, repos, and documents that your architecture describes.
Prerequisites
- Workspace created with at least one board
- Integration credentials configured at the org level (for OAuth sources)
- Access to the external system you want to connect (repo permissions, Confluence space access, etc.)
How sources work
Sources live in a workspace-level catalog. Each source is registered once, then bound to one or more boards. The same Confluence space can feed multiple boards without being imported twice.
Source families
Every source falls into one of three families. The family tells you how it connects and how it gets content onto the board.
A push source: the plugin does the analysis on your machine and pushes a finished graph — nodes and edges — straight to the board. No AI extraction on the platform side. The binding is two-way: it also carries the platform's build context (compiled skills, intents, aspect contracts) down into the repo for /build and /intents to implement.
| Source | Auth | What it brings |
|---|---|---|
| Cdx Code | Boards API token + secret | A code-derived graph pushed from your repo via Claude Code, Codex, or Cursor |
For the complete catalog and how each reaches the board, see the Sources Overview.
Source roles
Every binding plays one of two roles. The role decides whether the source shapes the board or just sits next to it.
Governing sources must all share one type — but you can have more than one. Reference sources are unlimited.
The sources that drive the board: its nodes and edges are built from them.
| How many | One or more — all governing sources on a board must share one type (Cdx Code / Cdx Work are exempt) |
| What it does | Creates and updates nodes and edges |
| Syncs to the board | Cdx Code / Cdx Work push on demand via /sync; document sources update the board only when you rebuild from them in Chat |
| Good fits | Cdx Code (code-derived) output, or a primary provider like Confluence, Jira, or Notion that should shape the board |
| Typical example | "Cdx Code analyzes the payments-service repo and governs the Payments board — when services get added, they show up automatically." |
A board's governing source is fixed to one source type (e.g. all Confluence, or all Jira). Add another governing source, and it has to match that type — the ContextDX plugins (Cdx Code and Cdx Work) are the one exception, they can coexist with any type.
A governing Code Plugin binding does one more thing: it turns the board into an app board — one board, one repo, with its own hub. Two rules come with that: a board can take only one governing Code Plugin binding, and a board inside an app board can't take one at all. App boards can't nest — the bind option is replaced with a note pointing to the app board above.
Start with reference. If you find yourself wishing that source shaped the board's structure, switch it to governing.
Sync states
A governing plugin binding (Cdx Code / Cdx Work) carries one of two states — it's unsynced (newly bound, nothing pushed yet) or synced (the board reflects the source's current state). Document bindings carry no sync state: Chat reads them on demand, and a governing document reshapes the board when you ask Chat to rebuild from it. Reference bindings don't sync either.
For whether the source is reachable and behaving, see Health tracking below — that's a separate signal.
Health tracking
Each source carries a health status:
- Healthy — Accessible and syncing normally
- Degraded — Accessible but experiencing issues
- Failing — Not accessible or sync is broken
Governing sources are your "single source of truth" for a board. Reference sources give chat extra context without changing your diagram. When in doubt, start with reference and switch to governing once you trust the data.