Following image jobs from submission to usable candidates.

THE WORK

The project.

The Velvet Paradox gives a submitted image request a local history while the provider is still working. Its n8n workflow records the queued job, retains the concept and variant it belongs to, and follows the provider's status and result locations. Completion creates one candidate per returned image only when image URLs are present. Failed and timed-out jobs retain their own outcomes instead of appearing as empty successes.

Keeping that context available requires care because a Data Table write can replace the current n8n item. The workflow restores job identity for later nodes, but its poll normalizer also reloads the initial counter. That possible reset still needs a loop test. This account covers the exported workflow and maintenance logic, not a verified provider render or live recovery run.

IMPLEMENTATION

Design choices.

1. The workflow restores identity after storage nodes replace the payload. Later writes need the original concept and job, but progress fields such as the attempt counter must come from the latest loop pass rather than the initial snapshot.
2. The queued record precedes submission. It makes a pending request locally traceable, although the time-dependent job ID identifies an attempt rather than deduplicating replayed requests. A repeated submission can still create another provider attempt.
3. Candidate creation requires artifacts as well as a completed status. An empty completion can't become a candidate; valid output produces a separate candidate for each image URL returned.
4. Provider failure, polling timeout and stale-work recovery have separate records. Each explains a different stopping point. The maintenance path doesn't substitute for proving that the normal poller reaches its own attempt limit.

HOW IT FITS TOGETHER

Architecture.

• The submit-and-poll workflow validates the concept, variant and prompt, separates context from job fields, and stores a queued record before calling the provider. The pending request therefore already has a local attempt identity.
• Provider normalization extracts the request identity and the status and result locations. After Data Table writes return row-shaped output, the workflow joins back the original context so later operations still identify the same concept and job.
• Wait, poll, normalize and increment nodes repeat while the provider is pending. The workflow records running state and has separate completion, failure and timeout branches; the counter must survive every pass for the configured attempt limit to work.
• The completion branch requires image URLs before emitting candidates. A separate maintenance workflow finds stale jobs and expired concept reservations, providing a recovery path for work whose original polling execution no longer advances.

CHECKS & RESULTS

What was checked.

A source review shows what the code does. It is not a fresh test of the running app.

1. Code and development records reviewedReviewed11 September 2026

   The code, tests and available development records were checked. Reported test results keep their original scope. No fresh app or live deployment check was run for this write-up.

   Scope of this check

   Code review, not a fresh run of the app