All code

Repository

SportsBet

Lets you ask a plain question about American football statistics, such as which players clear a given line most often, and answers it from real data rather than from memory.

Ask a filtered question about a slate of prop lines.


Private repository. Everything below is written from the code; none of it is a link you can follow.

What it is

An NFL statistics platform built around player props and parlays rather than box scores. It ingests real-time data, computes hit rates for individual prop lines, builds game-centric parlays, and puts a natural-language assistant over the top. The product is the query, not the dashboard.

Why it exists

Prop betting is a filtering problem. The data to evaluate a line is public, but it is spread across box scores, injury reports and odds feeds, and nobody wants to join those by hand every Sunday.

As a business

There is a market — prop research tools are a paid category — but nothing here pursues it. No multi-user model, no billing, a shell script to start and stop it. This is infrastructure for a personal edge, not a product, which is the same instinct that later became arbor, with the difference that arbor put money behind its conclusions.

Stack

Backend
Python · FastAPI-style routers · Programmatic self-audit
AI
GPT-5
Deploy
Render

The decision

The problem

Asking for props above a hit rate and better than some odds is a natural way to ask and a dangerous thing to hand a model. If it answers from its own knowledge it will confidently produce plausible, wrong numbers — and in a betting context a fabricated hit rate is worse than having no tool at all.

What I did

The model translates rather than recalls. It turns the question into a filter, and the filter runs against computed statistics. The numbers come from the data layer; the model only decides what to select.

What it costs

It is constrained to questions the filter vocabulary can express. A question outside it either fails or gets silently narrowed, and the second failure mode is much worse than the first.

Where it ended

Stopped in December 2025. Its ideas — probability estimation, honest accounting, self-auditing — continue in arbor, on a venue where the system can act on its own conclusions.

A piece of the code

backend/llm/prompts.py

AUTO_BUILDER_NL_PARSER_PROMPT = """You are a betting assistant that convertsnatural language instructions into structured filter parameters.RULES:1. Never invent new fields - only adjust existing filter parameters2. If the user doesn't mention something, don't change it3. Be conservative: if unsure, don't make dramatic changes4. Output ONLY JSON, no extra textAVAILABLE FILTER FIELDS:- min_model_probability (0.0 to 1.0)- min_hit_rate (0.0 to 1.0)- min_games_sample (integer >= 0)- max_legs_per_player (integer >= 1)- allowed_stat_types (array of strings)"""
The model translates, it does not recall. Asking for props above a hit rate is a natural way to ask and a dangerous thing to hand a language model, because it will confidently produce a plausible number and a fabricated hit rate is worse than having no tool. So the model's entire job is turning a sentence into a filter, and the filter runs against computed statistics. The cost is that a question outside the vocabulary either fails or gets silently narrowed, and the second is much worse than the first.

Excerpt — trimmed for reading, not a full file.

Ask about this project