Customers only: preview

Designing the semantic layer behind reliable iGaming GenBI

A technical design guide to metric contracts, join cardinality, query controls and reproducible investigations for conversational iGaming analytics.

For CTOs, CDOs and Heads of BI

The difficult part of Generative BI is not producing valid SQL. It is producing the right calculation at the right grain, under the right permissions, and preserving enough evidence for another person to reproduce the answer.

Executive summary

An iGaming GenBI interface should resolve a business request into an explicit metric contract before executing it. The contract defines the time basis, population, dimensions, exclusions and calculation. A semantic layer provides a controlled vocabulary and model of those relationships; it does not make incorrect source data correct.

The design proposed here separates probabilistic language interpretation from deterministic calculations and validation. That separation gives a Head of BI something concrete to test. It also helps a CFO distinguish a revenue explanation from a persuasive paragraph. These are reference-design recommendations, not a description of an independently audited Bounty AI deployment.

1. Model grain and business meaning before natural language

Make each metric executable

A request for NGR needs more than a column named revenue. Agree which deductions apply, whether they are accrued or realised, and which event date determines the reporting period. A sportsbook result can be grouped by settlement date while sports handle is grouped by placement date. Those choices change the interpretation of a comparison.

  • Give each metric an owner, a version and a defined aggregation grain.
  • Specify currency treatment, timezone, product boundaries and late-arriving adjustments.
  • Distinguish zero from unavailable or incomplete data.
  • Define allowed dimensions and the relationship between facts and those dimensions.

Prevent fan-out at the model boundary

Suppose one player has ten settled bets and three campaign assignments. Joining both fact sets directly on player UID can produce thirty rows. Summing bet revenue after that join overstates it. A language model can generate syntactically valid SQL that contains precisely this mistake.

Pre-aggregate compatible facts to an agreed grain or use a modelled join path that preserves the metric’s semantics. Treat uniqueness and relationship tests as part of the metric contract. Do not assume that naming a primary entity proves uniqueness in the underlying data.

In dbt’s documented approach, semantic models form a graph connected by entities, and those entities describe join relationships. This illustrates the modelling mechanism; it does not establish that Bounty AI uses dbt. Source: dbt semantic models.

Customers only

The rest of this guide is for Bounty AI customers.

Full guides, product screens and walkthroughs are available to Bounty AI customers and pilot partners. Access is by invitation, and customer sign-in is not open yet.

  1. 2. Separate interpretation, execution and investigation
  2. 3. Test failures that a polished demo can hide
  3. Operational outcome: fewer disputes that require reconstruction
Pilot on your data

Pilot partners get the full library when their pilot starts.

Free to read now

A shared business view needs shared meaningRead the article

More in the Client library

All guides