Everything this site shows is in the file — all 68,583 rows.

One row per video, and one row per video per day — titles, ids, views, watch time, retention, and the shape of each video's own run.

• cohort_video_launch_age_window116 rowsPer-(video, age-window) launch-context metrics: views, CTR, retention bucketed by days since publish.

  Drives the cohort-lift detector and the per-video launch comparison chart.

  One row per (video_id, age_window, snapshot_date)

  11 columnsvideo_id, age_window, views, impressions, weighted_ctr, avg_view_duration_sec, avg_view_pct, watch_time_minutes, subs_gained, engaged_views, snapshot_date

  Sits beside summary_video, video_daily

  Once called summary_video_launch_window.

• event_video_phase_transition186 rowsOne row per detected lifecycle-phase transition (consecutive days where stage[d] != stage[d-1] in summary_video_stage_daily).

  Carries from_phase / to_phase, days_in_from_phase, trailing-3d view rates before / after, and a magnitude score (abs(views_rate_change_pct) * (1 + days_in_from_phase / 7)) so detectors can rank transitions by impact. Feeds the existing stage_transition channel_timeline_event type via Phase 6.4.

  One row per (video_id, event_date, snapshot_date)

  10 columnssnapshot_date, video_id, event_date, from_phase, to_phase, days_in_from_phase, views_3d_before, views_3d_after, views_rate_change_pct, magnitude

  Sits beside summary_video_stage_daily, channel_timeline_event

• summary_channel_cohort14 rowsPer-ISO-week cohort rollup of videos published that week.

  Carries mean day-1/day-7/day-30 views, mean click rate and retention, median days-to-100-views, and 7/14/30-day survival shares. vs_baseline_pct compares the cohort's mean day-30 views to the rolling mean of the prior 8 cohorts; coarse cohort_label tier marks ≥ +20% as outperforming and ≤ -20% as underperforming. NULL cohort_label means the baseline is not yet available (fewer than one prior cohort).

  One row per (cohort_week, snapshot_date)

  17 columnscohort_week, cohort_start_date, video_count, avg_day1_views, avg_day7_views, avg_day30_views, avg_day1_ctr, avg_retention_pct, avg_engagement_rate_composite, median_days_to_100_views, survival_day7_pct, survival_day14_pct, survival_day30_pct, baseline_avg_day30_views, vs_baseline_pct, cohort_label, snapshot_date

  Sits beside summary_video, video, video_daily

• summary_videoStart here30 rowsOne row per public video.

  Lifetime aggregates plus derived metrics: velocity (days-to-first-1k, etc.), decay phase, CTR / retention quadrant, lifecycle classification, edit-intensity class, source HHI. Many columns require minimum sample sizes; rows below the gate are NULL.

  One row per (video_id, snapshot_date)

  88 columnsvideo_id, contributor_id, title, published_at, duration_seconds, days_tracked, total_views, total_impressions, weighted_ctr, avg_avd_sec, avg_retention_pct, total_watch_minutes, total_likes, total_comments, total_shares, total_subs_gained, total_subs_lost, engagement_rate, subs_per_1k_views, watch_min_per_impression, primary_traffic_source, title_changes, thumbnail_changes, day1_views, day1_impressions, day1_ctr, ctr_confidence, total_unattributed_impressions, day3_views, day3_impressions, day3_ctr, day3_avd_sec, day7_views, day7_impressions, day7_ctr, day7_avd_sec, days_to_first_impression, days_to_first_browse_imp, days_to_first_suggested_imp, days_to_first_external_view, days_to_first_search_view, first_external_date, days_to_first_subscriber, peak_views_day, peak_views_value, days_to_50_views, late_growth_pct, imp_to_view_ratio, avd_drift_sec, source_hhi, ctr_quadrant, country_hhi, dominant_country_code, dominant_country_share, country_concentration_with_weak_retention, country_audience_match_score, lifecycle_stage, tail_half_life_days, days_in_growth, days_in_peak, days_in_tail, survives_day_7, survives_day_14, survives_day_30, sticky_traffic_ratio, engagement_rate_composite, engagement_velocity_24h, engagement_velocity_7d, days_to_third_subscriber, days_to_fifth_subscriber, days_to_10_views, days_to_100_views, days_to_500_views, days_to_1000_views, days_to_first_comment, days_to_first_like, days_to_first_share, avd_confidence, engagement_confidence, edit_count_lifetime, edit_count_first_30d, edit_count_after_30d, first_edited_at, last_edited_at, first_edit_lag_days, fields_ever_edited_json, edit_intensity_class, snapshot_date

  Read it with this in mindCTR values carry a ctr_confidence tier (noise/low/medium/high). Never display CTR without its tier — small samples are noisy. ctr_quadrant is NULL for noise-tier videos.

  Sits beside video, video_daily, summary_era, summary_video_country_lifetime

  Feeds summary_video_trajectory_cone, summary_video_nearest_peers, summary_video_decay_model, summary_video_launch_context, summary_video_daily_rank

• summary_video_daily_rank2,092 rowsPer-(video, day) channel-internal rank by daily views.

  Lets cross-video comparison queries answer "was this video the channel's #1 driver on that date?" without re-aggregating.

  One row per (video_id, date)

  15 columnsvideo_id, date, views_rank, views_percentile, impressions_rank, impressions_percentile, ctr_rank, ctr_percentile, retention_rank, retention_percentile, subs_gained_rank, subs_gained_percentile, engagement_rate_rank, engagement_rate_percentile, peer_count

  Sits beside video_daily, summary_video

• summary_video_launch_context30 rowsPer-video launch-context snapshot: channel-wide state at publish (subscriber count, recent average daily views, publish gap, last era swap).

  Drives the launch-context-underperformance detector.

  One row per (video_id, snapshot_date)

  16 columnsvideo_id, publish_date, channel_subs_at_publish, channel_recent_7d_views, channel_recent_28d_views, channel_active_videos_7d, channel_top_video_share_7d, channel_source_diversity_7d, channel_quiet_inventory_share, channel_day7_median_at_publish, prior_video_id, days_since_prior_publish, prior_video_day_7_views, video_day7_views, context_label, snapshot_date

  Sits beside summary_video, summary_channel_metrics_daily

• summary_video_nearest_peers20 rowsTop-5 nearest peers per video by trajectory similarity (cosine distance over the cumulative-views vector during the first 30 post-publish days).

  Peers are flat columns peer_1_id … peer_5_id with matching peer_K_distance scores; trailing slots are NULL when fewer than 5 candidates qualify. Mirrors the live similarity constants in dashboard/src/lib/forecast/similarity.ts (getTopSimilarVideo / getSimilarVideos).

  One row per (video_id, snapshot_date)

  14 columnsvideo_id, peer_1_id, peer_1_distance, peer_2_id, peer_2_distance, peer_3_id, peer_3_distance, peer_4_id, peer_4_distance, peer_5_id, peer_5_distance, shared_age_days, peers_qualified, snapshot_date

  Sits beside summary_video, summary_video_trajectory_cone

• summary_video_retention_curve500 rowsThe audience-retention curve per video: one point per (video, elapsed-time ratio) showing how much of the audience was still watching at that fraction of the video.

  audience_watch_ratio is this video's own retention at that point; relative_retention_performance is YouTube's own attributed comparison band against similar videos (nullable when YouTube has no peer set). Both metrics are non-monetary. A curve is stored only for a video that has reached 100 cumulative views — below that the curve is absent by design (too few views to be meaningful) — so a small channel shows nothing here. The shape YouTube returns is a single lifetime curve that never changes per snapshot, so it is stored ONCE (no snapshot dimension); the dashboard re-derives on which as-of dates a video's curve was lit from summary_video.total_views at that date.

  One row per (video_id, elapsed_ratio)

  4 columnsvideo_id, elapsed_ratio, audience_watch_ratio, relative_retention_performance

  Read it with this in mindEmpty when the build had no private retention source (fixtures, local builds) and on any channel whose videos haven't reached 100 cumulative views — emptiness is the honest empty state, not an error. NOT snapshot-extended (no snapshot_date column): the curve is a single lifetime shape stored once, so it is intentionally absent from the snapshot-coverage and snapshot-monotonicity gates. relative_retention_performance is YouTube's attributed band, not a benchmark this product invented.

  Sits beside summary_video, video

• summary_video_stage_daily2,092 rowsPer-(video, day) lifecycle-stage classification (e.g. ramp, plateau, decay) based on the video's own velocity curve.

  Used by the lifecycle-phase detector.

  One row per (video_id, date)

  4 columnsvideo_id, date, stage, days_in_stage

  Sits beside summary_video, video_daily

  Once called video_stage_daily.

• v_video_stateStart here30 rowsPer-video state convenience view joining video, summary_video, and video_current_state.

  Replaces three separate lookups for the per-video page.

  One row per (video_id)

  9 columnsvideo_id, display_label, published_at, total_views, weighted_ctr, ctr_confidence, avg_retention_pct, lifecycle_stage, ctr_quadrant

  Sits beside video, summary_video, video_current_state

• videoStart here30 rowsOne row per public video on the channel.

  Carries publish date, exact duration in seconds, era, language, and the real 11-char YouTube video ID (preserved in this owner build). The real video title is preserved here too; display labels come from this table.

  One row per (video_id)

  13 columnsvideo_id, contributor_id, title, published_at, duration_seconds, privacy_status, scheduled_at, sequence_number, display_label, title_word_count, title_has_number, title_is_question, title_char_count

  Read it with this in mindOwner (de-anon) build: real titles, real 11-char YouTube IDs, and exact durations are preserved (the anon-era duration bucketing was removed at flc/D2). Private / deleted videos are excluded upstream.

  Feeds summary_video, video_daily, video_era, summary_video_country_lifetime, traffic_daily

