Sources

Sources connect a board to code, documents, tickets, URLs, and notes.

This page explains the concept. Sources Overview lists source types. Connecting Sources covers setup.

A source is something a board learns from

Register a source once in the workspace catalog, then bind it to as many boards as need it. A source can be a repo, a document repo, a URL, or a pasted note; provider connectors such as Confluence are coming soon.

The catalog is the inventory; a binding connects one source to one board.

Push and pull

Sources differ by who reads the material.

The code plugin pushes. It analyses your repo on your machine and sends a finished graph: nodes and edges, already structured. Nothing is interpreted on our side because the analysis happened before anything arrived.

The connect plugin grounds. It does not build a board. It takes a board an architect already authored and checks it against the PRDs, RFCs, and ADRs in a document repo, linking evidence and reporting drift. It uses the same install mechanics as the code plugin but does a different job; see the connect plugin.

Everything else is pulled. You provide the content location. We fetch the content, and chat reads it on demand. Where a document governs a board, it can build nodes and edges from that document.

Governing and reference

Every binding is either governing or reference.

A governing source creates and updates the board's structure. It participates in sync and can conflict with another governing source over the same element. Bind the source you'd trust to redraw the board.

A reference source is context only. It never redraws anything and never causes a sync conflict. Chat and insights read it on demand.

Reference is where most material belongs: ADRs, RFCs, Jira tickets, vendor docs, and runbooks. With your confirmation, chat can draft intents from reference material and name the source document.

Reference bindings are unlimited. More than one governing source is allowed only in specific cases, including a classification match and a Code Plugin exemption. Sources Overview states the rules.

Binding a repo makes an app board

One governing Code Plugin binding turns a board into an app board: one board, one repo, with its own hub, aspects, intents, and compiled skills.

Two rules come with that slot: a board takes exactly one governing Code Plugin binding, and a board inside an app board cannot take one. App boards do not nest, so on a board beneath one, the bind option is replaced with a note pointing at the app board above it.

Is it current?

Two signals answer that, and they sit in different places: a sync badge on the canvas binding indicator, and a binding's pulse on the board's hub. Sources Overview explains what each value means and which one to read first.

Where to go next