Explainer

Gaming software versions: how to read the audit trail

Close view of a microchip and surrounding circuit board
Context photograph of electronics, not the equipment of a named gaming supplier or laboratory. Photo: Jeremy Waterhouse / Pexels

The short answer

A product name is not enough to identify what changed or what was evaluated. Preserve version, component, configuration, and document references when reporting on gaming technology.

In this article

Software announcements often describe a platform as one object. The evidence behind them can concern a particular component, build, configuration, or integration. A version trail connects the broad description readers see with the more specific records that support it.

Separate four kinds of change

Illustrative example

An editorial change record
Change typeEvidence to retain
InterfaceScreens or release notes tied to a build
Rules or configurationThe applicable configuration and effective date
InfrastructureWhich environment or component changed
Third-party integrationBoth sides of the integration and its documented scope
A general documentation framework. These fields do not imply that every change has the same testing or approval requirements.

GLI’s iGaming technical-standards overview includes change management among its review areas. The exact requirements for a real deployment must come from its applicable documentation. A general overview cannot settle whether an individual update needs a particular approval.

A small example of scope drift

Suppose an original release note identifies version 4.1 of a reporting module. Six months later, a sales page describes platform 5.0 and links to that old note. The old document still establishes what was said about 4.1. It does not, without additional evidence, establish the complete behavior of 5.0 or every component within it.

A reporter should preserve both references and ask which claims carry forward. If no answer is available, the article can describe the announced change while making the evidence gap explicit. This is more informative than either accepting the broad claim or declaring the entire update invalid.

Keep the publication record reproducible

  • Record the exact document URL and the date it was checked.
  • Quote the product and version identifiers consistently.
  • Distinguish a supplier’s announcement from independently verified behavior.
  • Explain substantive corrections instead of changing only the article date.

These steps help a later reader reconstruct why a statement was made. They also make maintenance less expensive: when one version changes, the editor can locate the claims tied to it without rereading every article about the supplier.

Sources and further reading