• video_current_state4,034 rowsPer-video snapshot of the most recent lifecycle / decay state flags.

  Read by the per-video page for "where this video is right now" pills.

  One row per (date, video_id, snapshot_date)

  18 columnsdate, video_id, current_state, state_reason, confidence_tier, noise_reason, days_since_publish, total_views_to_date, total_impressions_to_date, views_7d, impressions_7d, day7_views_to_date, late_views_to_date, late_growth_pct_to_date, lifecycle_stage, primary_traffic_source, evidence_json, snapshot_date

  Sits beside summary_video, summary_video_stage_daily

• video_daily2,110 rowsPer-(video, day) metrics from the YouTube Analytics + Reporting APIs: views, watch time, impressions, click rate, average view duration, average view percentage, subscribers gained/lost, likes, comments, shares.

  One row per (video_id, date)

  22 columnsvideo_id, contributor_id, date, days_since_publish, views, watch_time_minutes, avg_view_duration_sec, avg_view_pct, impressions, ctr, likes, comments, shares, subscribers_gained, subscribers_lost, engaged_views, dislikes, metrics_source, pre_publish_stub, ctr_confidence, unattributed_impressions, avd_confidence

  Read it with this in mindpre_publish_stub = 1 rows exist for the seven days before a video's publish_date and carry NULL impressions / 0 views. Filter WHERE pre_publish_stub = 0 or use video_daily_clean. YouTube reporting lags 2-3 days — see _about.reporting_cutoff. Live and on-demand viewing of the same video on the same day were recorded as one collapsed row before the live_or_on_demand dimension landed in the ingest (per-channel migration date; rows ingested before it carry no split). Daily totals sourced from the Reporting feed for those earlier days can undercount live-stream viewing; days ingested after the migration sum both splits fully.

  Sits beside traffic_daily, summary_video, summary_video_traffic

  Feeds summary_video, summary_channel_metrics_daily, video_daily_clean

• video_daily_cleanStart here2,092 rowsStub-clean view over video_daily — WHERE pre_publish_stub = 0.

  Use this instead of video_daily directly unless you need the pre-publish stub rows for some specific reason.

  One row per (video_id, date)

  22 columnsvideo_id, contributor_id, date, days_since_publish, views, watch_time_minutes, avg_view_duration_sec, avg_view_pct, impressions, ctr, likes, comments, shares, subscribers_gained, subscribers_lost, engaged_views, dislikes, metrics_source, pre_publish_stub, ctr_confidence, unattributed_impressions, avd_confidence

  Sits beside video_daily

Where the views came from — Browse, Suggested, Search, External — plus impressions, click rate, and the countries watching.

• cohort_video_geography_age_window34 rowsPer-(video, country, age-window) view counts.

  Buckets the first N days after publish, the next N, etc., so cross-video comparison is age-normalised. Used for "does this video's country mix typically settle at day 28?" questions.

  One row per (video_id, country, age_window, snapshot_date)

  13 columnsvideo_id, age_window, country_code, geo_bucket, views, watch_time_minutes, avg_view_duration_sec, engaged_views, subs_gained, subs_lost, view_share, watch_share, snapshot_date

  Sits beside summary_video_country_lifetime, summary_video_country_daily

  Once called summary_video_geo_window.

• cohort_video_traffic_age_window254 rowsPer-(video, source, age-window) view counts.

  "How quickly does Browse vs Suggested ramp up on this video?" Used by source-mix age-curve detectors.

  One row per (video_id, traffic_source_id, age_window, snapshot_date)

  15 columnsvideo_id, age_window, traffic_source_id, impressions, views, watch_time_minutes, weighted_ctr, ctr_confidence, avg_view_duration_sec, avg_view_pct, watch_min_per_impression, impression_share, view_share, watch_time_share, snapshot_date

  Sits beside traffic_daily, summary_video_traffic

  Once called summary_video_source_window.

• event_country_first_view24 rowsOne row per country marking the date the channel received its first view from there.

  Feeds the geographic-emergence detector.

  One row per (country)

  4 columnsvideo_id, country_code, first_active_date, first_meaningful_date

  Sits beside summary_channel_country_daily, channel_timeline_event

  Once called country_activation_log.

• event_source_first_view98 rowsFirst date each (video, traffic source) recorded any views.

  Computed from MIN(date) over traffic_daily where views > 0. Drives the source-activation-order detector.

  One row per (video_id, traffic_source_id)

  4 columnsvideo_id, traffic_source_id, traffic_source_name, first_active_date

  Sits beside traffic_daily, summary_video_traffic

  Once called source_activation_log.

• source_age_pattern_daily6,911 rowsPer-source age-curve template: median view share at each days_since_publish.

  Reference points for asking whether a specific video's source mix is precocious vs. typical.

  One row per (traffic_source_id, days_since_publish)

  15 columnsdate, traffic_source_id, traffic_source_name, age_window, videos, views, impressions, weighted_ctr, avg_view_duration_sec, watch_time_minutes, view_per_impression, watch_min_per_impression, date_view_share, confidence_tier, noise_reason

  Sits beside summary_video_traffic, cohort_video_traffic_age_window

• summary_channel_country_cohort_stability98 rowsPer-country cohort stability: how much the country's relative share has drifted over rolling windows.

  Quiet countries with stable share differ from quiet countries fading out; this row distinguishes them.

  One row per (date, country_code, snapshot_date)

  10 columnsdate, country_code, views_share_current, views_share_7d_ago, views_share_change_pct, avd_sec_current, avd_vs_baseline_sec, persistence_score_7d, emergence_label, snapshot_date

  Sits beside summary_channel_country_daily, summary_channel_country_trailing30

• summary_channel_country_daily98 rowsPer-(country, day) channel-wide views, watch time, and subscribers gained.

  Long format for stacked-area charts and geographic drift detection.

  One row per (country, date)

  7 columnsdate, country_code, views, watch_time_minutes, avg_view_duration_sec, subs_gained, subs_lost

  Sits beside summary_channel_country_trailing30, summary_video_country_lifetime

• summary_channel_country_trailing3010 rowsPer-country trailing-30-day channel-wide rollup: views, watch hours, share of total.

  Snapshot of "where the recent audience lives" without re-aggregating the daily table on every read.

  One row per (country, snapshot_date)

  9 columnscountry_code, total_views, total_watch_minutes, avg_view_duration_sec, subs_gained, subs_lost, window_start, window_end, snapshot_date

  Sits beside summary_channel_country_daily

• summary_channel_source_geo_daily169 rowsJoint (source × country) channel-wide daily view counts.

  Supports questions like "what share of External traffic comes from US vs CA?" without joining three tables at query time.

  One row per (date, traffic_source_id, country)

  9 columnsdate, traffic_source_id, country_code, geo_bucket, views, watch_time_minutes, avg_view_duration_sec, avg_view_pct, engaged_views

  Sits beside summary_channel_country_daily, summary_traffic_source_daily

• summary_channel_source_leading_indicator189 rowsPer-source leading-indicator score: how reliably this source's daily movement predicts the next-week channel-wide trend.

  One row per (date, snapshot_date)

  10 columnsdate, source_hhi_14d, top1_source_share_14d, sticky_share_14d, net_subs_next_7d, net_subs_next_14d, hhi_change_14d, pearson_r_hhi_vs_subs, pattern_label, snapshot_date

  Sits beside summary_traffic_source_daily, summary_channel_metrics_daily

• summary_channel_source_share_daily540 rowsLong-format trailing-7-day per-source view share.

  Used by stacked-area charts and source-mix-shift detectors so they don't re-roll the 7d window per query.

  One row per (date, traffic_source_id)

  6 columnsdate, traffic_source_id, share_7d, share_28d, views_7d, views_28d

  Sits beside summary_channel_metrics_daily, summary_traffic_source_daily

• summary_channel_threshold_impression_pattern1 rowChannel-pattern memory for the "does a click-rate or watch-duration jump on one of this channel's older videos tend to be followed by a step-up in YouTube's impressions to that video?" question.

  Walks every video on the channel and, for each leading-edge CTR or AVD jump observed at age >= 14 days (mirror of the thresholds in late-life-ctr-jump.ts / late-life-avd-jump.ts), checks whether the next 7 days of impressions averaged at least 20% above the prior 7 days. Aggregates counts to channel-grain at this snapshot. The followed-rate (*_followed_count / *_event_count) is a sample-of-one observation, not a base rate — when videos_evaluated is small, the per-video card should hedge.

  One row per (snapshot_date)

  11 columnssnapshot_date, ctr_jump_event_count, ctr_jump_followed_count, avd_jump_event_count, avd_jump_followed_count, ctr_min_pp_delta, avd_min_rel_delta, followup_window_days, followup_impression_lift_threshold, videos_evaluated, computed_at

  Sits beside summary_video, video_daily, summary_channel

• summary_channel_traffic14 rowsLifetime per-source channel-wide rollup: views, watch hours, average view percentage, subscribers gained, weighted CTR.

  Used to compare source contribution at the channel level.

  One row per (traffic_source_id, snapshot_date)

  11 columnstraffic_source_id, traffic_source_name, total_views, total_watch_minutes, total_impressions, pct_of_total_views, pct_of_total_impressions, weighted_ctr, avg_watch_min_per_view, subs_per_1k_views, snapshot_date

  Sits beside traffic_source, summary_video_traffic, summary_traffic_source_daily

• summary_traffic_source_daily373 rowsChannel-wide per-source daily aggregates: views, watch hours, average view percentage, weighted CTR, subscribers gained.

  Drives source-mix-over-time charts.

  One row per (traffic_source_id, date)

  8 columnsdate, traffic_source_id, traffic_source_name, total_views, total_impressions, total_watch_minutes, weighted_ctr, video_count

  Sits beside traffic_daily, summary_traffic_source_daily_history

  Once called summary_traffic_daily.

