{
  "sessionId": "cmudg4qlq000ez5ii6kqjrdmy",
  "slug": "everything-on-one-machine",
  "sources": [
    {
      "id": "1d94f8cf-457a-46f0-90de-69d4a0013ea2",
      "label": "The case for local generation ¶1",
      "title": "The case for local generation — The case for local generation",
      "source": "Homeforge Games, September 2026",
      "pageNumber": null,
      "text": "# The case for local generation\n\n*Homeforge Games, September 2026.*\n\nHomeforge Games builds pull-tab, Class II and slot games, and every piece of art, animation, music and math in them is generated on hardware we own and operate. No image, video or audio request in our pipeline leaves the building. This document explains why we chose that constraint, in the terms a skeptic can check: what we own, what it costs at our volume, what it guarantees, and what risk it removes.",
      "document": {
        "id": "cmudg4c370001z5iidlw6daj2",
        "title": "The case for local generation",
        "summary": "- The document explains why Homeforge Games chose to generate all assets locally, detailing ownership, cost at volume, guarantees, and risk reduction. \n- It is a company whitepaper from Homeforge Games (September 2026) outlining the economics, reproducibility, and supplier-risk considerations of local generation for their games."
      },
      "knowledgeBank": {
        "slug": "homeforge-games",
        "name": "Homeforge Games"
      }
    },
    {
      "id": "a0f06b96-3279-4c78-9f90-a9f1236a6722",
      "label": "The case for local generation ¶2",
      "title": "The case for local generation — Ownership",
      "source": "Homeforge Games, September 2026",
      "pageNumber": null,
      "text": "## Ownership\n\nThe practical meaning of ownership in a generative pipeline is narrower than the word suggests, and it is worth being precise about it. It does not mean we trained the models. We did not. It means the model files sit on disks we control, the generation runs on a machine we can walk over to, and the inputs and outputs never transit a third party's service.\n\nThree things follow from that, and all three are checkable. The first is that our unreleased work stays unreleased. When we are designing a game, the theme, the symbol list, the art direction and the math all exist as text and images that would tell a competitor exactly what is coming. None of it is transmitted anywhere. There is no vendor log, no retention window to read, and no question about whether our material could be used to train somebody else's next model, because the material never arrives anywhere that could do that.\n\nThe second is that the pipeline keeps working when the internet does not. That sounds like a small thing until a generation run is the thing standing between you and a deadline.\n\nThe third is that nobody else's policy decides what we may depict. Casino and charitable gaming art is not controversial by any reasonable standard, but it is adjacent to categories that hosted services restrict, and \"gambling\" appears in the usage policies of most large providers in some form. We have never wanted to discover mid-project that a theme is disallowed, or to negotiate an exception for a jackpot symbol. Running locally, the question never comes up.",
      "document": {
        "id": "cmudg4c370001z5iidlw6daj2",
        "title": "The case for local generation",
        "summary": "- The document explains why Homeforge Games chose to generate all assets locally, detailing ownership, cost at volume, guarantees, and risk reduction. \n- It is a company whitepaper from Homeforge Games (September 2026) outlining the economics, reproducibility, and supplier-risk considerations of local generation for their games."
      },
      "knowledgeBank": {
        "slug": "homeforge-games",
        "name": "Homeforge Games"
      }
    },
    {
      "id": "315e96e1-4dc7-443f-b6b6-ee4f970e56a8",
      "label": "The case for local generation ¶3",
      "title": "The case for local generation — Cost at volume",
      "source": "Homeforge Games, September 2026",
      "pageNumber": null,
      "text": "## Cost at volume\n\nThe economics only make sense if you count the whole library rather than a single image. As of September 2026, our library is 232 games. Those games contain 2,547 still images, 1,506 animated clips and 1,149 audio tracks. That is the working total, not a projection.\n\nThe number that matters is not the first image, it is the fiftieth attempt at the same image. Generative work is iterative, and most of what we generate is discarded. A symbol gets regenerated because the lighting is wrong. A logo gets regenerated because the model misspelled the title. A background gets regenerated because the model painted a word into the artwork. In one batch this September, we regenerated 107 logos across the library, and the runs behind that number included several hundred attempts that were rejected by our own checks before a human ever saw them. When each attempt has a price attached, iteration becomes a budget conversation, and the honest result of a budget conversation is that you ship the third-best version because the fourth attempt cost money. When the marginal cost of an attempt is electricity, you keep going until it is right.",
      "document": {
        "id": "cmudg4c370001z5iidlw6daj2",
        "title": "The case for local generation",
        "summary": "- The document explains why Homeforge Games chose to generate all assets locally, detailing ownership, cost at volume, guarantees, and risk reduction. \n- It is a company whitepaper from Homeforge Games (September 2026) outlining the economics, reproducibility, and supplier-risk considerations of local generation for their games."
      },
      "knowledgeBank": {
        "slug": "homeforge-games",
        "name": "Homeforge Games"
      }
    },
    {
      "id": "95d9bda3-375f-49d0-9998-fad1d6a73a28",
      "label": "The case for local generation ¶4",
      "title": "The case for local generation — Cost at volume",
      "source": "Homeforge Games, September 2026",
      "pageNumber": null,
      "text": "When the marginal cost of an attempt is electricity, you keep going until it is right.\n\nOur direct costs are the hardware, which is a single laptop-class GPU with 8 GB of video memory, and the power to run it. At the draw of that class of hardware, a batch that occupies the GPU for two hours consumes roughly a quarter of a kilowatt-hour, which at typical United States commercial rates is a few cents. We do not claim that is the total cost of the approach. The real costs are elsewhere, and document two and document three cover them: engineering time, wall-clock time and the quality ceiling of models small enough to fit.",
      "document": {
        "id": "cmudg4c370001z5iidlw6daj2",
        "title": "The case for local generation",
        "summary": "- The document explains why Homeforge Games chose to generate all assets locally, detailing ownership, cost at volume, guarantees, and risk reduction. \n- It is a company whitepaper from Homeforge Games (September 2026) outlining the economics, reproducibility, and supplier-risk considerations of local generation for their games."
      },
      "knowledgeBank": {
        "slug": "homeforge-games",
        "name": "Homeforge Games"
      }
    },
    {
      "id": "945d6b4f-7d29-4eca-aad7-209ba3048182",
      "label": "The case for local generation ¶5",
      "title": "The case for local generation — Reproducibility",
      "source": "Homeforge Games, September 2026",
      "pageNumber": null,
      "text": "## Reproducibility\n\nEvery asset we generate is stored with the inputs that produced it, and the models that produced it are files we keep rather than services we call. The consequence, which document four develops, is that an asset can be regenerated in the same style months later, and that a game we shipped in January can be revisited in September without discovering that the tools underneath it have moved.\n\nThis is not a theoretical benefit in our industry. A pull-tab or Class II game is a regulated product. It goes to an independent test laboratory with a mathematical description of its behavior, and it can come back with questions long after the team has moved on. Being able to reconstruct how a piece of that product was made, rather than approximately re-create it, is the difference between answering a regulator and apologizing to one.",
      "document": {
        "id": "cmudg4c370001z5iidlw6daj2",
        "title": "The case for local generation",
        "summary": "- The document explains why Homeforge Games chose to generate all assets locally, detailing ownership, cost at volume, guarantees, and risk reduction. \n- It is a company whitepaper from Homeforge Games (September 2026) outlining the economics, reproducibility, and supplier-risk considerations of local generation for their games."
      },
      "knowledgeBank": {
        "slug": "homeforge-games",
        "name": "Homeforge Games"
      }
    },
    {
      "id": "9240fedd-0ef8-460e-8cf8-a078063f2faa",
      "label": "The case for local generation ¶6",
      "title": "The case for local generation — Supplier risk",
      "source": "Homeforge Games, September 2026",
      "pageNumber": null,
      "text": "## Supplier risk\n\nThe failure we most wanted to avoid is the one where nothing breaks. A hosted model gets improved, the outputs shift, and a library built over a year stops matching itself. Nothing errors. Nothing alerts. The art in game 200 simply does not look like the art in game 12, and by the time anyone notices, the old behavior is gone.\n\nPrices move too, and terms move, and capacity moves. A provider is entitled to raise a price, restrict a category, deprecate a version or prioritize larger customers during a busy week, and a studio our size has no leverage over any of those decisions. None of those changes would be bad faith. They would simply be somebody else's business decisions landing inside our production schedule.\n\nRunning locally does not make us immune to the field moving. New model families appear constantly, and when we adopt one, our output changes too. The difference is that we choose the moment. We can keep the old model beside the new one, regenerate a sample of existing work, compare them and decide whether the change is an improvement before it touches anything we ship. An upgrade becomes a decision with a date on it, made by us, rather than an event that arrives.\n\nThe honest summary is that local generation trades a supplier relationship for an operational burden. We think that trade is right for a small studio producing a large volume of assets for a regulated product with a long tail of obligations. It is emphatically not right for everyone, and document three is about the cases where we would tell you not to do it.",
      "document": {
        "id": "cmudg4c370001z5iidlw6daj2",
        "title": "The case for local generation",
        "summary": "- The document explains why Homeforge Games chose to generate all assets locally, detailing ownership, cost at volume, guarantees, and risk reduction. \n- It is a company whitepaper from Homeforge Games (September 2026) outlining the economics, reproducibility, and supplier-risk considerations of local generation for their games."
      },
      "knowledgeBank": {
        "slug": "homeforge-games",
        "name": "Homeforge Games"
      }
    },
    {
      "id": "3572e2b0-9688-48c8-9b2f-26a2d3e58089",
      "label": "What it takes ¶1",
      "title": "What it takes — What it takes",
      "source": "Homeforge Games, September 2026",
      "pageNumber": null,
      "text": "# What it takes\n\n*Homeforge Games, September 2026.*\n\nThis document is the inventory: the hardware the work runs on, how fast it moves, and one real batch measured end to end. Every figure below was measured on our own machine in September 2026 unless stated otherwise, and where a number is an estimate rather than a measurement, it says so.",
      "document": {
        "id": "cmudg4gs50004z5iitj1yvwk4",
        "title": "What it takes",
        "summary": "- It describes the hardware platform, throughput metrics, and real end-to-end batch work for a game asset pipeline (images, animation, audio, and checks) used by Homeforge Games. \n- It is a company document, specifically an inventory/report from Homeforge Games dated September 2026."
      },
      "knowledgeBank": {
        "slug": "homeforge-games",
        "name": "Homeforge Games"
      }
    },
    {
      "id": "dbf49075-9e4f-41b1-bc10-43eb62f926a6",
      "label": "What it takes ¶2",
      "title": "What it takes — Hardware",
      "source": "Homeforge Games, September 2026",
      "pageNumber": null,
      "text": "## Hardware\n\nEverything runs on one workstation with a single laptop-class GPU carrying 8 GB of video memory. That is a deliberately ordinary machine, and it is the most surprising thing we say at conferences. People expect a rack.\n\nThe 8 GB ceiling is the defining constraint of the whole operation, and it shapes every decision downstream. Models are selected for whether they fit, compressed versions are used where the full-size ones will not, and jobs are scheduled so that only one large model is resident at a time. When the image generator, the video generator, the audio generator and the vision checker all want the same memory, they have to take turns, and our tooling is largely an exercise in making them take turns without stepping on each other. A machine with 24 GB or more would remove most of that work, and if we were starting again with a budget, that is where the money would go.\n\nStorage matters more than people expect, and not in the direction people guess. The finished library is small: 232 games of stills, animation clips and audio came to about 2.2 gigabytes as of September 2026. The model files are the heavy part. Our collection of them, accumulated across image, video and audio work, runs to several hundred gigabytes, which is to say the tools take up roughly a hundred times the space of everything we have ever made with them.",
      "document": {
        "id": "cmudg4gs50004z5iitj1yvwk4",
        "title": "What it takes",
        "summary": "- It describes the hardware platform, throughput metrics, and real end-to-end batch work for a game asset pipeline (images, animation, audio, and checks) used by Homeforge Games. \n- It is a company document, specifically an inventory/report from Homeforge Games dated September 2026."
      },
      "knowledgeBank": {
        "slug": "homeforge-games",
        "name": "Homeforge Games"
      }
    },
    {
      "id": "ef709f00-6461-4c2f-ad84-988a1adec56a",
      "label": "What it takes ¶3",
      "title": "What it takes — Throughput",
      "source": "Homeforge Games, September 2026",
      "pageNumber": null,
      "text": "## Throughput\n\nThe per-asset numbers are these, all measured in September 2026 on the machine described above, and all reported as the median across a real batch rather than a best case.\n\nA still image at 1024 by 384 pixels, which is the shape we use for game logos, takes about 11 seconds. A larger still at 1280 by 720, which is the shape we use for game backgrounds, takes about 21 seconds. An editing pass over an existing 1280 by 720 image, where the model is asked to change one thing about a picture that already exists rather than paint a new one, takes about 89 seconds, because that job uses a bigger model that only just fits.\n\nAnimation is the expensive part by an order of magnitude. A six-second looping clip generally takes six to seven minutes. Clips that need a more elaborate treatment to loop cleanly take roughly 25 minutes. A single game with nine or ten animated elements therefore spends over an hour of wall-clock time on animation alone, and that is the dominant term in every schedule we write.\n\nAudio is cheap by comparison. A full set of six music and effect tracks for one game takes about two minutes.\n\nDeck mathematics is not a generative cost at all. Building and validating a finite pool of a few thousand tickets is ordinary computation and finishes in seconds.",
      "document": {
        "id": "cmudg4gs50004z5iitj1yvwk4",
        "title": "What it takes",
        "summary": "- It describes the hardware platform, throughput metrics, and real end-to-end batch work for a game asset pipeline (images, animation, audio, and checks) used by Homeforge Games. \n- It is a company document, specifically an inventory/report from Homeforge Games dated September 2026."
      },
      "knowledgeBank": {
        "slug": "homeforge-games",
        "name": "Homeforge Games"
      }
    },
    {
      "id": "bfdbf69a-d73c-4b74-b6d8-ffd3dc035ef8",
      "label": "What it takes ¶4",
      "title": "What it takes — A real batch",
      "source": "Homeforge Games, September 2026",
      "pageNumber": null,
      "text": "## A real batch\n\nThe clearest way to give the shape of it is a whole game. **Mythic Space Odyssey**, one of the titles in our public library, went from concept to complete package in about an hour and forty minutes: fifteen still images, nine animated clips, six audio tracks, a validated ticket pool of 3,960 tickets and the runtime configuration around it. **Gemstone Quest Rising** and **Cosmic Buck Blast** both landed in about the same time. Those are representative rather than exceptional, and they include the retries our automated checks triggered along the way.\n\nWhen animation is switched off, the same pipeline produces a complete static game in roughly fifteen minutes, which is what we use when somebody needs to see a concept rather than play a finished product.\n\nThe second kind of batch is library-wide maintenance, and that is where owning the hardware changes what is thinkable. This September we regenerated the title logo for 107 existing games and removed text that models had painted into the background art of 41 more, 119 games in total. The logo generation occupied the GPU for about an hour and forty minutes. The background repairs, which use the slower editing model, took about the same again. Add the automated checking passes between them and it was a day's work on one machine, most of it unattended.",
      "document": {
        "id": "cmudg4gs50004z5iitj1yvwk4",
        "title": "What it takes",
        "summary": "- It describes the hardware platform, throughput metrics, and real end-to-end batch work for a game asset pipeline (images, animation, audio, and checks) used by Homeforge Games. \n- It is a company document, specifically an inventory/report from Homeforge Games dated September 2026."
      },
      "knowledgeBank": {
        "slug": "homeforge-games",
        "name": "Homeforge Games"
      }
    },
    {
      "id": "58d907ab-5cac-4dbf-874f-aa4631c9f1e0",
      "label": "What it takes ¶5",
      "title": "What it takes — A real batch",
      "source": "Homeforge Games, September 2026",
      "pageNumber": null,
      "text": "The background repairs, which use the slower editing model, took about the same again. Add the automated checking passes between them and it was a day's work on one machine, most of it unattended.\n\nThat is the figure we would ask a room to sit with. Reworking the art of 119 shipped games was not a budget request. It was a Tuesday. At a few cents per generated image with a hosted service, the same batch, including every rejected attempt, would have been a line item somebody had to approve, and the honest consequence of needing approval is that the work would not have happened at all. The misspelled logos would still be in the library, because fixing them would have cost more than living with them.\n\nWhat it takes, then, is one ordinary machine, patience with animation, and the engineering time to make a set of models that do not fit in memory together behave as if they do. The hardware is the cheap part. The tooling around it is where the real investment goes, and document three is honest about what that means when the work does not go smoothly.",
      "document": {
        "id": "cmudg4gs50004z5iitj1yvwk4",
        "title": "What it takes",
        "summary": "- It describes the hardware platform, throughput metrics, and real end-to-end batch work for a game asset pipeline (images, animation, audio, and checks) used by Homeforge Games. \n- It is a company document, specifically an inventory/report from Homeforge Games dated September 2026."
      },
      "knowledgeBank": {
        "slug": "homeforge-games",
        "name": "Homeforge Games"
      }
    },
    {
      "id": "14fd0197-7ecd-4db2-9083-7c503e389f3b",
      "label": "Where local generation loses ¶2",
      "title": "Where local generation loses — The honest limitations",
      "source": "Homeforge Games, September 2026",
      "pageNumber": null,
      "text": "## The honest limitations\n\nThe quality ceiling is real. Models small enough to run in 8 GB of video memory are not the largest models available, and the gap shows most clearly in the hardest cases: hands, faces, complex scenes with many interacting elements, and above all text. Our models misspell words inside images regularly. We have shipped logos reading \"Solipse Rush\" where the game is called Solar Eclipse Rush, and \"Pyranid of Riches\" where it should say Pyramid. We also discovered this September that an earlier automated check had been passing those images because the small vision model doing the checking reported the name it expected to see rather than the letters actually drawn. Two separate model weaknesses, stacked, put misspelled art into a shipped library, and it took a human noticing a pattern to catch it.\n\nSpeed is the second limitation, and it is not close. One GPU is one job at a time. An animation-heavy game takes us over an hour of wall-clock time, and a library-wide maintenance pass takes a working day. A hosted service would run those requests in parallel across hardware we could never justify buying, and would finish a day's work in minutes. We have no burst capacity at all. When a deadline moves toward us, we cannot spend money to go faster, which is exactly what money is for.",
      "document": {
        "id": "cmudg4jrh0007z5iiwvs6b5s3",
        "title": "Where local generation loses",
        "summary": "- The document presents the limitations of local generation (quality, speed, engineering burden, and fixed capability) and discusses when using an API or hosted service is the right choice. \n- It is a written case against local generation, authored by Homeforge Games in September 2026—the people who implemented local generation."
      },
      "knowledgeBank": {
        "slug": "homeforge-games",
        "name": "Homeforge Games"
      }
    },
    {
      "id": "abf4764b-7c8a-4435-946f-0ce94c04568d",
      "label": "Where local generation loses ¶3",
      "title": "Where local generation loses — The honest limitations",
      "source": "Homeforge Games, September 2026",
      "pageNumber": null,
      "text": "We have no burst capacity at all. When a deadline moves toward us, we cannot spend money to go faster, which is exactly what money is for.\n\nThird, the engineering burden is substantial and permanent. Making four different model families take turns inside 8 GB is work that produces no art. Our tooling handles memory pressure, crashed jobs, corrupt output files, truncated images and models that quietly refuse to load, and every one of those behaviors was discovered in production. We also had to build our own quality gates, because nobody is doing that for us: automated checks that read titles back letter by letter, confirm every symbol has art, confirm the mathematics is in band, and reject the output otherwise. A studio buying generation as a service gets to skip all of it.\n\nFourth, and least appreciated, local capability is frozen at whatever you installed. Hosted services improve without you doing anything. Ours improve when somebody sits down and makes them improve, on a day they could have spent on games.",
      "document": {
        "id": "cmudg4jrh0007z5iiwvs6b5s3",
        "title": "Where local generation loses",
        "summary": "- The document presents the limitations of local generation (quality, speed, engineering burden, and fixed capability) and discusses when using an API or hosted service is the right choice. \n- It is a written case against local generation, authored by Homeforge Games in September 2026—the people who implemented local generation."
      },
      "knowledgeBank": {
        "slug": "homeforge-games",
        "name": "Homeforge Games"
      }
    },
    {
      "id": "1c824354-dc71-4187-8f16-4bc97692a83d",
      "label": "Where local generation loses ¶4",
      "title": "Where local generation loses — When an API is the right answer",
      "source": "Homeforge Games, September 2026",
      "pageNumber": null,
      "text": "## When an API is the right answer\n\nIf your volume is low or spiky, use a service. The whole economic argument for local generation rests on iteration at volume, and if you need forty images this quarter, the hardware and the engineering time will never pay for themselves.\n\nIf you need the best possible quality on a small number of hero assets, use a service, or hire an illustrator. We optimize for a large library of consistent, good assets, and that is a different target from a handful of exceptional ones.\n\nIf you have a hard deadline and variable load, use a service. Elasticity is the single thing we cannot buy, and it is genuinely valuable.\n\nIf nobody on the team wants to own infrastructure, use a service. This approach needs somebody who will cheerfully debug memory exhaustion on a Sunday. If that person does not exist on your team, the pipeline will rot, and a rotting pipeline is worse than a paid one.\n\nIf your work is not regulated and never needs to be reconstructed later, the reproducibility argument in document four largely does not apply to you, and it is one of the strongest arguments we have.\n\nWhat we would say is this: local generation is not a quality strategy, and anyone selling it as one is overselling. It is an ownership, cost-at-volume and reproducibility strategy, and it asks for engineering effort as payment. We think the trade is worth it for a small studio shipping a large regulated library. We would not argue with somebody in a different situation who reached the opposite conclusion.",
      "document": {
        "id": "cmudg4jrh0007z5iiwvs6b5s3",
        "title": "Where local generation loses",
        "summary": "- The document presents the limitations of local generation (quality, speed, engineering burden, and fixed capability) and discusses when using an API or hosted service is the right choice. \n- It is a written case against local generation, authored by Homeforge Games in September 2026—the people who implemented local generation."
      },
      "knowledgeBank": {
        "slug": "homeforge-games",
        "name": "Homeforge Games"
      }
    },
    {
      "id": "9f172e88-2cc7-4dd6-9782-d2465292b945",
      "label": "Reproducibility, and why it matters for games ¶2",
      "title": "Reproducibility, and why it matters for games — Same inputs, same output",
      "source": "Homeforge Games, September 2026",
      "pageNumber": null,
      "text": "## Same inputs, same output\n\nIn plain language, reproducibility means that the same request, made again, produces the same picture. Image generation is not random in the way people assume. It starts from a number, and given that same starting number, the same model, and the same description, it will produce the same image again. The catch is that all three have to still exist.\n\nThat is where hosted generation and local generation part company. When the model lives on a service, the version you used is the version that was current that day. When it is replaced, your starting number and your description now produce something else: often something better, but not the same thing. You cannot go back and get the original, and usually you cannot even find out what changed.\n\nWe keep all three. Every asset we generate is stored alongside the description that produced it and the starting number it came from, and the model files themselves are kept as files. When we regenerate a piece of art a year later, we are not approximating the original process. We are repeating it.\n\nTwo practical habits follow. Before we adopt a newer model, we regenerate a sample of existing work with it and compare the results against the originals, so that a change in house style is a decision somebody made rather than a drift somebody noticed later. And when a single asset is wrong, we can rework that one asset in the original style without touching the rest of the game, which is how a library stays consistent across a year of production.",
      "document": {
        "id": "cmudg4n3i000az5iifjft2b07",
        "title": "Reproducibility, and why it matters for games",
        "summary": "- The document explains reproducibility in game asset generation, describing how keeping the same inputs, model, and starting number allows exact regeneration and outlining habits to compare new models and fix individual assets without affecting the rest of the game, with reasons tied to regulatory and long‑term library considerations.  \n- It is a policy/whitepaper-style document published by Homeforge Games in September 2026."
      },
      "knowledgeBank": {
        "slug": "homeforge-games",
        "name": "Homeforge Games"
      }
    },
    {
      "id": "63d367f2-0851-4090-90f6-68d4cf27d85e",
      "label": "Reproducibility, and why it matters for games ¶3",
      "title": "Reproducibility, and why it matters for games — Why games care",
      "source": "Homeforge Games, September 2026",
      "pageNumber": null,
      "text": "## Why games care\n\nGaming has a specific reason to care that most creative industries do not, and it is regulatory.\n\nA pull-tab or Class II game is a regulated product. Before it can be offered, its mathematics goes to an independent test laboratory for review, along with a description of how the game behaves. That review is not the end of the relationship. Questions come back, sometimes months later, sometimes from a different jurisdiction with its own requirements, sometimes about a title whose original developer has moved on to other work. The question is rarely \"can you make something like this again\". It is \"explain exactly what this is\".\n\nA studio that cannot reconstruct its own product answers that question with a shrug, and a shrug is expensive. It means re-doing work, re-submitting, and explaining a gap to a regulator whose entire job is to be unsatisfied by gaps. We hold the mathematical description of every game we have made, and we can produce the analysis that accompanies a submission on demand rather than reconstructing it from memory.\n\nThe same logic runs through the commercial side. Operators ask for variants: the same game at a different price point, or with a different name for a particular market. If making a variant means regenerating the art and getting art that no longer matches, a variant is a new project. If the original inputs still exist and still work, it is an afternoon.",
      "document": {
        "id": "cmudg4n3i000az5iifjft2b07",
        "title": "Reproducibility, and why it matters for games",
        "summary": "- The document explains reproducibility in game asset generation, describing how keeping the same inputs, model, and starting number allows exact regeneration and outlining habits to compare new models and fix individual assets without affecting the rest of the game, with reasons tied to regulatory and long‑term library considerations.  \n- It is a policy/whitepaper-style document published by Homeforge Games in September 2026."
      },
      "knowledgeBank": {
        "slug": "homeforge-games",
        "name": "Homeforge Games"
      }
    }
  ]
}