Part 3 of 7 · AWS autoposting series ~4 min read

How a post actually goes out

Five quick checks between “it’s time” and “post is live.” Cheap gates first, expensive gates only when needed.

The posting robot wakes up on a schedule, picks the next queued post, and runs it through a small gauntlet before letting it touch Facebook.

Five-stage posting pipeline with three-way verdict routing A vertical pipeline. At the top, an EventBridge timer fires. The post then passes through five stages in sequence: schema check (free), keyword check (free), semantic similarity check using Titan Text Embeddings v2 (about two-hundredths of a cent per thousand tokens), and an LLM judge using Claude Haiku 4.5 (only fires when similarity is borderline, about five percent of posts). After the LLM judge, the verdict routes to one of three outcomes: PASS publishes to the Facebook page, REVIEW sends an email to you for approval, BLOCK is logged to the audit table only. EventBridge timer fires 1. Schema check required fields, length free 2. Keyword check allowlist + denylist free 3. Similarity check vs niche centroid ~$0.00002 / 1K tokens 4. LLM judge Claude Haiku 4.5 only if borderline (~5%) 5. Verdict routing PASS Publish to Facebook page REVIEW Email you to approve BLOCK Logged to audit table
Fig 3. Five gates between “it’s time” and “post is live.”

Cheap checks first, expensive checks only when needed

Most posts pass all five stages in well under a second. A typo or a missing required hashtag is caught for free in stage 1 or 2 — no AI runs, no money spent. The cheap embedding model only weighs in at stage 3, and that costs a fraction of a cent per post. Only when the score lands in the borderline band does the smarter, more expensive judge get called — about five percent of posts in steady state.

Why bother?

The point isn’t paranoia — it’s catching the moment when a faith post accidentally gets queued against the DailyScalper page (because someone got distracted while drafting), before the world sees it. The schema gate alone catches that: a post tagged with the wrong page is rejected at stage 1, no AI required.

The keyword denylist catches the next layer: a post containing “XAUUSD” or “FTMO” cannot reach a faith page, no matter how it slipped through.

The semantic check is the safety net for everything else: subtle drift, off-brand voice, content that’s technically allowed but doesn’t fit the page’s identity.

Three possible endings

  • PASS — the post goes to the Graph API, gets a published timestamp, and the audit table records it.
  • REVIEW — you get an email with the post text and an approve link. Your call.
  • BLOCK — the post is marked blocked in the queue with a reason. Never posts. Logged for review so you can tune the rules later.

Per-page rules live in S3, not in code

Each page has a small JSON config in S3: which hashtags it requires, which terms it blocks, what its niche centroid is, where its similarity thresholds sit. Tuning the rules — raising a threshold, adding a denylist term — doesn’t require a redeploy. Edit the JSON, save, the next post uses the new rules.

All posts