Product Requirements Document

Card Trend Intelligence

A deterministic early-warning system for collectible demand. It combines performance, cultural attention, card-market participation, liquidity, supply, grading, price, and catalyst evidence to identify under-the-radar, confirming, crowded, and fading trends.

Version1.0

Generated2026-08-09T23:54:16+00:00

SourcePRD Markdown v1.0

Product Requirements Document: Card Trend Intelligence System

Working name: Card Trend Intelligence (CTI)
Document type: Product Requirements Document (PRD)
Version: 1.0
Status: Architecture-ready
Generated: 2026-08-09
Primary audience: Product architecture, data architecture, application engineering, analytics engineering, AI/ML engineering, security, operations
Secondary audience: Collectors, hobby-market researchers, product stakeholders

1. Executive Summary

Card Trend Intelligence is a market-signal platform for identifying emerging, confirming, crowded, and fading trends in trading cards before those trends are obvious from price alone.

The system combines:

player or subject performance;
general search interest;
creator and social breadth;
card-specific attention;
transaction velocity;
active inventory;
grading activity;
population growth;
sealed-product activity;
price movement;
release and event catalysts;
market concentration;
provenance and evidence quality.

The core product question is:

What player, character, set, product, or card is gaining real-world or cultural momentum faster than its card market is repricing?

The inverse question is equally important:

Where has card-market enthusiasm become materially stronger than underlying performance, participation, liquidity, or demand?

The platform must not depend on a large language model to determine whether something is trending. Trend classification must be deterministic, explainable, reproducible, and traceable to source observations.

AI may assist with:

ambiguous entity resolution;
content classification;
summarization;
catalyst extraction;
narrative explanation;
analyst workflows.

AI must not be the authoritative scoring engine.

The product should initially focus on sports and major collectible-card ecosystems, while using a generalized ontology and signal model that allows later expansion to entertainment cards, TCGs, creators, and other collectible categories.

2. Product Decision

2.1 Recommendation

Build a signal intelligence platform, not a price guide and not a “top cards to buy” recommendation engine.

The product should rank market conditions and anomalies, not make unsupported investment claims.

The primary output should be:

what is changing;
why it is changing;
how early or mature the trend is;
whether independent sources agree;
which cards or card families are participating;
what evidence would invalidate the trend;
what risks suggest the market may already be crowded.

2.2 Product thesis

Card markets often reprice after earlier signals appear elsewhere.

A simplified lifecycle is:

PLAYER / SUBJECT PERFORMANCE
        ↓
GENERAL ATTENTION
        ↓
CARD-SPECIFIC ATTENTION
        ↓
TRANSACTION VELOCITY
        ↓
INVENTORY ABSORPTION
        ↓
PRICE MOVEMENT
        ↓
GRADING / SUPPLY RESPONSE
        ↓
CROWDING / DISTRIBUTION / FADE

A useful system should identify divergence between these stages.

Examples:

performance rises sharply while hobby demand remains modest;
search and creator breadth accelerate before prices rise;
transaction velocity increases while inventory shrinks;
prices surge while sales liquidity falls;
graded population grows faster than demand;
sealed product appreciates while underlying singles remain weak;
one influencer creates apparent hype without broad participation.

3. Problem Statement

Collectors and hobby-market participants currently rely on fragmented signals.

Relevant information is distributed across:

sports statistics;
Google search behavior;
YouTube;
Instagram;
TikTok;
Reddit;
marketplaces;
grading companies;
price guides;
release calendars;
card manufacturers;
leagues;
team and player news;
live-commerce platforms;
card shows and community activity.

Most existing products emphasize:

historical prices;
recent sales;
population reports;
portfolio tracking;
individual marketplace search.

These products are useful but usually answer:

“What has already happened?”

The opportunity is to answer:

“What appears to be starting, how confident are we, and which evidence supports that conclusion?”

4. Goals

4.1 Primary goals

The system must:

detect emerging player, subject, set, product, and card trends;
detect market trends before price becomes the dominant signal;
distinguish broad trends from concentrated or manufactured hype;
identify performance-to-hobby divergence;
identify player-to-card divergence;
measure transaction and inventory confirmation;
measure grading and population risk;
classify trend maturity;
retain complete source provenance;
expose evidence behind every score and classification;
support historical replay of prior trend decisions;
support scheduled monitoring and alerts;
allow independent replacement of data sources;
support multiple sports and collectible categories without redesigning the core domain model.

4.2 Secondary goals

The system should:

support researcher-defined watchlists;
detect category-level trends;
discover related entities;
correlate catalysts with signal changes;
expose confidence separately from momentum;
support analyst notes and manual overrides;
allow later simulation or backtesting;
support portfolio/watchlist monitoring without requiring a brokerage-like model;
provide machine-readable APIs for future agents and applications.

5. Non-Goals

The initial system will not:

guarantee financial returns;
issue regulated financial advice;
execute purchases or sales;
automatically bid on auctions;
scrape websites in violation of terms of service;
depend on unrestricted TikTok or Instagram access;
use an LLM as a numerical trend oracle;
treat asking prices as equivalent to verified sales;
assume a /1 serial number is inherently valuable;
treat player popularity as equivalent to card liquidity;
infer card scarcity without population, print-run, or supply evidence;
build a generalized social-network crawler;
require Kafka, Kubernetes, or other high-complexity infrastructure for the MVP.

6. Target Users

6.1 Advanced collector

Needs to understand:

which players or card families are gaining momentum;
whether a trend is early or already crowded;
whether price movement is supported by liquidity;
which card expressions are receiving demand.

Primary action:

Investigate a candidate before making a collecting decision.

6.2 Market researcher

Needs to understand:

category and player trends;
causal catalysts;
cross-platform confirmation;
changes over time;
anomalies and divergences.

Primary action:

Explain what is changing in the hobby and why.

6.3 Data/technical user

Needs:

APIs;
raw observations;
entity mappings;
feature values;
source lineage;
reproducible scoring.

Primary action:

Build additional models, dashboards, workflows, or alerts.

