{ "sessionId": "cmudg8tmf000h7piih0ca4bn0", "slug": "governing-what-nobody-has-certified", "slides": [ { "order": 1, "title": "Governing what nobody has certified yet", "bullets": [ "Scope: United States regimes, materials dated Sep 2026", "We separate what rules say from open questions" ], "imageUrl": null, "altText": "Title slide. States session title, scope as United States regimes with materials dated September 2026, and that the presentation will separate what rules say from open questions.", "targetSeconds": 60, "script": "I will speak in the first person. This session is about United States gaming certification regimes as IEGM reviewed them in September 2026. By way of definition: when I say \"certification regime\" I mean the statutes, regulations and technical standards that require an approval or testing report before a device is offered for play. I will separate what a rule says from how it might be read, and I will stop when the sources are silent. The materials I rely on include Nevada Regulation 14 and the federal Class II standards in 25 C.F.R. part 547, as collected and reviewed by IEGM in September 2026.", "sourceReferences": [ "aa1bbf1f-6222-407b-9f16-da2b73562195" ] }, { "order": 2, "title": "Agenda & objectives", "bullets": [ "Three pressures: runtime content, pipeline vs build, autonomous accountability", "Objective: name violated assumptions and identify open questions" ], "imageUrl": null, "altText": "Agenda slide listing the three generative-system pressures: runtime content, pipeline versus build, and accountability for autonomous proposals; and the session objective to identify settled versus open questions.", "targetSeconds": 40, "script": "My agenda and objectives are simple. First, I will name the three pressures generative systems exert on existing regimes: content produced at runtime, certification of a pipeline rather than a single build, and accountability when an autonomous system proposes mathematics. Second, the objective: you should be able to name which certification assumptions are violated and to distinguish settled rules from genuinely open questions. Those three pressures are identified in IEGM's September 2026 analysis.", "sourceReferences": [ "e1d54d79-e50d-4919-b394-32a0b91e395d", "022e47de-023e-45eb-b9c3-ded920e1d970" ] }, { "order": 3, "title": "Certification process as it stands", "bullets": [ "Nevada: approval-before-play; application → testing → approval", "Federal Class II: lab report then tribal finding before use" ], "imageUrl": null, "altText": "Describes the current approval sequence: Nevada requires administrative approval before play with application, testing, optional field test and final approval; Class II requires lab testing and a tribal finding before permitting use.", "targetSeconds": 60, "script": "Here is the certification process as it stands in the two regimes I examined. In Nevada, approval is required before play: the manufacturer or distributor must not distribute and a licensee must not offer a device for play until administrative approval, Commission approval or a Chair-ordered field test occurs. Federally, for Class II systems, submission to a testing laboratory and a written laboratory report precede a tribal gaming regulatory authority's conforming finding; that sequence is required before permitting use or any modification thereto under 25 C.F.R. part 547. This is what the rules say; I will note interpretive gaps later.", "sourceReferences": [ "a89f09d8-6c2c-4038-a595-b5f3b4dad45f", "0182d2d1-94ca-4a49-b83d-2f757f9f0341" ] }, { "order": 4, "title": "What is fixed at submission", "bullets": [ "Approval binds to an artifact identified by values (e.g., SHA1)", "Rules expect a stable component that can be verified" ], "imageUrl": null, "altText": "Explains that certification attaches to specific artifacts identified by values like SHA1, and that rules presume a stable component that can be deterministically verified.", "targetSeconds": 60, "script": "Define the operative fact: certification binds to a specific artifact. Nevada requires the laboratory to report the SHA1 signature of applicable files and to attest that tested source produced materially identical software to production. The federal Class II rules require a verification methodology, illustrated by hashing formulas, and private and Institute standards likewise insist on an identification that changes when a component changes. That is what the rules require; an interpretation is that they presuppose a stable component that can be deterministically checked.", "sourceReferences": [ "bd4823f1-491f-4b11-a362-7e870f56e051", "58eebc55-9bb4-4299-9365-ca6a66759317", "f1692828-7018-4a67-a129-36f706d7fff1" ] }, { "order": 5, "title": "Assumption 1 — Content produced at runtime", "bullets": [ "Rule: all possible outcomes must be available at play start", "Generative composition during play challenges that assumption" ], "imageUrl": null, "altText": "States Nevada's requirement that all possible outcomes be available upon initiation of play, and notes that systems composing content during play raise a question the text does not settle.", "targetSeconds": 70, "script": "Assumption one, stated plainly: the rules assume all possible game outcomes are available at the initiation of each play. Nevada Regulation 14.040(3) expressly requires that \"all possible game outcomes must be available upon the initiation of each play\". That is what the rule says. An interpretive challenge arises when a system composes content during play rather than selecting from an enumerated set; whether the text refers to the set of mathematical outcomes or to the set of artifacts a player sees is unresolved. IEGM takes no position on which reading is correct.", "sourceReferences": [ "22065b28-ddf0-4f17-bbb5-b3fd34d08e40" ] }, { "order": 6, "title": "Nevada: presentation vs material gameplay", "bullets": [ "Artistic attributes excluded unless material to understanding outcome", "No published test for when generated presentation is material" ], "imageUrl": null, "altText": "Explains Nevada's carve-out excluding artistic attributes from 'modification' unless necessary for the player to understand game or outcome, and states there is no published test for applying this to generated content.", "targetSeconds": 60, "script": "How Nevada frames presentation versus material gameplay: Nevada's definition of modification excludes changes to software used for artistic attributes, for example graphics, sound and animation, unless those elements are material to game play because they are necessary for the player to understand the game or game outcome. That is what the rule says. What is not present in the text is a published test for deciding when generated presentation is material rather than merely decorative. That lack of a test is an unresolved question in the sources I examined.", "sourceReferences": [ "dcdfebdc-60b1-45ab-b1e2-53e035782f2f", "c55d8ade-8810-4093-9acd-6b922a7cc501", "27a00b5e-8cef-4845-aa92-6c7f2523e249" ] }, { "order": 7, "title": "Assumption 2 — A pipeline, not a build", "bullets": [ "Certification presumes a stable component to hash or verify", "Model updates or remote serving break that presumption" ], "imageUrl": null, "altText": "Explains that certification assumes a component stable enough to be hashed/verified, and that models updated, retrained or served remotely do not present a single stable artifact.", "targetSeconds": 80, "script": "Assumption two, stated and defined: certification presumes a stable build rather than a changing pipeline. The rules attach approval to an artifact identified by a value that changes when the artifact changes: SHA1 signatures, verification methods and component identifications all serve that function in Nevada, federal part 547, and private standards. That is what the rules say. A system whose behavior derives from a model that is updated, retrained, re-weighted or served remotely does not present a single stable artifact of that kind, undermining the assumption; the hash of a deployed binary may remain checkable but no longer answers whether the running thing behaves like the examined thing.", "sourceReferences": [ "58eebc55-9bb4-4299-9365-ca6a66759317", "ac7f9225-c8d3-448f-9a0d-ffda60da5cc6", "bd4823f1-491f-4b11-a362-7e870f56e051" ] }, { "order": 8, "title": "Where the pipeline question shows up", "bullets": [ "Change mechanisms: prior-approval, retest triggers, certificate scope", "Each is event-driven; none describes continuous change" ], "imageUrl": null, "altText": "Lists existing mechanisms for handling change—prior written approval, retest triggers, certificate scope—and notes they assume discrete, identifiable change events rather than continuous automatic change.", "targetSeconds": 60, "script": "Where the pipeline question shows up in practice: the regimes provide change mechanisms that are event-driven. Nevada requires prior written approval for a modification affecting the manner or mode of play and gives the Chair discretion to treat a modification as a new device; the federal rules apply the submission, testing and finding sequence to any modification thereto. The Institute's standards list retest triggers and periodic recertification upon material change. Each mechanism assumes a discrete, reportable change; none of them describes continuous automatic change. Whether continuous change should be treated as a stream of modifications requiring prior approval, as a single approved process subject to monitoring, or as something the current framework cannot accommodate, is unresolved.", "sourceReferences": [ "ac7f9225-c8d3-448f-9a0d-ffda60da5cc6", "022e47de-023e-45eb-b9c3-ded920e1d970", "26a4b535-9d94-4966-abab-f0dfb7222346", "0182d2d1-94ca-4a49-b83d-2f757f9f0341", "e1d54d79-e50d-4919-b394-32a0b91e395d" ] }, { "order": 9, "title": "Assumption 3 — Accountability for autonomous proposals", "bullets": [ "Attestations name persons and labs, not design origin", "No US requirement asks applicants to disclose machine origin" ], "imageUrl": null, "altText": "States that attestation duties (signed lab statements, manufacturer certification, tribal finding) name persons and labs, and that IEGM has identified no US requirement asking applicants to disclose whether a design was generated by an autonomous system.", "targetSeconds": 60, "script": "Assumption three, stated and defined: accountability in current regimes is tied to named persons and testing laboratories. Nevada requires a laboratory statement signed under penalty of perjury and requires manufacturer certification; part 547 places the conforming finding with the tribal gaming regulatory authority. That is the text. What the texts do not ask is whether applicants must disclose that a paytable, rule set or mathematical model was generated by an autonomous system. IEGM has not identified any U.S. gaming certification requirement that asks for such a disclosure as of September 2026; whether disclosure would be useful is unresolved.", "sourceReferences": [ "04145bcf-d7e4-4bed-8f2f-ff420d6b308c", "c0ae9efa-5a42-4407-b529-fbd2c443c527" ] }, { "order": 10, "title": "Nevada specifics: what certification requires", "bullets": [ "Approval required before distribution or offering for play", "Approval conditioned on statute, regs, and technical standards" ], "imageUrl": null, "altText": "Summarizes Nevada Regulation 14: administrative approval required before distribution or offering for play, and final approval depends on compliance with statute, regulations, and technical standards.", "targetSeconds": 50, "script": "What Nevada requires today, stated with jurisdiction and date: Nevada Regulation 14 requires administrative approval before distribution or offering a gaming device for play, and final approval is conditioned on compliance with the Gaming Control Act, these regulations, and technical standards adopted under section 14.050. That is what the rule says. The Chair publishes technical standards with notice and an objection period; once approved, changing a device is itself a regulated act under Nevada's modification rules.", "sourceReferences": [ "a89f09d8-6c2c-4038-a595-b5f3b4dad45f", "26a4b535-9d94-4966-abab-f0dfb7222346" ] }, { "order": 11, "title": "Federal (Class II) specifics", "bullets": [ "Part 547: lab test report then tribal finding for systems/mods", "Requires a verification methodology (e.g., hashing) for software" ], "imageUrl": null, "altText": "Describes federal Class II process at 25 C.F.R. part 547: submission to testing lab, formal written lab report, and tribal regulatory authority finding; and that part 547 requires an industry-standard methodology for verifying game software.", "targetSeconds": 50, "script": "What the federal Class II regime requires today: 25 C.F.R. part 547 requires that a testing laboratory test a system or any modification and provide a formal written report certifying its findings before a tribal gaming regulatory authority may make a conforming finding. Section 547.8(f) requires an industry-standard verification methodology for game software, with hashing illustrated as an acceptable approach. That is what the federal text says; it anchors approval to an examined thing and re-opens review when that thing changes.", "sourceReferences": [ "0182d2d1-94ca-4a49-b83d-2f757f9f0341", "f1692828-7018-4a67-a129-36f706d7fff1" ] }, { "order": 12, "title": "Open Q — unit of certification & continuous change", "bullets": [ "Unresolved: certify process, output bounds, or each output?", "Unresolved: when continuous change becomes a modification" ], "imageUrl": null, "altText": "States unresolved questions: what the unit of certification should be for a pipeline (process, bounds, or each output) and that no framework sets a threshold for when continuous automatic change is a modification requiring approval.", "targetSeconds": 60, "script": "Open question: the unit of certification and continuous change. The sources show the core unresolved choices: certify the generating process, certify bounds on outputs, or certify each output before release. The frameworks IEGM reviewed do not state which of those is the unit when the product is a process; IEGM records the question as unresolved. Also unresolved is when accumulated automatic change becomes a modification requiring prior approval; Nevada's definition assumes discrete changes and provides no threshold for continuous change. I will not answer those questions here because the rules do not.", "sourceReferences": [ "27a00b5e-8cef-4845-aa92-6c7f2523e249", "022e47de-023e-45eb-b9c3-ded920e1d970", "ac7f9225-c8d3-448f-9a0d-ffda60da5cc6" ] }, { "order": 13, "title": "Open Q — disclosure, lab scope, statistical vs deterministic", "bullets": [ "Unresolved: must origin of design be disclosed to regulators?", "Unresolved: what would a lab examine when behavior is in model weights", "Unresolved: can statistical assurance replace deterministic verification?" ], "imageUrl": null, "altText": "Lists unresolved issues: disclosure of design origin, what laboratories should examine when behavior derives from model weights, and whether statistical assurance can substitute for deterministic verification.", "targetSeconds": 50, "script": "Open question: disclosure, laboratory scope, and statistical versus deterministic assurance. IEGM found no U.S. requirement that asks whether a submitted design was machine-generated; whether such disclosure should be required is unresolved. What a laboratory would examine when behavior derives from model weights rather than readable source code is unresolved; current scope rules assume examinable source. Whether statistical assurance—large-sample simulation—can substitute for deterministic verification like hashing is also unresolved, and the Institute notes that they answer different questions today.", "sourceReferences": [ "c0ae9efa-5a42-4407-b529-fbd2c443c527", "9d009938-7608-40b2-968f-1328f31a1727", "22065b28-ddf0-4f17-bbb5-b3fd34d08e40", "f1692828-7018-4a67-a129-36f706d7fff1" ] }, { "order": 14, "title": "Practical implications (interpretive, not normative)", "bullets": [ "Common applicant steps: freeze builds, document update policies", "Labs and vendors use large-scale simulation where relevant" ], "imageUrl": null, "altText": "Provides interpretive practical steps applicants and labs currently take: freezing builds for submission, documenting update policies, and using large-scale simulation—stated as interpretive responses, not regulatory requirements.", "targetSeconds": 40, "script": "Practical implications for applicants and labs, presented as interpretation, not regulation: in practice, applicants and test labs take conservative, interpretive steps today. Common responses include freezing a build for submission, documenting update and rollback policies, and using large-scale simulation to establish statistical properties where appropriate. These are interpretive, pragmatic measures the industry uses in the absence of new rules; they are not themselves regulatory requirements and I label them as interpretive responses.", "sourceReferences": [ "022e47de-023e-45eb-b9c3-ded920e1d970", "ac7f9225-c8d3-448f-9a0d-ffda60da5cc6", "9d009938-7608-40b2-968f-1328f31a1727" ] }, { "order": 15, "title": "Conclusion & takeaways", "bullets": [ "Name certification assumptions generative systems violate", "Identify which questions are genuinely unresolved as of Sep 2026" ], "imageUrl": null, "altText": "Concluding slide prompting attendees to name the certification assumptions that generative systems violate and to recognize which questions remain unresolved as of September 2026.", "targetSeconds": 35, "script": "Conclusion and takeaways. Name the three certification assumptions generative systems violate: that outcomes are enumerated at play start, that there is a single stable build to verify, and that accountability corresponds to human-origin attestations. And name which questions are genuinely unresolved as of September 2026: the unit of certification for processes, when continuous change counts as a modification, whether origin-of-design must be disclosed, what a lab should examine for model-weighted behavior, and whether statistical assurance can replace deterministic verification. Where the sources are silent, I have stopped rather than guessed.", "sourceReferences": [ "e1d54d79-e50d-4919-b394-32a0b91e395d", "27a00b5e-8cef-4845-aa92-6c7f2523e249", "22065b28-ddf0-4f17-bbb5-b3fd34d08e40", "58eebc55-9bb4-4299-9365-ca6a66759317", "04145bcf-d7e4-4bed-8f2f-ff420d6b308c", "ac7f9225-c8d3-448f-9a0d-ffda60da5cc6", "c0ae9efa-5a42-4407-b529-fbd2c443c527", "9d009938-7608-40b2-968f-1328f31a1727" ] } ] }