Connecting Sources

Architecture that drifts from reality is worse than no architecture at all. Sources are how you anchor your boards to actual code and docs — so your views stay current as systems change.

Prerequisites

Before connecting sources, make sure you have:

• A workspace set up with at least one board
• Admin or editor permissions on the workspace
• OAuth connectors configured (for provider sources like Confluence, Notion, Jira)
• Or just a URL or text to paste (no setup needed for Web URL and Note)

How sources work

Sources live in a workspace-level catalog. You register a source once, then bind it to one or more boards. Each binding defines the source's role; plugin bindings also track their own sync state independently.

Adding your first source

The fastest way to get started depends on what you have:

Source types

Available today:

Coming soon:

Binding sources to boards

Once a source is in your catalog, bind it to a board:

1. Open a board → click the Sources panel
2. Click Bind Source → select from the catalog
3. Choose a role:

Reference bindings are the board's context library: chat reads them on demand, whole-document — pin the sources a conversation should use, or let chat pull any bound document (a PRD, an ADR, a runbook) into the conversation while it works. It can even draft a spec from one, with your confirmation.

The sync workflow

A governing plugin binding (Cdx Code / Cdx Work) tracks a simple state: unsynced when newly bound, synced once a push has been applied to the board — each with its own timestamp, so you always know what's current. Document sources carry no sync state: Chat reads them on demand, and a governing document shapes the board when you ask Chat to build or refresh from it. Reference bindings don't sync either; their content is read on demand.

Source health

Each source carries a health status:

A failing source doesn't break your board — it just means the data may be stale.

Build-from-code sources (Cdx Code)

Cdx Code (and the VS Code / JetBrains plugins) analyze your application code locally and push a ready-made graph — nodes and edges — straight to your board through the Boards API. Instead of pulling and interpreting content remotely, the plugin does the analysis on your machine and pushes the finished result.

When to use build-from-code

These sources authenticate with a Boards API token + secret rather than OAuth. Use this when:

• You want code-derived architecture — analysis that reads your actual codebase structure
• You need incremental updates tied to git diffs, not full content re-extraction
• You'd rather keep analysis local and push the result than hand source content to the platform

See the ContextDX Plugins to install and run them, and the Boards API reference for payload shape and auth.

Troubleshooting

Source shows "failing" health status

Cause: The external service is unreachable or the OAuth token has expired.

Fix:

1. Go to Settings → Integrations and check if the connector is still connected
2. If expired, click Reconnect to re-authorize
3. Return to Sources and check if health updates to healthy

Governing source bound, but nothing appears on the board

Cause: Building a board from a document source happens through Chat, which needs a connected model provider.

Fix:

1. Make sure a model provider (e.g. OpenRouter) is connected for your workspace
2. Ask Chat to build the board from the source — it reads the document and generates the structure

What's next