6.4 Product operator

Needs:

collector health;
data-source status;
API quotas;
broken entity mappings;
unresolved aliases;
scoring-version history;
anomaly review.

Primary action:

Keep the trend intelligence trustworthy and operational.

7. Core Product Concepts

7.1 Observation

An immutable measurement from a source.

Examples:

Google search index for “Munetaka Murakami cards”;
number of YouTube creators mentioning a player;
eBay active listing count;
median verified sale price;
PSA population count;
Topps release date;
player home-run total;
Reddit post count;
number of new cards graded in seven days.

An observation is evidence, not interpretation.

7.2 Entity

A canonical thing the system tracks.

Examples:

NBA;
MLB;
Pokémon;
Cooper Flagg;
Charizard;
2026 Topps Chrome Basketball;
2026 Topps Chrome Cooper Flagg #201;
PSA 10 version of a card;
a serial-numbered parallel.

7.3 Signal

A derived metric produced from observations.

Examples:

seven-day search velocity;
creator-breadth acceleration;
inventory depletion;
transaction growth;
grading-population acceleration;
price momentum;
market concentration.

7.4 Trend

A deterministic classification derived from multiple signals.

Examples:

Emerging;
Confirming;
Established;
Crowded;
Fading;
Re-emerging.

7.5 Confidence

A separate measure representing how much independent evidence supports the trend.

High trend score with low confidence means:

Something is moving strongly, but evidence is concentrated or incomplete.

Moderate trend score with high confidence means:

Several independent signal families agree.

8. Domain Model

The system must support a generalized collectible graph.

8.1 Entity types

category
sport
league
team
ip
game
person
player
character
manufacturer
brand
set
product
card
parallel
variant
grade
grader
event
marketplace
source

The model must be extensible.

8.2 Example sports hierarchy

Sports
└── Basketball
    └── NBA
        └── Dallas Mavericks
            └── Cooper Flagg
                └── 2025-26 Topps Chrome
                    └── Cooper Flagg Rookie #201
                        ├── Base
                        ├── Refractor
                        ├── /99
                        ├── /25
                        ├── Auto
                        └── 1/1

8.3 Example TCG hierarchy

TCG
└── Pokémon
    └── Mega Evolution
        └── Charizard
            └── Charizard ex
                ├── Raw
                ├── PSA 9
                └── PSA 10

8.4 Relationship types

At minimum:

belongs_to
contains
appears_on
plays_for
part_of
manufactured_by
licensed_by
parallel_of
variant_of
graded_by
related_to
triggered_by
precedes
succeeds
alias_of

The architecture may implement this in relational tables initially.

A graph database is not required for MVP.

9. Signal Taxonomy

The system must maintain separate signal families.

9.1 Performance signals

For athletes:

recent production;
season production;
rate statistics;
advanced metrics;
minutes/playing time;
role changes;
lineup changes;
injuries and returns;
prospect call-ups;
rookie debuts;
awards;
records;
milestones;
team context;
playoff exposure.

For non-athlete subjects:

release activity;
media exposure;
tournament activity;
IP events;
anniversaries;
new products;
cultural events.

9.2 General attention signals

Google Trends;
search-result volume where defensible;
YouTube publication volume;
unique creator count;
YouTube views;
comments;
Reddit discussion volume;
general news frequency;
publicly accessible social activity.

9.3 Card-specific attention signals

videos explicitly mentioning cards;
card-specific search terms;
marketplace search volume if available;
watchlist counts if available;
card community mentions;
grading searches;
set-specific social discussion.

9.4 Commerce signals

verified sales per time window;
unique buyers where available;
unique sellers;
auction count;
number of bids;
median transaction price;
transaction price distribution;
active listing count;
active seller count;
inventory depletion;
sell-through rate;
days-to-sale;
bid depth.

9.5 Price signals

raw-card median price;
graded-card median price;
card-family index;
player index;
category index;
sealed-product market price;
MSRP;
spread between grades;
spread between raw and graded.

Asking prices must never be represented as verified transaction prices.

9.6 Collector conviction signals

grading submission velocity;
PSA/BGS/CGC/SGC population growth;
gem rate;
percentage of high-grade submissions;
sealed-product premium;
repeat transaction activity;
sustained volume after initial catalyst.

9.7 Supply-risk signals

population growth;
PSA 10 population growth;
listing growth;
seller growth;
print-run data;
serial-number parallel count;
number of equivalent “1/1” variants;
sealed supply;
reprint announcements.

9.8 Catalyst signals

release dates;
product announcements;
league events;
awards;
milestones;
player trades;
injuries;
debuts;
championships;
media appearances;
movie/game releases;
anniversaries;
card bounties;
conventions;
card shows;
licensing changes.

Catalysts must be modeled separately from trend scores.

A known catalyst can explain a trend but must not automatically create one.

10. Primary Derived Metrics

10.1 Player Momentum

Represents change in the underlying athlete or subject.

Initial conceptual model:

PlayerMomentum =
  RecentPerformance
+ RoleChange
+ RelativePerformance
+ Exposure
+ CatalystStrength

The exact feature weights must be configurable and versioned by sport.

10.2 Hobby Momentum

Represents card-market attention and participation.

HobbyMomentum =
  SearchAcceleration
+ CreatorBreadth
+ CardAttention
+ TransactionVelocity
+ InventoryAbsorption
+ GradingVelocity
+ PriceMomentum

10.3 Hobby Gap

Core under-the-radar measure.

HobbyGap = PlayerMomentum - HobbyMomentum

Interpretation:

large positive value: underlying subject momentum may be ahead of card demand;
near zero: hobby and subject momentum are aligned;
large negative value: hobby expectations may be ahead of underlying momentum.

Scores must be normalized before subtraction.

10.4 Card Momentum

Represents the market behavior of a specific card or card family.

CardMomentum =
  CardSearch
+ CardCreatorBreadth
+ TransactionVelocity
+ SellThrough
+ InventoryAbsorption
+ PriceMomentum
+ GradingDemand

