Help & FAQ

GPP Lab is research and lineup-construction software for DraftKings NFL Classic GPPs: single-entry, 3-max, and 20-max contests with fields under 10,000 entries. It does not currently support Showdown, FanDuel, cash games, or mass multi-entry workflows.

Start on Slate to verify the player pool and add projections. Read Environment, form a thesis in Quadrant, Stacks, and FLEX, build in the Optimizer, test candidates in Sim Lab, and use Results after a contest to calibrate the next decision cycle.

No. The site compares projections, modeled ranges, ownership assumptions, construction rules, and simulated outcomes. NFL results and opponent behavior remain uncertain. Use the outputs to make an inspectable decision, not as a promise of profit or contest placement.

Slate, Environment, Data, Insights, Help, and the informational pages are open. Quadrant, Stacks, FLEX, Optimizer, Late Swap, Sim Lab, and Results are invite-gated. There is no subscription at launch; invites and optional Ko-fi support are separate from your private workspace.

You can inspect the published slate, schedule, salaries, and historical context without them. Your own projection snapshot is required for personalized point, ownership, ceiling/floor, leverage, optimizer, and simulation reads. Missing ownership is shown as unavailable and is never silently treated as a genuine 0% estimate.

Projection snapshots are scoped to the anonymous browser workspace that uploaded them and are not exposed to other workspaces. You can activate an older snapshot or delete one from Slate. Deletion removes it from the workspace immediately and marks it for permanent purge after 30 days, subject to the limited exceptions in the Terms.

Only upload material you own or have permission to process this way. A compatible CSV format does not itself grant usage rights. See the Terms and Data Sources pages for details.

Historical and weekly football feeds refresh on a scheduled weekly pipeline, while an administrator publishes the active DraftKings salary and status snapshot. The slate UI identifies missing or stale inputs rather than assuming they are current. Source feeds can still contain errors or change after collection.

It is ceiling minus floor, divided by projected points. When uploaded bounds are unavailable, GPP Lab derives them from a lognormal player distribution using historical volatility when enough games exist and a position fallback otherwise. Those bounds summarize the model; they are not guaranteed prediction-interval coverage.

They are the active slate's median modeled width and median positive projected ownership. The four regions are descriptive comparisons within this slate, not fixed thresholds or universal labels for good and bad plays.

Player leverage compares projection with ownership. Outcome width/ownership compares modeled range with ownership. Stack leverage compares a correlated stack's ceiling-weighted range with modeled joint ownership. Each answers a different question, so compare values only within the same metric and slate context.

Use them to compare environments and decide where deeper research is worthwhile. Totals and implied team totals reflect market expectations; projection and ownership totals reflect your active inputs. None of them says that a game must shoot out or that a stack is automatically strong.

GPP Lab stores that game in the current build thesis so the Optimizer can use it when a selected build template calls for a target. It does not lock a player or force a game stack by itself.

It is the share of a generated opponent field containing the selected QB and same-team pass catcher, under the chosen entry-limit preset. The independent product of player ownership is shown only as a comparison baseline; players in real lineups are not independent.

No. It is a reproducible synthetic field built from projected ownership, roster rules, salary regime, and evidence-versioned construction assumptions. Fitted, directional, and fallback labels tell you how much historical support the preset has; none makes it the true future field.

It solves legal DraftKings Classic rosters for the objective and constraints you select. Objectives can emphasize projection, ceiling, ownership-aware heuristics, or a prior simulation score. Templates are reproducible starting settings, not claims of an optimal contest strategy.

A normal portfolio contains 1–20 lineups. Diversified generation can create a larger candidate pool for simulation, but the final optimizer output remains capped at 20 lineups.

Two or more hard rules cannot be satisfied together—for example locks exceeding a position limit, minimum exposures competing for too few portfolio slots, or a salary floor the available roster cannot reach. Remove or relax one hard rule and build again; soft targets do not cause infeasibility.

Minimum and maximum are hard portfolio bounds. Target is a soft preference used to steer the mix while preserving legal lineups and stronger objective values. Always review realized exposures after the run, especially in a small portfolio where one lineup changes the percentage substantially.

The tool compares the current time with the recorded kickoff for each player's game. Started players are pinned and open roster slots are solved again. Always confirm live contest status and the final DraftKings roster before submitting; source timestamps and game statuses can be delayed or wrong.

It samples correlated player outcomes, scores your candidate lineups against a generated opponent field, applies the selected payout shape and tie splitting, and summarizes repeated modeled results. The output is conditional on every projection, distribution, correlation, field, and payout input.

Treat them as comparisons within the same run. EV incorporates the payout model and duplicate splits; win and top-1% rates count modeled finishes. Small differences may be simulation noise, and the values are not independently validated probabilities for the live contest.

Projection is only one part of a top-heavy contest. A lineup can share a common core, duplicate exactly, split payouts when it wins, or produce its ceiling less often than a nearby alternative. Read projection, win rate, payout shape, and duplication together.

It compares projected and actual ownership, projected and actual points, observed field construction, and top-finisher roster patterns. The goal is to find systematic input or field-model misses that can inform future process—not to grade decisions solely by one player's result.

No. It describes rosters selected because they already finished near the top. The sample is outcome-selected and observational, so stack rates, salary usage, and ownership totals do not prove those traits caused the finish or will work on another slate.

“Last week vs prior 3” is fastest and noisiest. “Last 2 vs prior 3” smooths one-game swings but reacts more slowly. “Last week vs season” uses the broadest comparison but can lag a role that already changed. The page shows adequacy warnings when a window cannot support a metric well.

No. They describe recent production moving differently from the opportunity proxy. The current holdout supported fades more strongly than targets, and both remain research prompts rather than lineup instructions.

The active projection file may omit a column, a player may not resolve to the published salary pool, historical feeds may not have enough qualifying games, or the weekly source may not have published yet. GPP Lab preserves missingness instead of replacing unknown values with zeros.

The saved optimizer or simulation run no longer matches the current slate, projection snapshot, thesis, or constraints. It remains available for audit, but build or simulate again before treating it as the current workflow result.

Optimizer, simulation, and late-swap attempts share a per-workspace rolling-hour compute budget. A limited response includes how long to wait. This protects the live service; changing pages or retrying immediately does not reset the window.