Pre-publish QA, wired into the CMS boundary.

Try the text demo

Paste AI-written, human-written, or mixed draft content. The public demo is rate limited, capped, and forces store_content:false.

{
  "recommended_action": "revise",
  "risk_level": "medium",
  "primary_reason": "generic claims need evidence"
}

A concrete example

Setup: A programmatic travel-safety site running 1,200 city-scam pages through a generator over six weeks. Pre-gate baseline: roughly 8% of pages required emergency rewrites within 30 days because readers complained the advice was generic.

Result: After integrating the gate at the WordPress save_post hook, 27% of drafts routed to revise on first pass. The most common failure was 'specificity_gap' — the generator was writing the same pickpocket warning for every city. With evidence spans fed back to the rewrite agent as prompts, those pages returned with named neighborhoods, named scam patterns, and one specific local source per page. Reader complaints dropped to under 1% within 60 days. Editor time per published page dropped from ~12 minutes to ~3 minutes.

FAQ

Will this slow down my publish workflow?

Median latency on text scoring is in the low single seconds. For high-volume publishers, the batch endpoint accepts 1–25 items per call; bundle drafts when latency matters more than evidence freshness.

What happens when the API is unavailable?

Fail-open or fail-closed is your local policy decision. Most teams fail open for low-stakes content (route the draft to publish) and fail closed for YMYL content (route to editor queue). Document the decision in your runbook.

Can I score sections separately?

Yes, and you should for long pages. Score by H2 section; aggregate the worst section as the page risk. Section-level scoring also makes the evidence array actionable — your rewrite agent can target the specific bad paragraph instead of regenerating the whole page.

WordPress pre-publish hook pattern

// CMS pre-publish gate. WordPress example; the shape is universal.
add_action('save_post', async function ($post_id, $post) {
  if ($post->post_status !== 'publish') return;

  $result = await veracityAnalyze([
    'type'    => 'text',
    'content' => extractUniqueBody($post),
    'context' => [
      'format'        => 'article',
      'intended_use'  => 'publish',
      'domain'        => 'travel safety',
    ],
    'store_content' => false,
  ]);

  switch ($result['recommended_action']) {
    case 'allow':
      // Pass-through; CMS publishes normally.
      return;
    case 'revise':
      wp_update_post(['ID' => $post_id, 'post_status' => 'draft']);
      update_post_meta($post_id, 'rewrite_brief', $result['evidence']);
      queueRewriteAgent($post_id);
      return;
    case 'human_review':
      wp_update_post(['ID' => $post_id, 'post_status' => 'pending']);
      notifyEditor($post_id, $result);
      return;
    case 'reject':
      wp_update_post(['ID' => $post_id, 'post_status' => 'trash']);
      logRejection($post_id, $result['primary_reason']);
      return;
  }
});

Agent policy

Start by routing only the drafts that already have a 'pending QA' status. Don't gate everything on day one — calibrate thresholds on a non-blocking shadow run for the first two weeks.