10.5 Card Gap

Measures whether a particular card is participating in a player's broader trend.

CardGap = PlayerOrSubjectMomentum - CardMomentum

This enables conclusions such as:

Player trend: strong
Rookie autos: strong
Numbered parallels: confirming
Base PSA 10: weak
Mass-produced flagship base: fading

The product should avoid reducing a player thesis to “buy any card of this player.”

10.6 Supply Pressure

SupplyPressure =
  PopulationGrowth
+ ListingGrowth
+ SellerGrowth
+ PrintRunGrowth

10.7 Liquidity Quality

LiquidityQuality =
  TransactionCount
+ BuyerBreadth
+ SellerBreadth
+ BidDepth
- PriceDispersionPenalty
- ThinMarketPenalty

10.8 Creator Breadth

Number of distinct creators discussing an entity within a time window.

This must be reported separately from total views.

10.9 Creator Concentration

Use a concentration measure such as HHI.

HHI = Σ(s_i²)

where s_i is each creator's share of total measured attention.

A high HHI reduces confidence.

10.10 Sell-Through

Where sufficient data exists:

SellThrough =
  SoldListings /
  (SoldListings + ActiveListings)

Alternative fixed-window definitions may be used if marketplaces expose different data.

The chosen definition must be source-specific and documented.

11. Time-Series Requirements

The system must calculate rolling windows for:

1 day;
3 days;
7 days;
14 days;
30 days;
90 days;
365 days where data exists.

For every metric, support:

current value;
previous-window value;
absolute delta;
percentage delta;
velocity;
acceleration;
percentile;
moving average;
volatility;
robust deviation;
data coverage.

12. Normalization

Absolute values are insufficient.

Every entity should primarily be compared against:

its own historical baseline;
its relevant peer cohort;
its category.

Example:

A niche UFC fighter going from 100 to 700 searches may be more significant than Charizard moving from 500,000 to 530,000.

The initial engine should support:

Standard Z-score

z = (x - μ) / σ

Robust Z-score

Preferred for noisy social and market data:

RobustZ =
  (x - Median(x)) /
  (1.4826 × MAD(x))

Use robust normalization where outliers are common.

13. Trend Scoring

The trend engine must be deterministic and versioned.

An initial configurable model may be:

TrendScore =
  0.20 AttentionAcceleration
+ 0.15 CreatorBreadth
+ 0.25 TransactionVelocity
+ 0.10 SupplyAbsorption
+ 0.10 PriceMomentum
+ 0.08 SealedMomentum
+ 0.07 GradingMomentum
+ 0.05 CatalystContext
- RiskPenalty

These weights are a starting hypothesis, not an industry standard.

They must:

be configurable;
be stored with scoring version;
be testable;
support category-specific variants;
support later calibration using historical backtests.

14. Confidence Scoring

Confidence is not trend magnitude.

Confidence should increase when:

multiple independent source families agree;
source coverage is complete;
creator concentration is low;
transaction counts are sufficient;
observations persist across multiple windows;
market matching confidence is high;
entity resolution confidence is high.

Confidence should decrease when:

one source dominates;
one creator dominates;
transaction count is thin;
price dispersion is extreme;
entity matching is uncertain;
the source is stale;
a source is missing;
data was inferred rather than directly observed.

Example:

Trend: 91
Confidence: 32

Interpretation:
Strong movement, weak confirmation.

versus:

Trend: 73
Confidence: 94

Interpretation:
Broad, persistent trend confirmed across independent sources.

15. Trend Lifecycle State Machine

Required states:

Dormant
Emerging
Confirming
Established
Crowded
Fading
Re-Emerging

Conceptual transitions:

stateDiagram-v2
    [*] --> Dormant

    Dormant --> Emerging
    Emerging --> Confirming
    Emerging --> Dormant

    Confirming --> Established
    Confirming --> Fading

    Established --> Crowded
    Established --> Fading

    Crowded --> Fading
    Fading --> Dormant
    Fading --> ReEmerging
    ReEmerging --> Confirming

15.1 Example classification logic

Emerging

Typical characteristics:

player/subject momentum rising;
search acceleration rising;
creator breadth rising;
price still flat or modest;
commerce may be early.

Confirming

Typical characteristics:

multiple independent sources agree;
transaction velocity rising;
inventory contracting;
price beginning to respond.

Established

Typical characteristics:

sustained participation;
strong liquidity;
pricing and transactions agree;
broad collector participation.

Crowded

Typical characteristics:

population and listings rising rapidly;
price growth exceeds participation growth;
creator concentration increases;
underlying player momentum no longer leads hobby momentum.

Fading

Typical characteristics:

search declines;
creator breadth declines;
transaction volume declines;
listings increase;
prices become less liquid.

16. Hysteresis

The system must prevent daily state flapping.

Example:

Enter Confirming:
score >= 70 for three consecutive observations

Leave Confirming:
score < 55 for three consecutive observations

Entry and exit thresholds must be configurable.

State transitions must be recorded historically.

17. Divergence Detection

Divergences should be first-class outputs.

17.1 Early demand divergence

Search ↑↑
Creator breadth ↑↑
Sales ↑
Price →

Interpretation:

Potential early trend.

17.2 Supply-risk divergence

Graded population ↑↑↑
Sales ↑
Search →
Price ↑

Interpretation:

Potential population dilution.

17.3 Sealed speculation divergence

Sealed price ↑↑↑
Singles →
Transactions →
Social ↑

Interpretation:

Wax speculation may be ahead of underlying single-card demand.

17.4 Distribution divergence

Price ↑↑
Sales ↓
Search ↓
Listings ↑

Interpretation:

Potential market distribution into weakening liquidity.

18. Source Strategy

The data layer must use adapters.

No downstream component should depend on a source-specific schema.

18.1 Initial source priorities

Tier 1: MVP

sports statistics / official league data;
Google Trends or equivalent search-interest source;
YouTube Data API;
eBay active inventory;
GemRate;
PSA population pages or licensed source;
Card Ladder or equivalent market index/sales source where commercially available;
Topps / manufacturer release calendars;
official league/team/player news.

