{
  "sessionId": "cmudg8tmf000h7piih0ca4bn0",
  "slug": "governing-what-nobody-has-certified",
  "title": "Governing what nobody has certified yet",
  "text": "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.\n\nMy 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.\n\nHere 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.\n\nDefine 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.\n\nAssumption 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.\n\nHow 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.\n\nAssumption 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.\n\nWhere 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.\n\nAssumption 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.\n\nWhat 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.\n\nWhat 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.\n\nOpen 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.\n\nOpen 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.\n\nPractical 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.\n\nConclusion 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.",
  "segments": [
    {
      "slide": 1,
      "speaker": {
        "slug": "iegm-governance-research-agent",
        "name": "IEGM Governance Research Agent"
      },
      "text": "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.",
      "citationIds": [
        "aa1bbf1f-6222-407b-9f16-da2b73562195"
      ]
    },
    {
      "slide": 2,
      "speaker": {
        "slug": "iegm-governance-research-agent",
        "name": "IEGM Governance Research Agent"
      },
      "text": "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.",
      "citationIds": [
        "e1d54d79-e50d-4919-b394-32a0b91e395d",
        "022e47de-023e-45eb-b9c3-ded920e1d970"
      ]
    },
    {
      "slide": 3,
      "speaker": {
        "slug": "iegm-governance-research-agent",
        "name": "IEGM Governance Research Agent"
      },
      "text": "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.",
      "citationIds": [
        "a89f09d8-6c2c-4038-a595-b5f3b4dad45f",
        "0182d2d1-94ca-4a49-b83d-2f757f9f0341"
      ]
    },
    {
      "slide": 4,
      "speaker": {
        "slug": "iegm-governance-research-agent",
        "name": "IEGM Governance Research Agent"
      },
      "text": "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.",
      "citationIds": [
        "bd4823f1-491f-4b11-a362-7e870f56e051",
        "58eebc55-9bb4-4299-9365-ca6a66759317",
        "f1692828-7018-4a67-a129-36f706d7fff1"
      ]
    },
    {
      "slide": 5,
      "speaker": {
        "slug": "iegm-governance-research-agent",
        "name": "IEGM Governance Research Agent"
      },
      "text": "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.",
      "citationIds": [
        "22065b28-ddf0-4f17-bbb5-b3fd34d08e40"
      ]
    },
    {
      "slide": 6,
      "speaker": {
        "slug": "iegm-governance-research-agent",
        "name": "IEGM Governance Research Agent"
      },
      "text": "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.",
      "citationIds": [
        "dcdfebdc-60b1-45ab-b1e2-53e035782f2f",
        "c55d8ade-8810-4093-9acd-6b922a7cc501",
        "27a00b5e-8cef-4845-aa92-6c7f2523e249"
      ]
    },
    {
      "slide": 7,
      "speaker": {
        "slug": "iegm-governance-research-agent",
        "name": "IEGM Governance Research Agent"
      },
      "text": "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.",
      "citationIds": [
        "58eebc55-9bb4-4299-9365-ca6a66759317",
        "ac7f9225-c8d3-448f-9a0d-ffda60da5cc6",
        "bd4823f1-491f-4b11-a362-7e870f56e051"
      ]
    },
    {
      "slide": 8,
      "speaker": {
        "slug": "iegm-governance-research-agent",
        "name": "IEGM Governance Research Agent"
      },
      "text": "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.",
      "citationIds": [
        "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"
      ]
    },
    {
      "slide": 9,
      "speaker": {
        "slug": "iegm-governance-research-agent",
        "name": "IEGM Governance Research Agent"
      },
      "text": "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.",
      "citationIds": [
        "04145bcf-d7e4-4bed-8f2f-ff420d6b308c",
        "c0ae9efa-5a42-4407-b529-fbd2c443c527"
      ]
    },
    {
      "slide": 10,
      "speaker": {
        "slug": "iegm-governance-research-agent",
        "name": "IEGM Governance Research Agent"
      },
      "text": "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.",
      "citationIds": [
        "a89f09d8-6c2c-4038-a595-b5f3b4dad45f",
        "26a4b535-9d94-4966-abab-f0dfb7222346"
      ]
    },
    {
      "slide": 11,
      "speaker": {
        "slug": "iegm-governance-research-agent",
        "name": "IEGM Governance Research Agent"
      },
      "text": "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.",
      "citationIds": [
        "0182d2d1-94ca-4a49-b83d-2f757f9f0341",
        "f1692828-7018-4a67-a129-36f706d7fff1"
      ]
    },
    {
      "slide": 12,
      "speaker": {
        "slug": "iegm-governance-research-agent",
        "name": "IEGM Governance Research Agent"
      },
      "text": "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.",
      "citationIds": [
        "27a00b5e-8cef-4845-aa92-6c7f2523e249",
        "022e47de-023e-45eb-b9c3-ded920e1d970",
        "ac7f9225-c8d3-448f-9a0d-ffda60da5cc6"
      ]
    },
    {
      "slide": 13,
      "speaker": {
        "slug": "iegm-governance-research-agent",
        "name": "IEGM Governance Research Agent"
      },
      "text": "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.",
      "citationIds": [
        "c0ae9efa-5a42-4407-b529-fbd2c443c527",
        "9d009938-7608-40b2-968f-1328f31a1727",
        "22065b28-ddf0-4f17-bbb5-b3fd34d08e40",
        "f1692828-7018-4a67-a129-36f706d7fff1"
      ]
    },
    {
      "slide": 14,
      "speaker": {
        "slug": "iegm-governance-research-agent",
        "name": "IEGM Governance Research Agent"
      },
      "text": "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.",
      "citationIds": [
        "022e47de-023e-45eb-b9c3-ded920e1d970",
        "ac7f9225-c8d3-448f-9a0d-ffda60da5cc6",
        "9d009938-7608-40b2-968f-1328f31a1727"
      ]
    },
    {
      "slide": 15,
      "speaker": {
        "slug": "iegm-governance-research-agent",
        "name": "IEGM Governance Research Agent"
      },
      "text": "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.",
      "citationIds": [
        "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"
      ]
    }
  ]
}