Governing what nobody has certified yet

What the rules anchor to is an examined artifact identified by a verification method, so preserve the identifiers and attestations that tie the released binaries to what was tested: the SHA1 signature of all applicable post‑installation files and an attestation that reviewed source produced materially identical production software (Nevada 14.400) [1]. § 547.8(f), with hashing as an illustrated approach, and any component identifiers that cannot be satisfied by a component differing from what the lab examined (SBCGS‑T § 871(c)) [1]. Keep the formal written test laboratory report for the system and for any modification, because § 547.4(c) applies the submission, testing, and conforming‑finding sequence to any modification thereto [2]. Maintain discrete change records aligned to Nevada’s event‑driven modification regime (definition at 14.010(25) and prior‑approval trigger at 14.110(1)), noting that these mechanisms do not describe continuous change and how to treat it is unresolved [2]. If presentation assets are generated, retain materials showing whether they are merely artistic attributes or material to understanding the game or outcome; Nevada excludes artistic attributes from “modification” unless material to gameplay, and no published test for that line has been identified [3][4]. requirement identified by IEGM asks for disclosure that a design was machine‑generated; whether to require such disclosure is unresolved [5][6].

§ 547.4(c); § 547.8(f)) [1][2]. 14.110(1); 14.010(25); 14.120(2)) [1]. How this is read for continuous evolution: every cited mechanism is event‑driven and assumes discrete, reportable changes; none describes continuous automatic change, so the treatment of ongoing evolution without prior approvals is unresolved [1]. It is also unresolved whether statistical assurance could substitute for deterministic verification; the two kinds of assurance answer different questions today [3]. A dated observation: a January 7, 2026 post‑workshop draft revising Nevada technical standards contained no references to AI or generative systems, which does not resolve these gaps [4]. Accordingly, the materials do not state how regulators handle generative logic that evolves without prior approval [1][3].

§ 547.8(f) requires a verification methodology for game software (Nevada; United States federal) [1][2]. Those provisions presume a stable component whose deployed identity can be matched to what was examined; a difference is treated as an error, not normal operation (Nevada; United States federal) [2]. § 547.4(c) applies submission, testing, and a conforming finding to any modification (Nevada; United States federal) [3]. None of those mechanisms describes continuous change; whether to treat continuous evolution as a stream of modifications, as a single approved process, or as beyond current frameworks is unresolved [3]. The unit of certification when the product is a process is also unresolved, with candidate approaches noted but not chosen [4]. What happens to a certificate when the underlying model changes is likewise unresolved [5].

My materials don’t cover that. [1]

What the rules say, with jurisdiction and date: Nevada Regulation 14, as reviewed by IEGM in September 2026, anchors approval to a specific artifact by requiring the lab to report the SHA1 signature of applicable files and to attest that reviewed source produced materially identical production software [1][2]. § 547.8(f), as reviewed by IEGM in September 2026, requires an industry‑standard verification methodology for game software, illustrated by hashing [1][2]. These change‑control mechanisms are event‑driven and assume discrete, reportable modifications; none describes continuous change [3].

Explanation (unsettled): If continuous change is not treated as separate modifications, the hash of a deployed binary may remain checkable but no longer answers whether the running thing behaves like the examined thing [1]. The unit of certification for a process is unresolved; candidate approaches include certifying the generating process, certifying bounds on outputs, or certifying each output, but none is adopted in these regimes as of September 2026 [4][2]. Whether statistical assurance can substitute for deterministic verification is also unresolved, and certificates tied to software identification become ambiguous when the underlying model changes [5].

Approval attaches to a thing that has been examined, and a change to that thing re‑opens the process [1]. Nevada provides that a modification may only be made by a licensed manufacturer who has received prior written approval from the Chair [2], and the federal Class II regime requires submission to a testing laboratory, a written report, and a conforming finding for any modification thereto [1][3]. Every one of those mechanisms is event‑driven and assumes a discrete change; none describes a process that changes continuously [3]. § 547.8(f) [4][5]. SBCGS‑T section 885(a) makes a certification valid for the configuration and the software identification stated in the report [6]. Where the software identification no longer distinguishes the tested behavior from the deployed behavior, the term of a certificate becomes ambiguous, and the sources record this as unresolved [6].