Tier 2: enrichment

Reddit;
Instagram where approved;
additional grading companies;
PriceCharting;
Fanatics;
auction houses;
Whatnot data where permitted;
card-show calendars.

Tier 3: restricted / optional

TikTok;
X;
premium market-data feeds;
proprietary marketplace analytics.

The MVP must remain useful without Tier 3 sources.

19. Source Adapter Contract

Each source adapter should implement a common interface.

Example:

export interface SignalCollector {
  id: string;
  version: string;

  collect(input: {
    entities: EntityRef[];
    since: Date;
    until: Date;
    cursor?: string;
  }): Promise<CollectorResult>;
}

CollectorResult should contain:

interface CollectorResult {
  observations: Observation[];
  nextCursor?: string;

  metadata: {
    source: string;
    collectedAt: string;
    requestCount: number;
    partial: boolean;
    warnings: string[];
  };
}

Collectors must not perform downstream scoring.

20. Observation Contract

Example:

interface Observation {
  id: string;

  source: string;
  sourceType:
    | "official_api"
    | "licensed_api"
    | "public_web"
    | "partner_feed"
    | "manual";

  entityId?: string;
  rawEntityText?: string;

  observedAt: string;
  collectedAt: string;

  metric: string;
  value: number;
  unit?: string;

  dimensions?: Record<string, string | number | boolean>;

  resolution?: {
    confidence: number;
    method: "exact" | "alias" | "fuzzy" | "rule" | "llm" | "manual";
  };

  provenance: Provenance;
}

Observations should be append-only.

Corrections should create new records or correction events rather than mutating historical evidence invisibly.

21. Provenance Requirements

Every observation must preserve:

source;
source URL or API endpoint identifier;
query or request parameters where permitted;
retrieval timestamp;
observation timestamp;
collector version;
normalization version;
entity-resolution version;
source confidence;
transformation steps;
raw source identifier;
licensing or usage constraints when known.

Every derived metric must preserve:

input observation IDs;
scoring version;
calculation time;
formula/version;
missing-data policy;
confidence calculation.

Every trend explanation must trace back to:

claim
→ feature
→ rollup
→ observations
→ source

22. Entity Resolution

Entity resolution is a critical subsystem.

Examples:

Cooper Flagg
Flagg
Flagg RC
2025-26 Flagg
Topps Chrome Flagg
Flagg rookie refractor

These may refer to related but distinct entities.

The system must resolve them hierarchically.

22.1 Resolution order

exact canonical ID;
exact alias;
normalized alias;
domain rules;
fuzzy candidate generation;
optional LLM adjudication;
manual review.

22.2 Confidence thresholds

Example:

>= 0.95  auto-link
0.70–0.95  LLM or rule-assisted adjudication
< 0.70   unresolved/review queue

Thresholds must be configurable.

22.3 Learning aliases

Once a previously unresolved phrase is confidently mapped, store the alias.

Example:

"topps chrome flagg super"
→ CARD-229194

The system should not repeatedly pay AI or computational cost for known aliases.

23. AI Responsibilities

AI is optional and bounded.

Allowed

ambiguous entity resolution;
classify content as card-related or general;
identify likely catalyst from article/post;
summarize evidence;
generate narrative explanations;
create analyst briefings;
propose aliases;
extract card attributes from unstructured text;
cluster related content.

Not authoritative

AI must not:

invent prices;
infer sales without evidence;
set trend scores directly;
replace deterministic feature computation;
overwrite source data;
mark a card “buy” or “sell” without rule-defined evidence;
fabricate provenance.

All AI outputs must include:

model identifier;
prompt/template version;
input references;
output timestamp;
confidence or review status.

24. Player Performance Layer

Sports use cases require a player-performance subsystem.

Each sport needs a feature adapter.

Example MLB inputs:

plate appearances;
batting average;
OBP;
SLG;
OPS;
wRC+ if licensed;
home runs;
stolen bases;
Statcast measures where available;
lineup position;
playing time;
team context.

Example NBA inputs:

minutes;
points;
rebounds;
assists;
true shooting;
usage;
starting role;
injuries;
rookie ladder / awards context.

Player Momentum must use sport-specific normalization.

A 20-point NBA game and a two-home-run MLB game cannot be processed through a naive common metric.

25. Event Detection

The system should recognize unusual performance events.

Examples:

career high;
multi-home-run game;
triple-double;
record;
debut;
game-winning performance;
prospect call-up;
championship;
award;
viral moment.

Events should start an observation clock.

Example:

T0
6h
24h
48h
72h
7d
14d

The system should compare pre-event and post-event:

search;
creator activity;
card-specific attention;
sales;
listings;
price;
grading.

This allows evaluation of whether an event became a durable hobby trend.

26. Card Selection Layer

A player trend does not imply all cards are desirable.

The system must support card-family analysis.

For each player or subject, group cards by:

rookie vs non-rookie;
flagship;
chrome;
autograph;
patch;
serial-numbered;
parallel;
insert;
base;
raw;
graded;
grader;
grade;
population;
print run where known.

The product should support statements such as:

PLAYER
Kon Knueppel       ↑↑

CARD FAMILIES
Rookie Autos       ↑↑
Numbered Chrome    ↑
Chrome Base        ↓
Flagship Base      ↓↓

27. Risk Model

Trend output must include risks.

Potential penalties:

creator concentration;
thin transactions;
extreme bid/ask spread;
rapid population dilution;
rapidly increasing active listings;
low buyer breadth;
large known print run;
uncertain entity matching;
unverified marketplace transactions;
source disagreement;
event-only spike;
stale data;
low sample count.

A trend must never be presented without material risk indicators when they exist.

28. Market Manipulation / Hype Controls

The system must explicitly detect potential manufactured hype.

Signals:

one creator responsible for most views;
repeated reposts rather than unique creators;
sudden price jump on very low transaction count;
suspicious wash-like repeated sales if data permits;
rapid listing-price increases without verified sale confirmation;
highly concentrated seller inventory;
low-liquidity cards showing extreme percentage changes.

