Production trackers are good at organising what the studio wants to see. Shots, assets, tasks, assignments, due dates, statuses, notes and reviews all need somewhere to live, especially when a project involves multiple departments, external vendors and a schedule that changes every week.

The trouble starts when the tracker is mistaken for the production system itself. A tracker may show that a task is in progress or approved, but those labels only mean something if they’re connected to the files, publishes, versions, reviewables and handoffs moving through the studio.

Without that connection, the tracker becomes a polished place for people to type updates about work that’s happening somewhere else. It may have better permissions than a spreadsheet, better review tools and better reporting, but the studio is still relying on people to keep the system aligned with reality by hand.

That’s why production tracking without a pipeline so often becomes a glorified spreadsheet. The interface improves, but the underlying problem remains. The work still depends on manual updates, naming habits, folder browsing, Slack messages and someone remembering what was last approved.

Tracking production is not the same as running production

Studios often compare AYON with tools like ftrack, Kitsu or Flow Production Tracking because they all sit near the same operational problem. They help teams organise production data and understand what needs to happen next.

That comparison is useful up to a point, but it can hide the more important distinction between tracking production and running production.

Production tracking gives the management view of the work. It helps a team see who’s assigned, what’s due, which status a task is in, what needs review and where feedback has been left.

Pipeline sits closer to the work itself. It handles the context an artist is working in, the application they launch, the workfile they save, the publish they create, the version that gets recorded, the review media that gets generated and the data another artist needs to load later.

These aren’t minor implementation details. They’re the difference between a status that has been typed in and a status that’s backed by something real.

A production tracker can tell a producer that modelling is approved. A pipeline can tell the studio which model version was approved, where it’s stored, what it contains, whether it passed the studio’s publishing rules and how rigging can load it without guessing.

Pipeline should not be an afterthought

Many tracking-first platforms provide APIs, webhooks, launchers, integration frameworks or other extension points. These are useful, especially for studios that already have experienced pipeline teams and a mature internal toolset.

The limitation is that extension points still leave the studio responsible for building the system artists actually work through. Someone still has to connect the tracker to digital content creation tools. Someone has to define the launch context. Someone has to manage workfile naming. Someone has to design the publishing workflow. Someone has to validate outputs, create review media, version data, connect dependencies and make published work available to the next department.

For studios with years of custom pipeline development, that may be an acceptable trade-off. The tracker becomes one part of a wider system built from internal tools, DCC integrations, naming conventions, publishing logic, farm submission, review automation and deployment processes.

For studios without that foundation already in place, a tracker can create a false sense of completeness. The team gets a clean task board, a review page and a central production database, while artists may still be saving files into shared folders, uploading review media manually, asking which version is current and relying on producers or coordinators to keep statuses up to date.

At that point the tracker is doing only part of the job. It’s organising information, but it’s not carrying the production workflow.

Manual work fills the gap

The practical problems tend to appear once production is underway. An artist uploads a playblast for review, but the source scene isn’t connected to the reviewable. A supervisor approves a version, but the downstream artist still has to ask which cache or render to use. A coordinator updates a task status because the publishing step didn’t do it. A lead checks a shared folder because the tracker shows a version, but not enough context to trust it.

None of this means the tracker is useless. It means the tracker is operating too far away from the production workflow.

When the tracker can’t answer which file was published, which version was reviewed, which output was approved and what the next artist should load, the team fills the gaps with Slack messages, spreadsheets, folder browsing, personal memory and informal habits.

That creates a hidden cost across the studio. The team isn’t only paying for a production tracker. It’s also paying for the time spent keeping the tracker, file system, review process and artist workflow aligned by hand.

The pipeline layer has to come first

It’s tempting to start with the production layer because it’s the part that looks useful to the widest group of people. Producers want dashboards, coordinators want task lists, supervisors want review tools and studio leadership wants reports.

Those things matter, but they become fragile when the data underneath them isn’t created by a consistent pipeline.