The sources do not establish a method to define the scope of model‑weight–based behavior for examination, and record this as unresolved. [1] What the rules say today is that laboratory scope assumes examinable source for each component that affects outcome, award value, accounting, skill elements, or required controls, and anchors assurance to software identification and verification methods such as hashing. [2] Nevada requires the lab to report SHA‑1 signatures of applicable files and to attest that reviewed source code produced materially identical production software, and to provide a signed statement under penalty of perjury. [3] § 547.8(f) requires an industry‑standard verification methodology for game software, with hashing illustrated, which similarly presumes a verifiable artifact. [2] Whether statistical assurance could substitute for deterministic verification for a generative component is unresolved, and the two answer different questions. [4] More generally, the unit of certification when the product is a process is itself unresolved, so a lab‑defined scope for model‑weight behavior is not stated in the frameworks reviewed. [5]

What the rules say today is that certification attaches to a specific examined artifact identified by a verification method such as hashing, and Nevada and federal Class II texts are built around that assumption [1]. § 547.4(c) applies submission, testing, and a conforming finding to any modification; none of these mechanisms describes continuous automatic change [2]. Accountability is located in named attestors—the laboratory, the manufacturer, and the tribal gaming regulatory authority—not in the origin of a design [3].

How this might be read for dynamic systems: the unit of certification for a process is explicitly unresolved; identified candidates include certifying the generating process, certifying bounds on outputs, or certifying each output before release [4]. When continuous change becomes a modification is also unresolved under Nevada’s definition and approval trigger [4]. Whether statistical assurance could substitute for deterministic verification is unresolved, and the two answer different questions; certificate term becomes ambiguous when model changes outpace software identification [5].

gaming certification requirement identified by IEGM asks applicants to disclose AI‑generated design origin as of September 2026, and whether such disclosure would be useful remains open; NIST’s 2024 Generative AI Profile is voluntary risk guidance, not product certification [3][6].

What the rule says (Nevada; Regulation 14): “all possible game outcomes must be available upon the initiation of each play of a game upon which a player commits a wager on a gaming device” (14.040(3)) [1]. The same Nevada chapter also requires that the outcome be determined “solely by the application of” chance, skill, or a combination (14.040(1)(b)) [2]. How this might be read for dynamic generation: the text does not settle whether “all possible game outcomes” refers to the set of mathematical outcomes the game can produce or to the set of player‑visible artifacts composed during play; IEGM records this as unresolved [1]. Where generated presentation is involved, Nevada’s modification definition excludes artistic attributes unless they are material to gameplay because necessary for the player to understand the game or its outcome; no published test applies that condition to content composed during play, and this remains unresolved [2][3][4]. If a generative component contributes to determining an outcome (not merely presenting it), the “solely” clause becomes relevant; IEGM is not aware of a published United States decision applying that clause to such a component as of September 2026 [2].

§ 547.4(c)(4) places the conforming finding with the tribal gaming regulatory authority [1]. requirement that asks for such disclosure as of September 2026 [1]. What the change‑control texts provide: event‑driven mechanisms premised on discrete, reportable modifications; none describes a process that changes continuously, and whether continuous change should be treated as a stream of modifications, as a single approved process, or as outside today’s framework is unresolved [2]. Related open questions include the unit of certification when the product is a process [3] and who is accountable when no person chose the parameter [4]. Accordingly, how regulators should ensure accountability for ongoing autonomous rule adjustments is not settled in these sources [2][1][3][4].

§ 547.4(c) applies the submission, testing, and conforming‑finding sequence to “any modification thereto” [1]. § 547.8(f) requires an industry‑standard verification methodology such as hashing [2].

How this might be read for evolving generative logic: every cited mechanism is event‑driven and assumes discrete, reportable changes; none describes continuous automatic change, so treating ongoing evolution without prior approvals is not stated in the texts and remains unresolved as of September 2026 [1][3]. Candidate approaches are identified but not adopted: certify the generating process, certify bounds on outputs, or certify each output before release; the unit of certification for a process is unresolved [3]. A dated observation: a January 7, 2026 draft of Nevada technical standards contained no references to AI or generative systems, which does not answer the unresolved questions [4].

