How do I set up a projection engine for building lineup tools with injury updates and multi-source player data?

To set up a projection engine for lineup-building tools with injury updates and multi-source player data, think of it as 4 layers:

1. Data ingestion
2. Normalization + player matching
3. Projection generation
4. Lineup optimization + rule enforcement

Here’s a practical blueprint.

---

1) Define the core data model

You want a single canonical player record that all sources map into.

Example canonical fields

• player_id (your internal ID)
• name
• team
• opponent
• position
• salary
• projected_minutes
• projected_usage
• base_projection
• ceiling_projection
• floor_projection
• injury_status
• injury_news_timestamp
• game_time
• source_flags / confidence
• projection_sources
• last_updated

Key principle

Keep raw source data separate from processed projection data.
Don’t overwrite raw feeds; always transform into a canonical layer.

---

2) Build multi-source ingestion

Typical sources:

• Fantasy/DFS projections API
• Injury/news API
• Depth chart / starting lineup feed
• Vegas lines / implied totals
• Player stats history
• Ownership projections
• Beat reporter/news text

Suggested pipeline

• Pull each source on a schedule
• Store raw payloads with timestamps
• Normalize into common schema
• Deduplicate by player and game
• Track source reliability and recency

Important:

Use a source priority system or weighted blending:

• Official injury report > beat reporter > aggregator
• Confirmed starter > projected starter
• Fresh news > stale data

---

3) Player identity resolution

This is one of the most important parts.

Players may appear differently across sources:

• “J. Smith”
• “John Smith”
• “Johnathan Smith”

Match using:

• Name similarity
• Team
• Position
• Game/date
• External IDs if available:
  • ESPN ID
  • Rotowire ID
  • Sportradar ID
  • NBA/NFL/MLB official IDs

Best practice

Create a persistent crosswalk table:

• internal_player_id
• source_name
• source_player_id

This prevents repeated matching logic every day.

---

4) Injury update handling

Injury news should update projections immediately and re-run lineup builds.

Injury states

Create a standard set like:

• Healthy
• Questionable
• Doubtful
• Out
• Probable
• Game-Time Decision
• Minutes Limit
• Rest
• Suspended

Injury impact logic

Each status should affect projections differently:

• Out → projection = 0
• Doubtful → heavy discount, often near 0 unless late positive news
• Questionable → probabilistic projection based on play probability
• Minutes limit → cap minutes / usage
• Probable → slight adjustment or none
• Confirmed out of starting lineup → adjust usage/minutes for starters behind them

Recommended approach

Use:

• A status-to-probability model
• A minutes adjustment model
• A usage redistribution model for teammates

Example:

• If a starter is out, redistribute minutes to backups
• Redistribute usage based on historical on/off data or depth chart rules

---

5) Projection engine design

A good projection engine usually combines:

A. Baseline projection

From historical rates:

• fantasy points per minute
• plate appearances
• snaps
• usage rate
• fantasy points per opportunity

B. Contextual adjustments

Adjust for:

• opponent strength
• pace
• Vegas implied team total
• spread / blowout risk
• home/away
• back-to-back / rest
• weather
• lineup position / batting order
• starting status

C. Injury and news adjustments

• player availability
• teammate injuries
• minutes changes
• role changes

D. Uncertainty ranges

Produce:

• median projection
• floor
• ceiling
• volatility score

This is very useful for GPP/DFS lineup tools.

---

6) Use a layered projection formula

A simple framework:

Projected Fantasy Points =
Base Rate
× Expected Opportunity
× Context Adjustment
× Injury Adjustment
× Role Adjustment

Example for NBA

Projection = (FP/min) × (Projected Minutes) × (Matchup Factor) × (Injury/Role Factor)

Example for NFL

Projection = Expected Touches/Targets/Snaps × Efficiency × Game Script Adjustment

Example for MLB

Projection = Batting Order + Platoon + Pitcher Matchup + Park Factor + Weather

---

7) Build a news-processing layer

If you’re using injury updates from text/news feeds, add NLP extraction.

Extract:

• player name
• injury type
• status
• expected minutes/availability
• teammate impact
• coach quotes
• confidence language:
  • “will play”
  • “likely out”
  • “game-time decision”
  • “limited”

Simple sentiment/confidence tagging

Use heuristics:

• “will start” = high confidence positive
• “questionable” = uncertain
• “unlikely to play” = negative
• “minutes restriction” = cap minutes

You can also use a small classifier or LLM-based parser to convert news into structured updates.

---

8) Recalculate projections on triggers

Don’t wait for a full nightly batch if injury news arrives.

Trigger events

• new injury report
• starting lineup announced
• player ruled out
• salary update
• Vegas line movement
• lineup lock approaching

Recommended architecture

• Batch job for full projections every morning
• Event-driven updates for late news
• Cache invalidation for affected players and teammates

---

9) Add lineup tool logic on top

Once projections are ready, lineup tools can optimize using:

• salary cap
• position requirements
• stacking rules
• exposure limits
• team limits
• late-swap constraints
• ownership caps
• correlation rules

Optimization objective

Usually maximize:

• projected points
• ceiling
• or a weighted blend of points + leverage

Use an integer programming solver if possible:

• PuLP
• OR-Tools
• CBC / Gurobi / CPLEX

---

10) Track confidence and versioning

Every projection should know:

• which sources were used
• timestamp of each source
• last injury update
• confidence score

Example confidence scoring

• 1.0 = confirmed starting, no injury concerns
• 0.8 = stable projection, minor news only
• 0.5 = questionable status
• 0.2 = uncertain role / late news
• 0.0 = out

This helps users trust the tool and helps with automation decisions.

---

11) Suggested system architecture

Services

• Ingestion service: pulls external APIs/news
• Normalizer: maps data into canonical schema
• Player resolver: handles identity matching
• Projection service: computes updated projections
• Optimization service: builds lineups
• API/UI: serves projections and lineups
• Scheduler/queue: handles refreshes and event-driven updates

Storage

• PostgreSQL for canonical structured data
• Redis for fast cache / live projections
• Object storage for raw payloads
• Optional search index for news text

---

12) Minimal implementation plan

If you want an MVP, do this first:

1. Build internal player ID system
2. Ingest 2–3 projection sources and 1 injury/news source
3. Normalize data into one schema
4. Create baseline projections using historical rates
5. Add injury status adjustments
6. Build lineup optimizer
7. Add late-news refresh and re-optimization
8. Add confidence/version tracking

---

13) Example pseudo-flow

Fetch sources
→ Resolve player identities
→ Merge into canonical player table
→ Parse injury news
→ Update status/minutes/role
→ Recompute projections
→ Store new projection version
→ Run optimizer
→ Publish lineups

---

14) Practical tips

• Don’t trust any single source completely
• Keep raw and processed data separate
• Build special handling for late scratches
• Use team/position/usage-based redistribution rules
• Rebuild lineups whenever high-impact news arrives
• Log every projection change for debugging

---

If you want, I can also give you:

1. a database schema for this system,
2. a Python architecture example, or
3. a projection formula template for a specific sport like NBA/NFL/MLB.