The product should label these:

Low Evidence
Concentrated Attention
Thin Market
Price Without Liquidity
Supply Expansion
Event Spike

These are evidence labels, not accusations of manipulation.

29. User-Facing Trend Labels

Avoid simplistic “BUY NOW” language.

Preferred labels:

Under Radar
Early Watch
Emerging
Confirming
Established
Crowded
Supply Risk
Event Spike
Fading
Re-Emerging

Optional analyst actions:

Investigate
Watch
Confirm
Avoid Chasing
Review Supply
Review Liquidity

30. Core Screens

30.1 Trend Radar

Primary question:

What is changing right now?

Example:

RANK  ENTITY              STATE         TREND  CONF  Δ7D
01    Hunter Goodman      Under Radar     88    78   ↑18
02    Murakami            Confirming      84    91   ↑11
03    UFC                 Emerging        82    87   ↑24
04    Pokémon Mega Evo    Established     78    94   ↑3
05    Roman Anthony       Crowded         76    89   ↓2

Actual values must come only from computed data.

30.2 Entity Detail

Must show:

current trend state;
trend score;
confidence;
player/subject momentum;
hobby momentum;
hobby gap;
card momentum;
supply pressure;
liquidity quality;
catalyst timeline;
evidence;
card-family breakdown;
history;
risks.

Example:

Search                  +42%
Independent creators    +67%
Sales/week              +38%
Active listings         -14%
Median verified price   +9%
Graded population       +6%

Known catalyst:
Upcoming product release

Confidence:
5 independent signal families agree

30.4 Under-the-Radar view

Rank by:

High Player Momentum
+
High Attention Acceleration
+
Early Commerce Confirmation
-
Price Saturation
-
Population Risk

This should be one of the primary product views.

30.5 Crowded / Risk view

Rank markets where:

hobby momentum exceeds player momentum;
price growth exceeds transaction growth;
population expands rapidly;
listings rise;
attention decelerates.

30.6 Card Expression view

For one player:

Player
├── Rookie Autos
├── Numbered Refractors
├── Base Chrome
├── Flagship Base
├── Inserts
└── Patches

Display trend and liquidity independently for each.

31. Visualization Requirements

Recommended visualizations:

trend lifecycle timeline;
attention vs commerce chart;
player momentum vs hobby momentum scatter;
trend vs confidence radar;
price vs sales velocity;
inventory depletion timeline;
population-growth timeline;
event/catalyst overlay;
card-family heat map.

Avoid charts that imply causation when only correlation exists.

Every chart must expose source and time window.

32. API Requirements

Initial API surface:

GET /entities
GET /entities/:id
GET /entities/:id/observations
GET /entities/:id/signals
GET /entities/:id/trend
GET /entities/:id/history
GET /entities/:id/cards
GET /entities/:id/catalysts

GET /trends
GET /trends/emerging
GET /trends/under-radar
GET /trends/crowded
GET /trends/fading

GET /cards/:id
GET /cards/:id/market
GET /cards/:id/population

GET /sources
GET /sources/health

POST /watchlists
POST /alerts

API responses must include:

generated timestamp;
scoring version;
source coverage;
confidence;
provenance links or IDs.

33. Alerting

Alert types:

33.1 Under-the-radar alert

Trigger when:

Player Momentum high;
Hobby Gap positive;
attention accelerating;
early commerce confirmation;
price still moderate;
confidence above threshold.

33.2 Confirmation alert

Trigger when:

transaction velocity increases;
inventory contracts;
multiple platforms agree.

33.3 Crowding alert

Trigger when:

price momentum materially exceeds liquidity;
population growth accelerates;
listing growth increases;
attention stops accelerating.

33.4 Fade alert

Trigger when:

attention rolls over;
transactions decline;
listings rise;
price remains elevated or begins declining.

Alert deduplication and hysteresis are mandatory.

34. Scheduling

Initial cadence:

Source type	Suggested cadence
player stats	hourly/daily depending on season
major events	hourly
search interest	daily
YouTube	6–24 hours
active inventory	6–24 hours
verified sales	daily
grading	daily
release calendars	daily
category indexes	daily
narrative brief	daily

Cadence must respect API quotas and source agreements.

35. Data Storage

35.1 MVP

Recommended:

Node.js 24+
TypeScript
SQLite
Drizzle ORM
Hono or Fastify
scheduled jobs
native fetch
Zod
server-rendered or simple static HTML frontend

No distributed infrastructure is required initially.

35.2 Scale path

Potential progression:

SQLite
  ↓
PostgreSQL
  ↓
PostgreSQL + TimescaleDB

Or ClickHouse if analytical event volume becomes very large.

The architecture should not prematurely require a graph database.

36. Suggested Relational Schema

Core tables:

entities
entity_aliases
entity_relations

sources
source_collectors
source_health

observations
observation_corrections

metric_rollups
feature_values

trend_scores
trend_state_history

catalysts
catalyst_entity_links

cards
card_attributes
card_populations

market_listings
market_sales

ai_annotations
analyst_notes

provenance
scoring_versions
normalization_versions

37. Example Entity Schema

CREATE TABLE entities (
  id TEXT PRIMARY KEY,
  type TEXT NOT NULL,
  name TEXT NOT NULL,
  parent_id TEXT,
  canonical_key TEXT UNIQUE,
  created_at TEXT NOT NULL,
  updated_at TEXT NOT NULL
);

38. Example Observation Schema

CREATE TABLE observations (
  id TEXT PRIMARY KEY,
  entity_id TEXT,
  source_id TEXT NOT NULL,
  metric TEXT NOT NULL,
  value REAL NOT NULL,
  unit TEXT,
  observed_at TEXT NOT NULL,
  collected_at TEXT NOT NULL,
  dimensions_json TEXT,
  provenance_id TEXT NOT NULL,
  FOREIGN KEY(entity_id) REFERENCES entities(id)
);