§ 547.8(f)), but none of the frameworks identified by IEGM state what the unit should be when the product is a pipeline that produces many artifacts; candidate answers include certifying the generating process, certifying bounds on outputs, or certifying each output, and this is unresolved [1]. Provisions in Nevada Regulation 14.400 and § 547.8(f) presume a stable component, and a system updated, retrained, re‑weighted, or served remotely does not present a single stable artifact; a hash remains checkable but no longer answers whether the running system behaves like the examined one [2]. Change controls in Nevada 14.110(1), 14.010(25), and § 547.4(c) are event‑driven and do not describe continuous change; whether to treat continuous change as a stream of modifications, a single approved process, or as outside current frameworks is unresolved [3]. Whether statistical assurance can substitute for deterministic verification is also unresolved [4]. Certificate term becomes ambiguous when model changes outpace software identification; unresolved [4].

What Nevada Regulation 14 provides is an event‑driven change regime: a “modification” is a change to an approved device that affects the manner or mode of play (including control programs), and a licensed manufacturer must obtain prior written approval from the Chair before making one, with discretion to treat a modification as a new device [1]. Every mechanism identified in the IEGM review assumes a discrete, reportable change; none describes a process that changes continuously, and whether continuous change should be treated as a stream of modifications, as a single approved process, or as outside today’s framework is unresolved [2]. If continuous change is not treated as a modification, the sources do not establish an alternative way Nevada Regulation 14 “handles” an evolving generative system; certification in the materials binds to a specific artifact (e.g., via the SHA1 signature in Nevada 14.400), and no framework identified states the unit of assurance when the product is a process rather than a fixed build [3]. Nevada also presumes all possible game outcomes are available at play initiation, which adds pressure when behavior is composed at runtime, but the text does not settle how that applies to generated artifacts [4].

§ 547.8(f) requires a software verification methodology such as hashing [1]. Change controls are event‑driven: Nevada requires prior written approval for any modification and may treat one as a new device, and § 547.4(c) applies submission, testing, and a conforming finding to any modification [2]. These mechanisms presume discrete, deliberate changes and do not describe continuous automatic change [2]. Generative systems updated, retrained, re‑weighted, or served remotely do not present a single stable artifact; a hash can still be checked, but it no longer answers whether the running system behaves like the examined one [1]. Nevada also requires that all possible game outcomes be available upon initiation of each play, which raises a question when content is composed during play [3]. Whether continuous change should be treated as a stream of modifications, a single approved process, or is outside current frameworks is unresolved [2]. The unit of certification for a process—certify the generator, certify bounds on outputs, or certify each output—also remains unresolved [4]. 7, 2026, Nevada’s post‑workshop draft technical standards did not reference AI or generative systems, a dated observation only [5]. requirement identified by IEGM mandates disclosing AI‑generated design origin [6].

My materials do not identify any regulator or testing laboratory that accepts large‑scale simulation results in place of hash‑based verification, nor do they set conditions under which that would occur [1]. The sources state that it is unresolved whether statistical assurance can substitute for deterministic verification, and note that the two kinds of assurance answer different questions [1]. They also state that simulation of large numbers of plays is a standard method for establishing return, while deterministic verification (e.g., hashing) is used to confirm software identity under federal Class II rules requiring an industry‑standard verification methodology, with hashing given as an illustration [1][2][3]. Accordingly, the materials show both practices exist in regimes today—simulation for return estimation and hashing for identity verification—but do not document any acceptance of simulation as a replacement for, or formally alongside, the required identity‑verification step [1][2][3].

Nevada requires a laboratory statement “signed under penalty of perjury” and a manufacturer certification, and the federal Class II regime places the conforming finding with the tribal gaming regulatory authority; those obligations can be discharged even when an autonomous system proposed the mathematics [1]. The federal sequence applies to “any modification thereto,” preserving a traceable attest-and-review path when changes are made [2]. These mechanisms are event‑driven and assume discrete, deliberate changes; they do not describe continuous automatic change, and how to treat continuous change is unresolved [2]. The rules do not require applicants to disclose whether a paytable, rule set, or model was generated by an autonomous system; whether such disclosure should be required is open [1][3]. Nevada also requires that “all possible game outcomes” be available at play initiation, but whether that refers to mathematical outcomes or player‑visible artifacts is unresolved, which bears on systems that alter rules mid‑play [4]. Voluntary AI risk guidance such as NIST AI 600‑1 is not a certification regime and does not supply mandatory accountability requirements [3].

