Why Vuti separates draft, review, scheduled, and published

the first useful vuti feature was not better copy. it was knowing what state a post was actually in.

that sounds small until one calendar is carrying posts for five networks. a draft can have copy but no approved image. a reviewed post can still need a date. a scheduled post should not silently return to editing. a published post is evidence, not an intention.

so i treat the workflow as four distinct product states:

draft → review → scheduled → published

draft means the system is still preparing the work

a draft is allowed to be incomplete. vuti can assemble an idea, adapt it for a network, use the brand voice, and pull verified details from the catalog. none of that makes the post ready to represent the person or business.

this is also where grounding matters. if a metric, customer result, product capability, or business detail does not exist in the workspace, the draft should not confidently invent it. fluent text is not the same thing as accurate text.

review is a real boundary

review is where a person decides whether the post is true, useful, and on-brand.

i do not see this as friction to remove. it is the control surface for the person whose name is attached to the post. the useful question is not “can the AI publish by itself?” it is “can the system prepare enough good work that approval is fast and informed?”

that changes how i build the product. previews need to match the destination. assets need to be visible. edits need to stay attached to the correct platform version. approval needs to be an explicit decision.

scheduled is a commitment

once a post is approved and has a publishing time, it becomes scheduled. the calendar should make that commitment obvious: which network, which account, which version, and when.

this is where ordinary integration work matters more than AI vocabulary. time zones, account connections, platform-specific formats, and failures at API boundaries can all turn good content into a bad product experience.

published is what actually happened

published should only mean the network accepted the post. it should not mean “we tried” or “the calendar time passed.”

that distinction creates a clean record of what went live. it also gives future planning something real to learn from: the exact post, platform, timing, and eventual performance.

why this matters for AI products

AI features often look impressive in a demo because the demo ends when text appears. production starts after that moment.

the product still has to preserve intent across editing, approval, scheduling, platform adaptation, authentication, and publishing. each boundary needs a state the user can understand.

for vuti, “human in the loop” is not a disclaimer below the generate button. it is the shape of the workflow. AI prepares the work; a person approves what represents them; the system keeps the states honest.

that is less magical than autonomous content. it is also much closer to the product i want running my own accounts.