• summary_traffic_source_daily_history373 rowsLongitudinal store of summary_traffic_source_daily, kept across rebuilds so detectors needing historical context can read it without re-aggregating raw traffic_daily on every read.

  One row per (traffic_source_id, date)

  6 columnsdate, traffic_source_id, traffic_source_name, total_views, total_impressions, weighted_ctr

  Sits beside summary_traffic_source_daily, traffic_daily

  Once called summary_traffic_daily_history.

• summary_traffic_top_videos_by_source97 rowsTop videos per traffic source by lifetime views.

  Used by the /traffic/[sourceId] detail page to render a leaderboard without scanning traffic_daily per render.

  One row per (traffic_source_id, rank, snapshot_date)

  9 columnstraffic_source_id, rank, video_id, total_views, total_impressions, weighted_ctr, total_watch_minutes, pct_of_source_views, snapshot_date

  Sits beside traffic_source, traffic_daily, summary_video_traffic

  Once called summary_traffic_top_videos.

• summary_video_country_daily137 rowsPer-(video, country, day) view counts.

  Daily-resolution analog to summary_video_country_lifetime. Long table; filter aggressively.

  One row per (video_id, country, date)

  9 columnsvideo_id, country_code, date, views, watch_time_minutes, avg_view_duration_sec, engaged_views, subs_gained, subs_lost

  Sits beside summary_video_country_lifetime, traffic_daily

• summary_video_country_lifetime5 rowsPer-(video, country) lifetime views, watch hours, retention, and subscribers gained.

  Used by the geographic-concentration detector to flag per-video country dominance.

  One row per (video_id, country, snapshot_date)

  10 columnsvideo_id, country_code, total_views, total_watch_minutes, avg_view_duration_sec, engaged_views, subs_gained, subs_lost, subs_per_1k_views, snapshot_date

  Sits beside summary_video_country_daily, summary_video

  Once called summary_video_country.

• summary_video_traffic107 rowsPer-(video, source) lifetime view share, CTR, retention.

  Source HHI on summary_video derives from this table. share_of_video_views is the per-video proportion attributable to that source.

  One row per (video_id, traffic_source_id, snapshot_date)

  12 columnsvideo_id, traffic_source_id, traffic_source_name, total_views, total_watch_minutes, total_impressions, share_of_video_views, weighted_ctr, subs_gained, funnel_engaged_views, avd_confidence, snapshot_date

  Sits beside traffic_daily, summary_video, traffic_source

  Once called summary_traffic.

• traffic_daily893 rowsPer-(video, source, day) view and click-rate share.

  The core long table for "where do views come from over time" questions.

  One row per (video_id, traffic_source_id, date)

  12 columnsvideo_id, date, days_since_publish, traffic_source_id, views, watch_time_minutes, avg_view_duration_sec, avg_view_pct, impressions, ctr, pre_publish_stub, ctr_confidence

  Read it with this in mindSame pre_publish_stub trap as video_daily — filter or use traffic_daily_clean. Per-source CTR can be noise tier for small impression samples; see ctr_confidence. Same live/on-demand collapse window as video_daily: per-source daily rows ingested before the live_or_on_demand dimension landed can undercount live-stream viewing for channels that live stream.

  Sits beside video_daily, traffic_source

  Feeds summary_video_traffic, summary_traffic_source_daily, traffic_daily_clean

• traffic_daily_cleanStart here849 rowsStub-clean view over traffic_daily — WHERE pre_publish_stub = 0.

  Use this instead of traffic_daily directly unless you need pre-publish stub rows.

  One row per (video_id, traffic_source_id, date)

  12 columnsvideo_id, date, days_since_publish, traffic_source_id, views, watch_time_minutes, avg_view_duration_sec, avg_view_pct, impressions, ctr, pre_publish_stub, ctr_confidence

  Sits beside traffic_daily

• traffic_sourceStart here16 rowsLookup table mapping YouTube's numeric traffic_source_id to a stable display name and human-readable description (e.g.

  "Browse features", "External", "Suggested videos").

  One row per (traffic_source_id)

  7 columnsid, api_name, display_name, category, generates_thumbnail_impressions, is_sticky, description

  Sits beside traffic_daily, summary_traffic_source_daily, summary_video_traffic

• v_traffic_daily_labeledStart here893 rowstraffic_daily_clean joined to traffic_source so the source display name appears alongside the numeric source_id.

  One row per (video_id, traffic_source_id, date)

  16 columnsvideo_id, date, days_since_publish, traffic_source_id, views, watch_time_minutes, avg_view_duration_sec, avg_view_pct, impressions, ctr, pre_publish_stub, ctr_confidence, source_display, source_api, source_category, source_description

  Sits beside traffic_daily_clean, traffic_source

Channel-level totals and daily snapshots: views, subscribers, publishing cadence, and how concentrated the catalog has been.

• channel_cadence_daily162 rowsPer-day publish-cadence state: rolling average gap between publishes, classifier output (steady, cadence_break, etc.), and per-day-of-week trend evidence.

  One row per (date)

  4 columnsdate, pattern, conformance_pct, days_since_break

  Sits beside summary_channel_metrics_daily, channel_timeline_event

• channel_phase_log1 rowLog of channel-wide maturity-phase transitions.

  One row per phase entered (seedling → sprouting → growing → established) with the date and triggering threshold.

  One row per (phase_name, phase_start_date)

  4 columnsdate, phase, prior_phase, evidence_json

  Sits beside summary_channel_stage_snapshot, summary_channel

• channel_signal_daily456 rowsLong-format per-(date, signal) feed of channel-wide signal values that don't fit the wide summary_channel_metrics_daily schema.

  Used by detectors that need a generic time-series backend.

  One row per (date, signal_name)

  18 columnssignal_date, signal_rank, signal_id, signal_type, subject_type, subject_id, metric_family, window, observed_value, baseline_value, absolute_delta, relative_delta, sample_size, confidence_tier, noise_reason, direction, rank_score, evidence_json

  Sits beside summary_channel_metrics_daily

• summary_channelStart here1 rowSingle-row channel-wide lifetime summary: video count, total views, total watch hours, subscriber count, channel-internal medians (CTR, retention, impression-to-view ratio), library half-mass video count, maturity stage, funnel pcts.

  One row per (snapshot_date)

  33 columnscontributor_id, total_videos, total_public_videos, total_days_tracked, first_video_date, latest_data_date, current_subscribers, total_views, total_impressions, total_watch_minutes, avg_daily_views, avg_ctr, avg_avd_sec, avg_retention_pct, total_subs_gained, total_subs_lost, avg_engagement_rate, imp_to_view_ratio_median, median_video_ctr, median_video_retention, algorithmic_dependency_index, median_days_to_100_views, median_days_to_1000_views, publish_gap_distribution, day_of_week_trend, gini_views, gini_subs, library_half_mass_video_count, funnel_impressions_total, funnel_clicks_total, funnel_subs_total, funnel_impression_to_sub_pct, snapshot_date

  Sits beside summary_channel_metrics_daily, summary_channel_snapshot_daily, summary_video

  Feeds app_dashboard_briefing_daily

• summary_channel_catalog_pressure_daily189 rowsDaily catalog-shape signals: count of videos receiving views, Gini-style concentration metrics, and pressure indicators describing how evenly attention is distributed across the catalog.

  One row per (date)

  11 columnsdate, videos_published_that_day, videos_published_14d, active_videos_7d, new_video_impression_share_7d, midlife_impression_share_7d, library_impression_share_7d, top1_impression_share_7d, top3_impression_share_7d, quiet_inventory_share, launch_pressure_index

  Sits beside summary_channel_metrics_daily, summary_video

• summary_channel_metrics_dailyStart here189 rowsChannel-wide daily aggregates: views, impressions, weighted CTR, subscriber net change, plus rolling 7d / 28d windows, source-mix diversity, top-video share, quiet-inventory share, and per-stage video counts.

  One row per (date)

  55 columnsdate, videos_published_that_day, cumulative_videos_live, most_recent_video_id, days_since_last_publish, total_views, total_impressions, total_watch_minutes, weighted_ctr, avg_avd_sec, subs_gained, subs_lost, subs_net, subs_total_eod, likes, comments, shares, views_7d, views_28d, watch_min_7d, watch_min_28d, impressions_7d, impressions_28d, weighted_ctr_7d, weighted_ctr_28d, source_diversity_score, top_video_share_7d, top3_video_share_7d, top_video_id_7d, videos_with_zero_views_7d, quiet_inventory_share, anomaly_score_composite, temperature_score, country_diversity_score, algorithmic_dependency_index, algorithmic_dependency_slope_28d, audience_persistence_pct, audience_replacement_rate, top_video_share_slope_14d, top3_video_share_slope_14d, source_diversity_slope_14d, quiet_inventory_slope_14d, country_hhi_slope_14d, recent_debut_trend_14d, gini_views_28d, gini_subs_28d, unattributed_channel_views, videos_in_debut, videos_in_growth, videos_in_peak, videos_in_tail, videos_in_quiet, videos_in_re_emerged, videos_in_zombie, videos_in_dormant

  Read it with this in mindLatest date may lag _about.reporting_cutoff by 1 day. Filter date <= (SELECT value FROM _about WHERE key = 'reporting_cutoff') for safe queries.

  Sits beside summary_channel, summary_channel_snapshot_daily, summary_channel_source_share_daily

  Feeds app_dashboard_briefing_daily, event_channel_state_change

  Once called summary_channel_daily.

