Dependencies

Most creative work doesn't exist in isolation. A Lighting task depends on Animation. Animation depends on a Character Rig and an Environment. The character rig depends on a Model, Textures, and Materials.

Clustta records these relationships in the project. Linked dependencies connect assets to the files they need and make those files available to the collaborators assigned to the work.

Why dependencies?

Without dependency tracking, granting an artist what they need to do their work is a chore:

• "I'm assigning you the Lighting task. You'll also need: the animation file, the rig, all the textures..." (around 20 items)
• The artist has to ask repeatedly for missing pieces.
• When the rig updates, no one knows which downstream shots are affected.

Dependencies fix all three problems.

What a dependency is

A dependency describes a relationship between assets, or between an asset and a collection. A linked dependency means the asset needs the referenced files to be available for its work or delivery.

Dependency relationships are stored in the project database - they're real metadata, not folder conventions.

Creating dependencies

Several ways:

• Drag and drop - In the browser, drag one asset over another and it registers it as a dependency.
• From the asset details pane - Add or remove dependencies from the dependency section.
• From an asset row or card - Open the dependency graph using the dependency quick action.
• From the dependency graph - Use the searchable picker beside the graph to find and add an asset or collection without leaving the view.

You can also drop a collection over an asset to add the entire collection as a dependency - useful for "this character depends on the entire textures collection".

The browser creates linked dependencies. Links between assets can also specify which checkpoint to use. Linked collection dependencies bring a group of assets into the graph.

Choosing a dependency version

Dependencies can follow the latest checkpoint, remain pinned to a specific version, or follow a checkpoint tag such as approved. Use the latest version when you want to receive ongoing updates. Pin a checkpoint when a shot or deliverable needs a stable input. Tags let the upstream artist decide which checkpoint is ready for others to use.

Selection	Behavior
Latest	Resolves to the dependency asset's latest checkpoint. The API calls this floating.
Pinned	Keeps the exact checkpoint selected for that dependency. New checkpoints do not change the pin.
Tag	Uses the checkpoint currently carrying that tag on the dependency asset. Moving the tag changes the version this dependency resolves to.

Open the searchable version selector on a dependency node to choose Latest, an available checkpoint tag, or an individual checkpoint. The selected option is shown on the node. Changing a selector requires permission to manage dependencies. A Fix selector warning means the selected checkpoint or tag cannot currently be resolved and must be replaced.

Tags are shared project labels, but each asset has its own checkpoint assignment for a tag. See Checkpoints & Versioning for assigning and moving them. Selector and tag changes travel through project sync; changing a selector does not itself replace a working file.

Building with dependencies

Choose Build with dependencies from an asset's context menu, or press Ctrl+Shift+F (Cmd+Shift+F on macOS). Clustta resolves the linked dependency graph and shows the exact checkpoints it will restore, including downloads, conflicts, and locally modified files.

Review the plan before selecting Build. Conflicting requirements must be resolved first. Locally modified files require the Overwrite locally modified dependency files confirmation; checkpoint any work you need to preserve before allowing replacement.

Clustta downloads missing chunks and restores dependencies before the assets that use them. If requirements change after the preview was opened, the build is rejected so you can review a fresh plan.

Visualizing dependencies

For remote projects, users with permission to manage dependencies can open an asset's dependency graph view. The graph:

• Shows the asset and its direct dependencies by default.
• Displays asset or collection type, selected version, assignee, and status where applicable.
• Surfaces unresolved selectors and other dependency warnings on the affected node.
• Provides node actions to navigate to an item, assign an asset where permitted, change its version, or remove the relationship.
• Includes a fit-view action for recentering the graph.
• Provides a Full graph toggle to expand recursively and show transitive dependencies.
• Opens a searchable dependency picker beside the graph for adding relationships in place.

The graph and details pane represent the same project relationships. Changes made in either place appear in the other.

Compatibility with older studios

Versioned dependency selectors require the versioned dependencies capability provided by API v2. When connected through API v1, basic dependency relationships continue to work, but Latest, checkpoint, and tag selector controls are unavailable.

Update both Clustta Desktop and the Studio server to use version selectors. See Project Compatibility for details.

Recursive resolution on assignment

When you assign a task to a collaborator, its linked dependencies are made available to that collaborator. Resolution follows linked relationships recursively, including linked collections, so the collaborator can access the files needed for the task.

Example, with every relationship below using the linked type:

Lighting (assigned to Adaeze)
|-- Animation                            <- auto-granted
|   |-- Character Rig: Jako               <- auto-granted (transitive)
|   |   |-- Model: Jako                   <- auto-granted
|   |   \-- Textures: Jako Skin           <- entire collection auto-granted
|   \-- Environment: Carpenter Shop       <- auto-granted
\-- FX                                   <- auto-granted
    \-- ...

Adaeze receives access to the linked inputs needed for Lighting, including the rig's own dependencies.

Dependency types

Clustta defines four built-in dependency types: linked, waiting on, blocking, and working.

Currently, only linked dependencies are used to resolve asset access and deliverability: they identify the files collaborators need to receive and build alongside an asset. A linked relationship in Clustta does not itself insert a reference into a Blender or Maya scene.

Waiting on, blocking, and working are intended for assignment and status workflows. They are not currently used to resolve file access or delivery, and should not be treated as automatic assignment or status rules. Use linked when an artist needs another asset's files.

Dependency types describe the relationship. Latest, Pinned, and Tag describe which checkpoint a linked asset dependency resolves to; they are separate settings.

Removing dependencies

Use the remove action on a dependency node, or remove the relationship from the asset details pane.

Removing a dependency does not revoke access to anyone who is currently assigned to the parent - they keep what they've already pulled. Future assignments use the new graph.

Best practices

• Model real relationships, not folder structure. A texture isn't a dependency of a character just because it lives in the character's folder - it's a dependency because the character's material uses it.
• Use collection dependencies for groups. A Lighting task doesn't need to depend on each of 30 individual cowry textures - depend on the Cowries Textures collection instead.
• Don't be afraid of deep graphs. The recursion handles it. The deeper your model, the more automatic your handoffs.