It is unsettled whether statistical assurance can substitute for deterministic verification; the sources state this question is unresolved and note that the two approaches answer different questions [1]. Federal Class II rules require a verification methodology for game software, with hashing given as an example, which is a deterministic identity check that the deployed component matches what was examined [2]. The premise of such verification presumes a stable component; where behavior derives from model weights that are updated, retrained, re‑weighted, or served remotely, a hash of the deployed binary can still be checked, but it no longer answers whether the running system behaves like the examined one [2]. Change‑control mechanisms in the examined regimes are event‑driven and assume discrete, reportable modifications; none describes a process that changes continuously, leaving the treatment of continuous automatic change unresolved [3]. Accordingly, the materials do not establish a replacement of deterministic verification with statistical assurance for continuously changing generative logic [1][3].

§ 547.4(c) applies the submission, testing, and conforming‑finding sequence to any modification thereto [1]. None of these provisions describes a process that changes continuously; whether continuous change should be treated as a stream of modifications, a single approved process, or outside the current framework is unresolved [1].

The verification premise also presumes a stable component: approval attaches to an artifact identifiable by hashing, but where behavior derives from weights that are updated, retrained, re‑weighted, or served remotely, the hash no longer answers whether the running system behaves like the examined one [2]. Open questions remain: the unit of certification when the product is a process [3]; what happens to a certificate when the underlying model changes [4]; and what a laboratory would examine when behavior derives from model weights rather than readable source [5].

The sources do not establish a certification pathway that treats the generating process as the unit of certification; IEGM records the question of “what is the unit of certification when the product is a process” as unresolved as of September 2026 [1]. As of September 2026, IEGM has identified no United States gaming certification requirement that asks an applicant to disclose whether a submitted paytable, rule set, or mathematical model was generated by an autonomous system, and whether such disclosure should be required remains unresolved [2][3]. part 547) locate attestations with named parties, but they do not require disclosure of autonomous-origin design elements [2]. What a laboratory would examine if behavior derives from model weights rather than readable source is also unresolved, making any disclosure scheme tied to a process unit undefined in scope and attestation content [3]. Relatedly, voluntary AI risk profiles like NIST AI 600‑1 do not create certification obligations and therefore do not supply a disclosure requirement [4].

§ 547.8(f) requires an industry‑standard methodology, acceptable to the tribal gaming regulatory authority, for verifying game software, with signature algorithms and hashing given as examples; verification is a deterministic identity check that the deployed component matches what was examined, not a judgment of quality or fairness [1]. How this might be read for generative logic that evolves during play: the hash of a deployed binary can still be checked, but hashing presumes a stable component and no longer answers whether the running system behaves like the examined one when behavior derives from changing model weights or remote updates; the verification premise is strained [2]. Related controls are event‑driven and assume discrete, reportable modifications; none describes continuous automatic change, leaving a gap for evolving generative behavior [3]. What remains unsettled: whether statistical assurance could substitute for deterministic verification; what the unit of certification should be when the product is a process; and when accumulated automatic change becomes a “modification” requiring prior approval [4][5].

regimes require and where they are silent; they do not prescribe a framework that would newly enable certification of generative systems. [1] Current accountability is anchored to named attestations: Nevada requires a laboratory statement signed under penalty of perjury and a manufacturer certification, and the federal Class II regime places the conforming finding with the tribal gaming regulatory authority. [2] certification requirement to disclose that origin. [2] Voluntary AI risk guidance, such as NIST AI 600‑1, is expressly “intended for voluntary use” and does not supply a certification regime. [3] On the certification unit, candidate approaches are noted—certifying the generating process, certifying bounds on outputs, or certifying each output—but no framework identified by IEGM selects among them. [4] More broadly, these regimes bind approval to a hash‑identified artifact, which presumes a stable component, a presupposition generative systems challenge. [5] As of January 7, 2026, a Nevada draft revising technical standards did not address AI or generative systems by name, which is an observation rather than a prediction. [6]

§ 547.8(f) requires a verification method such as hashing, all premised on comparing what was tested to what is deployed [1][2]. Change controls are event‑driven: Nevada 14.110(1) requires prior written approval for a “modification,” the Chair may treat one as a new device, and § 547.4(c) applies submission, testing, and a conforming finding to any modification thereto [3]. Nevada also requires that all possible game outcomes be available at play initiation, creating tension if rules or outputs are composed during play [4][2].

How this might be read: a continuously self‑modifying generative system is not the stable artifact these mechanisms presuppose; a hash can be checked, but it no longer answers whether runtime behavior matches what the lab examined [1]. Unresolved: whether continuous change is a stream of “modifications,” a single approved process, or outside current frameworks; the unit of certification for a process; and whether runtime‑composed artifacts are the “outcomes” in Nevada’s rule [3][4][5].

