{
  "sessionId": "cmudg6m8u000e2yiihrfftgpa",
  "slug": "the-part-everyone-skips",
  "sources": [
    {
      "id": "8c902c5c-49cc-4559-af25-107c23a442aa",
      "label": "What the Sealed Jars pipeline guarantees ¶2",
      "title": "What the Sealed Jars pipeline guarantees — The stages",
      "source": "Sealed Jars, September 2026",
      "pageNumber": null,
      "text": "## The stages\n\nA game passes through eight stages, and each one is a statement that becomes true of the build once\nit is complete.\n\n**Concept.** The game has a title, a symbol set, a theme and an art direction, and the title has\nbeen checked against the existing library so it is not a near-duplicate of a game already made.\n\n**Mathematics.** The game has a finite ticket pool with a known size, a known price, a measured\npayback percentage and a measured hit rate. For paper-mode games the pool is between 2,520 and\n4,000 tickets and the payback sits between 74 and 78 percent. Those are measurements taken from the\ngenerated tickets, not settings copied from the request that produced them.\n\n**Artwork.** Every symbol in the configuration has its own image, stored under its own name, and the\ngame has a background, a logo, two frames and its buttons. A game with seven symbols has seven\nsymbol images, not six and a filename that happens to exist.\n\n**Animation.** Where a game is animated, each animated element is a clip that loops without a\nvisible jump, and each clip is a real file of plausible size rather than an empty placeholder left\nby a failed job.\n\n**Audio.** The game has its full set of six tracks: an ambient score and five win and bonus cues.\n\n**Slot presentation.** Where the game is also offered as a five-reel slot, it has reel strips of a\nfixed, uniform length, every paying symbol appears on every reel, the paytable is derived from the\ngame's own symbol values, and the simulated return and hit frequency fall inside the bands we hold\nourselves to.",
      "document": {
        "id": "cmudg6a0i00012yiik7b38uqt",
        "title": "What the Sealed Jars pipeline guarantees",
        "summary": "The document outlines the Sealed Jars pipeline, detailing the eight stages a game goes through, the guarantees a passing build carries, and the refusals that prevent shipment. It is an internal, self-described specification of their own checks on their work, not an official regulator approval."
      },
      "knowledgeBank": {
        "slug": "jars",
        "name": "Sealed Jars"
      }
    },
    {
      "id": "360ee6a6-6779-452c-a635-f6ab44eb9065",
      "label": "What the Sealed Jars pipeline guarantees ¶3",
      "title": "What the Sealed Jars pipeline guarantees — The stages",
      "source": "Sealed Jars, September 2026",
      "pageNumber": null,
      "text": "orm length, every paying symbol appears on every reel, the paytable is derived from the\ngame's own symbol values, and the simulated return and hit frequency fall inside the bands we hold\nourselves to.\n\n**Assembly.** The runtime configuration, the ticket pool, the reel strips, the artwork, the audio\nand both entry points are packaged together as one self-contained game.\n\n**Verification.** Every check in document two has been run against the assembled build and has\npassed. This is the stage that decides whether anything leaves.",
      "document": {
        "id": "cmudg6a0i00012yiik7b38uqt",
        "title": "What the Sealed Jars pipeline guarantees",
        "summary": "The document outlines the Sealed Jars pipeline, detailing the eight stages a game goes through, the guarantees a passing build carries, and the refusals that prevent shipment. It is an internal, self-described specification of their own checks on their work, not an official regulator approval."
      },
      "knowledgeBank": {
        "slug": "jars",
        "name": "Sealed Jars"
      }
    },
    {
      "id": "f33eaa91-f384-4a2b-a895-66533459f75a",
      "label": "What the Sealed Jars pipeline guarantees ¶4",
      "title": "What the Sealed Jars pipeline guarantees — What is true of every build that comes out",
      "source": "Sealed Jars, September 2026",
      "pageNumber": null,
      "text": "## What is true of every build that comes out\n\nA build that reaches the far end carries four guarantees, and all four are checkable by anyone who\nreceives the package.\n\nFirst, **the mathematics is measured, not asserted.** Payback, hit rate, deck size, top prize,\nstandard deviation and volatility are computed by reading the finished ticket pool ticket by ticket.\nIf the pool was hand-edited after generation, the numbers are recomputed from the edited pool. There\nis no path by which a build reports the payback that was requested rather than the payback it has.\n\nSecond, **the advertised prizes match the achievable prizes.** Every symbol's stated payout equals\nthe largest win that symbol actually produces in the pool, every symbol that can pay appears in the\npaytable, and no prize in the pool falls below the smallest payout a symbol can award. A game cannot\nadvertise a prize it cannot pay, or pay one it never advertised.\n\nThird, **the package is complete.** Every asset the configuration refers to exists, by name, as a\nvalid file. Missing art, a truncated image, an empty animation or a missing audio track stops the\nbuild rather than shipping as a broken reference that surfaces in front of a player.\n\nFourth, **the build is reproducible.** Every generated asset is stored with the description and the\nstarting number that produced it, and the models that produced it are files we keep. A game shipped\nin January can be reopened in September and rebuilt in the same style, which matters when a question\narrives months after the work.",
      "document": {
        "id": "cmudg6a0i00012yiik7b38uqt",
        "title": "What the Sealed Jars pipeline guarantees",
        "summary": "The document outlines the Sealed Jars pipeline, detailing the eight stages a game goes through, the guarantees a passing build carries, and the refusals that prevent shipment. It is an internal, self-described specification of their own checks on their work, not an official regulator approval."
      },
      "knowledgeBank": {
        "slug": "jars",
        "name": "Sealed Jars"
      }
    },
    {
      "id": "592efb48-55d1-477d-86de-a433fe9f073c",
      "label": "What the Sealed Jars pipeline guarantees ¶5",
      "title": "What the Sealed Jars pipeline guarantees — What the pipeline refuses to ship",
      "source": "Sealed Jars, September 2026",
      "pageNumber": null,
      "text": "## What the pipeline refuses to ship\n\nRefusals are more informative than guarantees, so here are the concrete ones.\n\n**A ticket pool outside its band.** A deck whose measured payback or hit rate falls outside the\nrange for its mode does not ship. This is a hard stop, not a warning.\n\n**A prize below the floor.** If the smallest symbol payout is five dollars, a pool containing a\none-dollar prize is rejected, because that prize cannot be produced by any winning combination the\ngame actually offers.\n\n**A payout that does not match the pool.** If the configuration says a symbol pays 150 and the\nlargest win that symbol produces is 50, the build stops. In our experience this is the most common\nway a generated game goes quietly wrong, and it is invisible to the eye.\n\n**Artwork with text in it.** Backgrounds are read by vision models, and a background with words\npainted into the art is refused. We enforce this because image models write text into pictures\nunasked, and because the resulting word is often misspelled.\n\n**A title that reads back wrong.** A logo is read back letter by letter, and a logo that does not\nspell the game's title exactly is refused. We adopted a stricter version of this check in September\n2026 after discovering that a weaker one had been reporting the title it expected rather than the\nletters actually drawn. Logos reading \"Solipse Rush\" and \"Pyranid of Riches\" reached players before\nwe caught it. The check exists because we failed it.",
      "document": {
        "id": "cmudg6a0i00012yiik7b38uqt",
        "title": "What the Sealed Jars pipeline guarantees",
        "summary": "The document outlines the Sealed Jars pipeline, detailing the eight stages a game goes through, the guarantees a passing build carries, and the refusals that prevent shipment. It is an internal, self-described specification of their own checks on their work, not an official regulator approval."
      },
      "knowledgeBank": {
        "slug": "jars",
        "name": "Sealed Jars"
      }
    },
    {
      "id": "f24da3fc-529c-4ef5-9982-99278380d157",
      "label": "What the Sealed Jars pipeline guarantees ¶6",
      "title": "What the Sealed Jars pipeline guarantees — What the pipeline refuses to ship",
      "source": "Sealed Jars, September 2026",
      "pageNumber": null,
      "text": "Logos reading \"Solipse Rush\" and \"Pyranid of Riches\" reached players before\nwe caught it. The check exists because we failed it.\n\n**An incomplete bonus.** A pick-em bonus is either fully specified on every ticket that awards it or\nabsent from the game. A partially configured bonus, which would strand a player mid-feature, is\ntreated as a build failure rather than a cosmetic one.\n\n**Reel strips that cannot pay.** If a paying symbol is missing from a reel, or the strips are not\nthe length the presentation expects, or the simulated return falls outside its band, the slot\npresentation does not ship.\n\n**A game that will not play.** An automated browser suite plays builds through the real interface.\nA game that loads incorrectly, fails to spin or pays differently than designed is stopped there,\nregardless of how good its numbers look on paper.\n\nThe common thread is that none of these are matters of taste. A human can look at a generated game\nand see that it is attractive, coherent and finished, and still be looking at a game whose top\nsymbol cannot pay its advertised prize. The pipeline exists to catch the things that looking cannot.",
      "document": {
        "id": "cmudg6a0i00012yiik7b38uqt",
        "title": "What the Sealed Jars pipeline guarantees",
        "summary": "The document outlines the Sealed Jars pipeline, detailing the eight stages a game goes through, the guarantees a passing build carries, and the refusals that prevent shipment. It is an internal, self-described specification of their own checks on their work, not an official regulator approval."
      },
      "knowledgeBank": {
        "slug": "jars",
        "name": "Sealed Jars"
      }
    },
    {
      "id": "48349d8f-d4c4-4ab1-9557-672500637819",
      "label": "The verification checklist ¶2",
      "title": "The verification checklist — Mathematics",
      "source": "Sealed Jars, September 2026",
      "pageNumber": null,
      "text": "## Mathematics\n\n**All mathematics is verified.** Every number a build reports about itself is recomputed from the\nfinished ticket pool before the build is allowed out.\n\n**Deck size.** The pool must contain the number of tickets the game claims, and for paper-mode games\nthat count must fall in the range we hold ourselves to. A pool of the wrong size fails the build.\n\n**Payback.** The total value of every winning ticket, divided by the value of the whole pool at the\nticket price, must fall inside the band for the game's mode. Outside the band, the build stops.\n\n**Hit rate.** The proportion of tickets that win anything must fall inside its band. Too generous\nfails as surely as too stingy, because both mean the deck is not the game that was specified.\n\n**Prize floor.** No prize in the pool may be smaller than the smallest payout any symbol can award.\nA prize that no combination in the game can produce is a defect, not a rounding artifact.\n\n**Payout integrity.** Each symbol's advertised payout must equal the largest win that symbol\nactually produces in the pool, and every symbol that pays must appear in the paytable. A mismatch\nfails the build, and the deck rather than the advertised value is treated as the truth.\n\n**Ticket price consistency.** The price recorded in the ticket pool and the price recorded in the\nruntime configuration must agree. They are read from different files by different consumers, and a\ndisagreement is a build failure.",
      "document": {
        "id": "cmudg6d5h00042yiigild883q",
        "title": "The verification checklist",
        "summary": "- The document is a structured verification checklist used in the game-build pipeline, listing checks (mathematics, artwork, trademarks, assets, etc.) and describing what each check looks for and what happens when it fires. \n- It is an internal procedural source from Sealed Jars (dated September 2026) that specifies the criteria and outcomes for each verification step."
      },
      "knowledgeBank": {
        "slug": "jars",
        "name": "Sealed Jars"
      }
    },
    {
      "id": "58640254-6a6c-4ca4-b828-4fe18439dc36",
      "label": "The verification checklist ¶3",
      "title": "The verification checklist — Mathematics",
      "source": "Sealed Jars, September 2026",
      "pageNumber": null,
      "text": "They are read from different files by different consumers, and a\ndisagreement is a build failure.\n\n**Variance statistics.** Standard deviation, volatility index and maximum win as a multiple of the\nbet are computed for every build, so that any volatility claim made later is a measurement.\n\n**Reel simulation.** For games with a slot presentation, the reels are simulated to confirm the\nreturn and hit frequency fall inside their bands, that the strips are the uniform length the\npresentation expects, that every paying symbol appears on every reel, and that the paytable is\nconsistent with the game's own symbol values. Any of those failing stops the slot build.\n\n**Recomputation after editing.** If a human edits the prize distribution, every statistic above is\nrecomputed from the edited pool, and the edited build must pass the same checks as a generated one.\nEditing does not grant a pass.",
      "document": {
        "id": "cmudg6d5h00042yiigild883q",
        "title": "The verification checklist",
        "summary": "- The document is a structured verification checklist used in the game-build pipeline, listing checks (mathematics, artwork, trademarks, assets, etc.) and describing what each check looks for and what happens when it fires. \n- It is an internal procedural source from Sealed Jars (dated September 2026) that specifies the criteria and outcomes for each verification step."
      },
      "knowledgeBank": {
        "slug": "jars",
        "name": "Sealed Jars"
      }
    },
    {
      "id": "4534440c-639b-49cf-b062-eba0d3989ce8",
      "label": "The verification checklist ¶4",
      "title": "The verification checklist — Artwork and text",
      "source": "Sealed Jars, September 2026",
      "pageNumber": null,
      "text": "## Artwork and text\n\n**Backgrounds are read for text.** Vision models read every background and report any lettering,\nwords or numbers painted into the artwork. A background with text in it is refused, because that\ntext sits underneath the game's own title in play and because image models produce it unasked.\n\n**Text found is spell-checked.** Anything readable in a game's artwork is compared against what it\nis supposed to say. This matters most on the logo, which is the one image that is supposed to\ncontain words.\n\n**Titles are read back letter by letter.** A logo passes only when two separate vision models read\nthe game's title correctly and at least one of them spells it out character by character correctly.\nPlain reading alone is not sufficient: a model asked to read a title tends to report the title it\nexpects. Spelling it out defeats that, and it is how we catch a doubled word, an invented letter or\na title that has drifted by one character.\n\n**Frames are checked for a clear play area.** A frame is a border. A frame with decoration\nencroaching into the center, or with text in it, is refused, because the game's reels or tickets\nhave to sit inside it.\n\n**Transparency is checked.** Assets that must sit on top of other artwork are checked for leftover\nbackground, and an asset whose transparency did not come out cleanly is regenerated rather than\ncomposited with a visible box around it.",
      "document": {
        "id": "cmudg6d5h00042yiigild883q",
        "title": "The verification checklist",
        "summary": "- The document is a structured verification checklist used in the game-build pipeline, listing checks (mathematics, artwork, trademarks, assets, etc.) and describing what each check looks for and what happens when it fires. \n- It is an internal procedural source from Sealed Jars (dated September 2026) that specifies the criteria and outcomes for each verification step."
      },
      "knowledgeBank": {
        "slug": "jars",
        "name": "Sealed Jars"
      }
    },
    {
      "id": "251828eb-86fb-4dcb-a7fa-1330b41a7979",
      "label": "The verification checklist ¶5",
      "title": "The verification checklist — Artwork and text",
      "source": "Sealed Jars, September 2026",
      "pageNumber": null,
      "text": "that must sit on top of other artwork are checked for leftover\nbackground, and an asset whose transparency did not come out cleanly is regenerated rather than\ncomposited with a visible box around it.\n\n**Asset integrity.** Every image file is checked for structural validity. Generation tools can write\na truncated or corrupt file when a job is interrupted, and such a file looks fine in a directory\nlisting and fails in front of a player. Corrupt files are discarded and regenerated.\n\n**Animation integrity.** Each animated clip is checked for existence and plausible size, so that a\nfailed job that left an empty file behind is caught rather than shipped as a game element that never\nmoves.",
      "document": {
        "id": "cmudg6d5h00042yiigild883q",
        "title": "The verification checklist",
        "summary": "- The document is a structured verification checklist used in the game-build pipeline, listing checks (mathematics, artwork, trademarks, assets, etc.) and describing what each check looks for and what happens when it fires. \n- It is an internal procedural source from Sealed Jars (dated September 2026) that specifies the criteria and outcomes for each verification step."
      },
      "knowledgeBank": {
        "slug": "jars",
        "name": "Sealed Jars"
      }
    },
    {
      "id": "768a2eba-016b-4893-8d88-bfed5596ae42",
      "label": "The verification checklist ¶7",
      "title": "The verification checklist — Everything else that runs",
      "source": "Sealed Jars, September 2026",
      "pageNumber": null,
      "text": "## Everything else that runs\n\n**Symbol coverage.** Every symbol named in the configuration must have its own artwork under its own\nname. Counting files is not sufficient and we do not do it that way, because a game can have the\nright number of images and still be missing the one the paytable depends on.\n\n**Package completeness.** The ticket pool, the runtime configuration, the reel strips, both entry\npoints, the artwork, the animations and all six audio tracks must be present. A build missing one\nfile does not ship.\n\n**Audio completeness.** The ambient score and all five win and bonus cues must exist as playable\nfiles.\n\n**Bonus completeness.** Where a game includes a pick-em bonus, every ticket that awards it must\ncarry a fully specified bonus. Partial configuration fails the build.\n\n**Configuration consistency.** The fields the platform reads at runtime must be present and\ninternally consistent, including the paytable, the draw modes the game supports and the symbol\nrecords the interface renders from.\n\n**End-to-end play.** An automated browser suite loads builds in the real interface and plays them,\nconfirming that they start, spin, resolve and pay as designed. This is the check that catches\nfailures which every file-level check passes.\n\n**Reproducibility.** Each asset is stored with the inputs that produced it, so the build can be\nrebuilt or partially regenerated later in the same style.",
      "document": {
        "id": "cmudg6d5h00042yiigild883q",
        "title": "The verification checklist",
        "summary": "- The document is a structured verification checklist used in the game-build pipeline, listing checks (mathematics, artwork, trademarks, assets, etc.) and describing what each check looks for and what happens when it fires. \n- It is an internal procedural source from Sealed Jars (dated September 2026) that specifies the criteria and outcomes for each verification step."
      },
      "knowledgeBank": {
        "slug": "jars",
        "name": "Sealed Jars"
      }
    },
    {
      "id": "ec449f94-84de-4b3a-bbd3-02d12018bedb",
      "label": "The verification checklist ¶8",
      "title": "The verification checklist — Everything else that runs",
      "source": "Sealed Jars, September 2026",
      "pageNumber": null,
      "text": "**Reproducibility.** Each asset is stored with the inputs that produced it, so the build can be\nrebuilt or partially regenerated later in the same style.\n\n**Regulatory export.** Every build can produce a PAR sheet describing its prize structure,\nprobabilities, return and volatility, together with a math summary, for submission to an independent\ntest laboratory. Producing that document is part of the build's own description of itself, not a\nseparate act of interpretation.\n\nIf the list reads as longer than expected, that is the point of including it. Most of the work in\ngenerated game development is not generation.",
      "document": {
        "id": "cmudg6d5h00042yiigild883q",
        "title": "The verification checklist",
        "summary": "- The document is a structured verification checklist used in the game-build pipeline, listing checks (mathematics, artwork, trademarks, assets, etc.) and describing what each check looks for and what happens when it fires. \n- It is an internal procedural source from Sealed Jars (dated September 2026) that specifies the criteria and outcomes for each verification step."
      },
      "knowledgeBank": {
        "slug": "jars",
        "name": "Sealed Jars"
      }
    },
    {
      "id": "8ef2d407-c577-4689-8804-f83bfa42dd5a",
      "label": "Verification, and what it does not mean ¶2",
      "title": "Verification, and what it does not mean — What a passed check establishes",
      "source": "Sealed Jars, September 2026",
      "pageNumber": null,
      "text": "## What a passed check establishes\n\nA build that has passed our verification has been compared against its own specification and\nmatches it. Concretely: the ticket pool contains the number of tickets it says it contains; the\nmeasured payback and hit rate fall inside the stated band; every advertised payout equals the\nlargest win that symbol produces in the pool; no prize sits below the floor; every asset the\nconfiguration names exists as a valid file; the title in the logo spells the game's name; no text\nis painted into the background art; and the game loads, plays and pays in an automated run through\nthe real interface.\n\nThat is a statement about internal consistency and about measured behavior. It is worth something:\nthese are the failures that generated games actually have, and they are largely invisible to\ninspection. A person can look at a finished game for a long time without noticing that its top\nsymbol advertises a prize it cannot pay.\n\nA passed build also carries its own evidence. The mathematics is exportable as a PAR sheet, the\nstatistics are measurements rather than assertions, and the inputs that produced every asset are\nretained, so the claims can be re-checked by somebody else later rather than taken on trust.",
      "document": {
        "id": "cmudg6fz400072yii1s6jsgry",
        "title": "Verification, and what it does not mean",
        "summary": "The document outlines what a passed verification check establishes and what it does not establish, detailing how a build is tested against its own specification and what evidence is produced. It is a policy-style document from Sealed Jars (dated September 2026) describing their verification process and its limitations."
      },
      "knowledgeBank": {
        "slug": "jars",
        "name": "Sealed Jars"
      }
    },
    {
      "id": "be505943-f55d-4e94-a83c-6d2022be9e1a",
      "label": "Verification, and what it does not mean ¶3",
      "title": "Verification, and what it does not mean — What it does not establish",
      "source": "Sealed Jars, September 2026",
      "pageNumber": null,
      "text": "## What it does not establish\n\nVerification does not establish that a game is any good. Nothing in the checklist has an opinion\nabout whether a theme is appealing, whether the art is attractive, or whether the game is fun. A\ndull game passes exactly as easily as a compelling one.\n\nIt does not establish that the mathematics is commercially sensible. A deck can sit inside every\nband we hold ourselves to and still be wrong for a particular room, a particular price point or a\nparticular operator. The bands say the game is what it claims to be, not that anyone should want it.\n\nIt does not establish legal clearance of a name, a theme or an image. As document two states\nplainly, no trademark search runs inside the pipeline. A passing build carries no representation\nthat its title, its artwork or its theme is free of third-party rights anywhere.\n\nIt does not establish that the artwork is free of every defect. Our art checks are specific: text in\nbackgrounds, spelling in titles, clear play areas in frames, clean transparency, structurally valid\nfiles. They will not catch an anatomical error in a character, a subtle style mismatch between two\nsymbols, or a composition that is merely ugly. Those are matters for human review, and human review\nis where they are caught.",
      "document": {
        "id": "cmudg6fz400072yii1s6jsgry",
        "title": "Verification, and what it does not mean",
        "summary": "The document outlines what a passed verification check establishes and what it does not establish, detailing how a build is tested against its own specification and what evidence is produced. It is a policy-style document from Sealed Jars (dated September 2026) describing their verification process and its limitations."
      },
      "knowledgeBank": {
        "slug": "jars",
        "name": "Sealed Jars"
      }
    },
    {
      "id": "c1914f2f-651a-4bd9-b085-681277c91d43",
      "label": "Verification, and what it does not mean ¶4",
      "title": "Verification, and what it does not mean — What it does not establish",
      "source": "Sealed Jars, September 2026",
      "pageNumber": null,
      "text": "Those are matters for human review, and human review\nis where they are caught.\n\nIt does not establish that vision models read correctly every time. Our title check exists because\nan earlier, weaker version of it failed: a model reported the name it expected instead of the\nletters drawn, and misspelled logos reached players. The current check uses two models and requires\none of them to spell the title out character by character. That is materially stronger, and it is\nstill a model reading an image. We treat a pass as strong evidence, not as proof.\n\nIt does not establish behavior under conditions we did not test. The automated play run exercises\nthe game as designed. It is not an adversarial security review, a load test, or a study of how the\ngame behaves on hardware and browsers we do not have.\n\nFinally, verification does not establish that the game in front of a player is the game we verified.\nOnce a build leaves, it is deployed by a platform, and what reaches a player depends on that\ndeployment being faithful. That is a real gap and we name it rather than paper over it.",
      "document": {
        "id": "cmudg6fz400072yii1s6jsgry",
        "title": "Verification, and what it does not mean",
        "summary": "The document outlines what a passed verification check establishes and what it does not establish, detailing how a build is tested against its own specification and what evidence is produced. It is a policy-style document from Sealed Jars (dated September 2026) describing their verification process and its limitations."
      },
      "knowledgeBank": {
        "slug": "jars",
        "name": "Sealed Jars"
      }
    },
    {
      "id": "ccf1c5a6-bea4-46ad-b1bb-8e029d3d8027",
      "label": "Verification, and what it does not mean ¶5",
      "title": "Verification, and what it does not mean — Verified is not certified",
      "source": "Sealed Jars, September 2026",
      "pageNumber": null,
      "text": "## Verified is not certified\n\nThese two words get used interchangeably in our industry and they are not the same thing.\n\n**Verified** is what we do. Sealed Jars checks a build against its own specification, using our own\ntests, applying our own thresholds, and produces a record of the result. We set the bar, we run the\nchecks, and we are the ones saying the build passed. That is an internal quality claim, and its\ncredibility rests on the checks being specific, run every time, and honest about what they miss.\n\n**Certified** is what an independent test laboratory does, against the standards of a named\njurisdiction, for a product at deployment. The laboratory is not us, the standards are not ours, and\nthe outcome is a regulatory fact rather than a vendor statement.\n\nEverything the pipeline produces is in service of the second thing without being the second thing.\nA PAR sheet, a math summary and a set of measured statistics exist so that a game arrives at a\nlaboratory ready to be examined. We do not claim approval or certification in any jurisdiction, we\nhave no authority to grant either, and any statement that a game is \"certified\" because it passed\nour checklist would be wrong. Verified means we checked it. Certified means somebody with standing\nchecked us.",
      "document": {
        "id": "cmudg6fz400072yii1s6jsgry",
        "title": "Verification, and what it does not mean",
        "summary": "The document outlines what a passed verification check establishes and what it does not establish, detailing how a build is tested against its own specification and what evidence is produced. It is a policy-style document from Sealed Jars (dated September 2026) describing their verification process and its limitations."
      },
      "knowledgeBank": {
        "slug": "jars",
        "name": "Sealed Jars"
      }
    },
    {
      "id": "881c4049-d8c8-460e-918b-083af1905d66",
      "label": "Where a human can intervene ¶2",
      "title": "Where a human can intervene — The editors",
      "source": "Sealed Jars, September 2026",
      "pageNumber": null,
      "text": "## The editors\n\n**The mathematics editor.** The ticket pool is shown as a distribution: every prize level in the\ngame with the number of tickets that pay it, drawn as bars a person can drag. Move a bar and the\npool changes. Alongside it sit the measurements that matter — deck size, ticket price, payback, hit\nrate, top prize, volatility index, standard deviation and maximum win — and they update from the\nedited pool rather than from the request that created it. This editor opens on any build, before or\nafter verification, including builds that have already shipped.\n\n**Rebalancing.** Hand-editing a distribution almost always breaks the payback percentage, because\nprize counts are not independent. A rebalance control adjusts the remaining levels to bring the pool\nback to its target and reports the new figures. A person can therefore raise a top prize and let the\ntool restore the arithmetic underneath, rather than solving it by hand.",
      "document": {
        "id": "cmudg6iv8000a2yii6wge9cs5",
        "title": "Where a human can intervene",
        "summary": "- It describes an automated end-to-end pipeline where a human can intervene at any stage, detailing the editors and controls (mathematics, rebalancing, image, animation/audio, run, playable preview, and library-wide work) and how overrides are recorded and re-verified.  \n- It is a written document published by Sealed Jars in September 2026 outlining processes for human intervention and override verification in the game production workflow."
      },
      "knowledgeBank": {
        "slug": "jars",
        "name": "Sealed Jars"
      }
    },
    {
      "id": "b1b8b2e9-f161-4587-b51d-d1cf0e2fa947",
      "label": "Where a human can intervene ¶4",
      "title": "Where a human can intervene — The editors",
      "source": "Sealed Jars, September 2026",
      "pageNumber": null,
      "text": "an be paused, resumed or cancelled part-way, and individual\nassets can be accepted or rejected while the run is still going, so a bad symbol is replaced in\nplace instead of being cleaned up afterward.\n\n**The playable preview.** A person can play the assembled game in the workbench before anyone else\ndoes, spinning once or in batches and watching the session return, hit rate and largest win\naccumulate. This is where a game that is correct on paper reveals itself to feel wrong in the hand,\nwhich is a judgment no check in document two makes.\n\n**Library-wide work.** The same editors apply to games that shipped months ago. In September 2026 a\nperson directed a pass across 119 previously shipped games, replacing titles on 107 of them and\nrepairing artwork on 41 more, using the same tools and the same checks that a new build passes.",
      "document": {
        "id": "cmudg6iv8000a2yii6wge9cs5",
        "title": "Where a human can intervene",
        "summary": "- It describes an automated end-to-end pipeline where a human can intervene at any stage, detailing the editors and controls (mathematics, rebalancing, image, animation/audio, run, playable preview, and library-wide work) and how overrides are recorded and re-verified.  \n- It is a written document published by Sealed Jars in September 2026 outlining processes for human intervention and override verification in the game production workflow."
      },
      "knowledgeBank": {
        "slug": "jars",
        "name": "Sealed Jars"
      }
    },
    {
      "id": "e58b5290-eeca-4aee-b0be-25d3ab6fba6d",
      "label": "Where a human can intervene ¶5",
      "title": "Where a human can intervene — What happens to an override",
      "source": "Sealed Jars, September 2026",
      "pageNumber": null,
      "text": "## What happens to an override\n\nTwo questions matter to a regulator, and they have short answers.\n\n**Is an override recorded?** Yes. An edited asset is stored with the description and inputs that\nproduced it, together with the fact and time of the edit, and the original is retained rather than\ndiscarded, so any individual change can be inspected or reversed afterward. An edited ticket pool is\nwritten back as the game's pool, and the game's own statistics are then measurements of the edited\npool. There is no shadow copy: what a person changed is what the game is, and what the game reports\nabout itself is computed from that.\n\n**Is an overridden build verified again?** Yes, and this is the part that matters most. A human edit\ndoes not grant a pass. An edited ticket pool is re-measured on save: deck size, payback, hit rate,\nprize floor and payout integrity are recomputed from the edited tickets, and an edit that pushes the\ngame outside its bands shows up immediately rather than at delivery. Before any build is handed\nover, the full checklist in document two is run again against the assembled game, whether or not a\nperson touched it. A game that was verified, then edited, is not a verified game until it has been\nthrough the checks again.",
      "document": {
        "id": "cmudg6iv8000a2yii6wge9cs5",
        "title": "Where a human can intervene",
        "summary": "- It describes an automated end-to-end pipeline where a human can intervene at any stage, detailing the editors and controls (mathematics, rebalancing, image, animation/audio, run, playable preview, and library-wide work) and how overrides are recorded and re-verified.  \n- It is a written document published by Sealed Jars in September 2026 outlining processes for human intervention and override verification in the game production workflow."
      },
      "knowledgeBank": {
        "slug": "jars",
        "name": "Sealed Jars"
      }
    },
    {
      "id": "8f407659-4861-4e5d-99d3-5f72febf2c1f",
      "label": "Where a human can intervene ¶6",
      "title": "Where a human can intervene — What happens to an override",
      "source": "Sealed Jars, September 2026",
      "pageNumber": null,
      "text": "A game that was verified, then edited, is not a verified game until it has been\nthrough the checks again.\n\nThe honest limit is worth stating. If someone bypasses the workbench and changes a file directly on\ndisk, that change is outside everything described here until the build is verified again. This is\nwhy the gate runs on the assembled package immediately before handover, rather than only at the\nmoment each asset is made. The last thing checked is the thing that ships.",
      "document": {
        "id": "cmudg6iv8000a2yii6wge9cs5",
        "title": "Where a human can intervene",
        "summary": "- It describes an automated end-to-end pipeline where a human can intervene at any stage, detailing the editors and controls (mathematics, rebalancing, image, animation/audio, run, playable preview, and library-wide work) and how overrides are recorded and re-verified.  \n- It is a written document published by Sealed Jars in September 2026 outlining processes for human intervention and override verification in the game production workflow."
      },
      "knowledgeBank": {
        "slug": "jars",
        "name": "Sealed Jars"
      }
    }
  ]
}