The Platform

What's under the hood when we build your stack.

SportsMaaS is a vertical decision layer — it runs on top of your existing data platform and turns your models into decisions.

The demos prove the math is real. These are the eight layers that turn a customized deployment into something your coaches, scouts, analysts, and front office actually use.

The foundation

Deployment & Data

The eight layers run on top of your data platform — not a copy of it.

SportsMaaS connects to Snowflake, Databricks, or whatever warehouse you already run, and reads through a governed connection so your data stays where it lives — zero-copy, nothing exported, nothing duplicated. Every deployment is single-tenant and isolated, and the platform honors your existing permissions and governance — Unity Catalog, RBAC — instead of working around them. Your data platform stays the system of record. We're the decision layer on top of it.

Layer 1 of 8

Context Intelligence

The reason the system can be trusted to talk in your language.

Generic chatbots hallucinate because they pattern-match on training data. The customized platform doesn't — the language model never produces the numbers. Your ML models, built on your data, produce them. The language model only explains and cites what the models produced. Every claim is grounded in a source model and a specific row of data, and a citation validator checks every response before it ships.

Football MaaS model topology field map

Layer 2 of 8

The Lab

Talk to your models like you'd talk to a student worker.

Open the Lab. Ask a question in your own words. The advisor scans your full model registry and assembles the right combination to answer — scoring how well that combination actually works for your question. Suggested follow-ups appear automatically. New models can be loaded mid-conversation. Sessions save with full state, every response ends with a voice summary, and every conversation can render as a print-ready memo with citations carried through.

The Lab interface — pitch analysis conversation with model citations

Layer 3 of 8

Personalization

The platform knows who's talking — and remembers.

Two layers of knowing: the role lens (GM, coach, scout, analyst, medical) and the individual user (your specific staff, their priorities, their vocabulary, their preferences). Same loaded models, same question, different answer depending on who's asking. After every session, memory captures durable patterns, and the persona evolves on its own.

Your Persona panel — 11 new memories to merge into the AI profile, with Model Chat and Court Lab adaptation details

Layer 4 of 8

Model Ensembles & Synergy

Twenty-two models compose into thousands of combinations.

This is composite AI — an ensemble of validated domain models under a controller. Text-to-SQL tools and semantic layers query your tables to answer questions; our controller reasons over validated models to produce decisions — a layer above the warehouse, not a query on it. No human team can hold the difference between a useful combination of models and a useless one in their head — the platform does. A controller layer scores combinations, enforces diversity, discovers cross-model flows, and derives composite metrics — load sustainability, availability projection, value efficiency — that no single model computes. The Lab surfaces the combination effectiveness grade live, so you know how trustworthy the assembled answer is before you act on it.

Cross-model combination effectiveness panel

Layer 5 of 8

SPADE Discovery

How the platform learns your program before it goes live.

Day one of a customized deployment, there are no models in the platform. None. That's the point. SPADE Discovery is the 30-to-60-day on-site process — run by a dedicated forward-deployed engineer — that maps your decisions, data, and people to a bespoke model catalog before launch. Specific Scenario, Pain Quantified, Action Described, Data Sources, End State. The FDE stays embedded post-launch to build what's next.

SPADE Discovery Session — Jump Ball Tip Strategy chat with evidence captured for each SPADE dimension

Layer 6 of 8

Telemetry & Model Health

Every model can tell you where it's strong — and where it's weak.

Every model in the platform ships with a five-panel transparency surface in production: how the model works, what data it uses (and doesn't), live validation by segment, head-to-head against industry benchmarks, and an evidence trail back to the rows of data behind any claim. Retraining is triggered, gated, and audited — if a candidate model regresses on any segment vs. the current production version, the deploy fails closed.

Model Telemetry dashboard — drift root-cause analysis with PSI scores by segment, 29 models, 944 tests

Layer 7 of 8

Adaptive Evidence Retrieval

The platform earns the right to answer the question it wasn't scoped for.

Every deployment has a boundary — the day a coach asks a follow-up nobody scoped. Static tools say "that's not in the loaded data" and the conversation dies; generic AI writes ad-hoc SQL and answers with no provenance. Adaptive Evidence Retrieval is the third path: a governed layer that checks whether the answer lives in a source it's been authorized to read, retrieves only aggregate evidence — never raw rows — with full provenance, and runs it through the same Context Intelligence grounding as your model outputs. When no approved capability exists, it answers honestly and logs the gap. No arbitrary SQL, aggregate-only, every retrieval signed against a capability contract — and every unanswered question becomes a measured signal for what to approve next. The platform gets smarter because your people's demand is being measured, not because the AI is self-authorizing access to your data.

A governed retrieval

  1. User asks for a split nobody scoped
  2. Is there an approved capability for that evidence?
  3. Yes — retrieve aggregate evidence, attach provenance
  4. No — answer honestly, log the DomainGap

Aggregate only · never raw rows · every retrieval signed

Layer 8 of 8

The Desk

How the platform repairs and extends itself — every fix verified before it ships.

Over a multi-year deployment, three kinds of gap emerge: what the platform can't do yet (Discovery), what it's doing worse (Telemetry), and what's broken or needs to change — The Desk. A report enters wherever your staff already works — Slack, Teams, the Lab itself — and a four-agent team turns it into a structured, cited ticket, and for low-risk bug classes, a candidate fix. Nothing reaches production unsupervised: every fix is graded against a six-criterion rubric and the repo's real tests run in a network-disabled sandbox before a PR even exists, then it's verified by an automated gate or a named human reviewer. A knowledge graph gives every agent full context — people, customers, tickets, commitments — so a leader can ask "what's the top complaint from our top-five customers this quarter?" and get a real answer.

Report → verified fix

  1. Report lands in Slack, Teams, or the Lab
  2. Four agents draft a cited ticket — and a candidate fix
  3. Six-criterion rubric + real tests in a sealed sandbox
  4. PR only if graded and verified

Suggest-only first · every action logged with citations

Together, these layers form your sport-domain ontology — the connective meaning between your decisions, your models, and your data.

Want to see this for your program?

No demo until we understand your program. Tell us what you're working with.

Start the Conversation →