§ 547.8(f), which presuppose a stable component whose deployed version should not differ from what the lab examined [1]. When a generative system’s runtime behavior evolves during play, the hash of the deployed binary remains checkable, but that check no longer answers whether the running system behaves like the examined one, because the model-driven behavior is not a single stable artifact [1]. Change controls in Nevada (e.g., 14.110(1), 14.010(25), 14.120(2)) and in the federal Class II regime (§ 547.4(c)) are event‑driven and presume discrete, reportable modifications; none describes continuous automatic change, and how to treat such evolution is unresolved [2]. Nevada Regulation 14.040(3) requires that all possible game outcomes be available at play initiation, but whether that refers to mathematical outcomes or player‑visible artifacts is also unresolved [3]. More broadly, no identified framework states the unit of certification when the product is a changing process, which remains an open question [4].

§ 547.8(f)’s verification methodology requirement (United States; as reviewed by IEGM September 2026) [1][2]. Storage and verification provisions presume stability and treat a difference between the examined and deployed component as an error, not normal operation [1][2]. Change controls exist but are event‑driven: Nevada 14.110(1) requires prior written approval for a “modification,” the Chair may treat one as a new device, and § 547.4(c) applies submission, testing, and a conforming finding to any modification thereto (United States; as reviewed by IEGM September 2026) [3]. None of these mechanisms describes a process that changes continuously during play [3]. The unit of certification when the product is a pipeline that produces many artifacts is unresolved; candidate approaches (process, output bounds, or each output) are noted without a favored answer (United States; as reviewed by IEGM September 2026) [4]. Likewise unresolved is when accumulated automatic change becomes a “modification” requiring prior approval [4].

What the rules say (Nevada; Regulation 14; as reviewed by IEGM in September 2026): approval and change controls are tied to an examined artifact, with the lab reporting SHA1s and attesting source-to-binary identity, and prior written approval required for a “modification,” which the Chair may treat as creating a new device [1][2]. What the rules say (United States; federal Class II; as reviewed by IEGM in September 2026): a testing laboratory must test a system or any modification, and a verification methodology (illustrated by hashing) must anchor what was examined [1][2]. How the texts read on continuous change: every mechanism is event‑driven and presumes discrete, reportable changes; none describes a process that changes continuously [2]. If continuous change is not treated as a modification, the sources do not establish an alternative unit of certification for evolving generative systems; candidate units (process, output bounds, or each output) are identified but unresolved [3]. Related observation: NIST’s Generative AI profile is voluntary risk guidance, not a certification regime [4]. A January 7, 2026 Nevada draft of technical standards did not address AI terms; that is a dated textual observation only [5].

What the rule says (Nevada; Regulation 14): “all possible game outcomes must be available upon the initiation of each play of a game upon which a player commits a wager on a gaming device” (14.040(3)) [1]. The same section requires that outcome be determined “solely by the application of” chance, skill, or a combination, which can matter if a generative component contributes to determining outcome rather than merely presenting it [2]. § 547.8(f) requires a verification methodology, illustrated by hashing [3]. How that interacts with evolution at runtime: these verification provisions presume a stable component and that a difference between tested and deployed behavior is an error, not normal operation; when behavior derives from an updated or remotely served model, a hash no longer answers whether the running thing behaves like the examined thing [3]. The interpretive question you raise—whether “all possible outcomes” refers to the set of mathematical outcomes or to the player-visible artifacts composed during play—is explicitly unresolved in the sources I reviewed [1]. More broadly, current change controls are event‑driven and do not describe continuous automatic change, leaving how to treat such evolution unsettled [4].

What the rule says (Nevada; Regulation 14): approval must precede play, with application, Board evaluation, optional field test, and final approval conditioned on compliance with the Act, Regulation 14, and technical standards adopted under 14.050 [1]. Certification in these regimes binds to a specific artifact identified by a value that changes when the artifact changes, such as the SHA1 signature in Nevada 14.400, and the verification method must prevent a differing component from satisfying the check [2]. Nevada also fixes aspects of play by requiring that all possible game outcomes be available at the initiation of each play and that outcome be determined solely by chance, skill, or a combination [2]. Change controls are event‑driven: Nevada 14.110(1) requires prior written approval for a modification and 14.010(25) brings control‑program changes within that definition; none of the cited mechanisms describes continuous change [3]. What is unsettled: no framework IEGM identified states the unit of certification when the product is a process (candidate units include certifying the generating process, bounds on outputs, or each output), and the threshold at which accumulated automatic change becomes a modification is not stated; both are unresolved [4]. Accordingly, if continuous change is not treated as a modification, the sources do not establish an alternative unit of certification for generative processes under Regulation 14 [4].