• summary_channel_narrative_arc5 rowsMacro-structure of the channel's life as a small set of contiguous multi-week windows ("arcs" / movements) that the /story scroll choreographs against — pacing and motion shift at arc boundaries.

  Each arc carries a coherent shape derived from the channel's OWN signals: weighted timeline-event density, day-over-day view-rate change, and lifecycle-stage churn, smoothed and z-scored against the window's own baseline (no absolute thresholds — sample-of-one), then segmented by change-point detection. This is INTERPRETIVE, OBSERVATIONAL SEGMENTATION, not a ranking. No arc is a "best era", a climax, or a winner; a quiet stretch is a first-class movement, equal in weight to a busy one — only the shape differs. The neutral arc_kind / view_trend_label / dominant_motion enums carry no value judgement and headline is hedged. The thin- timeline guardrails (min arc 7 days, max arcs min(5, floor(span/10)), a genuinely flat signal collapsing to ONE steady arc) mean a quiet channel honestly gets fewer arcs — never padded drama. Context metrics only (event_density); no per-arc subscriber/view totals that could read as a scoreboard.

  One row per (arc_id, snapshot_date)

  13 columnsarc_id, arc_index, arc_start_date, arc_end_date, arc_kind, span_days, event_density, view_trend_label, dominant_motion, is_open, headline, computed_at, snapshot_date

  Sits beside summary_channel_metrics_daily, channel_timeline_event

• summary_channel_snapshot_daily53 rowsDaily snapshot of subscriber count and lifetime view count from the YouTube Data API.

  The "official" channel counter. Compare to summary_channel_metrics_daily.subs_net_change for analytics-vs-data reconciliation.

  One row per (date)

  5 columnsdate, subscribers, total_views, video_count, catalog_total_views

  Sits beside summary_channel_metrics_daily, summary_channel

  Once called channel_daily.

• summary_channel_stage_snapshot6 rowsSix rows — one per fixed channel-maturity stage (seedling → established).

  Each row carries the reached date, day number, and per-row stage facts. Stages still ahead are NULL.

  One row per (stage_name)

  10 columnsstage_id, stage_label, stage_order, reached_date, day_number, videos_at_stage, lifetime_views, current_subscribers, watch_hours, editorial_note

  Sits beside summary_channel, channel_phase_log

• summary_subscriber_event_daily1 rowPer-(date, video, kind) subscriber-loss and surge events.

  Lifts these out of the channel_timeline_event.evidence_json envelope into a queryable table for cross-reference.

  One row per (date, video_id, kind)

  6 columnsdate, video_id, kind, delta, threshold, baseline

  Sits beside video_daily, summary_channel_metrics_daily, channel_timeline_event

• v_latest_channel_stateStart here1 rowSingle-row view of the most recent summary_channel_metrics_daily row joined with summary_channel_snapshot_daily for the same date.

  The "what's the state right now?" entry point.

  One row per ()

  59 columnsdate, videos_published_that_day, cumulative_videos_live, most_recent_video_id, days_since_last_publish, total_views, total_impressions, total_watch_minutes, weighted_ctr, avg_avd_sec, subs_gained, subs_lost, subs_net, subs_total_eod, likes, comments, shares, views_7d, views_28d, watch_min_7d, watch_min_28d, impressions_7d, impressions_28d, weighted_ctr_7d, weighted_ctr_28d, source_diversity_score, top_video_share_7d, top3_video_share_7d, top_video_id_7d, videos_with_zero_views_7d, quiet_inventory_share, anomaly_score_composite, temperature_score, country_diversity_score, algorithmic_dependency_index, algorithmic_dependency_slope_28d, audience_persistence_pct, audience_replacement_rate, top_video_share_slope_14d, top3_video_share_slope_14d, source_diversity_slope_14d, quiet_inventory_slope_14d, country_hhi_slope_14d, recent_debut_trend_14d, gini_views_28d, gini_subs_28d, unattributed_channel_views, current_subscribers, channel_total_views, channel_total_public_videos, channel_total_videos, videos_in_debut, videos_in_growth, videos_in_peak, videos_in_tail, videos_in_quiet, videos_in_re_emerged, videos_in_zombie, videos_in_dormant

  Sits beside summary_channel_metrics_daily, summary_channel_snapshot_daily, summary_channel

Title and thumbnail edits, the eras between them, milestones, owner notes, and every dated event on the record.

• channel_timeline_eventStart here451 rowsUnified event ledger: publish, milestone, insight, stat_snapshot, rank_change, first_external, note, subscriber_loss_event, stage_transition, era_start, audience_expansion, source_quiet, creator_event.

  Drives the Story page.

  One row per (event_key, snapshot_date)

  14 columnsevent_key, snapshot_date, date, day_number, event_type, detector, headline, detail, evidence_json, direction, significance, video_id, resolved_by, resolved_date

  Read it with this in mindevidence_json is polymorphic — shape varies by event_type. See _json_schema for per-event-type key lists.

  Sits beside event_creator_edit, event_channel_annotation, event_country_first_view, event_source_first_view, event_channel_state_change

  Feeds v_event_ledger

  Once called channel_timeline.

• cohort_channel_change_verdict8 rowsChannel-scope mirror of cohort_video_change_verdict.

  Reads from event_creator_edit (channel-scope rows) and event_channel_annotation to score channel-wide pivots.

  One row per (pivot_date, pivot_kind, snapshot_date)

  37 columnspivot_date, pivot_kind, pivot_field, pivot_id, window_days, window_fits, before_views, after_views, before_impressions, after_impressions, before_avg_ctr, after_avg_ctr, before_avg_retention, after_avg_retention, before_sub_gain, after_sub_gain, before_active_videos, after_active_videos, before_external_share, after_external_share, views_delta_z, impressions_delta_z, ctr_delta_z, retention_delta_z, sub_rate_delta_z, verdict_views, verdict_impressions, verdict_ctr, verdict_retention, verdict_subs, verdict, verdict_basis, affected_video_count, fields_touched_json, neighboring_pivot_count, evidence_json, snapshot_date

  Sits beside event_creator_edit, event_channel_annotation

  Once called summary_channel_change_window.

• cohort_video_change_verdict28 rowsBefore/after rollup per video pivot (era boundary, subscriber-loss event, or hand-authored note).

  Each row carries metric snapshots on both sides of the pivot so the change-window detector can score whether the swap moved the needle.

  One row per (video_id, pivot_date, pivot_kind, snapshot_date)

  36 columnsvideo_id, pivot_date, pivot_kind, pivot_field, window_days, window_fits, before_views, after_views, before_impressions, after_impressions, before_ctr, after_ctr, before_ctr_n, after_ctr_n, before_retention, after_retention, before_avd_sec, after_avd_sec, before_sub_gain, after_sub_gain, views_delta_z, impressions_delta_z, ctr_z, ctr_z_n, retention_delta_z, sub_rate_delta_z, verdict_views, verdict_impressions, verdict_ctr, verdict_retention, verdict_subs, verdict, verdict_basis, neighboring_pivot_count, evidence_json, snapshot_date

  Sits beside event_creator_edit, summary_subscriber_event_daily, video_era

  Once called summary_video_change_window.

• event_channel_annotationno rows yetOwner-authored timeline annotations — the channel's own notes (written in the account console, stored per channel) and, on a local build, pipeline/creator-events.yaml.

  Durable record kept alongside channel_timeline_event so the source survives a rebuild. A note naming a video is video-scope and carries that id in affected_video_ids_json; a note about the channel is channel-scope. kind is the note's tense tag (expectation / change-rationale / retrospective) or note when it has none.

  One row per (event_id)

  10 columnsevent_id, date, end_date, scope, kind, public_label, public_body, affected_video_count, affected_video_ids_json, fields_touched_json

  Sits beside channel_timeline_event

  Once called channel_event_public.

• event_channel_state_change189 rowsChannel-wide state transitions (CUSUM step-change detections).

  Marks dates when channel-wide metrics shifted regime.

  One row per (date, state_kind)

  37 columnsdate, surface_state, reason_code, reason_text, classifier_version, daily_impressions, impressions_7d, imp_7d_pct, views_slope_7d, views_slope_28d, dominant_source_id, max_source_share_7d, suggested_share_7d, suggested_share_28d, search_share_7d, external_share_7d, external_share_28d, source_diversity_score, country_diversity_score, top_country_share_7d, top_video_id, top_video_share_7d, active_videos_7d, videos_published_14d, new_video_impression_share_7d, top1_impression_share_7d, top3_impression_share_7d, quiet_inventory_share, launch_pressure_index, recent_publish, recent_video_id, recent_video_age_days, first_week_candidate_views, first_week_baseline_median_views, first_week_candidate_impressions, first_week_ctr_confidence, first_week_views_above_median

  Sits beside summary_channel_metrics_daily, channel_timeline_event

  Once called summary_channel_state_log.

• event_creator_edit10 rowsOne row per field-level edit detected by diffing successive YouTube Data API snapshots.

  Sanitised from the private video_change_log + channel_change_log. Powers the changes page and feeds summary_creator_edits_* rollups.

  One row per (scope, video_id, channel_id, field, changed_at, change_kind, snapshot_date)

  13 columnssnapshot_date, scope, video_id, channel_id, changed_at, field, change_kind, before_value, after_value, time_since_publish_days, subscribers_at_change, source, confidence

  Sits beside cohort_video_change_verdict, cohort_channel_change_verdict, summary_edit_view_position

  Once called creator_change_log.

• summary_creator_edits_daily7 rowsDaily count of creator edits across all videos plus field-level breakdowns (title, thumbnail, description, tags).

  Includes an is_burst_day flag for days with unusually high edit activity.

  One row per (date)

  12 columnsdate, total_changes, video_changes, channel_changes, videos_touched, unique_fields, fields_touched_json, field_counts_json, baseline_mean, baseline_stddev, vs_baseline_z, is_burst_day

  Sits beside event_creator_edit, summary_creator_edits_weekly

  Once called summary_change_daily.

