Before You Create Another Draft, Check What Already Exists

During one recent AI-assisted publishing session, the draft list was checked before the published list.

A new draft was started for an article that was already public.

The platform had not lost the article. The article had not failed to publish. The observation was incomplete: one state class had been inspected, while another relevant state class had not.

That small mistake suggests a practical question for anyone using an AI agent with a CMS:

Before creating something, how do you establish that it does not already exist?

One publication, several state classes

A publishing dashboard rarely has one complete list called “everything.” Content may be separated into:

• drafts
• scheduled posts
• published posts
• archived posts
• submissions

Seeing nothing in one list does not establish absence from the others.

In this case, the dashboard showed zero drafts after cleanup and two published articles. The article in question was already publicly accessible. The extra draft was the duplicate.

The error was not “the article is missing.”

The error was:

We had not yet looked from every position required to support that conclusion.

A small preflight before creating content

Before an agent creates another article, page, release, or asset, I now want it to run this bounded check.

1. Identify the intended artifact

Write down the identity you expect:

• working title
• intended slug or URL
• publication or account
• substantive topic
• expected state

A title match alone may be insufficient. Titles can change. Two different titles can also contain substantially the same article.

2. Check every relevant state class

For a publishing system, that usually means checking at least:

• Drafts
• Published
• Scheduled, if the platform supports it
• Archived, when restoration is possible

The goal is not unlimited searching. It is a fixed inventory check over the state classes that can contain the artifact.

3. Open the strongest candidate

If an item may match, inspect enough to distinguish it:

• Does the title match?
• Does the slug match?
• Does the substantive content match?
• Is there a public URL?
• Is the public page actually reachable?

Do not create a replacement merely because the first list you opened was empty.

4. Classify the result

A small state vocabulary helps:

MISSING
No matching draft or public artifact was found within the checked scope.

DRAFT_ONLY
A matching draft exists, but public availability is not established.

PUBLISHED_ONLY
The public artifact exists; a new draft is unnecessary unless a revision is intended.

DUPLICATE
Equivalent draft and published artifacts both exist without a deliberate revision relationship.

UNKNOWN
The available views are insufficient to distinguish the state.

5. Take the minimum correcting action

The classification determines the next action:

• MISSING may justify creating a draft.
• DRAFT_ONLY may justify continuing the existing draft.
• PUBLISHED_ONLY may justify linking, observing, or promoting the existing article.
• DUPLICATE may justify removing the duplicate after confirming the exact target.
• UNKNOWN should stop creation until the missing observation is available.

What happened in this case

The sequence was:

Draft inspected
→ published article overlooked
→ duplicate draft created
→ owner correction received
→ Drafts and Published rechecked
→ public article opened and compared
→ duplicate draft deleted
→ Drafts 0 / Published 2 verified

This established one thing under one set of conditions: checking both inventory classes exposed the mistaken assumption and allowed the duplicate to be removed while preserving the public article.

It did not establish that this procedure prevents every duplicate, works identically on every CMS, or proves that two artifacts are semantically equivalent in all cases.

Those remain outside the evidence.

The correction is part of the loop

The most useful part of the event was not the deletion itself. It was the relationship between an assertion and a correction.

The agent concluded that an article still needed to be prepared. The owner contradicted that conclusion. The contradiction triggered a broader observation. That observation changed the model of the situation, and the next action became smaller: delete one duplicate instead of publishing another copy.

That is a compact world loop:

Act
→ receive correction
→ re-observe
→ distinguish states
→ update the model
→ apply the minimum correction
→ verify what remained unchanged

An owner correction is real evidence about the workflow. It is not evidence of market demand, reader trust, or product fit. Those require different observations.

Before your next AI-assisted publish

Ask the agent:

Which state classes did you check before deciding this artifact was missing?

If the answer is only “Drafts,” the next action may not be “create.”

It may be “look once more, from the other relevant position.”

This follows the same claim-scope distinction described in Your AI Says It’s Done. What Has Actually Been Proven?.

A free Claim Scope Review Checklist is also available for checking whether a technical conclusion stays inside its evidence.

What state classes does your publishing or release workflow check before it creates something new?