Reviewing generated images before caption work begins.

THE WORK

The project.

Metaphor in Matter separates making an image from deciding whether to develop it into a social draft. The exported n8n pipeline parses an image review, checks positive and risk scores, and requires an explicit publishable flag before caption generation begins. A malformed response or a rejection reason stops that path, so missing review data doesn't look like a pass.

Caption review adds its own scores and flags, plus a narrow check for overlap with visible-fact terms. A failed caption can be repaired once and checked again; the result becomes a draft or a recorded social rejection. Image rejection remains a separate outcome. These are implemented editorial rules, not calibrated measurements of quality, and accepted drafts aren't publication results.

IMPLEMENTATION

Design choices.

1. Generation is tied to one owned pool candidate. Claim verification and the single-item assertion keep the provider path from accidentally receiving an ambiguous batch of candidates.
2. Unusable review output is rejected. When JSON parsing fails, the workflow supplies zero positive scores, maximum risk scores and publishable=false. An empty assessment therefore can't carry the image into caption generation.
3. The scoring rules are explicit. Each of four positive dimensions needs at least 8/10; ordinary-image risk must be at most 2.5 and caption dependency at most 3. These thresholds make a decision repeatable from the supplied scores, not an objective measure of the image.
4. Caption QA includes a narrow text check. When visible-fact terms exist, the caption needs at least two overlaps as well as its model checks. Generic words can still overlap, so this constraint doesn't establish that the description is correct.
5. Caption correction stops after one repair. A second failed review becomes social-rejected instead of triggering another automatic attempt. That keeps persistent caption failure distinct from an earlier image rejection or a provider transport failure.

HOW IT FITS TOGETHER

Architecture.

• Telegram routing separates library and source work from image generation. Briefs enter a shared Data Table pool; the generation workflow conditionally claims a ready candidate, verifies the run owner and asserts that exactly one input item reaches the provider path.
• The returned image goes through model review and a parser for known response wrappers. The parser reads JSON, bounds scores and requires publishable to be literally true. Thresholds and explicit failure reasons determine whether caption work may start.
• Caption QA combines model scores and flags with a visible-fact term-overlap check. The first failed caption can go to a repair writer, then one further QA pass decides whether it becomes a draft or social-rejected output.
• Image rejection, caption rejection and draft output have distinct paths, preserving the stage that made the decision. Separate stale-lock maintenance handles abandoned work, but its update currently matches locked status without the candidate key or owner and needs tighter scope.

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