> ## 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.

# Models

> Organising your data in Speckle

## 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.

<CardGroup cols={2}>
  <Card title="Split into separate models" icon="code-branch">
    Use when ownership, discipline, package, or release schedule differs.
  </Card>

  <Card title="Keep in one model" icon="cube">
    Use when same team reviews and publishes changes as one unit.
  </Card>
</CardGroup>

## 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.

Some sections are dynamic and appear only when that content exists (for example, Issues or Data Validation results).
For current validation guidance, see [Validate your data in Speckle](/analytics/data-validation/overview) and [Viewing Results](/analytics/data-validation/viewing-results).

## Next step

Read [Versions](/workspaces/versions) for history and version workflows after first publish.

## FAQ

<AccordionGroup>
  <Accordion title="Can I label models as I do projects?">
    No. **Project labels** are a workspace-wide tag set for **projects** (see
    [Project labels](/workspaces/projects#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](#organize-model-names)) so models stay easy to scan
    in the list.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="Can I reorganize model naming later?">
    Yes, but renaming late can break team habits and external references. Align
    naming early to reduce migration work.
  </Accordion>

  <Accordion title="Do models affect permissions directly?">
    No. Access is controlled at project and collaborator level. Models help
    structure content inside those access boundaries.
  </Accordion>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>