A production view is only reliable when the work feeding it is structured. The system needs to know the project, the asset or shot, the task, the artist, the host application, the workfile, the product, the version and the representation. It needs to know where files belong, how versions are created, how outputs are checked and how departments pass work to one another.

If that foundation is missing, production tracking depends on manual behaviour. Artists have to remember the correct naming rules. Leads have to police which version is current. Coordinators have to update statuses after the fact. Pipeline teams have to repair mismatches between what the tracker says and what exists on disk.

A stronger approach is to establish the pipeline base first, then let production tracking reflect what the pipeline knows. When publishing, versioning, review and loading are part of the same production context, the tracker stops being a place where people report progress from the outside and becomes a view into the work moving through the studio.

What happens between modelling and rigging

A character model moving from modelling to rigging shows why this distinction matters.

In a tracking-only setup, the modelling task can be assigned, scheduled, reviewed and marked approved. The tracker can hold notes, thumbnails, versions and feedback, which may look complete from a production management point of view.

From a pipeline point of view, several important questions may still be unresolved. The approved item might be a viewport playblast, a turntable, a Maya scene, a geometry cache or a manually uploaded file. The model may or may not have been published to a controlled location. The publish may or may not have followed the studio’s naming rules. The right checks may or may not have run before the output became available. The rigging artist may still have to ask which version to load.

A production tracker can record the approval, but the pipeline needs to make the approved output usable.

In AYON, the work is built around production context. The artist works inside a project, folder and task. Workfiles have a defined place. Publishes create products and versions. Published versions can have representations and reviewables. Downstream artists load published work through pipeline tools rather than browsing the file system and choosing what appears to be latest.

That structure becomes more important as the project grows. A small team can sometimes survive on naming habits and communication, while a larger team needs the system to carry those rules consistently.

How AYON approaches the problem

AYON is built around pipeline, production tracking, review and delivery belonging to the same production platform rather than separate systems that need to be stitched together later.

At the pipeline level, AYON gives the studio a shared context for projects, folders, tasks, workfiles, products, versions and representations. Artists use that context when launching applications, saving workfiles, publishing outputs and loading work created by other departments.

At the production level, the same context gives producers, coordinators, supervisors and leads a clearer view of what’s happening. Tasks, comments, statuses, versions, reviewables and activity aren’t just separate records in a tracking system. They’re connected to the work artists are creating and publishing.

This is the practical meaning of saying AYON has a pipeline foundation. It’s not only a tracker with some integrations around the edges. It’s designed so the production layer can sit on top of pipeline data instead of asking people to manually describe the pipeline from outside it.

AYON also gives studios room to adapt the system to their own reality. Project anatomy, roots, templates, folder types, task types, statuses, applications, tools and publishing behaviour can be configured around the way the studio works. The goal isn’t to make every studio identical, but to give each studio a consistent base for managing work, versions, review and handoff.

Uploading a file is not the same as publishing

A common source of confusion is the difference between uploading media and publishing production data.

Uploading a file can be useful for review. A supervisor can watch it, comment on it and approve it. For some lightweight workflows, that may be enough.

Publishing has a different purpose. It creates a structured, versioned output that belongs to a known project, folder, task and product. It follows the studio’s naming and storage rules. It can create review media as part of the process. It can be loaded by other artists. It can carry relationships and metadata that help the studio understand where it came from and how it should be used.

This distinction matters because review isn’t the same as production handoff.

A manually uploaded playblast may show what the artist wants feedback on, but it doesn’t automatically prove that the correct cache, scene, render, rig, plate or model has been published in a usable form. A proper pipeline publish gives the studio something that can be tracked, reviewed and used downstream.

Spreadsheets reveal where trust has broken down

Studios will always use spreadsheets for some things because they’re quick, flexible and familiar.

The problem isn’t the existence of spreadsheets. The problem is when a spreadsheet becomes the source of truth because the production platform can’t answer basic production questions on its own.

