build.allanninal.dev

Part 5 of 7 · Content repurposer series ~5 min read

How a repurposed draft gets approved

A batch of drafts lands on the review desk on Monday afternoon. A six-part thread, three short posts, a quote-card caption — each with the source passage it came from sitting right next to it. There’s an Approve button, an Edit button, and a Skip button on every one. What happens when you tap each? This post walks through the three actions, what each does to the draft and the schedule, and how every choice gets logged so nothing posts that you didn’t wave through.

Key takeaways

  • Three actions per draft: approve (send it on or queue it), edit (tweak it), skip (drop it).
  • Approve hands the draft to your scheduler or your review channel — never straight to the public.
  • Edit opens a box pre-filled with the draft; your edit is what gets saved and sent.
  • Skip drops the draft and can pull a backup point off the bench to replace it.
  • Every action is logged, so next month you can see what got approved, edited, or skipped — and why.

Three actions on a draft

Three actions on a draft at the review desk A diagram showing one input on the left flowing through a review panel, then branching into three action paths. Far left: a "Draft on review desk" box showing a typical draft — the text, its format, and the source passage it came from — with three button placeholders below: Approve, Edit, Skip. You tap one button. The middle column shows the three branches. Branch one, Approve: a Function URL Lambda marks the draft approved and either queues it on the post scheduler to drip out across the week at the times the rules doc sets, or sends it to a review channel for a person to post by hand; an approved event is written to the audit trail. Branch two, Edit: opens a box pre-filled with the draft text; you tweak the wording and save; the Function URL Lambda stores your edited version as the approved one and writes an edited event with the before and after, then queues it the same way an approve does. Branch three, Skip: drops the draft for this run and, if there's a backup point on the bench, can pull one off to draft a replacement; nothing is sent. The right side shows the convergence: every action writes a row to the cr-audit DynamoDB table with timestamp, draft id, action, by-user, and the source passage. A note at the bottom: nothing posts on its own — approve, edit, or skip, a human taps every draft before it leaves the desk. Draft on desk text, format, passage [Approve] [Edit] [Skip] Action 1 Approve • Mark approved • Queue on scheduler or send to channel • Drips across the week Action 2 Edit • Box pre-filled with the draft text • Your version is saved, then queued Action 3 Skip • Drop this draft for this run • Can pull a backup point to replace it Audit trail DynamoDB cr-audit timestamp · draft_id action · by-user source passage Nothing posts on its own — a human taps every draft before it leaves the desk.
Fig 5. Three actions per draft, three different effects. Approve queues it or sends it to a channel. Edit saves your version and then queues it. Skip drops it and can pull a backup point to replace it. Every action writes to the audit trail.

Action 1: approve (the common one)

You read the draft, it’s good, you tap Approve. A Function URL Lambda marks the draft as approved and decides where it goes based on your setup. In the simple setup, it lands in a review channel where a person copies it out to the right platform by hand — a small extra step, but it means the system never touches a public account. In the fuller setup, it’s queued on a post scheduler that drips approved drafts out across the week at the times the rules doc sets — say, one a day at 9am, never two in an hour. Either way, an approved row is written to the audit trail with the draft, the source passage, and your name.

The drip matters. A week’s worth of posts approved in one sitting shouldn’t all go out in one sitting. The scheduler spaces them so your feed looks like a person posting through the week, not a batch job that fired at 2pm Monday.

Action 2: edit (the tweak)

Most drafts are close but not perfect. The hook could be sharper, a word feels off, you want to swap the opening line. Edit opens a box pre-filled with the draft text. You change what you want and save. The Function URL Lambda stores your version as the approved one — the model’s draft is kept too, but yours is what gets sent — and writes an edited row with the before and after, then queues it the same way an approve does.

Keeping both versions is worth it. Over a few months, the gap between what the model drafted and what you actually posted is the clearest signal of where the voice doc needs work. If you keep rewriting the openings, the voice doc’s examples probably don’t show enough of how you open. The edit history is how you tune the system without guessing.

Action 3: skip (the no)

Some drafts just don’t land. The point was thinner than it looked, the angle doesn’t fit this week, you already posted something similar. Skip drops the draft for this run. Nothing is sent. A skipped row is written so the reason isn’t a mystery later.

Skip has one extra trick: the backup points from Part 3. If you skip a draft and there’s a backup point sitting on the bench, the system can pull one off and draft a replacement, so a week of skips doesn’t leave you short. This is optional — the rules doc decides whether skips auto-refill or just drop — but it’s the difference between “I skipped three and now I have nothing” and “I skipped three and three fresh ones showed up.”

Every action is logged, every draft is traceable

The cr-audit table records every approve, edit, and skip with the user who did it, the timestamp, the draft, and the source passage it came from. That last part is the quiet payoff of the grounding rule: months later, you can look at any post that went out and see not just that a human approved it, but the exact sentence in the original piece it traces back to. If someone ever asks “where did this claim come from?”, the answer is one lookup away.

This is also how you measure whether the system is earning its keep. The log shows your approve rate, your edit rate, and what you skip most. A high skip rate on one format means the rules doc is asking for a format that doesn’t work for you; a high edit rate means the voice doc needs more examples. The review desk isn’t just a gate — it’s the feedback loop that makes next month’s drafts better.

Next post: the cost breakdown. The whole pipeline above runs in coffee-money territory at SMB volume; Part 6 explains exactly where the dollars go and why the Bedrock calls are the only line that really moves.

All posts