Have an Assistant Draft Content Without Inventing Business Facts

To get a usable draft from an assistant without invented prices, services, or credentials, give it a source pack that holds every business fact it may use, require it to mark any claim the pack does not support, and have it save the result as an unpublished draft with a list of open questions. An editor then checks the marked claims, answers the questions, and decides whether to publish. The assistant writes; a person owns the facts.

Assistants fill gaps fluently. Asked for a service page with no delivery area supplied, a model may write one anyway, and it can read as plausibly as everything around it. Google’s people-first content guidance, checked September 27, 2026, asks whether content has “any easily-verified factual errors” and whether the use of automation is clear to visitors where they might wonder how it was made. A source pack and a marking rule help you catch the first before a reader does.

Prepare authoritative source material

A source pack is a short document with only facts you stand behind, each with where it came from. For the fictional garden.example (a synthetic example):

SOURCE PACK: garden.example, "Spring lawn care" service page

S1  Service: lawn aeration and overseeding, March to May.
    Source: current price sheet, owner, 2026-09-20.
S2  Area served: the three towns listed on the Contact page.
    Source: Contact page.
S3  Crew: two-person crews; the owner visits every first job.
    Source: owner, by email.
S4  Booking: online form or phone. No same-day bookings.
    Source: Booking page.

NOT PROVIDED (do not state): prices, guarantees, certifications,
years in business, customer numbers, reviews.

The “not provided” list does real work. It names facts a model might otherwise supply on its own, and tells it those gaps are deliberate.

Separate facts from suggestions

Ask for a draft in which every sentence is one of three kinds: supported by a source line, general advice that makes no claim about the business, or marked for checking. A request that does this:

Write a draft service page from this source pack. In your reply, after the draft and outside it, list the source line (S1, S2…) behind each claim. Any statement about the business that the pack does not support must end with “(VERIFY: what needs confirming)”. Do not state anything from the NOT PROVIDED list. General lawn care advice is fine if it makes no claim about this business. After the draft, list every VERIFY item and every question you would ask the owner.

Put the marker at the end of a sentence rather than at the start of a paragraph, so it stays attached to the claim it questions. Keep paragraph openings plain in general: WP Visibility’s draft tools convert markdown to blocks, and its capability reference notes that a paragraph beginning with ##, >, -, or 1. can change block type on write-back.

Save the draft with the supported tools

With WP Visibility’s Agent module on, the assistant saves the result with create-draft. In 2.10.3 this ability:

• Always creates a draft. It has no status setting and cannot publish. update-draft refuses published posts and never changes post status.
• Converts a narrow markdown dialect into real blocks: headings, paragraphs, lists, quotes, code, and inline bold, italic, code, and links.
• Refuses images, tables, nested lists, and raw HTML, naming each unsupported feature, rather than approximating them.
• Is not idempotent. If a call times out, check the Drafts list before retrying, or you may get two drafts.
• Creates the draft under the connected user, so it shows in the Posts or Pages list with that author.

To revise the draft, the assistant reads it with serialize-content, edits that markdown, and sends the whole body to update-draft. Sending only a changed paragraph replaces the entire body with that paragraph. update-draft also refuses a draft another user has open in the editor.

The plugin’s tools cannot publish, but the connected user’s role can. An Author or Editor credential can publish through WordPress’s own editor or REST API. For drafting-only work on posts, a Contributor is the tightest default role that still works: WordPress’s Roles and Capabilities article, checked September 27, 2026, describes a Contributor as able to write and manage their own posts “but cannot publish them”. Pages are different: the same article’s capability table gives edit_pages to Editors and Administrators but not to Authors or Contributors, so create-draft refuses a page draft from a Contributor or Author. Build a WordPress Assistant Permission Matrix shows how to confirm what a credential can reach.

Drafts are content work, separate from the SEO review queue: with the Autopilot module on and Hold for my review selected, seven write abilities, such as update-post-seo, create-redirect, and update-settings, become proposals, but create-draft and update-draft write the draft directly. The draft status is the review point. See The Assistant Says It Changed Something and the Queue Is Empty for which calls create proposals.

Inspect the saved draft and outstanding questions

Open the draft in the editor and work through it in this order:

1. Search for “VERIFY”. Each marker is a claim to confirm or delete. Remove every marker before publishing; none should reach the live page.
2. Check every sentence about the business against the pack. Unmarked claims that are not in the pack are the dangerous ones: the model stated them without flagging them. Note how many you find, because that tells you whether the marking rule is working with this model and wording.
3. Read the NOT PROVIDED list against the draft. Look especially for prices, guarantees, years in business, and review counts.
4. Answer the open questions with the owner, add the answers to the source pack, and have the assistant revise with update-draft, or edit by hand.
5. Check structure in the editor. Confirm headings and lists came through as blocks and links point where they should.

If the same kind of unmarked claim appears across several drafts, change the pack or the request, not only the draft.

Decide who publishes

Publishing is a person’s decision. The person who publishes should be the one who can vouch for the facts. Keep the source pack with the post’s records so the next editor can see where each fact came from. Consider whether readers would want to know how the page was produced; Google’s guidance above suggests explaining the use of automation where readers might ask.

Checklist:

• Source pack with a source for each fact and a NOT PROVIDED list.
• Request requires VERIFY markers and a question list.
• Draft saved with create-draft; checked for duplicates after any timeout.
• Connected user’s role limited to what drafting needs.
• Every VERIFY resolved and removed; unmarked claims checked against the pack.
• A named person publishes.

For writing the request itself, see Write an SEO Job Brief That an Assistant Can Stop and Verify.