Sources Overview

A source is code, docs, tickets, notes, or a URL that gives a board real system context.

This page covers the catalog, binding rules, and freshness signals. For setup, see Connecting Sources.

What a source is, and where it lives

Register a source once in the workspace catalog, then bind it to any board that needs it. The catalog is the inventory; binding attaches a source to a board.

There is no top-level Sources nav item. Open the catalog from a board: either the bind dialog's catalog picker or the hub's Bindings card.

The catalog

The Add Source menu has three groups.

Every connector is listed in Settings → Connectors with Coming soon today; none can be authorized or browsed yet. The one live connector, the model provider, powers Chat rather than adding sources. Provider Sources describes what the connectors will bring.

Expand

1. 1

   Quick add — paste something

   A Note or Web URL, with no OAuth or configuration.

2. 2

   From your code — push a graph

   The Code Plugin sends a finished graph from the repo instead of extracting one from prose.

3. 3

   Import from a connector

   Provider sources are coming soon. You cannot authorize or browse these accounts yet.

Quick add

Quick-add sources need no OAuth, token, or configuration: paste and save.

Both are pull sources. You provide content; the platform extracts context.

Web URL

Use Web URL for engineering write-ups, vendor docs, internal wiki pages outside Confluence, or ADRs on a static host.

Choose Web URL, paste the address, give it a title, and save. The platform makes extracted concepts available to Chat and insights.

Note

Use Note for context that is not in a formal document: meeting recaps, Slack-thread summaries, standup decisions, or copied text from a PDF.

Choose Note, paste markdown or plain text, and save.

Push and pull

Sources differ by where processing happens.

The code plugin pushes. It analyzes your repo locally and sends structured nodes and edges. The same binding lets the plugin pull board build context back into the repo.

The connect plugin grounds. It checks an authored board against a document repo, links evidence, and reports drift. The connect plugin has the details.

Everything else is pulled by the platform. The platform fetches the content and extracts structure. Chat reads it on demand and can build nodes and edges from governing documents when you ask.

Governing and reference — how many you get

Every binding has a role. A governing source shapes the board: it creates or updates nodes and edges, participates in sync, and can conflict with another governing source. A reference source is read-only context for Chat and insights.

Rules:

• A board can have more than one governing source, but they must share a classification: all Confluence, or all Jira; not a mix.
• Code Plugin sources are exempt from that match. A Code Plugin source can govern alongside sources of any other type. It contributes structured code analysis rather than document interpretation.
• Exactly one governing Code Plugin binding is allowed per board. That slot is exclusive, and filling it makes the board an app board: one app, one repo.
• Reference bindings are unlimited. Any type, any number, read-only, and they never cause a sync conflict.

When provider sources ship, a board could have the code plugin and Confluence as governing sources, with Jira projects and a Note as references.

Reference reading is on demand and whole-document. Chat can use a bound PRD, ADR, or runbook, and with your confirmation can draft intents from it.

Is it current?

Two signals answer this. On the canvas, a binding indicator shows Synced, Not synced, Collecting, Indexing, or Checking. On the hub, each binding has a pulse: live (data arrived in the last day), quiet, dormant, or never. App Boards & Hubs covers the hub's Bindings card.

Neither signal is a live monitor. When a board looks stale, check the pulse first. A dormant plugin binding usually means the plugin stopped running. Once provider sources ship, a dormant connector binding may also need reauthorization.

Picking the right source

• Got a codebase? Use the code plugin. The GitHub connector will read repo text for READMEs and docs, not map architecture.
• Start as reference, promote later. Bind as reference first, then make it governing once you trust it.
• Match the source family to the board. Code architecture usually needs the code plugin. Decisions and process usually live in documents — a Web URL, a Note, or a document repo through the connect plugin, and Confluence, Notion, or Jira once those connectors ship.

Where to go next