Build an Offline AI Video Catalog for Photorealistic Assets

Why Photorealistic AI Video Breaks Conventional Asset Management

Generating photorealistic video with modern diffusion and video-synthesis models has become almost routine. Keeping track of what you generated, why it looked right, and how to regenerate it six months later is the hard part. A single shot may involve a base text-to-video pass, two image-to-video variations, an upscaling step, a frame interpolation step, and a compositing round in a nonlinear editor. That is a dozen files per finished clip, each tied to a specific model checkpoint, adapter, seed, and prompt.

Cloud-only workflows make this worse in three ways. First, storage and egress costs grow with every iteration, and iteration is the entire craft. Second, upload latency makes quick local experimentation painful once a project reaches hundreds of gigabytes. Third, and most importantly, cloud storage organizes files by upload time rather than by creative intent. You end up with a wall of output_0042.mp4 files and no reliable way to answer: which prompt produced the shot with the correct hand geometry?

An offline catalog solves this by treating metadata as the primary asset and video files as payloads that the metadata points to. The catalog lives on your own hardware, syncs when convenient, and stays queryable when the network does not. This guide covers the schema design, the local-first architecture, the synchronization rules, and the workflow habits that make an offline archive genuinely useful instead of a slower file system.

What an Offline Catalog Actually Is

An offline catalog is not a folder structure with thoughtful names. It is a database plus a manifest system plus a search layer, and it has four responsibilities:

1. Identity. Every file has a stable identifier derived from its content, not its path.
2. Provenance. Every file records how it was made: model, version, adapter, seed, prompt, and the parent file it was derived from.
3. Retrieval. Users can find assets by text, by visual similarity, by tag, by project, or by any combination.
4. Integrity. The catalog knows when files are missing, corrupted, duplicated, or out of sync with a remote copy.

A useful mental model is that the catalog is a directed graph. Nodes are assets; edges are transformations. "Clip B was interpolated from Clip A using a frame-interpolation model" is an edge. "LoRA C was trained on frames D through J" is a set of edges. Once you think in graphs rather than folders, questions that were previously impossible become simple queries: show every asset derived from a checkpoint that has since been deprecated.

Local-first, cloud-optional

The most resilient pattern is local-first with optional remote replication. The working database lives on the artist's machine or a studio NAS. A remote Postgres instance or object store acts as the shared source of truth for teams. Sync is a background process, never a blocking step in the creative loop. If the network dies mid-session, you keep working; the catalog reconciles later.

What belongs in the catalog

Not everything. Thumbnails, proxies, embeddings, transcripts, and structured metadata belong. Massive intermediate exports often do not: keep the last generation step, archive the rest to cold storage, and record a pointer. A catalog that indexes everything becomes as slow to browse as raw folders.

Designing a Metadata Schema That Survives Scale

The schema is where most homegrown archives fail. Teams start with filename, date, and a free-text notes field, then discover that free text cannot be aggregated. Build the schema in three layers.

Identity and provenance fields

• asset_id: UUID or content hash
• content_hash: BLAKE3 or SHA-256 of the media file
• parent_ids: array of upstream assets
• project_id, sequence_id, shot_id
• created_at, created_by, tool_version
• model_name, model_version, model_checkpoint_hash
• adapter_ids: array, for style or character adapters
• seed, sampler, steps, guidance_scale, resolution, duration, fps
• prompt, negative_prompt, prompt_template_id

The checkpoint hash matters more than the checkpoint name. Names get reused; hashes do not. If you cannot reproduce a result, the cause is almost always an ambiguous model reference.

Cinematic and semantic fields

These fields describe what the clip shows, not how it was made:

Field	Example	Purpose
shot_type	wide, medium, close-up	Editorial filtering
camera_motion	dolly-in, handheld, static	Matching across shots
lighting	golden hour, overcast, practical	Visual continuity
subject_tags	performer_a, coupe_1967, alley	Character and prop tracking
mood	tense, warm, clinical	Tone boards
location_ref	set_12, plate_04	Plate and set matching
captions	generated text	Accessibility and search

Keep cinematic fields as controlled vocabularies with an escape hatch. A tags array is fine for exploration; a shot_type enum is what makes a dashboard possible.

Technical and QA fields

• resolution, bitrate, codec, color_space
• has_audio, loudness_lufs
• artifact_flags: array such as warping, flicker, extra_fingers
• qa_status: unreviewed, approved, rejected, needs_rerun
• review_notes, reviewer_id, reviewed_at

