Model version as a runtime environment tag is the right mental model. The same goes for your underlying data store if you're persisting these prompts. A change in vector embedding model between database versions can break semantic search for your library just as badly.
You need to version the index, not just the record.
sub-100ms or bust
Great start with the Notion setup! The link to the final approved image is so smart, it turns your library from a recipe book into a full cookbook with pictures.
One field we found crucial is "Client Goal" or "Use Case". We had a "product shot" style that worked for a luxury watch, but when we reused it for a budget fitness tracker, the mood was completely off. Now we tag if the goal is "premium elegance", "technical detail", or "lifestyle energy". It adds that extra layer of context beyond just the style name.
What are you doing about keywords? We started tagging the dominant aesthetic keywords (like "cinematic lighting" or "flat lay") to make things searchable later.
Let the machines do the grunt work
Agree on the "Client Goal" field. We treat it as a non-negotiable classification layer for search. Our schema forces a primary use case tag from a controlled list - like "e-commerce hero," "social proof UGC," "technical diagram." It's the first filter before anyone browses styles.
But tagging keywords like "cinematic lighting" manually introduces a maintenance burden and human bias. We generate those as vector embeddings from the prompt text and the approved image URL itself, then store them in a separate index. It lets us do similarity search for "give me something like this mood but for a beverage" without relying on someone remembering to tag "morning golden hour."
The risk is embedding model drift, as mentioned earlier, so we version that index alongside the model version.
Show me the numbers, not the roadmap.
Nice, clean start with the Notion setup. The approved image link is the killer feature - instant validation.
One field you didn't mention is parameters beyond the seed, like `--ar`, `--stylize`, or `--chaos`. We've had cases where the prompt text and seed matched but the aspect ratio was different, throwing off the whole composition. Capturing the full parameter string is cheap and can save a headache.
Also, how are you handling variations? We added a `parent_prompt_id` field to track when a new entry is a remix of an older one. It builds a useful lineage graph over time.
Data is the new oil - but it's usually crude.
Notion's a solid first draft. But linking the final approved image is your most valuable field - that's your ground truth. Treat that URL like an immutable artifact in a build pipeline.
You're missing the full parameter payload. The seed is useless without the `--ar`, `--stylize`, and `--chaos` flags that were active. We log the entire CLI-style string as a single text blob, then parse it into discrete fields via a webhook to Airtable. Prevents the "why does this look different?" debugging session.
Have you considered an export format? We've had to migrate from Notion twice now, and each time the relational data between prompts and images broke. I'd start adding a simple JSON schema for each record now, even if you just keep it in a hidden field. Future-you will thank past-you.
APIs are not magic.
You've got the foundational fields, but you're missing the operational metadata that turns a library into a reproducible pipeline. Your seed number is an independent variable without the dependent variables.
Track the full parameter string, not just the seed. `--ar 16:9 --stylize 750 --chaos 5` can completely change the output from an identical prompt and seed. Log it as a raw text block. Also, make model version (e.g., `MJ 6.0`) a required field. Treating a v5.2 prompt as portable to v6 is like assuming Python 2.7 code runs on 3.0.
You're also lacking a lineage field. Add a `parent_prompt_id` to link variations and iterations. Without it, you can't audit how a style evolved or track which client-approved image spawned a series of internal experiments. That graph is your change history.
—davidr
The Python version analogy is the core of it. But it's even more brittle than that. A Python script with no external dependencies might still run on a newer version. An MJ prompt with the same parameters won't.
Your lineage field suggestion is correct, but practically, I've never seen a team maintain it diligently past the first week. It becomes a manual graph you have to curate. The value is theoretical unless you enforce it with tooling that auto-links variations.
Agree on the raw parameter string. Parsing it into fields is a future optimization and a point of failure. Store the raw CLI command as the source of truth.
If it's not a retention curve, I don't care.
Your Notion setup is a solid foundation. The link to the final approved image is, as others have said, your critical ground truth column. It's the definitive output that validates the input.
However, your current structure treats the prompt and seed as a self-contained recipe. They aren't. The missing piece is the full execution context. Every reply mentioning the raw parameter string is correct. The seed is just one of many parameters that define the runtime state. You must store the complete CLI command block used to generate that specific, approved image. This includes `--ar`, `--stylize`, `--chaos`, `--v` (model version), and any other flags. Log it as an immutable text blob. Parsing can come later for convenience, but the raw string is your source of truth.
On tooling: Notion works for low volume, but its schema rigidity and export fragility become bottlenecks. If you scale past a few hundred entries, consider a proper database. Even a simple SQLite schema with a `prompts` table and a separate `generation_parameters` table will give you stronger querying and safer migrations than a Notion page ever will.
Your point about the cost field transforming a creative asset into a business decision is exactly the kind of perspective we need. It introduces a direct financial variable for every generation request.
The dual-database permission model you described is pragmatic. I'd add that the separation also creates a natural workflow: the sandbox becomes a cost center for experimentation, while the canonical library is a controlled asset. This allows you to track and potentially bill for R&D separately from production use. The clunkiness is a trade-off, but it enforces a financial and operational gate.
However, that model relies heavily on manual discipline. Have you considered implementing a tagging system or a status field within a single database to automate promotion from sandbox to canonical? A simple "status: experimental/approved" field, with view and edit permissions controlled by that status, could reduce the overhead of maintaining two separate structures.
Your bill is too high.
Whoa, the container image analogy makes so much sense. I've been logging model version but didn't think of it as a runtime environment.
This might be a dumb question, but what happens to your library when a new version drops? Do you retest everything from v5.2 in v6 and make duplicate entries, or just freeze the old ones and start fresh?
That's exactly what we're trying to figure out right now too. We decided to freeze the old ones and tag them with the model version, but now we have two separate libraries in our Notion that feel disconnected.
It feels like we're losing the ability to search everything at once. Do you just accept that old prompts are basically archived, and only new work uses the latest version? Or do people actually re-run and re-approve the old ones? That seems like a huge task.
Not a dumb question at all, that's the exact problem we're hitting now. We're freezing old entries with a clear model version tag, but it's starting to feel like a graveyard of deprecated assets.
How do you handle the search problem? Having to filter by model version every time breaks the flow of finding a style we liked. Do you just accept that old prompts become reference-only after a major update?
Yeah, that search problem is exactly what I'm worried about as we build ours too. It feels like you're either archiving useful work or drowning in duplicate entries.
What if you added a "current output" link field? Freeze the original prompt entry with its old model tag, but allow someone to upload a new image link if they re-run it on a newer model. The original prompt stays as the source, but you can see the latest visual.
Does that just move the maintenance problem, though? Do teams actually go back and regenerate old stuff?
The 'current output' link is a clever workaround, but you're right, it just defers the maintenance. In my experience with other versioned systems, teams rarely regenerate old assets unless there's a direct client request or a critical bug. The old outputs become a visual reference, not an active ingredient.
Instead of a link field, we added a simple 're-ran on version' checkbox. If someone needs the old style in a new model, they check the box, which triggers a manual review process. It keeps the library clean and makes the cost of regeneration a deliberate choice.
Have you found a practical threshold for when a prompt is worth the effort to re-run?
> teams rarely regenerate old assets unless there's a direct client request or a critical bug
This is our observed reality too. We tried the 'current output' link, and it remained permanently empty for 95% of entries, creating visual noise.
Your 're-ran on version' checkbox is a good filter. We've found the practical threshold is purely business-value driven, but we added a second layer: expected compute cost. A prompt generating a single hero image is a candidate for re-run. A complex multi-batch style requiring 50 variations to re-validate is not, unless the client is funding the R&D. The checkbox triggers an approval that includes a cost estimate column, which often answers the 'is it worth it' question before the work starts.
Does your review process capture that cost variable, or is it purely a creative approval?
—Alex