Confirmed lineups: the gate every MLB research input depends on

Projected versus confirmed

A projected lineup is an estimate based on recent usage. It is useful for narrowing a slate, and unreliable for anything that depends on an exact batting slot or plate-appearance count.

A confirmed lineup is posted by the club. Once it exists, slot-dependent research — plate appearances, run and RBI context, handedness matchups — becomes meaningful. Before that, treat every slot-based read as a working hypothesis.

What confirmation actually unlocks

• Batting slot, and therefore the realistic plate-appearance count over nine innings.
• The hitters immediately ahead and behind, which drives run and RBI context.
• Handedness matchup against the announced starter, including any platoon decision the club made.
• Whether a hitter is in the field or in a designated-hitter slot, which sometimes signals a managed workload.
• Confirmation that a nagging day-to-day status did not become a rest day.

Late scratches and how to absorb them

Scratches happen after confirmation, sometimes minutes before first pitch. The correct response is not to salvage the row by substituting a similar hitter — it is to drop the row.

Hypothetical only: imagine a research row built around a hitter batting second against a specific starter. Ninety minutes before the game the hitter is scratched and the club shuffles three slots. Every downstream input — plate appearances, traffic ahead, handedness — has changed. The research no longer describes the game being played.

How DiamondEdge handles status

Rows are built from committed MLB snapshots, and status information is shown rather than assumed. When a benchmark cannot be established from available data, the card says benchmark unavailable instead of inventing a threshold.

On the public Results page, outcomes that could not be graded — including affected scratches — are reflected in the aggregate as voids. Results are reported as aggregate Free Preview outcomes by date and market; row-level historical detail is unavailable.

A lineup-aware research workflow

1. 1Before lineups post, narrow the slate on inputs that do not depend on slot: starter profiles, park, and conditions.
2. 2When lineups post, confirm the hitter is in and note the exact slot.
3. 3Compare the confirmed slot with the slot the hitter occupied during the recent sample you are reading.
4. 4Check handedness against the announced starter and note any platoon decision the club just made.
5. 5Re-check status within the last hour before first pitch.
6. 6If the hitter is scratched or the slot moves materially, drop the row rather than patching it.

Common pitfalls

• Building slot-dependent research on a projected lineup and forgetting it was a projection.
• Substituting a different hitter into a row that was built around someone else.
• Assuming a day-to-day designation means a player will be in the lineup.
• Ignoring a designated-hitter slot that signals a managed workload.
• Treating benchmark unavailable as a neutral default rather than as missing information.

Frequently asked questions