Two Private Sports Labs, One Evidence Contract

I had two private sports projects and one public-positioning problem.

Sunday Lab had become a substantial local NFL forecasting and practice system. NBA Lab had a smaller application and data-contract slice backed only by synthetic fixtures. Both were useful. Neither was a live product. Putting both names on a portfolio grid with the same visual weight would have made repository activity look like product evidence.

So I kept the repositories private and published the decision boundary instead.

This is a case study about the contract the two labs now share, the places where they deliberately differ, and the evidence they still do not have. It is based on private source and first-person review. It does not expose repository links, provider credentials, raw data, or private collaborator details.

Before: two names implied one maturity level#

The first design treated the NBA project as a sibling of the NFL project. That was directionally useful: both involve priced propositions, forecasts made before a cutoff, optional positions, and later evaluation. But the word sibling compressed an important difference.

Sunday Lab had a deeper local data foundation, database-backed contracts, a fixture path for interface testing, and a larger set of forecast and position rules. NBA Lab had a clean fixture-only slice, a source-approval boundary, and no activated live source. One was a broader private prototype. The other was still a bounded contract demonstration.

The public constraint was simple: describe the engineering judgment without publishing private source or making either project sound deployed, customer-validated, or safe for real-money use.

The obvious alternative was to open both repositories and let the code speak for itself. I rejected that. Public source would have revealed more implementation and product strategy than the case study required, while still failing to prove the outcomes a buyer or user would care about.

The shared contract#

The useful unit was not an NFL app or an NBA app. It was a sequence of records that should never collapse into one another.

That table is the most important artifact in both projects. It turns a screen full of sports numbers into an inspectable decision record.

A forecast can exist without a position. A pass is still a decision. A position points to the forecast and quote that existed when it was made. Later data cannot be relabeled as if it were known earlier. An evaluation grades the preserved record; it does not rewrite it.

The practice-credit boundary is equally strict. Credits are simulation units, not money. There are no deposits, withdrawals, payment rails, sportsbook accounts, or routes to a real wager. That constraint is product scope and safety control at the same time.

Unification without pretending the sports are identical#

My first impulse was to extract a shared library. The vocabulary looked reusable, so shared code looked like progress.

That would have been premature.

NFL and NBA workflows disagree in important places. A weekly football slate makes the week feel like the natural unit, but each game and proposition still has its own cutoff. Basketball schedules add postponements, denser game cadence, and different acquisition constraints. A shared package created before those differences were exercised would turn today’s guesses into tomorrow’s compatibility surface.

I unified the concepts and left the implementations separate.

source review -> observation -> evidence cutoff -> forecast
                                              -> pass or practice position
                                              -> settlement -> evaluation

The shared vocabulary is the stable part. Sport-specific schedules, providers, proposition rules, and interfaces remain behind each lab’s boundary. A package becomes justified only after two working implementations reveal which behavior is truly invariant.

The failure was a maturity shortcut#

The failure was not a bad formula. It was a reporting shortcut.

I could describe schemas, cutoff guards, append-only records, calibration metrics, and deterministic fixtures. Because those pieces were concrete, it was tempting to summarize both labs as working sports-forecasting products. That sentence would have hidden five absences: no public deployment, no authentication, no live odds integration, no external users, and no demonstrated decision improvement.

Sunday Lab also used the language of simulation before it had a user-facing scenario system. Its implemented record integrity was stronger than its scenario-learning evidence. NBA Lab’s architecture was similarly more complete than its acquisition surface: the fixture path worked, while non-fixture sources remained intentionally closed.

The correction was to make maturity part of the artifact instead of a footnote.

That table is less exciting than a launch announcement. It is also reusable. Every future change has somewhere honest to land.

What the private work actually proves#

The source evidence supports a narrower set of claims.

First, the projects encode separation between facts, quotes, forecasts, decisions, positions, and evaluations. Second, their fixture and database contracts treat time as part of correctness: a later observation cannot justify an earlier forecast. Third, they preserve the distinction between forecasting quality and luck by making calibration and price movement separate from the final practice-credit result. Fourth, NBA Lab refuses to activate a non-fixture source without an explicit approval record for the intended use.

Those are implementation claims. They are not adoption claims.

I have not measured whether either lab improves a person’s calibration over a season. I have not established that closing-line value in these prototypes predicts future performance. I have not observed retention, willingness to pay, or safer real-world decisions. No customer has validated the workflow. There is no production incident record because there is no production service.

The measured outcome of this pass is therefore about governance, not market success:

• two private projects now use one public claim vocabulary;
• both explicitly prohibit real-money interpretation;
• NBA Lab remains fixture-only and fail-closed for unapproved sources;
• their public maturity can be stated without exposing private source;
• zero live-product, customer-outcome, or profitability claims were added to the portfolio.

What I could not measure is more commercially important than what I could. The labs need longitudinal use, real pre-cutoff records gathered under approved terms, and an evaluation plan before I can say they improve forecasting behavior. A clean schema cannot answer that question.

The publication rule#

The public artifact is this case study, not the private repositories.

That choice has a cost. A reader cannot inspect every test or database constraint directly. The evidence level must therefore remain private evidence with a public, sanitized account, not public source and not independent validation. The site evidence standard makes that boundary explicit, and the broader simulation doctrine explains why reproducible synthetic behavior is still not real-world proof.

The benefit is proportional disclosure. The reusable decision model is public. Private collaboration, source review, acquisition strategy, and unfinished product detail stay private. If either lab later earns a public demo, a source release, or measured outcome, that will be a new evidence event rather than a retroactive reinterpretation of this one.

What comes next#

The next shared artifact should not be a monorepo.

It should be an evaluation protocol that both labs can implement independently: versioned scenario, forecast cutoff, input receipt, exact quote, pass-or-position decision, settlement rule, calibration bin, and review note. If the two implementations converge under use, then a shared package may have earned its boundary.

Until then, the practical test is simple. For every number on the screen, ask what kind of record it is, when it became knowable, which decision cited it, and what the later evaluation is allowed to claim.

If those answers are missing, do not add another model. Repair the evidence contract first.