39. Example Rollup Schema

CREATE TABLE metric_rollups (
  id TEXT PRIMARY KEY,
  entity_id TEXT NOT NULL,
  metric TEXT NOT NULL,
  window TEXT NOT NULL,
  value REAL,
  delta REAL,
  pct_delta REAL,
  velocity REAL,
  acceleration REAL,
  robust_z REAL,
  percentile REAL,
  coverage REAL,
  calculated_at TEXT NOT NULL,
  calculation_version TEXT NOT NULL
);

40. Example Trend Schema

CREATE TABLE trend_scores (
  id TEXT PRIMARY KEY,
  entity_id TEXT NOT NULL,

  attention REAL,
  commerce REAL,
  conviction REAL,
  catalyst REAL,
  supply_risk REAL,
  liquidity REAL,

  player_momentum REAL,
  hobby_momentum REAL,
  hobby_gap REAL,

  trend_score REAL NOT NULL,
  confidence REAL NOT NULL,
  state TEXT NOT NULL,

  scoring_version TEXT NOT NULL,
  calculated_at TEXT NOT NULL
);

41. Data Quality

Each metric must include:

sample count;
source freshness;
entity resolution confidence;
missing data;
source coverage;
estimated vs directly measured status.

The UI must not silently treat missing data as zero.

Required semantics:

0 = measured zero
null = unavailable / not observed
estimated = derived approximation

42. Source Health

Every collector should report:

last successful run;
last failed run;
API status;
quota remaining where available;
freshness;
record count;
parsing errors;
schema drift;
authentication status.

Source degradation must reduce confidence automatically when material.

43. Backtesting

The architecture must support historical replay.

Given:

date = 2026-05-01
scoring_version = v1.2

the system should be able to reconstruct:

observations available at that time;
feature values;
trend score;
confidence;
state.

This prevents hindsight bias.

Future scoring versions should be testable against historical outcomes.

44. Evaluation Framework

The product needs stronger evaluation than “did the price go up?”

Evaluate:

Detection quality

precision of Emerging labels;
false positive rate;
trend persistence;
time to confirmation;
time before price response.

Market-quality measures

increase in transaction velocity after detection;
reduction in inventory after detection;
sustained search/creator growth;
subsequent liquidity.

Risk detection

percentage of Crowded alerts followed by demand slowdown;
population-risk accuracy;
thin-market false-positive rate.

45. Success Metrics

MVP

The MVP succeeds if it can:

track at least 100 player/subject entities;
ingest at least four independent signal families;
retain source provenance for >99% of observations;
produce trend and confidence scores daily;
identify under-the-radar and crowded candidates;
explain every score through traceable evidence;
replay prior scoring decisions;
support at least MLB and NBA without rewriting the platform;
operate for 30 days without manual data reconstruction.

Product success

Longer-term success indicators:

useful trends identified before significant price repricing;
high agreement between early signals and later transaction growth;
low rate of trend alerts based only on one social source;
low false-positive rate from thin markets;
user investigation time reduced materially;
evidence chain considered trustworthy by expert collectors.

46. Security Requirements

The system must:

store API credentials in secret management;
never expose source credentials to the browser;
enforce least privilege;
record administrative actions;
validate all external data;
sanitize untrusted content;
protect against HTML/script injection in titles/descriptions;
rate-limit public APIs;
isolate AI prompts from raw executable content;
treat public social/media text as untrusted input.

If deployed publicly:

add authentication;
add RBAC;
separate read-only analyst access from administrative operations.

47. Legal / Data Governance

Each source must record:

access method;
terms-of-service constraints;
commercial-use status;
retention restrictions;
attribution requirements;
redistribution restrictions.

Do not rely on unauthorized scraping for core product functionality.

If a source becomes unavailable, the adapter architecture must allow replacement.

48. Reliability Requirements

MVP target:

daily scoring completion >99%;
no silent collector failures;
failed collectors do not corrupt prior observations;
partial data produces partial confidence, not false certainty;
source failures must be visible.

All pipelines must be idempotent where possible.

49. Performance Requirements

Initial goals:

entity detail response <500 ms from precomputed rollups;
trend list <1 second;
daily scoring for 10,000 entities <10 minutes on commodity infrastructure;
raw ingestion may be asynchronous;
expensive AI analysis must not block deterministic scoring.

50. Explainability Requirements

Every trend must support:

Why is this trending?
What changed?
Which sources agree?
What is missing?
What catalyst occurred?
What risks exist?
What would invalidate this trend?
Which cards are actually participating?

The system should expose the top contributing features.

Example:

Trend drivers

+18 Search acceleration
+16 Creator breadth
+14 Transaction velocity
+11 Inventory depletion
 +6 Grading momentum
 +4 Price momentum

Risk penalties

 -5 Population expansion
 -3 Thin-market penalty

51. “Under Radar” Definition

A candidate qualifies only when multiple conditions are met.

Initial conceptual rule:

PlayerMomentum >= high threshold
HobbyGap >= positive threshold
AttentionAcceleration >= medium threshold
Commerce >= early-confirmation threshold
PriceMomentum < saturation threshold
SupplyRisk < high-risk threshold
Confidence >= minimum threshold

The exact values must be configurable and tuned through backtesting.

52. “Crowded” Definition

Conceptual rule:

HobbyMomentum >> PlayerMomentum
AND
PriceMomentum high
AND one or more:
  PopulationGrowth high
  ListingGrowth high
  TransactionGrowth slowing
  SearchAcceleration slowing
  CreatorConcentration increasing

53. Buy/Sell Language Policy

The platform should describe market conditions rather than guaranteeing actions.

Preferred:

Under Radar
Early Confirmation
Momentum Expanding
Crowded
Supply Risk
Liquidity Weakening
Fading

Avoid as authoritative system labels:

Guaranteed Buy
Guaranteed Sell
Moon
Can't Miss

If the product later provides strategy simulations, those must remain separate from observational trend classification.

54. MVP Build Plan

Phase 0 — Research harness

Goal:

Validate source accessibility and matching.

Build:

source registry;
manual entity list;
observation store;
simple collector runner;
provenance logging.

Track 25–50 entities.

Phase 1 — Core trend engine

Build:

entity graph;
aliases;
time-series rollups;
robust normalization;
player momentum;
hobby momentum;
hobby gap;
trend score;
confidence;
state machine.

Support MLB first.

Phase 2 — Market confirmation

Add:

eBay active inventory;
verified-sales source;
GemRate;
PSA population;
card-family grouping.

Introduce:

supply pressure;
liquidity quality;
card gap.

Phase 3 — Cross-sport support

Add NBA and NFL.

Abstract:

player-performance adapters;
sport-specific normalization;
season context.

Add:

YouTube;
Reddit;
Instagram where approved;
creator concentration.

Phase 5 — Catalyst intelligence

Add:

release calendars;
league news;
official announcements;
event detection;
post-event observation windows.

Phase 6 — User product

Build:

radar;
entity pages;
watchlists;
alerts;
provenance drill-down;
history;
trend lifecycle visualization.

Phase 7 — Backtesting and calibration

Use historical data to:

calibrate weights;
compare scoring versions;
estimate false positives;
tune state thresholds;
tune risk penalties.

55. MVP Architecture Constraints

The architecture produced from this PRD should default to:

Node.js 24+
TypeScript
SQLite
Drizzle ORM
Hono or Fastify
native fetch
Zod
scheduled jobs
simple web UI

unless a concrete scale requirement justifies something else.

Avoid:

Kafka;
Kubernetes;
microservices;
graph databases;
vector databases;
agent frameworks;

until measured product requirements require them.

56. Reference Component Architecture

flowchart TB

    subgraph Sources
        STATS[Sports / Subject Data]
        SEARCH[Search]
        VIDEO[YouTube]
        MARKET[Marketplace]
        SALES[Verified Sales]
        GRADE[Grading]
        CATALYST[Release + Events]
    end

    subgraph Collection
        ADAPTERS[Source Adapters]
        RAW[Append-only Observation Store]
        PROV[Provenance Store]
    end

    subgraph Knowledge
        ENT[Entity Registry]
        ALIAS[Alias Registry]
        REL[Entity Relations]
        RESOLVE[Entity Resolver]
    end

    subgraph Analytics
        ROLLUP[Time-series Rollups]
        FEATURES[Feature Engine]
        SCORE[Trend Engine]
        CONF[Confidence Engine]
        STATE[Lifecycle State Machine]
        DIVERGE[Divergence Detector]
    end

    subgraph AI
        CLASSIFY[Content Classifier]
        LLMRESOLVE[Ambiguous Resolution]
        EXPLAIN[Narrative Explanation]
    end

    subgraph Product
        API[Application API]
        RADAR[Trend Radar]
        DETAIL[Entity Detail]
        ALERTS[Alerts]
        AUDIT[Evidence / Provenance]
    end

    Sources --> ADAPTERS
    ADAPTERS --> RAW
    ADAPTERS --> PROV

    RAW --> RESOLVE
    ENT --> RESOLVE
    ALIAS --> RESOLVE
    REL --> RESOLVE

    RESOLVE --> ROLLUP
    ROLLUP --> FEATURES
    FEATURES --> SCORE
    FEATURES --> CONF
    SCORE --> STATE
    FEATURES --> DIVERGE

    RESOLVE -. ambiguous .-> LLMRESOLVE
    RAW -. unstructured .-> CLASSIFY
    SCORE -. evidence .-> EXPLAIN

    SCORE --> API
    CONF --> API
    STATE --> API
    DIVERGE --> API
    PROV --> AUDIT

    API --> RADAR
    API --> DETAIL
    API --> ALERTS
    API --> AUDIT

57. End-to-End Flow

Example:

1. Player has unusually strong performance.
2. Performance collector records event.
3. Player Momentum rises.
4. Google/YouTube collectors detect attention acceleration.
5. Card-specific queries begin increasing.
6. Marketplace collector detects transaction growth.
7. Active inventory declines.
8. Price remains relatively flat.
9. Hobby Gap becomes strongly positive.
10. Confidence rises because multiple sources agree.
11. Entity transitions Dormant → Emerging.
12. User receives Under Radar alert.
13. Card-family layer finds rookie autos participating first.
14. Price accelerates later.
15. Entity transitions Emerging → Confirming.
16. Grading population begins increasing.
17. Price growth eventually outruns transaction growth.
18. Listings expand.
19. Entity transitions Established → Crowded.
20. User receives supply/liquidity warning.

58. Example Trend Record

{
  "entityId": "player:mlb:12345",
  "asOf": "2026-08-09T23:00:00Z",
  "scoringVersion": "trend-v1",

  "playerMomentum": 91,
  "hobbyMomentum": 54,
  "hobbyGap": 37,

  "attention": 76,
  "commerce": 52,
  "conviction": 39,
  "supplyRisk": 21,
  "liquidity": 63,

  "trendScore": 79,
  "confidence": 84,
  "state": "emerging",

  "drivers": [
    "performance_acceleration",
    "search_acceleration",
    "creator_breadth",
    "sales_velocity"
  ],

  "risks": [
    "limited_grading_history"
  ]
}

59. Architecture Deliverables Expected From This PRD

The architecture phase should produce:

context diagram;
container/component architecture;
deployment architecture;
source-adapter contract;
canonical domain model;
database schema;
event/data-flow diagrams;
scoring pipeline design;
feature-calculation contracts;
source provenance model;
AI boundary model;
API contract;
alerting architecture;
security model;
operational model;
observability plan;
scale assumptions;
failure-mode analysis;
data retention policy;
build sequence.

60. Engineering Deliverables Expected

The first implementation should include:

/apps
  /api
  /web

/packages
  /domain
  /entities
  /collectors
  /observations
  /provenance
  /rollups
  /features
  /trend-engine
  /confidence
  /alerts
  /sports
  /cards
  /shared

/data
  /seed
  /fixtures

