Explore

Project directory structure

Goal

A good Soko project structure should make it easy to:

navigate quickly (artists, supervisors, producers),

scale from small to large teams and from one title to many episodes,

keep dependencies traceable (what feeds what),

enforce consistency (naming, templates, outputs, statuses),

support vendors and permission boundaries when needed.

Soko supports multiple valid structure patterns. The “best” choice depends on team size, number of episodes, external vendors, and how your departments collaborate.

1) Separate “Scope levels” (what the work belongs to)

Animation pipelines typically have at least these scopes:

Show / Project-wide (e.g., global references, tech docs, standards, style guides)

Episode / Reel / Segment (or “Unit” in a feature film)

Sequence (story/scene grouping)

Shot

Asset (character, prop, environment, rig, etc.)

Best practice: ensure your folder objects/types and task templates reflect these scopes.

2) Use templates + empty outputs to standardize expectations

Use Task Templates so every shot/asset/episode gets the same baseline tasks.

Use Empty Outputs so it’s always obvious what should be published where (preview, cache, render, final, etc.).

Keep templates few and stable. Prefer “one template + optional add-ons” over dozens of variants.

3) Keep naming predictable (for filtering, reporting, automation)

Use consistent codes

Use fixed padding and increments where possible (####, start at 10, step 10).

Avoid “freeform names” for high-volume objects like shots.

4) Make links explicit (dependencies)

Regardless of folder structure, downstream work must clearly reference upstream outputs:

asset → shot

shot → edit

edit → audio/post → master (timelines feed finishing)

Use task links so “Inputs” are visible and scheduling makes sense.

5) Keep statuses small and stable

⁠

Example use of statuses⁠

⁠

6) Top-level production container (recommended naming)

For animation and VFX, the main “production container” at the top level should use a name that matches how your team thinks and speaks. We recommend one of these three standard names:

SHOTS (universal for films and series) Use when the production is primarily shot-driven and you want a consistent structure across all show types.

EPISODES (clearest for series) Use when the episode is the primary planning and reporting unit (schedules, deliveries, reviews).

SEQUENCES (if sequence is your primary planning unit) Use when the sequence is the main organizational unit and the team naturally groups work by sequences first.

Note: These names describe the top-level container. Inside, you can still nest other levels (e.g., EPISODES → SEQUENCES → SHOTS).

Project structure patterns

Pattern A — Episode/Reel-centric structure (self-contained per episode/reel)

Best when: small-to-medium teams, limited external vendors, high need for context, you want each episode/reel/act to feel self-contained.

Summary

Work is organized primarily inside an Episode/Reel/Act container. Inside that container you keep:

Sequences → Shots

Episode-wide work (editorial, audio, post, approvals) in a dedicated “common” area

Recommended top-level (series)

PREPRO

ASSETS

EPISODES

Recommended top-level (feature film options)

Choose one depending on how your show is structured:

SHOTS (if you’re shot-driven)

SEQUENCES (if you plan by sequences)

REELS / ACTS (if editorial structure is primary)

Episode/Reel subtree (recommended)

Inside each episode/reel/act:

EPISODES

00_COMMON (generic folder)

SEQUENCES/ → SHOTS

Best practices

Use a dedicated 00_COMMON area folder for work that belongs to the whole episode/reel.

Keep 00_COMMON strictly for episode/reel-wide work (not shot/asset work).

Keep sequences/shots consistent and predictable under the episode/reel.

Use an Episode/Reel template that creates only episode/reel-scope tasks + empty outputs.

Use a Shot template that creates shot-scope tasks + empty outputs.

Don’t

Don’t model 00_COMMON as a “fake sequence” if sequences are expected to behave consistently (automation, metrics, templating).

Don’t spread episode-wide deliverables across multiple unpredictable places—keep a single “home” for them.

Pros

Best “one place per episode/reel” navigation.

Easy packaging/archiving/hand-off per episode/reel.

Strong context for supervisors and producers.

Cons

Department teams (editorial/audio/post) may need to jump across episodes.

Permission boundaries are harder if vendors need only a department slice.

Deep paths can happen—keep naming short and consistent.

⁠

Pattern B — Department-centric structure (separate Editorial/Audio/Post/Deliveries)

Best when: larger teams, multiple episodes, external vendors, strict permission boundaries, department managers want a single home.

Summary

Shots live under the production container (EPISODES or SHOTS), while department work lives in dedicated top-level areas. Episodes are mirrored across departments (e.g., EDITORIAL/EP01, AUDIO/EP01).

Recommended top-level (series)

PREPRO

ASSETS

EPISODES

EDITORIAL

AUDIO

POST

DELIVERIES (optional but common)

Recommended top-level (feature film)

PREPRO

ASSETS

SHOTS (or SEQUENCES)

EDITORIAL

AUDIO

POST

DELIVERIES

Best practices

Mirror episode naming across departments (EP01, EP02…), so navigation stays consistent.

Make linking mandatory: department tasks should pull inputs from shot/sequence outputs.

Keep DELIVERIES as the single source of truth for approved finals and official exports.

Use department templates and enforce output naming (so exports are consistent).

Don’t

Don’t duplicate the same “final” in multiple places; nominate one truth location (usually DELIVERIES).

Don’t let department work drift without links to upstream sources (you’ll lose traceability).

Pros

Scales well to many episodes and parallel departments.

Better for vendors and permissions.

Clear department ownership and onboarding.

Cons

More navigation across the tree.

Requires discipline (links, naming, templates).

Context can be lost if a user only lives in one department area.

⁠

Pattern C — Hybrid structure (common for growing productions)

Best when: you want episode/shot-centric navigation for production, but also want clean governance for finals and/or one or two departments separated.

Summary

Daily production stays inside your production container (EPISODES or SHOTS).

One or two critical areas (often DELIVERIES, sometimes EDITORIAL) are top-level for “single truth”.

Everything remains linked so traceability stays intact.

Best practices

Keep work-in-progress close to where it’s produced (episode/sequence/shot).

“Graduate” approved outputs into DELIVERIES.

Maintain strict naming and versioning conventions for deliverables.

This avoids reorganization as the project scales.

⁠

Implementation guidelines (applies to all patterns)

1) Choose your primary navigation axis

Pick one:

Production-first: EPISODES/SHOTS/SEQUENCES → (shots)

Department-first: EDITORIAL/AUDIO/POST → (episodes)

Everything else should support that axis rather than fight it.

2) Avoid “special-case objects” that break automation

If an object type (like “Sequence”) is expected to behave consistently across the project:

do not create exceptions (e.g., a “sequence” that is actually episode-wide common work). Use a generic folder.

3) Standardize outputs by intent, not by software

Across 2D/3D pipelines, these categories are universal:

Workfile (editable source)

Preview (reviewable)

Cache (handoff)

Name outputs by what they are (preview, cache, workfile) rather than tool-specific naming.

4) Keep template count low

Want to print your doc?
This is not the way.

Try clicking the ··· in the right corner or using a keyboard shortcut (

CtrlP

) instead.