• summary_creator_edits_monthly2 rowsMonthly rollup of creator edits.

  Coarsest of the three edit cadence tables; used for long-trend visualisation.

  One row per (month_start_date)

  9 columnsyear_month, total_changes, video_changes, channel_changes, videos_touched, unique_fields, most_changed_field, most_changed_field_count, vs_prior_month_pct

  Sits beside summary_creator_edits_daily, summary_creator_edits_weekly

  Once called summary_change_monthly.

• summary_creator_edits_weekly5 rowsWeekly rollup of creator edits with field-level breakdowns.

  Mirrors summary_creator_edits_daily at a coarser grain for chart use.

  One row per (week_start_date)

  10 columnsiso_week, week_start, total_changes, video_changes, channel_changes, videos_touched, unique_fields, fields_touched_json, publish_days_in_week, edits_per_publish

  Sits beside summary_creator_edits_daily, event_creator_edit

  Once called summary_change_weekly.

• summary_edit_view_position7 rowsPer-edit context: cumulative view percentage and lifecycle phase at the moment the edit happened.

  Lets the dashboard render "edited when this video had received 23% of its lifetime views" annotations.

  One row per (video_id, changed_at, snapshot_date)

  7 columnsvideo_id, changed_at, field, views_at_change, cum_views_pct_at_change, view_phase, snapshot_date

  Sits beside event_creator_edit, summary_video

• summary_era60 rowsOne row per (video, era) with weighted CTR, total impressions, average retention, and view share.

  Drives the era A/B detector and the changes page's era table.

  One row per (video_id, era_index, snapshot_date)

  15 columnsvideo_id, field, era_index, era_value, start_date, end_date, days_active, total_views, total_impressions, weighted_ctr, avg_avd_sec, total_watch_minutes, total_subs_gained, thumb_ref, snapshot_date

  Sits beside video_era, event_creator_edit

• summary_field_co_change1 rowPairwise co-occurrence of edit field combinations: how often title + thumbnail are swapped together, etc.

  Drives the co-change heatmap on the changes page.

  One row per (field_a, field_b, snapshot_date)

  9 columnsfield_a, field_b, co_change_count, field_a_total, field_b_total, total_pairs, jaccard, lift, snapshot_date

  Sits beside event_creator_edit, summary_creator_edits_daily

• v_event_ledgerStart here772 rowsUnified event view spanning channel_timeline_event plus the typed event_* tables (event_creator_edit, event_channel_annotation, etc.).

  One canonical UNION ALL so cross-event-type queries don't have to list every table.

  One row per (date, event_type, subject_id)

  7 columnsevent_date, source_table, event_type, video_id, label, body, significance

  Sits beside channel_timeline_event, event_creator_edit, event_channel_annotation, event_country_first_view, event_source_first_view, event_channel_state_change

