Project
A connected codebase in Specsight, scoped to one organisation. Every feature, scenario, and changelog entry belongs to exactly one project.
A project is the unit of analysis in Specsight. You connect a GitHub or GitLab repository, give it a name, and Specsight produces a spec for that single codebase: features, scenarios, connections. Most teams start with one project per product.
Projects belong to an organisation, and roles (Admin, Developer, Editor, Viewer) are set once, at the organisation level, so every member sees every project. Plan limits split two ways: monthly allowances for analyses, syncs, digests, and release notes count across the whole organisation, while the codebase ceiling (source-file count and repository size) applies per project.
Multi-repo products work as multiple projects today: one for each service, each with its own spec. Native multi-repo projects, where one spec is drawn from several repositories, are on the roadmap.
Related terms
- OPERATIONS
Organisation
Your company workspace in Specsight. Every project, member, scenario and digest lives inside one organisation, and billing is set at this level.
- SPEC
Feature
A logical grouping of scenarios that represents a meaningful unit of the product, like “Document Upload” or “User Authentication.” features form the structure of a Specsight spec.
- SPEC
Scenario
A single plain-language description of how a product behaves in a specific situation. The atomic unit of a Specsight spec.
- OPERATIONS
Sync
The release-triggered update to a Specsight spec. Fires automatically every time code lands on the tracked branch, touching only the scenarios that release changed.