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 will see your sources on the Knowledge page. Each row shows what it is, how it is doing, when it was last pulled in, and what to do next. In the reference workspace a typical row reads DOCS_REPO · ready · 5h ago · Archive — the kind, the health, the freshness, the next action.
What you can connect
Three shapes cover almost everything teams actually maintain.
- 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 set of pages. A public reference, a status page, a vendor docs site that has the canonical answer your team keeps quoting. Add the URL, pick a refresh cadence, every meaningful change becomes a new draft for review.
- Local markdown in the repo's
.ship/knowledge/folder. For teams that want to author knowledge as code. Files committed there flow through the same review path as anything written in the web interface.
You will hear other shapes mentioned — Notion, Confluence, internal wikis — and most connect through one of the three above. 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 on a schedule you set. A vendor docs page that changes once a quarter does not need to be polled every hour. A docs repo where your team works daily probably does. The default cadences are sensible — daily for repos, weekly for web pages — and you can change them per source from the source's row on the Knowledge page.
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 cadence buys you the option to learn something new — the rest of the time the queue stays 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.