An approval workflow for AI-drafted posts is a small state machine with one rule: a post only becomes public after a named person accepts that exact version. Everything else is detail about who moves a post from one state to the next and what evidence they need.
Most workflows don't fail at the approve button. They fail just before it, when the draft rests on a stale source, or just after it, when someone edits the caption, the slot passes, or the account token expires. This guide is about designing for those edges. If you want the product page for Cadencz's version instead, it is linked at the end.
Draw the states before you choose a tool
Write each state a post can be in, then write who or what is allowed to move it to the next one. If you cannot name the mover, the transition will happen by accident.
| State | What is true in this state | Who moves it on | Exit |
|---|---|---|---|
| Brief | A source, a reader, and a destination are named | The requester | Drafting starts |
| Drafting | The model is writing; nothing can be signed off yet | Software | Draft, or failed generation |
| Draft | Editable text exists for each destination | The approver | Approved, or rejected with a reason |
| Approved | One version is frozen with its account, media, and time | The scheduler | Publishing at the slot |
| Publishing | The request is with the platform | Software | Published or failed |
| Failed | The text is intact and the error is stored | The publisher | Retry, edit, reconnect, or cancel |
How Cadencz implements those states
A worked example helps, so here is how Cadencz's own code models this, read from the backend on October 19, 2026. A planned post is `rendering` while the writer works, then `draft`. Trying to approve a card that is still rendering is refused with a message that it is still being written. Approval is also refused, with a clear error, when none of the post's target platforms has a connected account, because there would be nowhere to send it.
Approving does three things at once. It creates one copy of the post per connected channel, and one per part if the post is a thread, with thread parts spaced 30 seconds apart so replies attach in order. It sets each copy to `scheduled` if a time was chosen, or leaves it as `draft` with no slot. And if the planned slot has already passed by the time someone signs off, it moves the post to at least five minutes from now rather than publishing into the past.
After that, the publisher moves each copy to `publishing` and then `published` or `failed`. A failure keeps the post body and stores the error text on the row. If the platform rejects the credentials, the channel is marked as needing reauthorization so the app shows a Reconnect prompt instead of retrying a dead token. If an admin pauses a channel, scheduled posts stay scheduled and go out once it is back on. A setting to skip review entirely exists ("schedule straight to the calendar"), and it is off by default.
What an automated check can catch
Software is good at checks that have a right answer against the source material. It is bad at checks that depend on what is happening in the world this week. Design the automated pass around the first kind and leave the second to a person.
Cadencz's Critic is one concrete version of this. It is a second model that reads each draft and returns at most three issues, each tagged hard or soft. Hard issues are the ones that would make the post wrong to publish: an invented fact or a number the source does not support, a sentence reused from the creator's already published posts, a banned or promotional phrase, or copy over the platform's character limit. Only a hard issue sends the draft back to the writer, and the loop stops after two attempts so a bad prompt cannot spend credits forever. Formatting, hook strength, and tone are soft: they are shown to the person, who is a better judge of taste. The Critic runs on paid plans only.
Notice what that list cannot cover. The Critic compares the draft with the source, so a wrong source produces a confidently wrong post that passes. It cannot know that a customer withdrew permission to be named, that a launch slipped a week, or that the subreddit you are posting to banned self-promotion last month. Those are the checks your human pass exists for.
Order the human pass by cost of being wrong
Check in this order: truth (facts, numbers, dates, links, customer details), then whether the reader gets something before the product asks for attention, then voice, then platform fit, then delivery (account, time, media). The order matters because a failed truth check makes everything after it wasted work. Polishing the hook of a post whose central claim is false is the most common waste in any review queue.
Match the path to the risk of the post
A routine build note and a regulated customer claim should not go through the same path. One process will be too slow for the first and too thin for the second. Decide the risk level in the brief, before anyone drafts. Raising it after a post is scheduled means the record shows sign-off from someone who never saw the claim that needed them.
| Model | Use it for | Required decision | How it usually fails |
|---|---|---|---|
| Self-review | Routine founder education and low-risk build notes | A second look at truth, on a different day from drafting | Drafting and sign-off happen in the same sitting |
| Single approver | Product updates and ordinary brand content | One named person accepts the exact version | A team is named instead of a person |
| Parallel review | Claims needing product plus legal or security input | Every specialist sees the same frozen version | Feedback lands on different copies |
| Sequential review | Regulated, contractual, crisis, or executive posts | Each stage has a distinct job and a deadline | Stages are added without authority to say no |
Where approvals break in practice
Edits after sign-off. Someone fixes a typo, and in passing changes "up to 40%" to "40%". If the sign-off is not tied to a version, nobody notices. Rule: any change to text, media, link, account, or time reopens the checks that change affects, and the old decision stays in the history.
Sign-off in chat. A thumbs-up in Slack is not evidence, because nobody can prove which revision it referred to. Record the decision where the post lives.
Passed slots. A post approved Wednesday for a Tuesday slot has to go somewhere. Cadencz moves it forward to the soonest sensible time. For a time-sensitive post, such as a webinar reminder, the better design is to let it expire and say so.
Dead credentials. The approved post fails at publish time because a token was revoked. The failed state must keep the exact text, show the platform's error in plain words, and offer the one action that fixes it, which here is reconnecting the account, not retrying.
Silent automation. Turning off review for a recurring low-risk format is reasonable once the workflow has a record of clean weeks. Turn it on per format, keep an off switch, and keep posts with no connected channel waiting as drafts instead of dropping them.
Write rejection reasons that change the next draft
Store rejection reasons and read them monthly. If the same reason keeps coming back, fix the source note, the voice rules, or the brief, and the editing cost stops recurring.
Weak feedback
Too salesy. Try again.
Actionable rejection
Rejected: the opening claims this is the fastest workflow without evidence, and the reader gets no usable idea before the product link. Keep the onboarding example, drop the superlative, and lead with the three-question test.
Name who decides what
On a team, five jobs need an owner: the requester who supplies the source, the fact owner who confirms product, legal, or customer claims, the editor who owns voice and platform fit, the approver who accepts the final version, and the publisher who watches delivery and handles failures. Give each stage a backup for absence and a deadline. A status with no due time is a label, and silence should never count as a yes unless a written standing rule says it does.
A solo founder holds all five jobs. Keep the states anyway, and sign off on a different day from the one you drafted on. The separation is what stops a fresh draft from feeling finished.
Measure whether the workflow is helping
Look at quality and speed separately each month, so a fast process cannot hide mistakes and a careful one cannot hide avoidable waiting.
| Metric | How to calculate it | What it reveals |
|---|---|---|
| Median time to decision | Time from draft ready to approved or rejected | Whether the normal path is predictable |
| Deadline breach rate | Late decisions divided by decisions due | Where ownership or capacity is unclear |
| Revision rounds | Change requests before final sign-off | Whether briefs and rejection reasons are improving |
| Post-approval change rate | Approved posts edited before publishing | Whether sign-off happens too early |
| Preventable incident rate | Posts corrected or removed for issues the checklist covers | Whether the workflow protects the account |
| False-friction rate | Low-risk posts escalated without a policy reason | Whether the process is heavier than the risk |
The checklist to copy
If you would rather not build this from a project board, Cadencz's product page describes how its draft queue, Critic, and scheduler fit together, and the automation guide covers which steps are safe to hand to software.
- Source attached and current
- Reader outcome named
- Claims match the source, and the source is still true
- Customer details cleared for use
- Community rules checked for the destination
- Account, date, time, link, and media confirmed on the frozen version
- Someone owns the post if it fails