Quiet Lineage / Creative automation / 2026
Image jobs that finish with stored assets ready for review.
Quiet Lineage uses n8n to coordinate image-generation jobs across workers. A render is only marked successful after its image is saved, registered and queued for review.
THE WORK
The project.
Quiet Lineage coordinates image-generation work from a queued prompt to a stored image ready for review. Its n8n dispatcher checks how much work is already running, selects ready jobs by priority and age, and assigns each one to a worker with an execution token. The worker repeats that token when updating the job, so knowing the job ID isn't enough to change the current attempt.
A provider response doesn't complete the job. The worker checks the downloaded binary, stores it in Drive, creates the asset record and enqueues QA before recording render success. The exported implementation makes that sequence explicit, while leaving replay and partial-failure cases to test. In particular, the initial rendering update checks the token but not the job's current status.
- ROLE
- Software engineering
- STATE OF THE BUILD
- Prototype
- RECORD UPDATED
In this record
IMPLEMENTATION
Design choices.
- Ownership travels across the dispatcher-worker split. Repeating the claim token on job writes makes the current execution part of the update condition; knowing the stable ID or receiving a webhook response isn't enough by itself.
- Service access and record ownership are checked separately. The shared secret admits the caller, while the job/token pair identifies the claim it may act on. Neither removes the need to check whether the current state still permits that action.
- Rollback is narrower than a general reset. It releases only a still-claimed row under the same token, avoiding a late dispatch error resetting work that the worker has already advanced.
- Success waits until the output is saved, registered and handed to QA. That gives success a concrete meaning, but the separate Drive and table operations still need recovery when only part of the sequence completes.
HOW IT FITS TOGETHER
Architecture.
- The dispatcher reads ready and in-flight jobs and subtracts current work from capacity. It orders eligible jobs by priority and age, then updates a matching ready job to claimed with an incremented attempt and the execution's lock token.
- The worker handoff includes job, post and shot IDs, the prompt and the claim token. Payload parsing accepts an object or JSON object string and rejects other shapes before dispatch.
- The worker checks its configured shared secret and validates the handoff before provider polling. Rendering and terminal updates match the job ID and token, although the initial rendering update doesn't yet require an expected current status.
- After completion, binary validation precedes Drive storage, asset persistence and QA enqueueing. The job becomes successful and its lock fields are cleared only after those steps, distinguishing a provider response from a stored asset ready for review.
- If dispatch fails, rollback requires the same job to remain claimed under the same token. It returns that row to ready without unconditionally undoing a state the worker may already have advanced.
Explore the architecture map9 components · 12 connections
Claimed render queue and artifact completion
The dispatcher and worker share job state; provider output becomes a recorded asset before QA is queued.
Planning and queue
Dispatch and rendering
Artifacts and QA
Scroll or drag the background to move. Use the zoom buttons to resize.Arrow keys move between components. Enter selects.
Choose a component to explore
Select a numbered component on the map or use the component menu. Its details and connections will appear here.
No component selected.
All connections (12)
- 01 · Job preparation → 02 · Render-job tableReady jobs · Direct call
- 02 · Render-job table → 03 · Capacity-aware dispatcherCandidates + in-flight count · Direct call
- 03 · Capacity-aware dispatcher → 02 · Render-job tableConditional claim · Direct call
- 03 · Capacity-aware dispatcher → 04 · Worker entry checksClaimed payload · Async task
- 04 · Worker entry checks → 05 · Render coordinatorAccepted handoff · Direct call
- 05 · Render coordinator → 06 · fal image providerSubmit / poll · Async task
- 06 · fal image provider → 05 · Render coordinatorStatus / image output · Response / return
- 05 · Render coordinator → 07 · Google Drive artifactValidated file · Direct call
- 07 · Google Drive artifact → 08 · Asset tableStored-file metadata · Direct call
- 08 · Asset table → 09 · QA queueEnqueue ready QA · Direct call
- 09 · QA queue → 02 · Render-job tableMark render succeeded · Direct call
- 03 · Capacity-aware dispatcher → 02 · Render-job tableOwned-claim recovery · Direct call
MADE WITH
n8n · Apify · Data Tables · OpenAI · Grok · fal · Telegram · Notion
ACCESS & INPUT
Security controls.
- The worker compares the supplied shared secret with its configured value and fails when configuration is missing. This checks service entry separately from permission to update a particular job.
- Consequential job updates include the job ID and lock token. Dispatch recovery also requires claimed state, so a late failure response won't match a job that has already moved on.
- The first rendering update lacks a current-status condition. A repeated request with a still-valid token therefore needs another check before the token can be treated as protection against replay.
CHECKS & RESULTS
What was checked.
A source review shows what the code does. It is not a fresh test of the running app.
Code and development records reviewedReviewed
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
NEXT
Still to work through.
The completion path now distinguishes rendering an image from retaining an asset that QA can inspect. I'd next repeat a webhook while its worker is active, lose the response after acceptance, and interrupt the Drive and asset writes. Those checks would test whether the ownership and recovery rules hold across the full sequence; they weren't run for this source review.