If production needs a spreadsheet to know what’s ready, the tracker isn’t close enough to the work. If artists need Slack to find the latest version, the pipeline isn’t carrying enough context. If supervisors need to ask which file was reviewed, review isn’t tied tightly enough to publishing. If pipeline TDs spend their time reconciling tracker data with files on disk, the studio is paying a hidden tax on every department handoff.

A spreadsheet appearing in the middle of production often means the team doesn’t fully trust the system. It’s where people put the information they can’t reliably get from the tracker, the file system or the review process.

The better question isn’t whether the studio can avoid spreadsheets entirely. It’s why the spreadsheet is needed in the first place.

What to ask when comparing production platforms

When evaluating a production platform, dashboards, task boards and review pages matter, but they don’t prove that the platform can support production from the artist’s desk to final delivery.

The more revealing question is what happens when an artist actually does the work.

1. Can the artist launch the right application in the right project and task context?

2. Can the system save workfiles into predictable locations without relying on manual naming?

3. Can publishes be validated before they become available to the rest of the studio?

4. Can the platform create versioned products rather than loose uploads?

5. Can review media be tied back to the published output it represents?

6. Can downstream artists load the correct version without browsing folders or asking in chat?

7. Can production see progress based on real pipeline activity rather than manual status updates?

8. Can the studio adapt naming, storage, publishing and review rules without rebuilding the whole system around the tracker?

These questions expose the difference between a tracker that organises production information and a platform that helps run production work.

A good dashboard can make a project look controlled, but it won’t fix broken handoffs between modelling and rigging, animation and lighting, or lighting and compositing. The pipeline has to carry the context, versions and relationships that make those handoffs reliable.

Production tracking is valuable, but it should not stand alone

Production tracking gives studios structure. It helps people plan work, assign tasks, collect feedback, monitor progress and communicate across departments. No serious production platform should ignore that layer.

The problem is treating production tracking as the whole system.

When production tracking sits without a pipeline foundation, the studio still has to ask people what happened. It still has to trust manual updates. It still has to reconcile statuses with files on disk, reviewables in the player, notes in chat and publishes created elsewhere.

AYON takes a different approach by putting the pipeline foundation underneath the production view. Artists create, publish, review and load work in a shared production context, and production tracking can then reflect what’s moving through the studio.

A tracker can record that a shot or asset was approved, but a pipeline-aware platform can show what was approved, where it is, which version it is, how it was created, and what the next department can use. That’s the difference between tracking production and running production.

Questions studios ask about production tracking and pipeline

How is AYON different from ftrack, Kitsu or Flow Production Tracking?

Tools like ftrack, Kitsu and Flow Production Tracking are commonly used to organise production data, tasks, statuses and review workflows. AYON is different because it starts with the pipeline foundation, including context, workfiles, publishing, versioning, loading and integrations. Production tracking then connects to that same production data.

Does AYON replace a production tracker?

AYON includes production tracking, but it’s not only a tracker. It connects production tracking with pipeline, review, planning and delivery. Some studios may use AYON as their central production platform, while others may connect it to existing systems during transition or integration.

What does pipeline-first mean?

Pipeline-first means the system starts with how work is created, saved, published, versioned, reviewed and loaded. The production dashboard is then built on top of real production activity, rather than relying only on manual status updates.

Why is uploading review media not the same as publishing?

Uploading review media gives the team something to look at. Publishing creates a structured, versioned output that can be tracked, reviewed and used by downstream departments. A playblast upload can support review, but it doesn’t replace a controlled pipeline publish.

Can a tracker with an API become a pipeline?

It can become part of a pipeline, but the studio still has to build and maintain the missing layer, including DCC launch, context, workfiles, publishing, validation, versioning, review generation, loading and deployment. AYON gives studios that foundation as part of the platform.

Why does the pipeline layer need to come before production tracking?

Production tracking depends on trustworthy data. If artists are working outside the system and people update the tracker manually, the production view can drift from reality. A pipeline foundation makes the work structured first, so the production layer can reflect what’s actually happening.