Documentation Index
Fetch the complete documentation index at: https://docs.speckle.systems/llms.txt
Use this file to discover all available pages before exploring further.
What are models?
Models are containers for design data inside a project. Use separate models to keep ownership, review cycles, and version history clear. This page is for project owners and discipline contributors deciding how to split project content for day-to-day publishing.Why model boundaries matter
Model boundaries affect review clarity and troubleshooting speed. When one model mixes unrelated scopes, teams struggle to identify who owns changes and which versions should be promoted. Use separate models when teams differ by discipline, area, package, or release schedule. Keep related content together when people review and publish it as one unit.Split into separate models
Use when ownership, discipline, package, or release schedule differs.
Keep in one model
Use when same team reviews and publishes changes as one unit.
Create a model
A new project can start with no models. Create a model first, then publish versions into it. Use a model as a stable container. Versions carry the evolving design snapshots over time.Organize model names
Use model names that match your team structure. You can use/ in names to group related models, for example Building A/Floor 01.
Prefer naming conventions that help new team members predict where data should live.
If your team cannot agree where to publish, your naming structure is too ambiguous.
Work with versions
Clicking a model opens that model’s home page. Use this page to review model-level activity and publish new versions before opening specific version details.Model home page
The model home page surfaces model-level signals you need to coordinate work:- A current snapshot preview of the latest version.
- A drag-and-drop upload area to publish a new version directly.
- Version history for that model.
- Upload history for recent imports and publish events.
- Issues linked to that model.
- Data Validation KPIs for that model.
Next step
Read Versions for history and version workflows after first publish.FAQ
Can I label models as I do projects?
Can I label models as I do projects?
No. Project labels are a workspace-wide tag set for projects (see
Project labels). You cannot attach
that same label system to models inside a project today. Use model
names and path-style groupings with
/ (see
Organize model names) so models stay easy to scan
in the list.Should each discipline always have its own model?
Should each discipline always have its own model?
Not always. Split by discipline when ownership and release timing differ.
Keep one model when the same team reviews and publishes together.
Can I reorganize model naming later?
Can I reorganize model naming later?
Yes, but renaming late can break team habits and external references. Align
naming early to reduce migration work.
Do models affect permissions directly?
Do models affect permissions directly?
No. Access is controlled at project and collaborator level. Models help
structure content inside those access boundaries.
When should we create a new model instead of a new version?
When should we create a new model instead of a new version?
Create a new version for change over time in same scope. Create a new model
when ownership or scope boundary changes.