/scripts
  /collect
  /backfill
  /replay
  /score

/docs
  /architecture
  /data-sources
  /scoring
  /provenance

Exact monorepo structure may change during architecture.

61. Testing Requirements

Unit tests

normalization;
velocity;
acceleration;
robust Z-score;
trend scoring;
confidence;
state transition;
hysteresis;
divergence rules;
alias resolution.

Integration tests

each collector;
observation ingestion;
provenance chain;
daily scoring;
replay;
alert generation.

Contract tests

Protect against external API schema changes.

Golden datasets

Maintain fixed historical examples where expected score/state is known.

62. Observability

Track:

collector runs;
collector latency;
collector failure rate;
records collected;
unresolved entities;
duplicate observations;
scoring duration;
confidence degradation;
state transitions;
alert rate;
AI adjudication rate;
API usage;
source quota consumption.

Unexpected changes should trigger operational alerts.

63. Failure Modes

Source unavailable

Behavior:

retain prior observations;
mark source stale;
lower confidence;
do not substitute zero.

Entity unresolved

Behavior:

store raw observation;
route to unresolved queue;
do not contaminate wrong entity.

Marketplace match ambiguous

Behavior:

exclude or down-weight;
preserve raw result;
expose uncertainty.

Price source inconsistent

Behavior:

retain source-specific prices;
avoid silent averaging;
calculate consensus only when matching criteria are met.

AI unavailable

Behavior:

deterministic pipeline continues;
ambiguous items remain unresolved;
scoring proceeds from resolved evidence only.

64. Open Questions

Architecture and product discovery should resolve:

Which verified-sales provider offers the best commercial/API terms?
What level of GemRate API access is practical?
Can Card Ladder data be licensed programmatically?
What Google Trends API access is available to the project?
Which official sports-stat APIs provide sufficient historical depth?
How should card identity be normalized across marketplace titles?
What constitutes a card family for scoring?
How should population growth be normalized by card age?
Should autos, patches, and low-numbered parallels have separate liquidity models?
How should a player changing teams affect hobby baselines?
How should offseason sports be normalized?
What minimum transaction count is sufficient for price momentum?
How should TCG subjects replace athlete-performance metrics?
What source licensing prevents redistribution in the UI?
What alert cadence avoids encouraging reaction to noise?

These questions should not block the first research harness.

65. Product Principles

Evidence before narrative

Every conclusion begins with source observations.

Velocity before absolute popularity

Change matters more than raw scale.

Breadth before virality

Independent participation is stronger than one viral creator.

Liquidity before headline price

A price is only useful when a market exists around it.

Supply matters

Population expansion can undermine apparent demand.

Player and card are separate

A great player does not make every card attractive.

Confidence is separate from momentum

Strong movement can still be poorly supported.

AI assists meaning

AI does not replace deterministic measurement.

Provenance is part of the product

Users must be able to trace conclusions to evidence.

Architecture stays replaceable

Every source adapter can fail or disappear.

66. Final Product Definition

Card Trend Intelligence should become a deterministic early-warning system for collectible demand.

The system observes real-world performance, cultural attention, card-market participation, liquidity, supply, grading, and price.

It then identifies where those signals diverge.

The primary strategic advantage is not prediction in the abstract.

It is the ability to recognize:

attention and participation are changing faster than the card market has adapted.

And, later:

the card market has become more enthusiastic than its underlying evidence supports.

That creates a complete lifecycle:

DISCOVER
  ↓
UNDER RADAR
  ↓
EMERGING
  ↓
CONFIRMING
  ↓
ESTABLISHED
  ↓
CROWDED
  ↓
FADING
  ↓
RE-EMERGING

Every transition should remain explainable, reproducible, and auditable.

Appendix A — Initial Source Registry

Source	Signal family	MVP importance	Integration notes
Official league/stat providers	Performance	Critical	Sport-specific adapters
Google Trends	Attention	Critical	API availability may vary
YouTube Data API	Attention / creator breadth	Critical	Official API
eBay Browse API	Inventory	Critical	Active supply, not complete sold history
GemRate	Conviction / population	Critical	Partner API preferred
PSA	Population	High	Public/partner access strategy
Card Ladder	Price / sales	High	Commercial integration may be needed
PriceCharting	Price	Medium	Paid API
Topps	Catalysts	High	Release/product calendars
Manufacturer sites	Catalysts	High	Source-specific adapters
Reddit	Community	Medium	Terms and API constraints
Instagram	Social	Medium	Permission-dependent
TikTok	Social	Optional	Restricted access
X	Social/news	Optional	Paid API

Appendix B — Example Daily Brief

CARD TREND INTELLIGENCE — DAILY

UNDER RADAR

1. Player A
   Player Momentum       92
   Hobby Momentum        51
   Hobby Gap            +41
   Confidence            86

   Drivers:
   - performance acceleration
   - search +78%
   - unique card creators +44%
   - verified sales +31%
   - representative prices +6%

   Risk:
   - limited high-end liquidity

CONFIRMING

2. Player B
   Player Momentum       88
   Hobby Momentum        74
   Hobby Gap            +14
   Confidence            93

   Drivers:
   - transaction volume rising
   - listings contracting
   - rookie autos outperforming base

CROWDED

3. Player C
   Player Momentum       75
   Hobby Momentum        96
   Hobby Gap            -21
   Confidence            91

   Risks:
   - PSA 10 population +18% / 30d
   - listings +22%
   - search momentum flattening
   - price remains near peak

Numbers above are illustrative only.

Appendix C — Architecture Decision Guidance

The architecture should optimize first for:

auditability;
source replaceability;
deterministic replay;
simple local development;
evidence-quality visibility;
category extensibility.

Scale should be added only when measured requirements justify it.

The system is fundamentally:

OBSERVATIONS
     +
ENTITY GRAPH
     +
TIME-SERIES FEATURES
     +
DETERMINISTIC SCORING
     +
CONFIDENCE
     +
PROVENANCE

Everything else is a presentation or enrichment layer.