The artifact_flags field is quietly the most valuable one in the entire schema. Once you can aggregate failure modes by model version, you can make informed decisions about which pipeline configuration to trust.

Versioning Models and Tracking Usage Honestly

Model churn is relentless. Base checkpoints get updated, adapters get retrained, and a shot that looked perfect in March can look subtly different in June with the same prompt. Treat model versions as first-class entities in a separate table with columns for family, release channel, hash, license notes, and a deprecated_at timestamp.

Then record usage. Not for billing theater, but for engineering decisions. Useful counters include:

• generations per model version per week
• GPU minutes per model version
• rejection rate by model version
• average time from first generation to approved shot

Those four numbers answer the questions that actually matter. A model with a high rejection rate is not saving anyone time regardless of how fast it renders. A model that is rarely used but produces the highest approval rate may deserve a dedicated workstation.

Recording lineage without clutter

Store lineage as edges in a derivations table: source_asset_id, target_asset_id, operation, parameters, performed_at. This keeps the asset row narrow and lets you traverse graphs efficiently. A single query can then reconstruct the full history of an approved shot for a retrospective.

Making a Local Archive Searchable

Text search over filenames is nearly useless for video. You need three retrieval modes working together.

Semantic embeddings

Extract keyframes at a sensible interval, compute visual embeddings, and store vectors alongside the asset row. Tools such as FAISS, LanceDB, sqlite-vec, or pgvector all handle local vector search well. The keyframe interval is a tradeoff: every second gives fine granularity but multiplies storage; every two to three seconds is usually enough for shot-level retrieval.

Text and transcript search

If clips have dialogue or on-screen text, generate transcripts and run OCR. Store them with timestamps so a search hit points to a specific moment, not just a file. Full-text search over prompts, notes, and transcripts covers the majority of real queries.

Hybrid ranking

Vector similarity alone over-returns visually similar but contextually wrong results. Combine it with structured filters and full-text scores. A typical query might be: "wide golden-hour street shots, approved, no flicker flags, visually similar to asset 8f2c." That is a filter, a flag exclusion, and a vector search in one call.

Synchronization and Data Integrity

Offline archives rot quietly. Files get moved, drives fail, and two editors rename the same asset. Integrity is a design requirement, not a cleanup task.

Hashing and manifests

Hash every media file on ingest and store the digest. Periodically rescan and compare; a mismatch means corruption or an unauthorized edit. Generate a manifest per project and per sync batch so a remote copy can be verified without transferring content.

Conflict resolution

Use version vectors rather than wall-clock timestamps. Timestamps lie across machines with drifting clocks. When two clients edit the same asset, merge field-by-field where possible and flag true conflicts for human review. Deleting is the hardest case: prefer soft deletes with a deleted_at field so an accidental deletion on a laptop does not propagate instantly to the studio archive.

Deduplication

Exact hashes catch identical files. Perceptual hashes catch near-duplicates: the same shot re-exported at a slightly different bitrate. Run perceptual dedupe as a background job and suggest merges rather than performing them automatically.

Backup discipline

Follow the 3-2-1 pattern: three copies, two media types, one offsite. The catalog database itself needs the same treatment as the media. A perfect archive of video files with a lost database is just an expensive pile of unlabeled clips.

Architecture That Scales Without Becoming a Server Farm

A practical offline catalog has four layers.

1. Structured metadata store

SQLite is enough for a single workstation and is remarkably capable with proper indexes. For teams, PostgreSQL is the natural step up, and managed options such as Supabase reduce operational overhead while keeping a standard SQL surface. Use JSONB columns for flexible fields and normal tables for anything you plan to filter on heavily.

2. Object storage

Keep media in an S3-compatible store: MinIO on a local server, a NAS, or a cloud bucket. Store only paths and hashes in the database. Never store blobs in Postgres; large object handling will eventually become your bottleneck in backups and restores.

3. Background workers

Thumbnail generation, keyframe extraction, embedding computation, transcription, and hashing all belong in a job queue. Celery, RQ, or Temporal work well. Design jobs to be idempotent so a retry after a crash does not create duplicates.

4. Client application

The client should feel like a media browser, not a database admin panel. Prioritize a fast grid view with filters, a detail panel showing lineage, and a one-click "regenerate from this prompt" action. If browsing is slow, nobody will tag anything, and an untagged catalog decays into a folder tree.

Scaling batch work

For high-volume ingestion, batch by project and cap concurrency by GPU availability. Embedding extraction is CPU-friendly; upscaling is not. Separate queues for lightweight indexing and heavy rendering prevent a single upscaling job from stalling search indexing for the whole team.

