Why we're careful about these words
Most teams burn a week of trust when a word like "project" means three different things on three screens. Ship is intentional about a small vocabulary so your team can talk about work in the same words the console uses. None of these are jargon you'll need a glossary tab for. They're the labels you'll see at the top of pages, in dropdowns, in PR comments, and in the audit log.
Workspace
A workspace is the boundary around one team or one product line. It holds the people who can act, the repos that have been connected, the tracker that holds priorities, the standing knowledge, and the dashboard you land on. You'll usually have one workspace per product. If you switch products you switch workspace, and the rules change with you.
Connected repo
A connected repo is a GitHub repository your workspace has been pointed at. The connection is a boundary, not an inventory. You might have twenty repositories in GitHub and three of them connected to Ship. Only those three receive PR comments, only those three have routines firing on them, only those three appear when AI looks for code. You can connect more later; nothing happens to a repo you haven't connected.
Tracker
The tracker is your team's source of truth for what matters and in what order — Linear, Jira, GitHub Issues, GitLab, or Azure DevOps. One per workspace. Ship reads from it ("what's on the board?"), writes to it ("here's a clarification on ticket 47"), and never invents priorities of its own. If the tracker says blocked, Ship treats it as blocked.
Inbox
The Inbox is where decisions queue up for you. Five kinds of cards land there: a clarification (Ship needs an answer before it can proceed), an approval (a human signoff is required), a failure (something tried to happen and stopped), an improvement (Ship spotted something worth doing), and an exception (something that doesn't fit the normal lane). The Inbox is not a notification feed. It is a list of decisions, and when you act on one it leaves.
Knowledge
Knowledge is the catalog of standing facts your team has agreed to reuse. The brand voice. The deployment checklist. The integration notes nobody wants to re-explain. The code style guide. Each fact lives in a labeled bucket, and AI consults the catalog when it works on your behalf. When a recurring question keeps showing up, the right answer is to write a knowledge entry, not to answer it again.
Project
A project in Ship is a tracker-native project (a Linear project, a Jira epic). It's where motivation, scope, constraints, and decisions live in one body of text. Child tickets stay short and point back at the project. When you ideate with Ship about a new initiative, the conversation lands as a project description — not as a long ticket and not scattered across chat.
Routine and specialist
A routine is a named job Ship runs against a connected repo — a security review, a daily digest, a developer pass on a ready ticket. Each routine plays a role for the duration of its run. That role is the specialist: the business analyst who shapes tickets, the developer who writes the code, the reviewer who reads it, the designer who looks at the interaction. Your team talks about "the daily security review." The engine sees a routine called security review running as a reviewer specialist. Both descriptions are right.
Evidence
Evidence is the trail Ship leaves behind. The ticket the change traces back to, the pull request the code lives in, the check that confirmed it works, the knowledge article that informed it, the human who approved the step. Evidence is the difference between "the bot did something" and "we decided, here's the proof, here's why."
These eight words show up everywhere and we use them consistently. The next page walks one morning end to end.