Publishing pipeline quality gate
A pre-publish quality gate for agent-written articles, listicles, comparison pages, and programmatic SEO output. Stop generic drafts at the CMS boundary, send weak ones back to the rewrite agent with evidence attached, and only publish what would survive a human editor's first read.
I spent ten years at Clearscope watching editorial teams grade drafts. The single most reliable predictor of whether a piece would earn organic traffic was the same predictor of whether an editor would call it 'good': specificity. Named places. Named products. Specific numbers. A real example instead of a category statement. When we built VeracityAPI's text scoring, we deliberately weighted specificity_risk and provenance_weakness higher than synthetic_texture_risk, because the failure mode that matters at publish time isn't 'this sounds like AI' — it's 'this could've been written by anyone, about anything.'
Business value
- Caps the downside of high-volume programmatic publishing. One bad week of slop can knock domain quality for months; a gate at publish time prevents the bad week.
- Concentrates editor attention on the drafts that actually need a human, which is usually less than 20% of generator output once routing is tuned.
- Turns evidence spans into targeted rewrite prompts so your generation model fixes the specific weakness instead of re-writing whole drafts.
Agent job to be done
Be the last reader before publish. If the draft is specific, sourced, and useful, mark it allow. If it leans on generic phrasing or claims without support, route it to revise with evidence. If a claim could hurt readers or domain trust, hold it for human_review.
format: articleintended_use: publishdomain: programmatic publishing / editorial QA
Editorial workflow integration: where the gate actually sits
Most teams I've worked with run the gate as a CMS pre-flight hook (WordPress save_post, Sanity webhook, Contentful workflow stage). The trick is keeping the gate idempotent — if a draft fails, gets rewritten, and re-enters the queue, the scoring call should produce a fresh analysis_id and overwrite the rewrite_brief. Otherwise editors end up reading stale evidence and the gate loses credibility within two weeks.
When to call VeracityAPI
Run after content generation, internal-link insertion, and image selection — but before the CMS publish call, sitemap ping, or scheduling action.
What text to submit
Full unique body text (title, intro, body sections, FAQ, conclusion). Strip global nav, footer, related-post boilerplate, and recurring header chrome before submitting; templated text inflates slop_risk without telling you anything new. For pages over 100k chars, chunk by H2 and aggregate the worst section as the page risk.
Decision policy
- allow: risk_level=low and content_trust_score ≥ 0.65. Publish without delay.
- revise: risk_level=medium, or specificity_risk ≥ 0.40, or evidence flags two or more 'generic_phrasing' spans. Return to the generation agent with the evidence array as the rewrite prompt.
- human_review: risk_level=high, or evidence includes any 'unsupported_claim' with severity high, or the page covers YMYL topics (health, money, safety, legal). Block autopublish; route to an editor with the evidence pinned.
- reject: only after two failed rewrite cycles on the same page. Don't reject on first pass — most drafts can be saved.
Request template
The exact payload shape this use case sends. The sample below uses representative content for this workflow; substitute your own.
curl https://api.veracityapi.com/v1/analyze \
-H "Authorization: Bearer $VERACITY_API_KEY" \
-H "Content-Type: application/json" \
-d '{"type":"text","content":"Paris travelers should always be alert because scams happen everywhere. Keep your wallet safe and never trust strangers near tourist attractions. This guide covers essential tips for staying safe in France.","context":{"format":"article","intended_use":"publish","domain":"programmatic publishing / editorial QA"},"store_content":false}'Automation recipe
- Generator writes the draft and stores it with status=pending_qa.
- Quality-gate worker pulls pending drafts and sends each unique body section to POST /v1/analyze with store_content=false.
- If recommended_action is allow, the worker flips status to publish and the CMS picks it up on the next pass.
- If revise, the worker writes the evidence array into a rewrite_brief field and returns the draft to the generator with format-preserving instructions.
- If human_review, the worker creates an editor ticket with the title, the top three evidence spans, and a link back to the draft.
Evidence spans agents should inspect
- 'generic_phrasing' — sentences that could appear on any travel/finance/B2B page without changing meaning
- 'unsupported_claim' — best/safest/most/cheapest assertions without a named source or measurable comparison
- 'specificity_gap' — paragraphs that describe a category but never name a place, brand, product, or person
- 'padded_transition' — listicle filler between H2s that adds word count but no information
A concrete example
Setup: A travel-safety affiliate site ran 1,200 city-scam pages through their generator over six weeks. Before adding the gate, ~8% required emergency rewrites after readers complained the advice was generic or wrong.
Result: After integration, the gate blocked 27% of drafts on first pass. Most failed on 'specificity_gap' — the generator was writing the same 'be aware of pickpockets near tourist attractions' paragraph for every city. Once the rewrite agent was given the evidence spans as a prompt, those pages came back with named neighborhoods, named scam patterns, and one specific local source per page. Reader complaints dropped to under 1%.
Policy pseudocode
if (result.recommended_action === "allow") continueWorkflow(); if (result.recommended_action === "revise") rewriteWith(result.evidence, result.recommended_fixes); if (result.recommended_action === "human_review") queueForHumanReview(result); if (result.recommended_action === "reject") discardOrRebuild();
KPIs to track
- % of generator output blocked at publish (healthy steady-state: 15–35%)
- first-pass revise → allow conversion rate (healthy: 70%+)
- average word count of revised vs. original drafts (rewrites should add specifics, not just paraphrase)
- Search Console impressions / clicks for passed-vs-blocked-then-published pages over 90 days
- editor minutes saved per 100 published pages
What can go wrong
- This is a helpfulness proxy, not a Google ranking oracle. A page can pass the gate and still rank poorly for unrelated reasons (backlinks, SERP intent, UX).
- Dry, factual content (specifications, schedules, reference tables) sometimes elevates synthetic_texture_risk even when it's genuinely useful. Read the evidence before blocking.
- Don't score templated boilerplate. Score the unique body text. Otherwise every page will look 'generic' for the wrong reason.
Cost and latency notes
Analyze only is $0.005 per 1,000 characters; Analyze + revise with auto_revise=true is $0.010 per 1,000 characters. Both round up to the nearest 1,000 characters. Short captions/emails usually cost $0.005; longer pages or chapters scale linearly by length. Current v0.1 latency is LLM-bound, so batch/concurrent orchestration is recommended for high-volume pipelines.
Agent evaluation checklist
- Does this workflow have a costly failure mode from generic or weak-provenance text?
- Can the agent map evidence spans back to editable source locations?
- Should this workflow fail open, fail closed, or queue human review if VeracityAPI is unavailable?
- Which field drives policy: recommended_action, risk_level, content_trust_score, specificity_risk, or provenance_weakness?
- What local rule should complement the API score?