export const meta = {
title: "Managing Growing Media Libraries with Tagging and Search Workflows",
description: "Learn how to tag and search growing post libraries with consistent metadata, NLE workflows, MAM triggers, saved searches, and scalable rules for reuse and delivery.",
tldr: "Manage a growing media library by designing metadata around the searches your team actually runs, not by adding random tags after files pile up. Use controlled fields for status, rights, versions, source, and delivery-critical data, while reserving flexible tags and notes for creative discovery such as shot type, subject, scene, and story use. NLE search is often enough for active edits, but a MAM or DAM becomes necessary when assets span many projects, departments, rights windows, storage locations, and reuse workflows. Keep the system scalable by assigning tagging stages, owning the vocabulary, using saved searches to expose gaps, and expanding with transcripts, AI tagging, and archive backfill only where they solve real retrieval problems.",
slug: "managing-growing-media-libraries-with-tagging-and-search-workflows",
publishedAt: "2026-06-09",
readingTime: 16,
thumbnail: "https://cdn.aspectlabs.dev/blog/managing-growing-media-libraries-with-tagging-and-search-workflows/cover.png",
authors: ["bright"],
primaryTopic: "post-production",
topics: ["post-production"],
tags: ["media-management"],
}
A media library becomes hard to use when your team can no longer predict how to find the right file. One editor searches for “wide lobby,” another searches for “establishing office,” a producer asks for “the hero shot from scene 12,” and the assistant editor knows it is somewhere on a shuttle drive named `BROLL_MISC_03`.
Build tagging and search workflows into post production before the library becomes difficult to navigate. The goal is reliable retrieval. An editor, producer, or finishing artist should be able to find the correct media without depending on memory, chat history, or the one assistant who logged the shoot.
## Start with real search behavior
Do not start your tagging system with a taxonomy diagram. Start with the way your team actually searches under deadline pressure, because a post team searches differently from an archive librarian. Editors may search by scene, character, shot size, camera angle, usable moments, and story function. Producers may search by campaign, client, approval status, rights, and delivery version. Technical directors may search by codec, resolution, frame rate, color space, source camera, and whether a file is original, proxy, graded, mixed, or final.
Build the first tagging model around the questions people ask while they are working. Your post library needs to answer searches such as:
- “Show me all usable aerial b-roll from the downtown shoot.”
- “Find the close-up of the product pour from scene 4.”
- “Which selects include the CEO and exclude the customer interview?”
- “Where is the approved 16:9 master with clean audio?”
- “Do we have slow motion exterior footage from day 2?”
- “Which music stems are cleared for paid social?”
- “Find the latest color-approved version and exclude offline exports.”
These examples are more useful than a general instruction to “add keywords,” because they show which metadata needs structure, which values you need to control, and which information can stay in free-text notes.
## Fields and tags
Libraries become unreliable when every piece of metadata goes into one tag field. That can work for a small personal library, but it breaks when multiple people start tagging. “Scene 12,” “approved,” “wide shot,” “Seattle,” “drone,” “do not use,” and “licensed until 2026” are different kinds of information, which means they need to behave differently in search.
Use [fields for metadata](https://cloudinary.com/documentation/assets_onboarding_metadata_tags_tutorial) that needs consistency, filtering, reporting, or permissions. Use tags for descriptive retrieval language that helps people find media.
Aspect supports custom metadata attributes like text, single select, and multi-select fields, so teams can standardize searchable fields for status, rights, shot type, and other production metadata.
Most media libraries need several kinds of metadata:
- Descriptive information covers what the asset shows or contains, such as subject, character, location, action, shot type, scene, emotion, product, or topic.
- Structural information shows how the asset relates to the project, such as production, episode, scene, camera roll, clip ID, sequence, version, derivative, proxy, source, or final master.
- Administrative information describes ownership and use, such as rights status, approval status, usage window, client, territory, owner, deletion hold, or archival status.
- Technical information describes the file itself, such as codec, resolution, frame rate, aspect ratio, audio channels, camera, color space, LUT, duration, and checksum.
Once you separate those categories, decide which values must be controlled and which can stay open-ended. Do not let each editor type approval status manually. Use a short menu. Give visual descriptors more room for searchable tags and notes, because a rigid menu can slow people down.
A practical distinction is simple: if a value affects delivery, rights, relink, reporting, or approvals, make it a controlled field. If it helps creative discovery, you can often make it a tag.
## A small controlled vocabulary
A [controlled vocabulary](https://yetone.pro/blog/dam-metadata-taxonomy/) is the approved list of terms your team uses. It prevents one person from tagging “CU,” another “closeup,” another “close-up,” and another “tight.” Search can sometimes handle synonyms, but do not rely on fuzzy matching as the only way to find core production metadata.
Start with a small vocabulary that covers recurring work. An initial version might include fields like these:
- Asset type can include original camera media, proxy, audio, music, SFX, graphic, VFX plate, VFX render, still, offline export, review export, master, textless master, and caption file.
- Shot type can include establishing, wide, medium, close-up, insert, over-the-shoulder, POV, aerial, timelapse, slow motion, and screen recording.
- Content type can include interview, b-roll, product, performance, testimonial, demo, behind the scenes, archival, stock, and social cutdown.
- Status can include ingesting, logged, selected, in edit, needs review, approved, rejected, superseded, and archived.
- Rights can include unrestricted, internal only, editorial only, paid media approved, expired, pending, and unknown.
- Version role can include offline, online, color review, mix review, legal review, final, revised final, and superseded.
Do not try to cover every possible future project in the first version. A vocabulary that covers recurring cases and gets used consistently is more useful than a large schema that nobody follows.
Term naming also matters, so pick one style and enforce it. For example, use lowercase tags for descriptive keywords, title case for project names if needed, and standardized abbreviations only when everyone understands them. If your team uses “OTS,” define it. If producers search for “over the shoulder,” add it as an alias or synonym in the system instead of making users guess.
## Folders for custody, metadata for discovery
Keep folders in your post workflow, because they help with ingest, backups, relinking, turnover, and day-to-day navigation. Use folders for stable custody information, and use metadata for search.
A folder path usually represents only one hierarchy. A shot might belong to a project, shoot day, scene, camera roll, character, location, rights category, and campaign. If the file can live in only one folder, that folder structure will help some searches and hurt others.
Use folders for stable custody and provenance. Use [metadata for discovery](https://broadcastmgmt.com/media-asset-management/media-asset-management-workflow/).
For example, a useful folder structure may look like this:
```text
ProjectName/
01_Ingest/
2026-02-14_ShootDay01/
Camera_A/
Camera_B/
Audio/
02_Transcodes/
Proxies/
Editorial_Mezzanine/
03_Project_Files/
Premiere/
Resolve/
Media_Composer/
04_Exports/
Review/
Masters/
Textless/
05_Delivery/
06_Archive/
```
That structure tells the team where media came from and where deliverables belong. Tags and fields answer creative search questions.
For filenames, use stable identifiers that survive handoff. Avoid names like `final_final_NEW.mov`. At minimum, include project code, asset role, date or version, and a short descriptor where useful. For camera originals, avoid renaming unless your workflow preserves source filename, reel, camera roll, and timecode metadata for conform.
## Put metadata at natural workflow points
Do not treat tagging as work you can do later, because later often means the edit is already moving and nobody has time to fill in metadata carefully.
Assign metadata at specific points in the post workflow:
- At ingest, capture project, shoot date, source, camera roll, asset type, checksum status, and basic technical metadata.
- During sync and prep, add scene, take, interviewee, transcript, camera angle, and usable audio notes.
- During selects, add shot type, content tags, quality notes, story function, and selects status.
- During review, add approval status, rights status, client notes, and version role.
- During finishing and archive, add final delivery status, superseded relationships, master identifiers, and retention or deletion rules.
At each stage, add only the metadata that stage naturally knows. Do not make the ingest operator tag emotional tone for every b-roll clip if the editor will make selects later. Do not make the editor responsible for legal usage rights if production or clearance owns that information.
Metadata is easier to correct while the work is still active. After ingest, a search by shoot day should surface the expected camera rolls and audio folders. After selects, searches by scene and shot type should return the material editors expect to use. After finishing, a search by final delivery ID should separate the current master from review exports and superseded versions.
## Core metadata that keeps a library usable
Do not make every field required. Too many required fields slow down ingest and push people to enter filler values just to move on. Make a few fields mandatory, or the library will become unreliable.
For post teams, a practical minimum metadata set includes:
- Project or production name.
- Asset type.
- Source or origin.
- Creation date or shoot date where applicable.
- Owner or responsible department.
- Status.
- Rights or usage status, even if the value is “unknown.”
- Version role for exports and deliverables.
- Unique ID or stable filename reference.
These fields make the library searchable, auditable, and safer to reuse. Add everything else based on project needs.
Use “unknown” instead of leaving a field blank. Blank fields disappear from workflow, while “unknown” creates a visible problem that you can filter, assign, and resolve.
## Tags for retrieval
Make each tag match how someone will try to find the asset. Decorative tags create noise. If nobody will search for “beautiful,” do not use it. If editors often search for “empty office,” “hands typing,” or “night exterior,” add those tags.
For video, useful tags often describe visible content, editing function, and production context. A tagging pass might include terms for:
- People, products, places, and visible subjects, such as CEO, customer, storefront, skyline, or audience.
- Actions, such as walking, typing, pouring, cheering, opening, or driving.
- Shot and camera language, such as wide, close-up, insert, aerial, handheld, or locked-off.
- Story use, such as intro, transition, reaction, process, proof point, or ending.
- Quality and editorial notes, such as best take, soft focus, noisy audio, camera bump, or alternate.
- Scene, segment, and location references, such as scene 12, cold open, product demo, warehouse, office, or exterior street.
Do not tag every possible object in a frame unless your use case requires it. Aim for fast retrieval of useful media, not an exhaustive inventory of everything visible.
For long-form interviews, transcripts can be more useful than manual tags. If your system supports [transcript search](https://www.recharm.com/blog/video-asset-management), use it. Reserve tags for people, topics, legal restrictions, best soundbites, and editing meaning. A transcript can find the phrase “supply chain,” while a tag can identify the quote as “strong opener” or “approved proof point.”
Aspect automatically transcribes uploaded assets and supports 160+ languages, helping teams search spoken content without relying only on manual interview tags.
## NLE search during active edits
Premiere Pro, DaVinci Resolve, and Media Composer all give you ways to organize and find media inside an active editing project. For many teams, the NLE is the first search interface editors use during the edit. The limitation is that NLE organization is usually project-centered rather than library-centered.
Here is a practical comparison.
| Tool | Strengths for tagging and search | Tradeoffs |
| --- | --- | --- |
| Premiere Pro | Flexible bins, labels, metadata columns, markers, Productions for larger multi-project work, integration with Adobe metadata concepts. Good for teams that want adaptable organization inside editorial. | Metadata practices can become inconsistent across projects unless templates and column layouts are standardized. Free-form naming and bins can drift quickly on larger teams. |
| DaVinci Resolve | Database-driven project structure, metadata panel, keywords, flags, markers, smart bins, scene and clip organization, plus finishing context. Good when editorial, color, and finishing live close together. | Teams need discipline around database and project management and shared libraries. Some metadata may stay inside Resolve unless export and handoff paths are planned. |
| Media Composer | Mature bin-based organization, custom columns, markers, script-based and long-form workflows, relink and conform discipline. Good for broadcast, scripted, reality, and larger assistant-editor-driven environments. | Powerful but less forgiving for casual users. Search quality depends heavily on bin discipline, column standards, and assistant editor process. |
Choose the right tool based on where search needs to work. NLE metadata may be enough for one active edit. If multiple editors need the same footage across many projects, if producers need browser access, or if assets need rights and lifecycle management, do not rely on an NLE project as the whole library.
## Practical setup inside Premiere Pro
Premiere Pro works well when you standardize bins, labels, markers, and metadata columns before the project gets busy. For larger teams, use Productions to split work into multiple projects while keeping shared structure more manageable.
Use bins for editing structure and metadata for search. For example, bins might separate `Interviews`, `Broll`, `Audio`, `Graphics`, `Sequences`, and `Exports`. Metadata columns can then carry scene, shot type, status, rights, and notes.
Set up a shared project template with the columns editors actually use. If each editor chooses different columns, the metadata exists but nobody sees it. Use markers for time-based notes inside clips, such as “good reaction,” “alt line,” “camera bump,” or “usable from 01:03:12:08.” Use labels sparingly for broad visual categories like interviews, b-roll, graphics, audio, and sequences.
Premiere’s flexibility is also the risk. Editors can move quickly, but you still need to maintain a consistent taxonomy. If the team uses free-text markers and inconsistent bin names, search becomes personal rather than shared. Assign an assistant editor or lead editor to maintain the project template and normalize recurring terms.
## Practical setup inside DaVinci Resolve
Resolve’s media pool, metadata tools, keywords, flags, markers, and smart bins are useful when search needs to connect edit and finishing. This is especially relevant when the same system carries the project through edit, color, and delivery.
Start your Resolve workflow with metadata entry during ingest or media pool organization. Use bins for broad production organization, then use keywords and metadata fields to drive smart bins. For example, smart bins can collect all `Interview` clips, all `Scene 12` clips, all `Drone` shots, or all assets with `Rights = Pending` if you maintain that field.
Resolve’s advantage is that searchable organization can follow the work into color and finishing. A colorist can use scene, camera, reel, and status metadata if you have entered it consistently. Markers can also carry useful clip or timeline notes.
The tradeoff is that Resolve’s database and project structure need operational discipline. Be clear about who manages shared project libraries, how you make backups, and which metadata needs to leave Resolve for archive or MAM use. If important tags stay only inside one project database, they may not help the larger organization later.
## Practical setup inside Media Composer
Media Composer remains strong in environments where bin discipline, custom columns, script workflows, and conform reliability matter. It can be less friendly for casual tagging, but it supports structured editing organization when the team is trained.
Use consistent bins and custom columns. Assistant editors can create columns for scene, shoot day, camera, interviewee, location, rights, status, producer notes, and selects. Those columns become part of the editing language of the project.
Media Composer encourages structured organization. In scripted, broadcast, documentary, and reality workflows, the assistant editor process often already includes logging, grouping, syncing, and bin preparation. Add controlled metadata fields to that process instead of creating a separate tagging job later.
The tradeoff is adoption. If team members are not trained on bin views, columns, and search behavior, metadata can stay hidden or underused. Media Composer works best when the assistant editor team owns the organization model and keeps it consistent across episodes, reels, or segments.
## When an NLE is no longer enough
Use an NLE to organize the project in front of the editor. For broader library management, you usually need organization across departments, seasons, campaigns, storage locations, rights windows, and long-term reuse.
Consider a dedicated MAM, DAM, or [searchable media index](https://www.aja.com/assets/support/files/8406/en/AJA_Diskover-Media-Edition-User-Manual_v1.0r1.pdf) when the library has characteristics like these:
- Assets are reused across many projects, clients, seasons, or campaigns.
- Producers, marketers, legal reviewers, or clients need to search without opening an NLE.
- Rights, approvals, embargo dates, or territory restrictions affect reuse.
- The team needs browser-based review, download, permissions, or audit trails.
- Media lives across shared storage, cloud storage, LTO, shuttle drives, and archives.
- Search needs to include transcripts, captions, OCR, faces, logos, or visual similarity.
- The organization needs reporting on unused assets, duplicates, storage growth, or archive candidates.
A dedicated system becomes useful when search is part of operations, risk management, and reuse.
Do not expect a MAM to fix an undefined tagging process. If your team has no controlled vocabulary, no ingest rules, and no ownership model, a MAM will mostly expose inconsistency at a larger scale. Define the workflow first, then choose the system.
## The bridge between NLE metadata and library metadata
Tagging in one system is only part of the workflow. Make sure useful metadata survives between systems.
A post team may touch the same asset in camera cards, offload software, shared storage, an NLE, a color system, a review platform, a MAM, and an archive. Some metadata travels well, while some does not. File system tags, for example, may not survive copies, transfers, or cloud upload. Embedded metadata may survive better for some file types, but not every workflow preserves it. NLE project metadata may stay inside the project unless you export or map it.
Create a metadata map that states where each field lives and how it moves. For example:
| Metadata | System of record | Where it should appear |
| --- | --- | --- |
| Camera roll, clip name, timecode | Camera original and ingest log | NLE, conform, archive |
| Scene, take, shot type | NLE or logging system | NLE, MAM, archive |
| Rights status | MAM or production database | MAM, producer search, delivery review |
| Approval status | Review/MAM workflow | MAM, NLE reference, archive |
| Final master version | Delivery tracker or MAM | MAM, archive, project documentation |
| Transcript | Transcription system or MAM | MAM, NLE if supported, search index |
This map prevents the common failure where editors do valuable logging work but the information never leaves the NLE. It also prevents the opposite problem, where a MAM has official metadata that editors never see during the edit.
## Tag consistency across team members
Create consistency through constraints, defaults, and review habits.
Use a controlled vocabulary for fields that matter, and allow free-form tags only where variation is acceptable. Make the right term easier to choose than the wrong term. Autocomplete, dropdowns, saved searches, templates, and examples all reduce drift.
A lightweight ownership model can cover the key decisions:
- One owner maintains the vocabulary and approves new controlled terms.
- Assistant editors or media managers normalize tags during ingest and turnover.
- Producers own rights, approval, campaign, and client-facing status fields.
- Editors can add creative tags and notes, but should not redefine core fields.
- Superseded, rejected, and expired assets are tagged clearly instead of deleted casually.
That division keeps metadata close to the people who know it while avoiding a free-for-all.
When a new term appears, do not automatically add it to the official list. Ask whether it is a true new category, a synonym, a typo, or a one-project exception. “Drone,” “aerial,” and “UAV” might need one approved term plus synonyms. “Holiday campaign 2026” might be a valid project value, not a general tag.
## Saved searches as workflow tools
Use saved searches to turn metadata into daily operations. Instead of asking the team to remember what needs attention, create views that reveal work states.
Useful saved searches might include:
- Assets with `Rights = Unknown`.
- Clips from the current shoot day with no scene assigned.
- Review exports with `Status = Needs Review`.
- Final masters missing captions.
- Approved b-roll tagged `aerial` and `city`.
- Superseded exports created in the last 30 days.
- Assets tagged `best take` but not added to selects bins.
- Files with missing proxy or missing checksum status.
These searches make gaps visible while you still have time to fix them. They also show whether the tagging system supports the workflow.
If a saved search is empty when it should return results, inspect the metadata immediately. The problem may be missing tags, inconsistent terms, or a field that you are not populating at the right stage.
## AI tagging needs review
[AI tagging](https://docs.imagekit.io/media-library/overview/image-tags) can help with large backlogs. It can identify objects, faces, logos, speech, text in frame, and near-duplicates, but it can also create noise if the generated tags do not match how your team searches.
Use AI for first-pass enrichment, then review and map the results. Let it suggest tags, generate transcripts, detect duplicate or similar files, and flag obvious content. Then map those outputs into your controlled vocabulary.
For example, an AI system might tag a clip as “automobile,” “road,” and “person.” Your team may need “car exterior,” “driving b-roll,” “talent present,” and “paid social approved.” The machine description can be accurate while still falling short of production metadata.
AI works best when your system already has structure. If the rights field is inconsistent, AI will not know which assets are safe to reuse. If the shot type vocabulary is undefined, AI will create near-synonyms at scale. If the archive contains `final_v3_REAL.mov`, AI can describe the pixels, but it may not know whether the file is the approved master.
## Duplicates and near-duplicates
Libraries accumulate duplicates through repeated uploads, renamed exports, and derivative files that look similar but have different purposes. Do not let duplicate detection blindly delete files, because in post, two files can look identical but have different audio, captions, color, codec, rights, or delivery purpose.
Treat duplicate handling as classification first. Each apparent duplicate should be sorted into a useful category:
- Exact duplicates have the same file content and checksum.
- Technical derivatives include proxies, mezzanine files, transcodes, captioned versions, textless versions, audio splits, and alternate codecs.
- Creative versions include different edits, revised graphics, alternate grades, legal-safe versions, cutdowns, and localizations.
- Accidental duplicates are re-uploaded or renamed files with no valid workflow reason.
Only the last category is an easy cleanup target. The others need relationships, not deletion.
Use your library to show that a master has related proxies, review exports, cutdowns, and superseded versions. This is where structured metadata matters more than visual similarity. A system that says “these look alike” is helpful. A system that says “this is the current approved 16:9 master, and those are superseded review exports” is more useful in production.
## Phased scaling
Do not try to tag a 200,000-file archive to perfect standards all at once. Start with active work and high-value reusable assets, then backfill the archive based on demand.
A practical scaling path can move in stages:
- Define required fields, controlled vocabulary, folder rules, and NLE templates for new projects.
- Apply the system to active projects and recent assets that are likely to be reused.
- Create saved searches for missing metadata, rights unknowns, duplicate candidates, and superseded versions.
- Add transcript search, AI tagging, visual search, or MAM automation where it solves a known retrieval problem.
- Backfill older archive collections by priority, not by file count.
This order prevents your team from spending months tagging assets nobody needs while new projects continue creating inconsistent metadata.
Drive archive backfill by use case. If producers constantly ask for historical brand footage, prioritize that. If legal risk is the issue, prioritize rights and approval metadata. If editors waste time recreating graphics, prioritize final design assets and project files.
## Evaluate search quality through real retrieval
Test a tagging system by seeing whether people can find the right assets, not by counting how many tags exist. Retrieval success matters more than metadata volume.
Run common searches with the people who rely on the library. Ask an editor to find a specific b-roll type, a producer to find an approved master, and an assistant editor to find all footage from a shoot day and scene. Watch where they hesitate. If they search for terms the system does not support, add synonyms or adjust the vocabulary. If they get too many irrelevant results, tighten field definitions. If they get no results, the issue may be missing metadata or a search interface that does not expose the right fields.
Natural search terms should also be supported. If someone types “closeup” instead of “close-up,” they should still be able to find the media. If they type “NYC” instead of “New York,” the system should account for that difference. Synonyms and aliases can preserve consistency at input while supporting natural search at output.
## Common failure modes
Media libraries tend to degrade in predictable ways. You usually fix the problem with process, not a different search box.
A library starts to degrade when patterns like these appear:
- File names are the only searchable metadata.
- Tags are optional during ingest and usually skipped under deadline pressure.
- Multiple terms mean the same thing, such as “IG,” “Instagram,” “social,” and “paid social.”
- Rights and approval status are stored in email threads instead of fields.
- Editors add useful markers and notes, but they never leave the NLE.
- Review exports, masters, and superseded versions are not clearly distinguished.
- AI-generated tags create thousands of low-value terms nobody uses.
- Old assets are migrated into a new system without cleanup or mapping.
- Nobody owns the vocabulary, so every project invents its own.
- Search results include too many irrelevant files, so users go back to asking people.
When these patterns appear, do not start by adding more tags. First determine whether the problem is missing metadata, inconsistent terms, poor field design, weak permissions, or a search interface that does not match how the team works.
## A practical operating rule
For a growing post library, make every asset findable by production identity, creative content, workflow status, and usage safety.
That means you should be able to find a clip by project, scene, shoot day, camera, subject, shot type, and status. You should be able to find an export by project, version, aspect ratio, approval state, delivery role, and whether it has been superseded. You should be able to find a reusable asset by what it shows, what it is allowed to be used for, and who owns it.
When your tagging and search workflow supports those questions, the library becomes easier to manage as storage, folders, projects, and software increase.
| Workflow point | Likely owner | Metadata to add | Quick verification |
| --- | --- | --- | --- |
| Ingest | DIT, assistant editor, or media manager | Project, shoot date, source, camera roll, asset type, checksum status, technical metadata | Search by shoot day and confirm all expected camera rolls and audio appear |
| Sync and prep | Assistant editor | Scene, take, interviewee, transcript, camera angle, usable audio notes | Search by scene or interviewee and confirm synced material is easy to isolate |
| Selects | Editor or assistant editor | Shot type, content tags, quality notes, story function, selects status | Search by scene, shot type, and selects status to confirm useful options appear |
| Review | Producer, post supervisor, or review owner | Approval status, rights status, client notes, version role | Search for needs review, rights unknown, and approved versions to catch gaps |
| Finishing and archive | Online editor, finishing artist, or media manager | Final delivery status, superseded relationships, master ID, retention rules | Search by delivery ID and confirm the current master is not confused with review or superseded exports |
{"Most post teams should require project or production name, asset type, source or origin, creation or shoot date, owner, status, rights or usage status, version role for exports, and a unique ID or stable filename reference. Keep required fields limited so people do not enter junk values just to move forward."},
},
{
question: "Should media teams use folders or tags to organize footage?",
answer: <>{"Use folders for custody and provenance, such as ingest, transcodes, project files, exports, delivery, and archive. Use tags and metadata fields for discovery. A file can only live in one folder path, but it may need to be found by scene, location, subject, shot type, rights status, and approval state."},
},
{
question: "When is an NLE enough for media search, and when is a MAM needed?",
answer: <>{"An NLE is often enough when search is limited to one active edit and the main users are editors. A MAM or searchable media library becomes useful when assets are reused across projects, non-editors need browser access, rights and approvals affect reuse, media spans multiple storage locations, or the organization needs audit trails and lifecycle management."},
},
{
question: "How can teams keep tags consistent across editors and assistants?",
answer: <>{"Use controlled fields for important values, such as status, rights, asset type, shot type, and version role. Provide dropdowns, autocomplete, project templates, saved searches, and examples. Assign one owner to maintain the vocabulary, and let assistant editors or media managers normalize recurring terms during ingest and turnover."},
},
{
question: "How should a team handle duplicate media files in a growing library?",
answer: <>{"Duplicate handling should start with classification, not deletion. Some files are exact duplicates, while others are proxies, mezzanine transcodes, captioned versions, alternate codecs, revised cuts, localized versions, or superseded review exports. Only accidental duplicates are simple cleanup candidates. Valid derivatives should be linked with clear metadata so users know which file is current and approved."},
},
{
question: "How do we keep review notes, approval status, and version history connected to searchable media?",
answer: <>{"Review metadata should live next to the asset, not only in email threads or chat. Use timestamped comments, version stacking, custom fields for status, and a visible history of changes so editors can search for the current approved version and understand what changed. Aspect combines comments, annotations, custom metadata, version stacking, and change history inside its "}review workflow{"."},
},
]}
/>