• video_era60 rowsTitle/thumbnail eras per video.

  Each row marks the start of an era with the (often-hashed) configuration string. Used by the era detector to compare CTR / retention before vs. after a swap. field distinguishes title vs thumbnail eras; era_index is monotonic within a (video, field) sequence.

  One row per (video_id, field, era_index, snapshot_date)

  9 columnsvideo_id, field, era_value, era_index, start_date, end_date, is_inferred, thumb_ref, snapshot_date

  Read it with this in mindsnapshot_date is on the PK for V64 PK-shape consistency with every other Backfill-Pass-extended table, but era rows are written at SETUP time (one snapshot, the build's latestDataDate). As-of reads honor era membership via the start_date / end_date columns: a reader filtering start_date <= asOfDate AND (end_date IS NULL OR end_date > asOfDate) gets the era set active on asOfDate. Join restriction: a future query that joins video_era ON snapshot_date against another snapshot-extended table will return ZERO rows for any asOfDate other than MAX(snapshot_date) because only one snapshot is ever populated. The start_date/end_date filter is the only correct as-of read pattern; never join on snapshot_date here. Backfill Pass Phase 9 (F-4) reviewed the trade-off: a tiny writeVideoEraWalker step would re-INSERT ~100 era rows on every walker iteration (~33 × 100 = 3300 redundant rows for a ~33-day channel) without changing what any current reader returns. The decision (2026-05-14): keep video_era SETUP-populated and pin the constraint here so future joins don't silently lose rows.

  Sits beside summary_era, event_creator_edit

Projections, decay curves, and the calibration logs that record how earlier projections actually turned out.

• app_decay_curve_library56 rowsThe two decay shapes a catalogue actually carries, learned from the data rather than assumed.

  Every per-video projection used to lean on one global assumption — "views fade log-linearly" — which biases a front-loaded video and a slow-burn video in opposite directions. This table holds both curves: front_loaded banks most of its views in the first days and then flattens, slow_burn keeps accruing across the four weeks. One row per (shape, age) carrying that shape's cumulative share of its four-week total and the share that arrived on the day alone, plus how many videos were grouped into it. Learned by k-medoids with k = 2 over normalized cumulative-share vectors; each video's own match is stamped on summary_video_decay_model.curve_cluster / curve_cluster_distance.

  One row per (cluster_id, age_days, snapshot_date)

  9 columnscluster_id, age_days, snapshot_date, curve_label, cumulative_share, daily_share, member_video_count, member_band, computed_at

  Read it with this in mindA CURVE, never an identity: no video_id and no contributor_id is stored anywhere in this table, because a shape drawn from another pooled channel's catalogue would otherwise name that channel's video by reference. What ships is the normalized shape, a member VIDEO count, and member_band — the same floored channel band every other pool surface uses, never an exact count. Built from the pool when a pool input is supplied and from this channel's own catalogue when it is not, so it fills in from the smallest real input. A video needs a full, gap-free four-week trajectory with at least one view in it to be part of the learning set, and two such videos have to exist before two shapes can be separated at all — below that the table is simply empty. Fully re-derived at every reporting cutoff; read the latest with WHERE snapshot_date = (SELECT MAX(snapshot_date) FROM app_decay_curve_library). The clustering is deterministic (no randomness of any kind), so the same data always yields the same two curves.

  Sits beside summary_video_decay_model, app_video_forecast_prior

• app_video_forecast_prior2,491 rowsThe video-grain "what's likely next" empirical-Bayes prior, per snapshot: one row per this channel's own videos whose own (noisy, short-history) per-day-views decay rate is shrunk toward the cross-channel cohort's typical decay rate.

  The cohort comes ONLY from the gate-passed video-grain vidage cohort (app_pool_cell_stat, metric video_daily_views — raw order statistics); the own side comes ONLY from this channel's own video. own_slope is the video's own log-space decay rate (the same shape summary_video_decay_model fits), cohort_slope the cohort's typical decay rate (the prior mean), tau2 the prior strength, shrink_weight the empirical-Bayes weight B in [0,1] (short history shrinks harder), and shrunk_slope = B·cohort_slope + (1−B)·own_slope the blended "what's likely next" estimate a forecast consumes. The channel-grain analog of this lives inline in summary_channel_forecast (the subscriber slope EB-shrink); this is its per-video cousin.

  One row per (video_id, snapshot_date)

  11 columnsvideo_id, snapshot_date, own_slope, cohort_slope, tau2, shrink_weight, shrunk_slope, own_sample_days, cohort_sample_ages, member_band, computed_at

  Read it with this in mindEmpty (table absent) until the pool-aggregate flag is on — every build without the flag (fixtures, local builds) legitimately has no such table. Rows need this channel's OWN videos in the pool extract, so a non-pooled channel carries the table empty (its vidage reference band still ships in app_pool_cell_stat — give-to-get — but there is no own side to shrink). Rows appear once this channel's vidage cohort lights — which needs ≥2 videos across ≥2 pooled channels at matching ages and ≥3 lit ages (the lit-ages minimum is a slope-fit degeneracy rule, not a size gate; the real 2-channel pool crosses both). A video with fewer than 3 closed, observed per-day-views points has no own estimate to shrink and gets no row. Exact member counts are never stored (member_band is a floored band, the most conservative across the lit ages); the cohort side is fit over the already-published cohort medians, so the shrunk slope discloses no more than the cohort band itself. Fully re-derived every build (consent purge by construction); monotonicity does NOT apply. Slopes are log-space decay rates (per day of age), quantized to 6 decimals for cross-architecture byte-stability.

  Sits beside app_pool_cell_stat, summary_video_decay_model

• forecast_calibration_log1,267 rowsAppend-only credibility ledger for BOTH forecast layers.

  Arc rows (subscribers / daily_views) carry one past projection from summary_channel_forecast — the original published value + band, plus the observed actual once the build's reporting cutoff catches up to target_date. Milestone rows (milestone_*) carry one past crossing-date projection from summary_threshold_projection, measured in DAYS-TO-CROSSING: horizon_days holds the threshold value, predicted_* the projected days-out, and actual_value the days until the metric's cumulative series actually crossed. Source of truth lives at public/data/forecast-calibration-log.json (git-tracked, survives revert + rebuild); this table is a build-derived view of the latest 180 days of that file. inside_band is the load-bearing credibility signal — past forecasts whose actual fell inside [predicted_low, predicted_high] — and misses never silently exit the denominator: a sufficient-history forecast with no usable band scores 0 when the outcome arrives, and an overdue milestone (late edge passed, no crossing yet) scores 0 immediately while its actual_value stays open. error_pct and inside_band stay NULL while the outcome is open, and also when the model declined to forecast at all in its warm-up window (no claim to score — an honest gap, not a hidden one).

  One row per (forecast_made_on, horizon_days, forecast_type)

  10 columnsas_of_date, forecast_made_on, horizon_days, forecast_type, predicted_value, predicted_low, predicted_high, actual_value, error_pct, inside_band

  Sits beside summary_channel_forecast, summary_threshold_projection, summary_channel, summary_channel_metrics_daily

• forecast_decay_history485 rowsAppend-only per-(snapshot_date, video_id) snapshots of summary_video_decay_model.

  Captures the build's fit so consumers can compute deltas across builds — e.g., "this video's projected quiet date moved 14 days further out in the past week." Source of truth lives at public/data/forecast-decay-log.json (git- tracked, survives revert + rebuild); this table is a build- derived view of the latest 180 days of that file. Today's fit still lives in summary_video_decay_model; this ledger only accumulates history. predicted_quiet_date is NULL on the same rows where summary_video_decay_model leaves it NULL (model did not project a sub-5 day inside its 5-year horizon).

  One row per (snapshot_date, video_id)

  9 columnssnapshot_date, video_id, model_type, decay_rate_per_day, half_life_days, predicted_quiet_date, goodness_of_fit_r2, fit_age_days, sample_size_days

  Sits beside summary_video_decay_model, video, summary_video

• forecast_video_calibration_log14 rowsAppend-only credibility ledger for the per-video forecast layer — the video-grain mirror of forecast_calibration_log.

  TWO metric_type families share the grain and never pool. views_day_30/60/90 rows evaluate the decay model's POINT projections (summary_video_decay_model.predicted_views_day_N — a daily view-rate), resolved against the rolling 7-day mean of the video's per-day views ending at age N; their hit is within-±20%. cone_band_age_30/60/90 rows evaluate the trajectory cone's peer BAND of cumulative views by age N (summary_video_trajectory_cone p10..p90 — accumulated totals), resolved against the video's own realized cumulative views by that age; their hit is inside-[p10, p90]. Source of truth lives at public/data/forecast-video-calibration-log.json (git-tracked, survives revert + rebuild); this table is a build-derived view of the latest 180 days of that file. actual_value, error_pct, and hit stay NULL while target_date (= published_at + N days) is still in the future. Video-detail reads each family as its own channel-wide track-record statement (dashboard/src/lib/forecast/video-calibration.ts).

  One row per (forecast_made_on, video_id, metric_type)

  10 columnsas_of_date, forecast_made_on, video_id, metric_type, target_date, predicted_value, actual_value, error_pct, hit, resolved_on

  Sits beside summary_video_decay_model, summary_video_trajectory_cone, video, video_daily

• summary_channel_forecast8 rowsHorizon-banded channel-level forecast.

  One row per (horizon, forecast_type) at the latest reporting cutoff: horizons 7 / 14 / 30 / 90 days, types subscribers (cumulative count) and daily_views (rolling 7-day mean of per-day views). The forecast is treated as what it is — a COUNT. The projected value is the channel's recent LEVEL, measured with recency weighting (a day a week ago counts half as much as today, over 28 days) and with days far outside the channel's own normal range dropped from that level: one viral day is an event, not a new baseline. A trend is added on top only when the series really does follow one line (the same steadiness test the "at the current pace" copy uses elsewhere), and the whole thing is capped so a projection can never claim the channel is already running above its own best week in the last eight. The band is built from what has actually happened to this channel over exactly this horizon: the 10th and 90th percentiles of its own realized 7 / 14 / 30 / 90-day changes, measured on the calendar so a gap in the data can never pass a 116-day change off as thirty days. It is measured at each horizon rather than rescaled from one pooled set, and it always reaches at least as far as "nothing more happens" would. A viral day the projection deliberately does not chase shows up here, in how far the upper edge reaches. When a horizon has too few realized changes to quantile, the band borrows the nearest horizon that does, then falls back to a negative-binomial fit on the channel's per-day counts. Everything is deterministic and RNG-free, so reruns over identical input produce byte-identical bands. Thin data widens the band; it never blanks the row. A channel with fewer than three usable day-over-day changes publishes the pooled cohort's rate directly (when it is pooled), and a channel whose analytics spine is starved falls back to the daily subscriber / view snapshots. The confidence='insufficient' tier (below 14 days of usable history, or a band wider than the projection itself) is a LABEL, not a withhold: the dashboard renders the band only, no point claim, and published values clamp at 0. projected_value and the two _low/_high columns are NULL only for a forecast type with no observation anywhere — model_type then reads no_observation. Otherwise model_type names the method the centre used (count_persistence, count_stable_trend, pool_prior_rate, cold_persistence, optionally suffixed _eb when a pooled prior shrank the rate). Post-build, the calibration writer back-writes this cell's track record: historical_band_coverage, historical_hit_rate, and coverage_below_floor_days — a still-running streak of snapshots whose coverage sat below half, which the dashboard uses to demote a chronically-wrong cell to a directional reading. Projection assumes recent direction and discovery mix hold; arithmetic on the channel's own past, not a prediction.

  One row per (as_of_date, horizon_days, forecast_type)

  13 columnsas_of_date, horizon_days, forecast_type, projected_value, projected_low, projected_high, model_type, lookback_days, sample_size_days, confidence, historical_band_coverage, historical_hit_rate, coverage_below_floor_days

  Sits beside summary_channel, summary_channel_metrics_daily, summary_threshold_projection, forecast_calibration_log

• summary_channel_regime_forecast1 rowJoint-trajectory regime-transition forecast — one row per as_of_date carrying the channel's currently-classified surface state, the projected next state, and the expected transition window with uncertainty bands.

  Built by projecting each classifier-input feature in event_channel_state_change forward at its trailing 21-day OLS slope and re-classifying day-by-day for up to 60 days. Pair-bootstrap (B=200, seeded Mulberry32) widens the band: each feature's slope CI is computed, features whose CI straddles zero or whose |slope| sits below the noise floor are dropped, and the joint distribution of projected (transition_day, projected_state) tuples drives the modal projection. projected_state and the three expected_days* columns go NULL on the confidence='insufficient' branch (fewer than two meaningfully-moving features, bootstrap-transition rate under 50%, or modal-state agreement under 60%). contributing_features_json is the (name, slope_per_day, current_value, ci_low, ci_high) payload for each feature driving the projection. classifier_version pins the v2 state classifier so future bumps in compute-channel-state-log.js are observable downstream. Projection assumes recent direction and discovery mix hold; arithmetic on the past 21 days, not a prediction.

  One row per (as_of_date)

  11 columnsas_of_date, current_state, projected_state, expected_days, expected_days_low, expected_days_high, contributing_features_json, lookback_days, sample_size_days, classifier_version, confidence

  Sits beside event_channel_state_change, summary_channel, summary_channel_metrics_daily

• summary_threshold_projection3 rowsForward-looking projection of when the channel reaches the next round threshold (subscribers / cumulative views / video count).

  The pace starts from the trailing-window fit and, when the channel is pooled and a real ≥2-member cohort rung is lit, is EB-shrunk toward the shared pool's family prior for the threshold type — rate_per_day is always the rate the projection actually used. projected_date_low / projected_date_high are conformal crossing-date bands: the quantiles of the pace model's own past walk-forward prediction residuals, solved in closed form for the crossing time — the surface honestly widens when the model's own track record is noisy. The fitted dates stay published on the confidence='insufficient' tier (the dashboard then shows the date range only, never a single-date claim — the wide band carries the roughness); the date columns are NULL only when the pace is not positive or the crossing solves beyond the ~10-year horizon, where there is genuinely nothing honest to project at the current pace. Every published row also enters the calibration ledger (forecast_calibration_log) as a days-to-crossing prediction and is scored against the actual crossing. Post-build, the calibration writer back-writes historical_crossing_coverage — the trailing inside-band fraction of those resolved crossings (overdue-uncrossed counts as a miss, never a silent denominator exit), NULL until 5 have resolved on the cell. That fraction is what the dashboard's demotion reads. The published dates themselves are the conformal dates, unmodified: the widen-only auto-tune that used to stretch them was retired. Projections assume recent pace and cadence hold; they are arithmetic on the past N days, not predictions.

  One row per (threshold_type, threshold_value, snapshot_date)

  13 columnsthreshold_type, threshold_value, current_value, rate_per_day, projected_date, projected_date_low, projected_date_high, lookback_days, archetype, confidence, computed_at, historical_crossing_coverage, snapshot_date

  Sits beside summary_channel, summary_channel_metrics_daily, forecast_calibration_log, summary_channel_forecast

• summary_video_decay_model30 rowsPer-video decay model parameters: exponential / power-law fit coefficients, fit quality, and projected forward views over the next 30 / 90 days.

  Drives the decay-projection detector.

  One row per (video_id, snapshot_date)

  17 columnsvideo_id, fit_age_days, model_type, decay_rate_per_day, half_life_days, predicted_views_day_30, predicted_views_day_60, predicted_views_day_90, predicted_quiet_date, goodness_of_fit_r2, sample_size_days, usable_for_projection, shrink_weight, curve_cluster, curve_cluster_distance, quiet_date_uncertainty_days, snapshot_date

  Sits beside summary_video, video_daily

• summary_video_trajectory_cone8,580 rowsPer-(video, age_days) percentile-band trajectory cone (p10/p25/median/p75/p90 + mean + peer_count) over the channel's OTHER videos at the same age.

  Values are CUMULATIVE views by that age — each peer's running total of video_daily.views through the age, not the single day's count. Doubles as a forward-looking forecast band — rows exist for ages the subject has not yet reached, populated with the cone older peers traced at that age. A band draws from two peers up; between 2 and 4 peers the outer edges are the observed min/max rather than interpolated tails. Percentile columns are NULL when peer_count < 2 (one peer is not a distribution).

  One row per (video_id, age_days, snapshot_date)

  10 columnsvideo_id, age_days, views_p10, views_p25, views_p50, views_p75, views_p90, views_mean, peer_count, snapshot_date

  Sits beside summary_video, video_daily

  Feeds summary_video_nearest_peers

The cross-channel context this channel is read against — cohort cells and the named side-by-side rows.

• app_pool_cell_stat17,826 rowsStage-3 shared-pool aggregate slot, per snapshot: this channel's deciding cohort cell for each pool metric (views_28d, subs_28d, uploads_28d, video_day7_views, ctr_28d, the four traffic_*_share_28d mix shares, video_retention_half) — exactly one row per (metric, snapshot_date).

  Give-to-get: EVERY channel's build carries these cells whether or not the channel is in the shared pool — a non-pooled channel's cells are decided on its own cohort ladder but its values never enter any statistic (contribution stays consent-gated), and such a channel never gets the positioning columns (its honest grammar tops out at the quartile rung). gate_state is lit when the cell has data to show; the only non-lit value is withheld, which now marks a DARK row — the pool flag is off, or the metric has genuinely zero members — never a privacy withhold. All pool withholding was removed (operator- ratified): there is no k-anonymity floor, no dominant-member cap, no private-member-count rule, and no seeded noise. A whole-pool cell LIGHTS from the smallest real pool (≥2 members — the definition of a pool, not a floor) and publishes its RAW cohort statistics as-is. The deciding cell prefers the FINEST cohort rung holding ≥2 members (a real pool, as specific as the data allows); when no rung holds two, it falls back to the finest rung with at least one metric-contributing member — a member_band '1' bookkeeping row the dashboard never renders as a comparison. That lone member is usually the channel itself, but when the channel's own value is unknowable it can be a different pooled channel, whose exact value the row then carries. Lit rows carry the cell's median (and p25/p75 at the quartile rung), a floored member-count band, and a partial-pooling estimate for this channel (published whenever the channel is a member of the cell). At the percentile rung (a real pool — ≥2 members — with this channel itself a metric-contributing member) the row additionally carries this channel's standing in the cohort: subject_percentile, the observed range of the cohort's own member values (cohort_range_low/cohort_range_high), and trajectory_class (below/within/above that range). The range is a description of what the cohort's members actually recorded — the low and high edge of what happened — not a prediction and not a coverage claim: below 39 members it is exactly [min, max] of the members. Honesty is carried by accurate visuals + attribution (the floored member band, one tap away), never by a withheld cell or hedge copy; aggregates NEVER name a channel (cohort bands + counts + numbers only). The 28-day metrics are read over the days actually KNOWN inside the window and expressed as a 28-day equivalent — YouTube reports on a two-to-three day lag, so the newest days of any live window are simply not in yet, and demanding a complete window used to take the whole surface dark. known_days and window_scale record what the row saw and how much it was scaled, so a 28-day figure is never an un-auditable one; a fully observed window scales by exactly 1.0. A channel needs at least 14 known days in the window to contribute a value at all — a rule about whether the data was observed, never about how many channels are in the pool. The table also holds additive, age-indexed WHOLE-POOL cohort families on their own <family>:<age> cell keys (a magnitude band only — positioning columns and pooled_estimate stay NULL): chanage:<age> aligns pooled channels by days-since-first-video and publishes the RAW median + p25/p75 of cumulative subscribers (chan_cumulative_subscribers) and cumulative views (chan_cumulative_views) at that channel age — the source for the on-chart pool overlay — lit ONLY where ≥2 distinct channels align at that age (never a 1:1 mirror of a lone channel), with an HONEST member band ('2-4' at two channels). vidage:<age> is its video-grain sibling (per-day views by days-since-publish), lit once ≥2 videos across ≥2 pooled channels align at an age (the definition-of-pool rule — the only numeric gate) — and, like every family, it publishes the raw order statistics (the former ±2% small-cohort factor is gone).

  One row per (cell_key, metric, snapshot_date)

  17 columnscell_key, metric, snapshot_date, gate_state, rung, member_band, cell_median, cell_p25, cell_p75, pooled_estimate, subject_percentile, cohort_range_low, cohort_range_high, trajectory_class, known_days, window_scale, computed_at

  Read it with this in mindEmpty when the build ran without a pool-input extract (fixtures, local builds) — emptiness is the honest state, not an error. A channel NOT in the shared pool still carries these cells (give-to-get): the cohort statistics are the pool members' alone, the non-member channel contributes nothing and is never positioned. Exact member counts are never stored; member_band is the floored band. cell_p25/cell_p75 are NULL below the quartile rung (a single-member cell); the positioning columns (subject_percentile, cohort_range_low, cohort_range_high, trajectory_class) are NULL on every row below the percentile rung — cells where this channel is not itself a metric-contributing member, and the additive age-cohort families. pooled_estimate publishes for the channel-grain metrics whenever this channel is a member of the cell; it is NULL on the additive age-cohort families (chanage/vidage) and on dark rows. Fully re-derived every build, so a channel that leaves the pool vanishes from every snapshot on the next build. Cumulative-style monotonicity does NOT apply to this table.

  Sits beside app_pool_named_peer, summary_channel_metrics_daily

• app_pool_named_peer360 rowsThe open pool's named side-by-side rows, per snapshot: one row per channel that is currently BOTH public and pool-consented (this channel included when eligible).

  Carries only public-dashboard-class facts — lifetime totals (views, subscribers), video count, trailing 28-day views and uploads, and the channel's own median day-7 views — plus the peer's handle and display title. The same row set appears in every channel's DB; it is a pure function of the sweep-global pool extract.

  One row per (peer_contributor_id, snapshot_date)

  11 columnspeer_contributor_id, peer_handle, peer_title, snapshot_date, total_views, total_subscribers, video_count, views_28d, uploads_28d, video_day7_views_median, computed_at

  Read it with this in mindEmpty when the build ran without a pool-input extract. Peer lifetime totals can legitimately DECREASE across snapshot_date (deleted/privated videos, unsubscribes) and the peer set changes with consent — never assume monotonicity. views_28d is the 28-day equivalent over the days the pool's analytics history actually covers (reporting lag no longer blanks it), NULL only when fewer than 14 of the window's days are known; video_day7_views_median is NULL only when the peer has no video old enough for a day-7 reading. Current consent governs the whole history: every stored snapshot's rows reflect the channels consented TODAY.

  Sits beside app_pool_cell_stat

The file's own documentation: what each table and column means, worked query examples, the schema revision, and what data was available when.

• _aboutStart here23 rowsSingle-row product orientation.

  One key/value pair per fact the reader needs before querying: product name, schema version, build timestamp, reporting cutoff, voice rules, aggregate object counts, and the snapshot-date span (playhead_range_start / playhead_range_end) that every snapshot-extended table carries. compute_version is the SHA-1 of the build's compute-*.js source files only — it flips when logic in those modules changes between two deploys, signalling that derived tables were re-derived under updated code. Six sibling build modules that also shape derived rows are deliberately named outside that hash (write-pool-tables, pool-video-cohort, pool-channel-cohort, video-forecast-pool-prior, owner-tables, lifetime-seed), so an unchanged compute_version does not by itself prove every build module was unchanged. A new consumer should SELECT * FROM _about; before anything else.

  One row per (key)

  2 columnskey, value

  Read it with this in mindbuild_timestamp drifts on every rebuild; the fingerprint script normalizes it so semantic equality still works. playhead_range_* reflect the snapshot_date span of every snapshot-extended table — the canonical bounds for an as-of point-lookup (readers bind to the latest snapshot_date <= asOfDate).

  Sits beside _table_catalog, _column_catalog, _query_examples, _json_schema, schema_version

• _column_catalogStart here1,260 rowsOne row per column in every table and view.

  Carries type, unit, plain-language definition, nullability reason, enum values, and a pointer to a paired confidence column where applicable.

  One row per (table_name, column_name)

  10 columnstable_name, column_name, type, unit, definition, nullable_reason, enum_values, confidence_column, example_value, deprecated_alias

  Sits beside _table_catalog, _json_schema

• _json_schema48 rowsShape documentation for columns that store JSON text.

  Lists keys present, a worked example, and a description. Variant-aware so polymorphic columns (e.g. evidence_json shape per detector) can carry one row per variant.

  One row per (table_name, column_name, variant_value)

  7 columnstable_name, column_name, variant_key, variant_value, json_keys, example_value, description

  Sits beside _column_catalog

• _query_examplesStart here39 rowsGolden-path SQL examples.

  Each row is a (question, SQL) pair that illustrates a common analytical task end-to-end. Categorised and difficulty-tagged so a new consumer can scan, lift, and adapt.

  One row per (id)

  7 columnsid, category, question, difficulty, sql, expected_min_rows, notes

  Sits beside _table_catalog, _column_catalog

• _table_catalogStart here94 rowsIndex of every table and view in the public DB.

  Carries the layer, grain, row count, prose description, and relationship pointers (upstream_of / related_to). Renamed tables carry their old name in deprecated_alias.

  One row per (table_name)

  10 columnstable_name, layer, grain, row_count, description, query_first, upstream_of, related_to, caveats, deprecated_alias

  Sits beside _column_catalog, _query_examples, _about

• data_status6 rowsOne row per data domain (views, impressions, traffic_sources, channel_snapshots, reporting_timezone) with available_from / available_to date range and a human note.

  Read by the HonestyPanel "what data is in this view?" annotations. Plus one non-domain row, reporting_cutoff, whose available_to is the single date the dashboard charts through and whose source names the branch that resolved it.

  One row per (metric_type)

  6 columnsmetric_type, contributor_id, available_from, available_to, source, notes

  Sits beside _about, schema_version

• engagement_weights1 rowConfigurable weights table used by composite scores.

  Carries updated_at which is fingerprint-normalized.

  One row per (weight_name)

  5 columnsid, likes_weight, comments_weight, shares_weight, updated_at

  Sits beside summary_video

• metric_metadata30 rowsSemantic-metric definitions: each row carries a metric_id (e.g.

  ctr_confidence, reporting_timezone), plain-language definition, source tables, computation doc, and the confidence method. Surfaced via /data tile tooltips.

  One row per (metric_id)

  6 columnsmetric_id, definition, source_tables, computation_doc, confidence_method, last_modified

  Read it with this in mindCoexists with _column_catalog. Many metric_ids span multiple tables (source_tables is a comma list) and some (reporting_timezone, pre_publish_stub) are concepts rather than columns.

  Sits beside _column_catalog, _about

• schema_version77 rowsAppend-only log of schema versions with applied_at timestamps and a short note per version.

  The latest row's version number matches _about.schema_version.

  One row per (version)

  3 columnsversion, created_at, description

  Sits beside _about

Tables that exist to render this site rather than to describe the channel. Useful for reproducing a surface; skip them when analysing the channel itself.

• app_ctr_prior8 rowsWhat a click rate is compared against, at three levels.

  A CTR measured over five impressions and a CTR measured over fifty thousand are not the same kind of number, and until this table existed the dashboard handled that by hiding the thin one behind a tier label. Now each level publishes a typical click rate and how firmly that typical holds, and any (clicks, impressions) pair can be read against the nearest one: a video with a handful of impressions reads close to what its channel typically does, and the range shown around it stays wide until the impressions arrive to narrow it. Three scopes: pool — the typical rate across the OTHER channels in the shared pool, never including this channel's own number; channel — this channel's own typical rate, pulled toward the pool where one exists; channel_source — the same per traffic source, with scope_key holding the traffic_source_id, pulled toward the channel. Browse and Search click differently, so a per-source read leans on the surface it is actually on. prior_mean is the typical rate (a fraction 0..1); prior_strength is how many impressions' worth of evidence that typical is worth, so a channel whose videos all click alike carries a firmer typical than one whose videos scatter. prior_alpha / prior_beta split that strength across clicks and non-clicks.

  One row per (scope, scope_key, snapshot_date)

  13 columnsscope, scope_key, snapshot_date, prior_mean, prior_strength, prior_alpha, prior_beta, unit_count, observed_impressions, observed_clicks, parent_scope, member_band, computed_at

  Read it with this in mindIDENTITY WALL on the pool row: it carries a rate, a strength and member_band — the same floored channel band every other pool surface uses — and nothing else. unit_count, observed_impressions and observed_clicks are NULL on it by construction, because a leave-one-out impression total would be another member's own number on a small pool. No channel is ever named. The pool row is absent entirely on builds without a pool input (fixtures, local builds) — an honest absence, never an error. There is NO sample-size gate: a level is written whenever it has one impression to speak from, and a thin level says so through a low prior_strength, not by disappearing. prior_strength is clamped to [1, 5000] so a level where every unit agrees exactly cannot swallow a genuinely different video whole. Fully re-derived at every reporting cutoff; read the latest with WHERE snapshot_date = (SELECT MAX(snapshot_date) FROM app_ctr_prior). Deterministic — no randomness anywhere, REALs quantized to 6 decimals for cross-architecture byte-stability.

  Sits beside summary_video, summary_video_traffic, app_pool_cell_stat

• app_dashboard_briefing_daily442 rowsOne row per day with the dashboard's "today vs yesterday" briefing copy precomputed.

  Read by the homepage so server components don't run prose generators per request.

  One row per (date)

  10 columnsbriefing_date, briefing_rank, signal_id, title, body, reason_to_notice, confidence_tier, noise_reason, evidence_json, link_href

  Sits beside summary_channel_metrics_daily, summary_channel

  Once called dashboard_briefing_daily.

• app_detector_activity7 rowsPer-detector activity rollup over app_insight_snapshot: total_fires, first/last fired date, highest significance score and date.

  Bounded to the retained ~90-day snapshot tail; for lifetime totals use app_detector_lifetime. Powers the /help/detectors master list page.

  One row per (detector_name, snapshot_date)

  7 columnsdetector_name, total_fires, first_fired_date, last_fired_date, highest_significance, highest_significance_date, snapshot_date

  Sits beside app_insight_snapshot, app_detector_lifetime

  Once called summary_detector_activity.

• app_detector_lifetime58 rowsPer-detector LIFETIME accumulator. app_detector_activity is a window rollup over the retained ~90-day app_insight_snapshot tail; this table survives the prune by folding each new snapshot date's fires forward, so total_fires / first_fired_date are lifetime- accurate. scope='slot' mirrors the raw prose-routing-slot aggregation; scope='logical' is the recovered logical-detector aggregation.

  Overlaid onto the window rollups by /help/detectors.

  One row per (detector_name, scope)

  7 columnsdetector_name, scope, total_fires, first_fired_date, last_fired_date, highest_significance, through_date

  Sits beside app_insight_snapshot, app_detector_activity

• app_insight_snapshot6,614 rowsDaily snapshot of insight engine output.

  Each row is one insight_key ranked for a given snapshot_date. Backs the Moment chapter on the dashboard and the detector activity rollup.

  One row per (snapshot_date, insight_key)

  22 columnsid, contributor_id, snapshot_date, snapshot_order, insight_key, insight_id, detector_name, insight_category, subject_type, subject_id, significance, direction, certainty, title, body, context, evidence_json, generated_at, freshness_status, freshness_reason, freshness_prior_significance, signal_family

  Read it with this in mindgenerated_at is normalized away by the fingerprint script — it drifts on every rebuild without changing the insight content.

  Sits beside app_detector_activity

  Feeds app_detector_activity

  Once called insight_snapshot.

• app_metric_zscore_daily429 rowsPer-(metric, day) comparison of a trailing-7 value against the 28 days before it, in two readings: zscore in natural units (how many baseline standard deviations away) and surprise as a rank percentile bounded to [-1, 1].

  Used by the metric-anomaly detector and HonestyPanel "is today unusual?" annotations, and summed as |surprise| into summary_channel_metrics_daily.anomaly_score_composite — the bound is what stops one metric from swamping a day.

  One row per (metric_name, date)

  8 columnsdate, metric, value, baseline_mean, baseline_sd, zscore, sample_size, surprise

  Sits beside summary_channel_metrics_daily

  Once called metric_zscore_daily.

• app_wisdom_canon50 rowsCanonical list of YouTube growth beliefs the channel tests.

  Hand-authored. Each test_id carries the prose statement, the metric it bears on, and the test methodology.

  One row per (test_id)

  12 columnstest_id, belief_text, source_attribution, calculation_doc, requires_owner_mode, requires_cross_channel, default_thresholds_json, contributed_by, category, added_at, evidence_shape, agrees_directionality

  Sits beside app_wisdom_test, app_wisdom_verdict_daily

  Once called wisdom_canon.

• app_wisdom_flip_lifetime50 rowsPer-belief LIFETIME accumulator for the wisdom-flip history. app_wisdom_verdict_daily is bounded to a ~90-day tail, so a whole-ledger aggregate would go window-relative; this table folds each new verdict date forward so flip_count, first_seen_date, last_changed_date and current_streak_days stay lifetime-accurate.

  Read by /learnings (getWisdomHistorySummaries).

  One row per (test_id)

  8 columnstest_id, flip_count, first_seen_date, last_changed_date, current_status, current_confidence, current_streak_days, through_date

  Sits beside app_wisdom_verdict_daily, app_wisdom_canon

• app_wisdom_test50 rowsLatest verdict per wisdom test.

  Status is one of agrees, disagrees, inconclusive, not_currently_testable. Use not_yet_implemented flag (not status) to distinguish actively-tested rows from stubs.

  One row per (test_id, snapshot_date)

  10 columnstest_id, snapshot_date, status, inconclusive_reason, evidence_json, confidence, sample_size, prior_status, status_changed_today, not_yet_implemented

  Sits beside app_wisdom_canon, app_wisdom_verdict_daily

  Once called wisdom_test.

• app_wisdom_verdict_daily4,500 rowsVerdict history per wisdom test.

  Lets the dashboard render "this belief disagreed for three weeks then flipped" timelines. Bounded to a ~90-day forward tail (the de-walk); for a lifetime flip count / first-seen / streak use app_wisdom_flip_lifetime. status is the RAW per-build measurement. What surfaces show is the STABLE verdict derived from it: a new verdict takes over only after three consecutive builds hold it with |boundary_distance| >= 1, so a measurement hovering on its own threshold no longer reverses the belief every few days. Both readings are here — status for the raw series, boundary_distance for how far each build sat from the line.

  One row per (test_id, snapshot_date)

  11 columnsdate, test_id, status, inconclusive_reason, evidence_json, confidence, sample_size, prior_status, status_changed_today, not_yet_implemented, boundary_distance

  Sits beside app_wisdom_test, app_wisdom_canon, app_wisdom_flip_lifetime

  Once called wisdom_verdict_daily.

• owner_read_dailyStart here90 rowsOne consolidated "today's read" row per snapshot_date — the synthesis the home/digest surfaces lead with.

  NOT a new raw metric: it consolidates signals that already exist (the day's ranked insights from app_insight_snapshot, the trailing-7d channel rollup vs the prior window, the forecast usability tier) into one row a reader can dispatch on without re-assembling them. Each row carries the views/subs/impressions trend tags + their 7d windows, the top-mover video and its share, source-mix direction, active/quiet catalog split, the day's lead insight (key + signal_family + significance), and a sample-of-one thin_read honesty flag for days too quiet to read as anything but quiet. Populated by dashboard/scripts/generate-snapshots.ts inside its per-snapshot-date loop (empty at clean-build time, like app_insight_snapshot). Backfill-pattern-bound: PK ends in snapshot_date, computed_at binds to the snapshot date.

  One row per (snapshot_date)

  24 columnssnapshot_date, views_trend, subs_trend, impressions_trend, views_7d, views_7d_prior, subs_gained_7d, subs_gained_7d_prior, impressions_7d, impressions_7d_prior, top_mover_video_id, top_mover_share, source_diversity_score, source_mix_direction, active_video_count, quiet_video_count, forecast_usability, top_insight_key, top_signal_family, top_significance, insight_count, thin_read, thin_read_reason, computed_at

  Sits beside app_insight_snapshot, summary_channel_metrics_daily, summary_channel_forecast