Skip to content
On this page

Sources Overview

A source is a repo, a document, a note, a web page or a Sentry project that gives a board real system context. You register it once in the workspace catalog and bind it to boards with a role; Connecting Sources has the steps.

What a source is, and where it lives

The catalog lists every source in the workspace, and a binding attaches one source to one board. Open the catalog from Sources Catalog in the workspace sidebar. On a board's hub, the Bindings card opens a picker over it.

The app's repo comes with the app: making a board an app registers its Code Plugin source and binds it as governing, and /login in the repo connects it. Designs, specs, decisions and errors around the app, you register and attach yourself as reference sources. Two kinds of source has the details.

The catalog

On the Sources Catalog page, the Add Source menu has two groups.

GroupSourceWhat it brings in
Quick addNotePasted markdown or text: a decision, recap, or short context note
Quick addWeb URLAny HTTP/HTTPS page. We fetch it and extract architecture context
Import from a connectorConfluence, NotionDocuments and pages from your own connected account, read when someone asks
Import from a connectorSentryA project, bound to an app board, whose new and regressed issues become insights

The menu lists connected providers first; Sentry sits under Show more connectors until it's connected. Not every connector is a source: Jira issues are read in chat and receive work items, Slack receives posts, and the model provider runs Chat. Provider Sources covers each provider.

Paste a note or URL, or import from a connected account.
  1. 1

    Quick add — paste something

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

  2. 2

    Import from a connector

    Browse a connected account and pick the pages, or the Sentry project, to add.

Code Plugin sources

A Code Plugin source is an app's repo, and you don't add one from the menu. Its Edit changes the name and description. Its row has no Delete; Remove app on the app's hub removes the repo binding and its source together.

Each app's repo is listed with the app it governs.
  1. 1

    App: and the app's name

    The source governs that app; the name opens the app's hub.

  2. 2

    Codebase type and push count

    The catalog lists each Code Plugin source with its codebase type and push count.

Quick add

Note and Web URL need no OAuth, token or configuration: paste the content or the address, give it a title, and save. Chat and insights can read it from then on.

  • Use Web URL for a page outside a connected tool: an engineering write-up, vendor docs, a wiki outside Confluence, or ADRs on a static host.
  • Use Note for context that isn't in a formal document: a meeting recap, a Slack-thread summary, a standup decision, or text copied from a PDF.

Push and pull

Sources differ in where the processing happens: on your machine or on our servers.

The code plugin pushes. It analyzes your repo locally and sends nodes and edges, and through the same binding it pulls board build context back into the repo. Its /ground command checks an authored board against a document repo, links evidence and reports drift (Grounding a board in documents).

We pull everything else. ProvenMap reads that content in chat on demand, and when you ask, it builds nodes and edges from governing documents. We fetch a connected document each time it is read, so the content is always current. Sentry is the one scheduled pull: every hour, for insights.

Where processing happens: the platform pulls, the code plugin pushes.

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. Making a board an app writes its governing binding; the Bindings card attaches reference sources only.

  • A board can have more than one governing source, but they must be the same type: all Confluence or all Notion, not a mix.
  • A Code Plugin source is exempt from that match and can govern alongside sources of any other type.
  • A board takes exactly one governing Code Plugin binding. Filling that slot makes it an app board: one app, one repo.
  • Reference bindings are unlimited, of any type, and never cause a sync conflict.
Governing sources shape the board; references are read-only context.

In chat, ProvenMap reads a reference source on demand, the whole document, and with your confirmation it can draft work items from it.

Is it current?

Each binding on the hub's Bindings card has a pulse: live (data arrived in the last day), quiet, dormant, or never. The canvas doesn't show freshness. When a board looks stale, check the pulse first: a dormant plugin binding usually means the plugin stopped running. When a binding breaks lists the fixes.

Picking the right source

  • Use the code plugin for a codebase. It maps the architecture from the repo itself; no connector reads repositories.
  • Match the source to the board. Decisions and process usually live in documents: Confluence or Notion pages, a Web URL, a Note, or a document repo through the code plugin's /ground.

Where to go next