Summary
I am sharing this as a product/feature request based on a long-term, real-world attempt to use ChatGPT for consistent branded content production.
Over dozens of production and revision cycles, I tried to build a workflow where a user could simply say something like:
“Create this in the brand version.”
and ChatGPT would automatically follow previously approved rules for characters, visual identity, assets, layout, text quality, and production workflow.
To achieve this, I created increasingly detailed brand guidelines, character bibles, character IDs, locked assets, prohibited actions, production SOPs, runtime specifications, and multi-stage QA rules.
However, the same types of failures continued to occur.
The core issue was not a lack of instructions.
ChatGPT could understand and explain the rules, but those rules were not reliably enforced during subsequent tool execution.
I think this represents an important gap between:
Declarative Memory — knowing what rules should be followed
and
Procedural Enforcement — ensuring those rules actually constrain tool selection, generation, asset retrieval, QA, and delivery.
What I was trying to achieve
The desired workflow was simple from the user’s perspective.
The user should be able to say:
“Create educational content about X in the brand version.”
ChatGPT should then internally retrieve and enforce:
-
approved visual identity
-
approved characters
-
character identities
-
official assets
-
logos
-
layout rules
-
writing standards
-
prohibited modifications
-
production procedures
-
QA requirements
-
previously approved designs
-
previously rejected designs
The goal was not a single successful image.
The goal was a persistent production system.
Problems repeatedly observed
1. Approved characters changed identity between generations
Even after a character had been approved, later image generations could reinterpret it.
Its face, proportions, clothing, shape, colors, or overall visual identity could change.
Explicit instructions such as:
“Do not regenerate this character.”
or:
“Use only the approved official asset.”
could be understood correctly in conversation, yet the character could still be regenerated during a later tool call.
2. “Do not generate” was not an enforceable constraint
I explicitly defined certain assets as:
-
do not regenerate
-
do not redraw
-
do not replace with a similar version
-
use the original asset only
ChatGPT could explain these restrictions correctly.
But this did not necessarily prevent the image-generation workflow from generating those elements again.
This revealed an important distinction:
A rule existing in context is not the same as a rule constraining execution.
3. Using original assets solved identity consistency but created a different problem
To prevent character drift, I tried using the approved character images directly.
This preserved identity.
However, it often produced a pasted or collage-like appearance instead of a naturally integrated illustration.
This created a fundamental tradeoff:
Generate the character → new poses are possible, but identity may drift.
Use the original asset → identity is preserved, but new poses, expressions, viewpoints, and natural scene integration become difficult.
4. Character Bibles and Character IDs were not enough
I created detailed Character Bibles describing attributes such as:
-
facial appearance
-
hairstyle
-
clothing
-
age
-
proportions
-
personality and visual tone
I also introduced Character IDs.
The problem was not that these specifications lacked detail.
The problem was that there was no reliable guarantee that the required character specification would be retrieved and applied before the next generation.
What seems to be missing is a dependency check before execution.
If a production request depends on Character ID A, Asset B, and Brand Profile C, the system should verify that all three have been loaded before generation begins.
5. QA rules did not prevent failed outputs from being shown
I also created QA rules covering issues such as:
-
spelling and typographical errors
-
language quality
-
text overlapping illustrations
-
margins and spacing
-
logo placement
-
layout consistency
-
character identity
-
brand compliance
-
factual/content accuracy
However, defining a QA checklist did not guarantee that QA would actually occur before delivery.
Outputs that would clearly fail the defined QA rules could still be presented to the user.
The requirement is therefore not simply:
“Remember this QA checklist.”
It is:
“If QA fails, this output must not be delivered.”
6. More rules created larger SOPs, not necessarily better outputs
Every time something failed, I added another rule.
Over time I created increasingly detailed:
-
guidelines
-
prohibited actions
-
Character Bible entries
-
runtime specifications
-
production procedures
-
QA gates
But the fundamental problem remained.
The existence of a rule and the enforcement of a rule are different things.
As a result, the documentation became increasingly complex while output reliability improved much more slowly.
7. ChatGPT could promise a workflow change without actually enforcing it later
This was especially important from a trust perspective.
After a failure, ChatGPT could correctly explain the cause and say things such as:
“I understand the problem.”
“I will not use this workflow again.”
“This rule is now fixed.”
“From now on, I will always use the approved asset.”
But on a later request, the same production path could be selected again.
From the user’s perspective, this feels like the AI is making the same promise and then repeating the same mistake.
This is not only an output-quality issue.
It is a trust and reliability issue.
If the system cannot actually guarantee that a future tool call will obey a rule, it would be better to clearly distinguish between:
“I can remember this preference.”
and
“This is now an enforced execution constraint.”
The core problem: Declarative Memory vs. Procedural Enforcement
After many iterations, I believe this is the central issue.
ChatGPT can often correctly understand:
-
what the rule is
-
why the rule exists
-
what failed previously
-
how the failure should theoretically be prevented
But that understanding does not automatically control:
-
tool selection
-
asset retrieval
-
character retrieval
-
image-generation prompts
-
generation behavior
-
layout
-
typography
-
QA
-
repair
-
delivery eligibility
In other words:
Declarative Memory ≠ Procedural Enforcement
For persistent production workflows, both are necessary.
Why more prompt engineering does not solve this
When AI output fails, the common solution is to make the prompt or guidelines more detailed.
I tried that extensively.
After dozens of production and correction cycles, it became clear that additional prompt detail reaches diminishing returns if those instructions are not converted into execution constraints.
When a user has already spent significant time teaching the system:
“Never regenerate this asset.”
“Always use this approved character.”
“This layout was rejected.”
“This version was approved.”
“Never deliver an output that fails this QA rule.”
the solution should not simply be to ask the user to write an even longer prompt.
The system needs a way to recognize:
“This is not merely reference information. This is a persistent production constraint.”
Character Reference / Character Identity Lock
A particularly important feature would be a true Character Reference / Character Identity Lock system.
The system should allow an approved character identity to remain fixed while still allowing new:
-
poses
-
expressions
-
viewpoints
-
camera angles
-
interactions
-
scenes
Identity-locked attributes could include:
-
face
-
body proportions
-
unique shape
-
clothing
-
colors
-
accessories
-
brand-specific elements
-
character-specific design language
The model should then change the character’s performance, not reinterpret the character’s identity.
In other words, the goal is not:
“Generate a character similar to this reference.”
It is:
“This is the character. Now let this same character perform a new action.”
This would be significantly more useful than storing dozens or hundreds of fixed character poses.
Features that would help
Based on this experience, I would find the following capabilities valuable:
-
Project-level Brand / Production Profiles
-
User-defined commands linked to those profiles
-
Approved Asset Libraries
-
Asset-level Do Not Modify attributes
-
Asset-level Do Not Regenerate attributes
-
Negative Asset Locks
-
Character Reference
-
Character Identity Lock
-
New poses and expressions while maintaining the same character identity
-
Protection against automatic reinterpretation of brand characters
-
Approval State for approved vs. rejected outputs
-
Prevention of reuse of previously rejected character/design variants
-
Persistent production-state feedback such as “this layout is approved” or “this character version is rejected”
-
Guidelines that can operate as tool-execution constraints, not only reference documents
-
Pre-generation Dependency Checks
-
QA rules that control whether an output is eligible for delivery
What is really needed: a production pipeline
The most important improvement may not be another generation feature by itself.
It may be a production orchestration layer.
Ideally, one user request could internally trigger something like:
Retrieve Brand / Production Profile
↓
Retrieve execution constraints
↓
Dependency Check
↓
Retrieve approved Characters / Assets
↓
Plan content
↓
Generate only what needs to be generated
↓
Character Identity Check
↓
Place official assets
↓
Typography / layout
↓
Brand QA
↓
Content QA
↓
Layout QA
↓
FAIL → internally repair
↓
Run QA again
↓
ALL PASS
↓
Deliver final output
“One-shot production” should not mean “one generation”
This distinction is very important.
From the user’s perspective, a successful “one-shot” workflow does not mean that the model must generate the image exactly once.
What the user wants is:
one request → one approved delivery
not:
one request → one generation
Internally, the system could generate, inspect, repair, regenerate, re-layout, and re-check multiple times.
The user does not need to see every failed intermediate output.
Ideally:
FAIL should trigger internal repair, not user-side debugging.
The user should receive the result once it passes the required production checks.
Desired UX
The ideal user experience would be:
User:
“Create educational content about X in the brand version.”
ChatGPT internally:
Brand / Production Profile
→ Constraints
→ Approved Characters / Assets
→ Dependency Check
→ Content Planning
→ Controlled Generation
→ Identity Preservation
→ Official Asset Placement
→ Typography
→ Brand QA
→ Content QA
→ Layout QA
→ Internal Repair if needed
→ ALL PASS
User receives:
One completed, compliant deliverable.
Why I think this matters beyond image generation
Although I encountered these problems while building a branded visual-content workflow, I believe the underlying issue is broader.
The same architecture could apply to:
-
documents
-
presentations
-
videos
-
web content
-
recurring business materials
-
other persistent creative workflows
As ChatGPT becomes capable of using more tools and producing more complex deliverables, persistent production work will increasingly require more than memory.
It will require a reliable connection between:
Memory
→ Constraints
→ Dependencies
→ Tool Execution
→ QA
→ Repair
→ Delivery
That connection is what would allow ChatGPT to move from being a tool that can create individual outputs to something closer to a reliable AI production studio.
Privacy / Intellectual Property Note
This feedback is based on a long period of real-world experimentation and repeated production/revision cycles.
However, I have intentionally anonymized it.
I am not including any actual:
-
brand names
-
organization/company names
-
character names
-
logos
-
character images
-
personal images
-
production assets
-
completed branded materials
What I hope can be useful for product and model improvement is not the underlying brand intellectual property, but the failure patterns, attempted solutions, workflow limitations, and product-design lessons discovered through this long-term use case.
The main takeaway I would like to emphasize is:
The next step for persistent creative workflows is not simply better memory or longer prompts. It is the ability to turn selected remembered rules into enforceable production constraints.
And from the user’s perspective:
“One-shot creation” should mean one request / one approved delivery — not one generation.