Video Gating Foundation

Context

Summry's immediate product goal is reliability: give users a trustworthy way to decide whether a YouTube video is worth watching. That becomes harder when the product tries to summarize every kind of video with the same assumptions. Tutorials, podcasts, lectures, reviews, vlogs, and visual-first demos all fail in different ways.

The next product direction is a multi-layer constraint gate. Instead of treating every submitted video as equally suitable, Summry needs durable state for whether a video is in scope, what kind of knowledge video it appears to be, how usable its transcript is, and which processing strategy should be used later.

Problem

Before this change, a video mostly moved through processing with one coarse lifecycle:

• pending
• processing
• ready
• failed

That status is still useful, but it does not answer product-quality questions like:

• Is this video inside Summry's current promise?
• Is it a tutorial, lecture, podcast, explainer, commentary piece, or review?
• Is the transcript strong enough to trust?
• Should the summary use a generic or category-specific strategy?

Without first-class fields for those answers, later classification and prompt-routing work would either be transient worker logic or scattered metadata.

Implementation

This first gate adds the persistence and API contract foundation only.

The video model now tracks:

• eligibility status
• content category
• transcript quality
• processing strategy
• eligibility reason

New videos default to an unevaluated state. That means existing URL normalization, metadata fetching, duration checks, chat room creation, and processing enqueue behavior remain unchanged. The new fields simply create a durable place for later gates to write their decisions.

The more stable fields, eligibility status and transcript quality, use database enums. The more likely-to-change taxonomy fields, content category and processing strategy, are stored as strings with application-level allowed-value checks. That keeps future category and prompt-routing experiments from requiring a database enum migration every time the vocabulary changes.

Chat room video responses also expose the fields so the workspace can eventually show caution or unsupported messages from durable backend state instead of inventing client-side interpretations.

Tradeoffs

The main tradeoff is schema commitment. Persisting first-class columns is more rigid than a generic JSON blob, but it makes the fields easier to query, test, expose through typed API responses, and use in future public quality gates.

There is also a smaller type-system tradeoff. Category and strategy are intentionally looser at the database/API layer than eligibility and transcript quality. That gives Summry room to evolve the taxonomy quickly, but it means the application code has to keep enforcement centralized and tested.

This slice intentionally does not classify videos yet. Every new video starts as unknown or generic. That keeps the first step small and reviewable, but it means the product behavior is not visibly different until the later gates are implemented.

Lessons Learned

The existing video lifecycle did not need to be replaced. The right move was to keep processing status focused on job state and add separate product-quality fields beside it.

That separation should make future work easier to reason about:

• status answers whether processing is done
• eligibility answers whether Summry should trust or continue processing the video
• strategy answers how the summary should be generated

Next Steps

The next gate should add metadata-prior classification from title, description, channel, YouTube categories, and tags. That stage should still avoid hard rejection; it should only establish an early prior for later transcript-based checks.