Treating a malformed model review as a rejection

The reviewer also produces data that needs checking#

An image review is another model response, not a ready-made decision. The workflow accepts known response wrappers, parses their JSON, bounds the scores and requires publishable to be literally true. If parsing fails, it supplies rejecting defaults and a failure reason.

The next gate checks positive thresholds, risk ceilings and explicit rejection reasons before allowing caption generation. This makes the action defined even when the review is malformed. It doesn't make the model's quality judgment objective or calibrated.

Give caption repair a stopping point#

Caption QA checks its own model scores and flags. When visible-fact terms are available, it also requires at least two shared terms. That adds a concrete text constraint, but two common words can overlap without the caption describing the image accurately.

A failed caption gets one repair and another review. A second failure becomes social-rejected; a pass becomes a draft. An image rejected before this work begins retains its image-rejected state, so the result explains which stage stopped it.

Apply the decision to the candidate that owns the work#

Generation verifies the candidate owner, but stale-lock maintenance updates by locked status without including the candidate key or owner. Later pool writes also don't consistently repeat the owner. A correct review decision doesn't resolve that row-selection problem.

I'd test malformed review output and both caption outcomes alongside a reclaimed-lock case. That would check the editorial routes and whether recovery can change the wrong candidate. No provider generation or concurrency test was run for this note.