The shape of the problem
Your team has already written most of what your agents need. The trouble is the writing lives in seven places — a docs repo, a Notion workspace, a few README files, a wiki nobody has updated since the last reorg, the standing-meeting notes from October. A source is how you tell Ship "this is one of those places — keep an eye on it." From there, the imports flow into the review queue, get a topic and a bucket assigned, and become articles your team and your agents read from the same page.
You manage sources in the Import sources panel on the Knowledge page. Each importer shows its name, type, status, and when it last ran (with the error if a run failed), and you can add a new source or trigger an on-demand run. Adding a source creates the importer and immediately runs it so your corpus starts populating.
What you can connect
The Add import source picker lists the importer types your engine offers — typically a GitHub docs repository, a web page or sitemap, a file upload, and connectors such as Notion or Confluence. The available types come from your workspace's Lighthouse engine, so the exact list can grow over time.
- A GitHub docs repository. The most common shape. If your team already keeps standing notes in
docs/alongside the code, point Ship at that repo. The system watches the default branch and pulls changed files on a schedule. Every change still passes through a reviewer. - A web page or sitemap. A public reference, a status page, a vendor docs site that has the canonical answer your team keeps quoting. Add the URL, and every meaningful change becomes a new draft for review.
- A file upload. A one-off document you want in the corpus without standing up a repo or feed.
- A connector such as Notion or Confluence. When the canonical text lives in a wiki your team already maintains, connect it directly as its own importer type.
The destination — an article in a reviewed bucket — is the same regardless of where the text came from.
What gets recorded
Every imported document carries its provenance. We record the kind of source, the URL or file path it came from, the time it was fetched, and the route that brought it in. This metadata stays attached to the article forever. When an agent cites the article in a piece of work, you can follow the citation back to the source and ask "is this still true?" Six months from now, when somebody asks where a rule came from, you do not have to remember — the article remembers.
Scheduled refresh, on your cadence
Sources refresh automatically on a recurring schedule, and you can trigger an on-demand run from the Import sources panel at any time. A vendor docs page that changes once a quarter does not need a manual nudge often; a docs repo where your team works daily keeps itself current on its own.
Every refresh that finds a change opens a new draft. Every refresh that finds nothing closes quietly. A successful refresh is allowed to produce zero work. If nothing changed upstream, no draft appears, no reviewer is interrupted, no agent gets a fresh fact it did not need. The schedule buys you the option to learn something new — the rest of the time things stay calm.
Authoring inline still works
You do not need a source to write knowledge. You can author articles directly in the web interface, paste in a markdown file, or have an agent suggest one as part of its work. Imported sources cover the bulk of what teams want to bring in — they let you adopt Ship without re-typing five years of accumulated notes. But the single-page article you write at 3 p.m. on Tuesday because someone asked the same clarification three times is just as valid a piece of knowledge as anything that came from a repo.
What stays out
Some text does not belong in knowledge, no matter where it came from.
- Secrets and credentials. The system declines to take in API keys, tokens, or password-shaped strings.
- Customer data. Tickets, names, anything that should not leave your tracker. Sources that contain customer data should be filtered upstream before the page goes into Ship.
- In-flight debate. Pull request reviews, Slack threads still being argued. Wait until the decision is settled before turning it into an article — that is what the distiller and review path is for.
Sources are the door into your knowledge base. They are not a magic vacuum cleaner. Choose them deliberately, watch their freshness on the Knowledge page, and prune the ones that stop being useful. Your team will be reading the result every day.