Every system on this site — the picks, the Predictive Model projections, the "active this week" algorithms — comes from the same place: a query run against a database of every NFL game back to 1999 and every FBS college football game CFBD has data for, using PPQL (Predictive Playbook Query Language), a purpose-built syntax for asking "how has X performed against the spread historically?" and getting a real, testable answer back instead of a hunch.

The two query tools you'll use most are the NFL Historical Query and CFB Historical Query pages. Both work the same way: you type a condition (e.g. 9.5>=line>=3.5 and week<=3 and season>=2017), hit Run, and the page shows you every game since 1999 that matches — plus the record, win rate, ROI, and statistical significance of betting that exact situation every time it came up.

A condition is built from fields (things like team, line, points, rushingyards) compared with operators (=, >, >=, ranges like 9.5>=line>=3.5) and joined with and / or. The full, current field list is always live under "Field reference" on each query page — it's generated directly from the database schema, so it can never drift out of date the way a written cheat-sheet would.

See it end to end: a real conversation that turns a hunch into a tested system →

Running a query is the easy part. Reading the "Result significance" section correctly is what separates someone who finds a real edge from someone who talks themselves into a fluke. Here's what each tile means and when to trust it:

• ATS / O-U / SU record — the raw win-loss-push count for that exact situation. On its own, this tells you almost nothing: 12-4 sounds great, but 16 decided games is a tiny sample.
• p-value — this is the number that actually answers "could this record just be noise?" It's a two-sided exact binomial test against a 50% baseline (or 52.38%, break-even at -110, if you set the baseline that way). A p-value of 0.03 means a real, no-edge coin-flip system would only produce a record this lopsided about 3% of the time by chance. Anything above roughly 0.05 should be treated as "not distinguishable from luck yet," no matter how good the win rate looks.
• ROI and profit ($1,000/game and $50/game) — what a flat bettor at -110 actually would have made or lost, at two reference bet sizes so you can scale to your own bankroll without doing the math yourself.
• Averages — the query's own scoring/yardage/turnover profile (and the same for the opponent), useful for sanity-checking that a system's story matches its numbers — e.g. a "shootout" system should actually show a high average total.
• Record after a loss — the system's record on the very next qualifying game, immediately following one of its own losses. This is the honest way to check whether a system "bounces back" instead of just assuming it does.
• Max win/losing streak and max drawdown — the longest run of straight wins or losses a system has actually gone on, plus the true dollar peak-to-trough swing at flat stakes. See Lesson 5 for how to actually use these two numbers — they answer different questions and shouldn't be read the same way.

Deep dive: how the p-value is calculated, start to finish, with the real formula →

This is the single biggest way a real quant tool like this one gets misused, so it gets its own lesson instead of a footnote. With 225+ NFL fields and 180+ CFB fields available, it is always possible to keep adding conditions until you land on a query with a great-looking record and a low p-value — not because you found a real edge, but because you tried enough combinations that one was bound to look good by chance alone. This is called the multiple comparisons problem, and it's exactly why every p-value on this site carries a note warning that it "does NOT account for having tried many candidate queries and reporting the best one."

Three practical habits that actually protect you from this:

1. Start from a real hypothesis, not a scan. "Home divisional underdogs off a bye" is a testable idea with a story behind it. "Every field combination until something hits 65%" is p-hacking, even if the resulting query is perfectly correct PPQL.
2. Distrust a query with very few conditions and a huge edge. The more specific and narrow a query gets, the smaller its sample almost always is — and small samples are exactly where noise looks like signal.
3. Use the grouped breakdown. Break a promising query out by season (the grouping dropdown on the query page) before trusting it. A real edge tends to show up most seasons, not just as a total dragged up by two monster years.

Once bare conditions feel comfortable, PPQL has a lot more depth built in specifically for building real, defensible systems rather than one-off queries:

• Shortcut fields and macros — PPG/PAPG (points scored/allowed per game this season), COMP (completion %), DIV/NDIV/CONF/NCONF (divisional or conference matchup flags) read like plain English instead of raw column math.
• Opponent lookups (o:) — put o: in front of any field to pull today's OPPONENT's value instead of this team's own, e.g. o:PPG>=27 means "today's opponent scores 27+ per game."
• Recency prefixes (p:, pp:, ...) — reach back into a team's own recent game history without a separate query, e.g. p:points>=30 means "scored 30+ in their last game."
• Windowed and season aggregates (tS(), tA(), tMAX(), tMIN()) — count, average, max, or min a condition or field over a real window, e.g. a team's own season-to-date scoring average, computed as of that game (never using future data it wouldn't have had yet).
• Grouping — break any query's record out by season, team, week, month, or site, to see consistency instead of one combined number (see Lesson 3).

The full syntax reference with live examples always lives at the bottom of each query page under "Query Syntax & Examples" — that's the canonical source, kept in sync with the actual parser, so treat this lesson as the tour and that section as the reference manual.

See this whole workflow play out in a real example, start to finish →

Once you're tracking more than one system, the natural next question is capital allocation: how much weight to put behind each one, and when to scale a system back. The max win/losing streak and max drawdown tiles (Lesson 2) exist for exactly this, borrowed directly from how a portfolio manager rotates sector exposure rather than staying static.

Two numbers, two different jobs:

• Max losing streak (a game count) answers "how many bets in a row could go against me" — useful for sizing a single wager so a normal cold stretch doesn't wipe out a unit.
• Max drawdown (a real dollar figure, peak-to-trough) answers "how much of my money could actually be underwater at once" — and it can be worse than the losing streak alone suggests, since it's measured from whatever peak came before it, not just the losses themselves.

Deep dive: named statistical methods for quantifying streaks (runs test, longest-run distribution, and more), with formulas →

Coming next: bankroll management and unit sizing, how spreads/ totals/moneylines actually price a game, closing line value, and the psychology traps (chasing losses, results-oriented thinking) that undo good systems. This module builds on Lessons 1-5 above, so it's being written second on purpose.

Deep dives that build on the lessons above — each one is already linked from the lesson it extends, but here they are together as one list: