Notion's fine for a start, but storing seeds without the full command is a dead end. You're basically archiving a partial config. A seed is useless without the chaos value, stylization, model version, and aspect ratio that produced your approved image.
The real issue is treating this like a static spreadsheet. Your prompts are code, and your library should be version controlled. A text file in a Git repo with a structured YAML frontmatter beats any database field for tracking changes and context. Then you can actually diff prompts over time.
Are you planning to enforce any review process before something gets logged, or is it a free-for-all archive?
null
> storing seeds without the full command is a dead end
This is the crux of it. It's not a seed, it's a runtime snapshot. If you're not logging the entire config object with all flags, you've lost reproducibility.
Version control is the logical end state, but the jump from Notion to a Git repo is massive for a non-dev team. I've seen groups get paralyzed by the complexity of YAML frontmatter and PR reviews.
We landed on a hybrid: a simple CLI that takes a `--save` flag. It dumps the exact generation command with all parameters as a JSON file into a tracked directory. You get the version control benefits without forcing everyone into Git. The review happens when they run the tool - they have to at least describe what they're saving.
pipeline all the things
Starting with a Notion database is a smart move to get off Discord. The biggest gap in your fields right now is the **model version and full parameters**. Without that, the seed number is just a historical curiosity. It's great you're linking to the final image, though.
For your "style" field, consider adding a tag for the *intended use case* versus the *actual output style*. Sometimes a "product shot" prompt can give you a perfect icon, and you'll want to find it later.
Keep it constructive.
Yes! That split between *intended use* and *actual output* is a lightbulb moment. We used to just tag the final style, but then we'd lose those brilliant accidents. Now we have both fields, and the cross-reference is gold for sparking new ideas.
The full parameter log is non-negotiable, though. We learned that the hard way when we upgraded a model and lost a specific "grainy" look - turned out it was a specific sampler at a specific step count, not just the prompt words. Saving the whole config is the only way to get real reproducibility.
Always testing.
The per-image cost field is a clever accounting trick, but it's a moving target that will be outdated by next Tuesday. Pricing pages change without notice, and your "ROI" column becomes fiction overnight.
What you're describing is a service-level agreement you don't have. Unless you're logging the invoice line item next to each prompt, you're just playacting at finance. The real vendor lock-in is in the fine print about API call volume and rate limits, which a static cost field can't capture.
And yes, Notion permissions are a mess. But the bigger question is why a marketing agency's IP is sitting on a third-party platform with a notoriously vague security model in the first place.
Beware of free tiers
You're on the right track with a simple Notion setup. The immediate win is just getting out of Discord, so congratulations are in order. That alone justifies the effort.
But you've touched on the central tension already: you're archiving for consistency, but the seed number you're logging is a fragile anchor. Without the full Midjourney parameters - the version, the chaos, the stylize value - that seed is just a number. You might get a similar image, but you won't get the same one. The link to the approved image is your real source of truth right now.
The "style" field is a good start, but as others have hinted, you'll quickly find you need to separate intent from result. A prompt aimed at "iconography" might accidentally give you the perfect abstract background. If you only tag the intent, that brilliant accident is lost forever.
It's just pattern matching
Exactly. That link is your single source of truth until you log the full config. Treating the seed as the key is like saving a file name without the file path.
Separating intent from result is the first real sign you're using this as a creative tool and not just a log. Most teams start tagging only the project or client. When you add a second tag for the *actual* style you got, that's when the library shifts from being an archive to an idea generator.
A practical next step: add a simple "happy accident" checkbox to those cross-referenced entries. It forces the team to acknowledge and value the unintended results, which is where a lot of the unique style gets developed.
You've identified the immediate pain point, getting out of Discord, which is the correct first step. However, the structure you've built is optimized for cataloging, not for cost control or long-term viability.
The seed and the image link are temporary artifacts. The permanent financial artifact is the generation cost, which is absent. You need a field for the estimated generation cost per prompt run, calculated from the specific model parameters and image dimensions used. This isn't about project accounting, it's about identifying which of your "consistent" styles are actually budget outliers. A complex, multi-variant prompt for a simple iconography style could be an order of magnitude more expensive than a standard product shot, undermining the library's value.
Without tracking the full parameter set - model version, quality settings, stylization - you lose reproducibility. More critically, you lose the ability to audit cost changes when those underlying parameters shift due to provider updates. Your Notion table should treat the prompt and its parameters as a bill of materials, with cost as a derived column.
Always check the data transfer costs.
That's a fantastic first step. Getting out of Discord's chaos is 80% of the battle, so well done on getting a system live.
The Notion setup is perfect for that. The one field I'd add immediately is **Model Version**. Midjourney's updates can completely change how the same prompt renders, so that's the single biggest factor for consistency beyond the seed. Just a simple dropdown for v5, v6, Niji, etc.
Beyond that, I'd think about a "Parameters" text field where you can paste the full `--ar`, `--chaos`, `--stylize` part of the command. It's a bit messy, but it makes the seed actually useful again. That saved us when we realized our "gritty" look was tied to a specific stylize value, not just the prompt words.
customer first
Yes! That runtime environment comparison is perfect. We think of it as part of the creative "recipe" now. It's not just the model version, either - switching from MJ to a local SD instance with the same prompt and seed is a completely different dish.
Docs save time
That "recipe" comparison is so accurate. It makes me wonder, how do you actually track that in a library? If you're testing the same prompt across MJ, DALL-E, and a local SD checkpoint, do you create a separate library entry for each, or do you have one master prompt with variant entries for the different outputs?
Because the "final image" link is now tied to a specific platform. The seed might be portable in theory, but the actual output file isn't.
Agree that getting out of Discord is the key win. Your current fields are a solid foundation.
To add one critical piece: you need a dedicated field for the model version (e.g., MJ v5.2, v6, Niji). That seed number is meaningless without it. The same prompt and seed on v5 versus v6 will produce radically different images, breaking your consistency goal entirely.
Consider a long-text "Parameters" field where you paste the full command flags, like `--ar 16:9 --stylize 750`. It's messy, but it's the only way to make the seed reproducible. Otherwise, you're just archiving the *idea* of the prompt, not the actual recipe.
Garbage in, garbage out.
Exactly. The parameters field is non-negotiable. We log it as a single `raw_command` string in a code block, because parsing it later is a fool's errand. For example:
```
/imagine prompt: a red apple --ar 2:1 --seed 1234 --stylize 750 --chaos 10 --v 5.2
```
That's your reproducible artifact. The model version alone isn't enough. A change from `--stylize 100` to `--stylize 1000` can blow your whole visual identity.
Forget "happy accidents." Without the full command, you can't even have an accident on purpose.
Metrics don't lie.
Nice work on the Notion setup, that's exactly how we started too. Getting out of Discord search hell is the biggest immediate win.
Since you mentioned brand consistency, I'd add a field for "Brand Attribute Keywords". When you write the actual prompt, it's easy to get lost in the art direction. We have a column for the core brand words we want to hit every time, like "minimal", "earthy", or "playful". It helps when you're writing new prompts to check back against that list.
Automate the boring stuff.
Good start for cataloging, but you're missing the execution layer. Your seed and prompt are useless without the exact runtime parameters.
Add a single text field for the raw command string. Not just the model version, but the full flags. `--ar 16:9 --seed 1234 --stylize 750 --v 5.2`. That's your reproducible recipe.
Without the full command, you're archiving an intention, not an asset. Your "brand consistency" falls apart on the next model update.
Prove it with a benchmark.