{"schemaVersion":"1.0","type":"TechArticle","types":["Article","TechArticle"],"slug":"i-thought-i-needed-generation-history-what-i-actually-needed-was-four-different-workflows-ed6tb","url":"https://api.zyvop.com/i-thought-i-needed-generation-history-what-i-actually-needed-was-four-different-workflows-ed6tb","title":"I Thought I Needed Generation History. What I Actually Needed Was Four Different Workflows","subtitle":"A gallery solved retrieval. It did not solve reruns, continuation, or controlled variation.","tldr":"Generation history looked like a simple gallery feature until I separated retrieval, reproduction, continuation, and variation into four different workflows.","keywords":["Software Architecture","UX","Product Engineering","Generative AI","AI Product","AI Workflow","Case Studies"],"entities":["Warren","Software Architecture","UX","Product Engineering","Generative AI","AI Product","AI Workflow","Case Studies","ZyVOP"],"keyTakeaways":["When I first thought about adding generation history to an AI product, the requirement sounded simple: save the old outputs and let users come back to them later.","That sounds like a gallery problem.","It turned out to be a workflow problem."],"headings":["1. Retrieval","2. Reproduction","3. Continuation","4. Variation","A gallery is still useful","What I would store now","The product lesson"],"outboundLinks":[],"contentText":"When I first thought about adding generation history to an AI product, the requirement sounded simple: save the old outputs and let users come back to them later. That sounds like a gallery problem. It turned out to be a workflow problem. After watching how people actually used the generator, I noticed that “history” was hiding several different jobs. 1. Retrieval The simplest one is retrieval. A user wants to find an old result again. For this, a gallery works well. You need things like: generated image creation time tool type original inputs maybe the model or provider This is the easiest version of history. But it only solves: “Show me what I made before.” It does not solve what often comes next. 2. Reproduction Sometimes the user wants to make the same thing again. That sounds similar to retrieval, but technically it is a different operation. To reproduce an old generation, you may need more than the visible prompt. You may also need: model identifier provider model version application configuration hidden system instructions uploaded source files generation parameters seed, if the model supports one And even if you save all of that, exact reproduction may still not be possible. Providers change. Models get replaced. Default behavior changes. Your own internal prompt may evolve. So “Run again” can quietly mean one of two things: Replay the original recipe or Use the old inputs with today’s system Those are not the same promise. 3. Continuation Then there is a different behavior: the user does not want the old result back. They want to continue from it. I started noticing users keep the same core idea and change one variable at a time. They might keep the subject but change: placement proportion style complexity supporting elements That is not retrieval. It is not really reproduction either. The old result is being used as context for the next decision. A gallery can display the old image, but that does not automatically make the workflow easy to continue. 4. Variation Variation is close to continuation, but I think it deserves its own category. The intent is: “Keep what worked. Change this one thing.” That sounds trivial from the UI. Technically, it raises a lot of questions. What exactly should be inherited? The prompt? Structured controls? The generated image? The previous output as an image reference? The model configuration? If every generation is stored as an isolated row, then the product has very little understanding of how attempts relate to one another. That is where a parent-child model starts to become useful. Instead of: generation generation generation generationyou can start thinking in branches: original ├── change style ├── change placement └── change detail └── continue from hereNow the system can represent how the user is exploring, not just what files were created. A gallery is still useful None of this means a simple history gallery is a bad feature. For many products, retrieval alone is already valuable. The mistake is assuming that because users ask for “history,” one history screen solves every job hidden behind that word. I ended up thinking about the feature as four separate intentions: retrieval reproduction continuation variation That distinction changes both the UI and the data model. What I would store now At minimum, I would want a generation record to preserve enough context to explain what happened: generation_id user_id tool_type input output provider model_id created_atFor a more advanced continuation system, I would also consider: parent_generation_id action_type config_version source_asset_referenceThe important field may eventually be parent_generation_id. Without relationships between generations, history is mostly an archive. With relationships, it can become a workflow. The product lesson The most interesting part for me was not the database design. It was realizing that users often describe a need using the language available to them. “Give me history” sounds like one feature. But the actual job may be: find something reproduce something resume something modify something Those jobs look similar from a distance. They lead to very different product decisions. I am still keeping the first version intentionally small. But now I am much less interested in building a perfect gallery and much more interested in understanding what users are trying to do after they find an old generation. That may be the more important history feature.","contentHash":"sha256:4e1613bd60aa60999f86a8ffd9cf99c5bbb2ebeaf423da91881b59fa9c851a16","authorName":"Warren","authorUrl":"https://api.zyvop.com/author/warren","authorSameAs":[],"category":"Case Studies","tags":["Software Architecture","UX","Product Engineering","Generative AI","AI Product","AI Workflow"],"audience":"Software engineers and developers building applications with Case Studies","tone":"Instructional, practical, code-first","readingTimeMinutes":3,"wordCount":699,"faqs":null,"primaryTopic":"Case Studies","publishedAt":"2026-08-09T08:16:50.265Z","updatedAt":"2026-08-30T17:05:00.104Z","canonicalUrl":"https://api.zyvop.com/i-thought-i-needed-generation-history-what-i-actually-needed-was-four-different-workflows-ed6tb"}