Feeding Generation Pipelines From the Catalog

This is where an archive stops being a museum and starts being infrastructure.

Retrieval-augmented prompting

Instead of writing prompts from scratch, retrieve three approved shots that match the target look and use their prompt structures as a template. Store successful prompt templates as reusable records with variables for subject, lighting, and motion. Over time your catalog becomes a prompt library with proven outcomes attached.

Curating fine-tuning datasets

When training a character or style adapter, query the catalog for approved assets with consistent framing and no artifact flags. Export the curated set with its metadata as a training manifest. This is dramatically faster than manually sorting clips, and it makes training runs reproducible.

Consistency references

For character consistency across shots, store reference stills per character and let the generation step pull them automatically. If a shot drifts, the lineage graph shows exactly which reference was used.

Dictating assistants and review agents

Automated directing or continuity tools only work when they can read structured history. An assistant that knows your approved shot types, your common camera motions, and your rejected artifact patterns can propose a shot list that fits the existing material rather than inventing a new visual language every session.

A Practical End-to-End Workflow

1. Ingest. Drop new generations into a watched folder. The ingest job hashes the file, reads embedded metadata or a sidecar JSON, and creates the asset row.
2. Derive. Generate a proxy, a thumbnail strip, keyframes, and embeddings. Mark the asset as indexing until these complete.
3. Tag. Auto-suggest cinematic fields from embeddings and captions, then let a human confirm. Confirmed tags carry more weight in search.
4. Review. Move assets through unreviewed → approved or rejected, adding artifact flags and notes.
5. Reuse. Query the catalog when building the next sequence. Reuse prompts, references, and approved plates rather than regenerating blindly.
6. Archive. Push large intermediates to cold storage, keep proxies and metadata hot, and verify manifests monthly.

The entire loop should add only a few minutes of human attention per asset. Automation handles the rest; the catalog's job is to make that automation trustworthy.

Mistakes to Avoid

• Naming-based organization only. Folders cannot express lineage, and names collide.
• Storing prompts in a text file. Prompts belong in the database where they can be filtered and versioned.
• Skipping checkpoint hashes. Model names are not identifiers.
• Blocking sync. If saving a file waits for the network, artists will disable the tool.
• Over-indexing everything. Index proxies and keyframes, archive raw renders.
• No soft deletes. Hard deletes propagate mistakes across every synced machine.
• Ignoring rejection data. Rejected generations are the most informative records you have.
• No backup plan for the database. Media redundancy without metadata redundancy is wasted effort.
• Building a schema with no enums. Free-text fields cannot power dashboards or automations.

FAQ

How much storage does an offline catalog add?

Typically 5 to 15 percent of the media volume if you store one proxy, a thumbnail strip, keyframes at two-second intervals, and embeddings. Text and metadata are negligible. You can reduce this further by keeping keyframes for approved assets only.

Is SQLite really enough for a single artist?

Yes, comfortably, into the hundreds of thousands of assets with proper indexes. Move to PostgreSQL when multiple machines need concurrent writes or when you want remote access and richer query capabilities.

How do I handle assets generated on a machine without network access?

Use a local write-ahead log. Each client writes operations to an append-only file with version vectors, and the sync process merges logs when connectivity returns. This is the same pattern mobile apps use and it survives long offline stretches well.

What is the minimum viable schema?

If you build nothing else, capture content hash, parent assets, model version hash, prompt, seed, QA status, and artifact flags. Those seven fields answer the majority of real-world retrieval questions.

Should I embed every frame?

No. Embed keyframes every one to three seconds. Frame-level embeddings create massive indices with marginal retrieval gains, and they slow down every search.

How do I keep an archive useful after a year?

Re-run the perceptual dedupe and manifest verification quarterly, review deprecated model versions annually, and keep an approved-only view as the default browsing mode. Curation, not accumulation, is what keeps a catalog fast and trustworthy.

Can this work for a small team of two or three people?

Yes, and it is arguably where the payoff is highest. A shared Postgres instance, MinIO for media, and a single sync service cover a small studio comfortably, and the lineage graph prevents the duplicate-work problem that plagues small teams most.

The Bottom Line

Photorealistic video generation has made output abundant and context scarce. The teams that stay productive are not the ones with the fastest renderer; they are the ones who can find the shot that worked, explain why it worked, and rebuild it on demand. An offline catalog built around content hashes, explicit lineage, controlled vocabularies, and hybrid search turns a growing pile of clips into a queryable memory for your entire pipeline. Start with the seven essential fields, add background indexing early, and let the archive compound in value with every generation you run.