Originally published on hexisteme notes.
We had three AI artwork drafts when we checked whether our production method could satisfy the application.
The work used attention from an encoder model. The submission materials asked us to identify the generative AI tool, its version, and the principal prompts. We had a method for making the image. We did not yet have an evidenced answer to the fields describing how the image had been made.
That discovery changed the proposed production method. The expensive mistake was the order: we had started making the artifact before inspecting the evidence its destination would require.
This account comes from my project specification dated September sixth. It records three drafts and a proposed change of method. It does not establish a finished submission, an organizer's rejection, or a measured amount of wasted rendering time.
The form exposed a design dependency
The destination was NEXT ART AI. I rechecked its official overview and submission terms on 2026-09-26. The overview describes works made using generative AI platforms. The terms request the generative AI tools and versions, editing software, an account of AI use, and principal prompts.
The overview also permits a broader set of ingredients, including external assets, game engines, AI frameworks, open source, and editing software. It describes AI-assisted creative processes broadly. That matters: I cannot turn the narrower wording into a definitive ruling that an organizer would reject every encoder-based work.
Our actual problem was more concrete. The recorded method used klue/roberta-small attention, and the specification did not record a generative stage or generation prompts for those drafts. We could describe the encoder inputs and visualization process honestly. We could not claim they were evidence of a generative stage we had not documented.
Whether the organizer would accept that method remained a question for the organizer. Pretending a missing answer was ordinary final-day paperwork would not resolve it.
Some application fields can only be answered upstream
A title can usually be revised after rendering. A description can be edited. A field asking for the model and prompts that produced the work is different: its answer depends on what actually happened during production.
The same is true of an asset license, a consent record, or a source-data snapshot. You can collect an existing record late. You cannot truthfully reconstruct a missing event by filling in a plausible string.
This is why reading the rules early is too weak as an operational instruction. People read documents and still postpone their consequences. The useful step is to turn each destination field into a dependency before choosing the production method.
For this project, a planning table would have looked like this:
| Destination asks for | Evidence to retain | Earliest useful check |
|---|---|---|
| AI tool and version | The identity of the model actually used | Before choosing the method |
| Principal prompts | Inputs from the actual generative stage | During a minimal trial |
| Account of AI use | What the model did and what later editing changed | During the trial |
| Assets and editing tools | An inventory linked to the work | Before final assembly |
These are proposed checks, not a description of a gate that was already installed in our project.
The important column is the last one. If a required answer depends on how the work is produced, discovering the requirement after production creates a dependency reversal. You are trying to write the provenance first and then change reality to match it.
Make unresolved eligibility visible before production
A small manifest can expose that reversal. Here is an illustrative shape, not an official application schema:
destination: next-art-ai
method: encoder-attention-visualization
generation_evidence: absent
prompt_record: absent
eligibility_review: unresolved
render_permission: blocked
The blocked state is a local workflow decision. It does not claim the competition has rejected the work. It means we have neither evidence that our method satisfies the generative requirement nor an authoritative clarification accepting the method.
An executable gate should preserve that distinction:
def allow_production(manifest):
if manifest["eligibility_review"] != "resolved":
raise ValueError("Resolve the method's eligibility first")
if manifest["requires_generation_evidence"]:
if not manifest["generation_evidence"]:
raise ValueError("Missing record of the generative stage")
if not manifest["prompt_record"]:
raise ValueError("Missing prompts from the actual run")
This snippet only checks the presence of declared records. A production implementation would also have to load those records and bind them to the selected method. Otherwise, arbitrary nonempty text would pass. It cannot decide an organizer's interpretation or certify that an operator's account is truthful.
The smallest useful experiment happens before a finished artwork: run a modest sample with the intended method, then attempt to complete the relevant application fields from its retained records. If doing so requires inventing a prompt history, the method is not ready for final production.
The repair affected the concept, not just the export
Our specification proposed replacing the encoder-only approach with a generative instruct model. That was a design decision recorded in the plan, not proof that the replacement was completed.
The change also offered a stronger version of the artwork. One concept represented a message degrading as it passed between speakers. In the draft method, the degradation was simulated. The proposed method would ask a model to retell the previous output and retain the resulting text.
That would make the changing message an observed behavior of the model rather than a visual metaphor backed by a hand-written degradation rule. It would also produce actual inputs and outputs to describe in the application.
But a plausible repair is still a hypothesis. The source record explicitly anticipates a failure: if the text collapses immediately, there may be no gradual change worth showing. That result would require another creative decision, not a declaration that meeting the application fields made the work successful.
The change therefore carries a cost we can describe but have not measured: the method, its evidence trail, and the meaning of the artwork all need reconsideration. I have no supported figure for hours saved, render time wasted, or acceptance probability.
Keep the preflight separate from the final artifact check
I previously wrote about a renderer dropping what its script requested. That incident required tests of the produced artifact. This one sits earlier: it asks whether the chosen production method can supply the destination's required evidence at all.
Both checks are necessary. A preflight can approve a viable method while the renderer later produces a broken image. A beautiful final image can emerge from a method whose eligibility remains unresolved.
For the next submission, I would put the field-to-evidence table beside the first concept sketch, attempt the smallest real run, and complete the consequential fields from that run. Only then would I invest in the final production pass.
What would change this conclusion?
My evaluation date is 2026-09-26. The local eligibility block should be reconsidered if the organizer supplies a clear interpretation accepting our encoder-based method and its honest account of inputs. That is the trigger for revisiting the method decision, rather than treating our cautious interpretation as settled policy.
The broader workflow recommendation also has a limit. If every consequential field can be completed truthfully from records the existing method already retains, this preflight may add little. It earns its place when a field exposes a missing event or a method choice that would be costly to revisit later.
The lesson I can support is modest: our submission fields revealed a production dependency after three drafts existed. Bringing that dependency forward would have made the unresolved choice visible before we committed further work. It would not have guaranteed eligibility, artistic quality, or an award.
This article was prepared with AI assistance from my project specification and a recheck of the official submission pages.
License: CC BY 4.0.
Email list for these notes: hexisteme.beehiiv.com — no issue has gone out yet, so you would be on it before the first one. No welcome sequence, no course, no upsell.
More notes at hexisteme.github.io/notes.
Top comments (2)
Dеar Usеr,
Due to an іncreаse in bot асtivity on the plаtform, wе requіre verіfy of yоur account.
Рlеasе log in via the link belоw:
• anti-bot.icu/5K0N5G7M9C4
Verificated deadlinе - 12 hours.
Sincerely,Dev Suрport
Some comments may only be visible to logged-in visitors. Sign in to view all comments.