That isn't covered in the materials I've been given, so I can't answer it. The parts I couldn't find are listed below.

Nevada (Regulation 14; as reviewed by IEGM in September 2026) treats a “modification” as a change that affects the manner or mode of play and brings changes to control programs within that definition; prior written approval from the Chair is required before making a modification [1][2]. Nevada also excludes changes to software used for artistic attributes—graphics, sound, animation—unless those elements are material to gameplay because they are necessary for the player to understand the game or game outcome; the text supplies no test for applying this to generated presentation composed during play [3]. § 547.4(c) applies the submission, testing, and finding sequence to any modification thereto (United States; as reviewed by IEGM in September 2026) [1][2].

Interpretation: each regime’s change controls are event‑driven and assume discrete, deliberate changes at identifiable moments; they do not describe continuous automatic change [1]. What threshold, if any, turns accumulated automatic adaptation into a “modification” requiring prior approval is unresolved, and no framework IEGM identified states when or whether continuous change should be treated as a stream of modifications or as an approved process subject to monitoring (as of September 2026) [1][4][2].

As of September 2026, IEGM has not identified any United States gaming certification requirement that asks an applicant to disclose whether a submitted paytable, rule set, or mathematical model was generated by an autonomous system; whether such disclosure should be required remains unresolved [1][2]. Nevada Regulation 14 and federal Class II rules locate accountability in attestations by named parties—the Nevada testing laboratory’s statement under penalty of perjury, the manufacturer’s certification, and the tribal gaming regulatory authority’s conforming finding—and each of those obligations can be discharged even when mathematics were proposed by an autonomous system, because the attestations concern the product and testing rather than the design’s origin [1]. Voluntary AI risk guidance exists—NIST AI 600‑1 profiles the AI RMF—but it is “intended for voluntary use” and does not create mandatory certification‑disclosure obligations [3]. What disclosure, if any, should consist of is explicitly unresolved [2].

Nevada requires a laboratory statement signed under penalty of perjury and a manufacturer certification, and the federal Class II regime places the conforming finding with the tribal gaming regulatory authority [1]. Each of those obligations can be discharged even if an autonomous system proposed the mathematics, because the attestations concern the product and the testing rather than the design’s origin [1]. requirement as of September 2026 [1]. Whether disclosure would be useful is treated as an open question, and voluntary AI risk guidance (NIST AI 600‑1) is expressly “intended for voluntary use” and is not a certification requirement [2]. Two accountability points remain unsettled: who is accountable when no person chose a parameter, and what a lab should examine when behavior derives from model weights rather than examinable source [3][4]. decision on that as of September 2026 [5].

§ 547.4(c)(4) places the conforming finding with the tribal gaming regulatory authority [1]. Those attestations can be discharged even when an autonomous system proposed the mathematics, and the texts do not require disclosure of autonomous origin; whether such disclosure should be required is open [1][2]. Generative systems that adjust rules during play surface “content produced at runtime” issues because Nevada Regulation 14.040(3) requires all possible game outcomes to be available at the initiation of each play, and whether that refers to mathematical outcomes or player-visible artifacts is unresolved; IEGM takes no position [3]. decision applying it to such components as of September 2026 [4]. Change controls are event‑driven and do not describe continuous automatic change; how to treat continuous change is unresolved [5]. The unit of certification for a process is also unresolved [6].

§ 547.4(c)(4) places the conforming finding with the tribal gaming regulatory authority [1]. As of September 2026, IEGM has not identified any United States gaming certification requirement that asks an applicant to disclose whether a paytable, rule set, or mathematical model was generated by an autonomous system, and whether such disclosure should be required is unresolved [1][2]. The obligations to attest can be discharged even when the mathematics was proposed by an autonomous system, because the attestations concern the product and testing rather than the design’s origin [1]. Voluntary AI risk management guidance exists—NIST AI 600-1 (July 2024) profiles the AI RMF—but voluntary guidance is a different instrument and does not supply mandatory product-certification disclosure requirements [3][4].