Every time you brew a prompt in PAL, whether from a saved Blend or a one-off Quick Brew, the exact text you generated gets logged and timestamped. That's what this feature is: a plain record of what you actually sent to a model, not what you meant to send or what the Blend looks like today. It isn't version control for the Blend itself, and it doesn't compare one edit against another.
What gets logged every time you brew
Each generation is saved as its own record: the full rendered text, a timestamp, and which Project and Blend it came from. Nothing about editing a Blend later changes what's already in this record. The two are separate on purpose: a Blend is the thing you keep editing forward, and a generation is a fixed snapshot of one specific output, frozen at the moment you brewed it.
That includes generations that never came from a saved Blend at all. Quick Brew, PAL's ephemeral assembly-and-generate flow, writes to the same history the moment you generate, even when nothing about the prompt was saved as a reusable Blend. The record doesn't care whether the text behind it still exists as an editable Blend somewhere; it just keeps what was actually sent. Delete the Blend a month later, or never turn a Quick Brew into one in the first place, and the generation it produced is still sitting in the history, unaffected either way.
Finding a past generation again
PAL's project history page is searchable, and the search runs against two things: the generated text itself, or the title of the Blend that produced it. That covers the two ways you'd actually go looking, either "I remember roughly what it said" or "I remember which Blend I used," without needing to recall an exact date. Say a client asks, three weeks later, exactly what tone the last two posts used, and you don't remember which Blend you'd been iterating on at the time. Typing a phrase you remember from the output into the history search is usually faster than trying to recall exactly what your tone rules said that week, and the same search covers every generation in the Project, not just the ones tied to a single Blend.
Inside the builder, a smaller history panel shows the most recent generations for the Blend you're currently working on, capped at the twenty most recent, enough for a quick gut check without turning the panel into a second history page. The full history page itself is scoped to one Project at a time and pages through results in batches, so a Project with hundreds of generations behind it stays browsable instead of loading everything at once.
A brewed generation remembers which tasks fed it
If you generated using the {{tasks}} slot, what fed that generation isn't a separate record sitting off to the side. It's part of the output text itself: the numbered list PAL rendered at brew time is saved inside the generated text exactly as it went out, in the same order the tasks sat in on the board. That matters most for anything brewed as a batch: a generation built from six selected to-dos keeps all six, in that order, right there in the text, rather than collapsing into an anonymous block with no trace of what went in. Open a past generation later, and reading the text is how you find what fed it: the numbered list sits in the output itself, not stored elsewhere as a separate view. Task cards on the board carry their own small badge marking that a task was brewed and when, but for the full list, the generated text in History is where it actually lives. If the {{tasks}} mechanics themselves are new to you, The {{tasks}} Workflow covers how selecting and brewing tasks actually works.
What a generation record isn't
It doesn't monitor edits to the Blend, and there's no way to line up two states of it side by side. Editing a global block changes what the next generation produces; it has no effect on generations already sitting in the history. Nor does it reconstruct what a Blend looked like at some point in the past; the only thing preserved is the finished text a generation actually produced. If what you actually want to know is how an edit reaches every place a shared block is used, that's a different question, answered by scope and inheritance, not by this log; What Is a Reusable Prompt System covers how that works. What the history answers instead is narrower and, for client work, more often the question you actually have: exactly what did I paste into the model for this client, and when.
Why a plain log is still worth keeping
A client asks what exactly you sent them last month. A generation went out with a typo you only noticed later, and you want to see how far back it started happening. A teammate wants to see an example of a finished prompt, not just the Blend that can produce one. None of these need a side-by-side comparison tool. They need the same thing: an honest, searchable log of what was actually generated, kept exactly as it was at the time. None of this requires deciding in advance what's worth keeping, either. Every generation gets logged the same way, whether it turns out to matter later or not, so the record stays complete instead of depending on remembering to save the important ones. That's the whole design: not a tool for managing revisions, just an honest memory of what already happened.