Autopilot is an attractive demo.
Connect an account. Choose a cadence. Let the system find topics, write posts, generate images, schedule them, and learn from engagement. The empty calendar fills itself.
For an executive, the same sequence compresses several different authorities into one button.
The authority to inspect private material.
The authority to decide what is true.
The authority to speak in the person's name.
The authority to choose a time and destination.
The authority to transmit the content to a platform.
The authority to interpret the response.
We do not believe a useful product should acquire all of those powers merely because automation makes the demo look complete.
R009-M01 · MECHANISM — Drafting, verification, approval, scheduling, and delivery are different decisions. Convenience does not make them interchangeable.
A draft is a proposal
The first refusal is semantic.
A draft is not “content ready to go.” It is a proposed version that can be reviewed.
That proposal should identify its sources, separate the executive's account from external research, tag material claims, and state limits. It should have a stable version and hash so the reviewer knows what object is in front of them.
If the executive changes one sentence, the approved object—if one existed—no longer exists in the same form. The new bytes need a new decision.
Crafted Virtue's current scheduling boundary binds approval to an exact draft ID and rejects a stale approved version. [R009-C01 · INTERNAL GROUND TRUTH · DUAL-VERIFIED]
The claim remains pending until a role-distinct verification reopens the current migration, tests, and release evidence. The design principle is non-negotiable: approval belongs to the text that was seen.
Verification is not approval
A claim can be well sourced and still be inappropriate to publish.
It may disclose confidential information. It may create legal or regulatory risk. It may misstate the executive's view. It may be strategically premature. It may be technically correct and badly framed.
Likewise, approval cannot turn an unsupported claim into truth.
The founder can decide, “Yes, this is my final wording.” The evidence system can still say, “This material claim is held.” Both decisions matter.
The workflow therefore has separate states:
Research asks whether support exists.
Verification asks whether the exact claim matches that support.
Quality review asks whether the draft preserves voice, limits, and required controls.
Human approval asks whether the named person authorises this exact version.
Publication asks whether a current approved object may be delivered to an exact destination.
No stage is a substitute for another.
R009-M02 · MECHANISM — Human-in-the-loop is not a person somewhere in the process. It is a current human decision at the point where speech becomes attributable.
The database is part of the promise
A policy can say “nothing publishes without approval” while the system permits an engineer, scheduler, or provider adapter to bypass the policy.
That is not an approval gate. It is documentation.
The invariant must live where the prohibited transition occurs.
Before a schedule is accepted, the database can require the exact draft, the applicable approval chain, current claim state, and destination. Before delivery, the worker can recheck the same coordinates and refuse stale state. An adapter can receive only the bounded request required for its task, without approval authority in the payload.
Current scheduling tests reject an unapproved latest version and a stale approved version, and cover the normal due-scan path. They do not, by themselves, prove every later delivery-time negative. [R009-C02 · INTERNAL GROUND TRUTH · DUAL-VERIFIED]
The significance is not that tests make errors impossible. It is that the safety promise has executable form. A future change has to break a constraint or a test rather than merely contradict a paragraph nobody reads.
Derivatives multiply risk
An approved article becomes a LinkedIn post, an X thread, a chart, a square video, a vertical video, and a YouTube script.
It is tempting to let the approval travel with the source.
The derivative may have changed the claim.
A 1,700-word article can explain that a study used one company and detected no promotion penalty under a particular hybrid-work design. A 60-second script can reduce the line to “remote work does not hurt promotion.” The source is the same. The claim is not.
A chart can crop the baseline. A caption can lose the denominator. An image can imply that a generated scene is documentary evidence. A title can convert a modeled range into an observed fact.
The product therefore treats each derivative as a new object with lineage, not inherited permission.
Crafted Virtue's existing repurposing boundary freezes one approved blog source, creates independent derivatives, forces fresh Truth Filter and QA, and creates no automatic schedule or provider intent. [R009-C03 · INTERNAL GROUND TRUTH · DUAL-VERIFIED]
This is slower than automatic syndication. It is also the only way the word “approved” keeps a stable meaning.
Scheduling is operational intent
Choosing Thursday at 08:30 is not a content decision.
It is a delivery preference that depends on a still-valid content decision.
Schedules should therefore reference approved content rather than contain a second editable copy. If the source changes, the schedule becomes stale. If the destination changes, the platform-specific checks run again. If the approval expires under a policy, the schedule cannot silently revive it.
The same separation matters for media.
Text approval allows final rendering to begin. It does not approve narration. Narration approval does not approve the final visual edit. A final-media approval for 16:9 does not approve the vertical crop. Exporting a YouTube file does not authorise upload.
These distinctions can feel bureaucratic until the first disputed sentence appears in three channels and nobody knows which version the executive actually saw.
R009-M03 · MECHANISM — The cost of separate approvals is visible before publication. The cost of ambiguous authority appears after publication, when correction is harder.
Why social remains draft-only
Crafted Virtue has an isolated internal social system, but the application boundary remains draft-only. It can prepare exact approved internal marketing artifacts for a Postiz draft. It cannot schedule or publish them through that adapter. Account connection and live harmless acceptance remain separate owner-controlled work.
YouTube is separate again. Review packages can contain a 16:9 export candidate, title, description, chapters, captions, thumbnail, and evidence manifest. Upload remains disabled until the account/API boundary and the exact media approval close.
This is deliberate asymmetry.
Different platforms create different risks, terms, formats, credentials, and failure modes. One successful connection should not become authority everywhere.
R009-C04 · INTERNAL GROUND TRUTH · DUAL-VERIFIED — The current internal marketing port exposes draft creation/deletion but no scheduling or publishing operation.
The product should make refusal legible
Safety cannot be a blank button.
When a job is held, the reviewer should see why.
The claim lacks independent corroboration.
The article changed after approval.
The video script strengthened a sentence.
The narration receipt belongs to another hash.
The final render has not passed captions or safe-area QA.
The social account has not completed acceptance.
The destination is unavailable.
The Control Center should present these as exact coordinates, not one red “something went wrong” state. The user needs to know whether to change the content, supply evidence, record a decision, reconnect a provider, or wait for a separate gate.
The refusal is part of the product.
What automation is still for
Rejecting autopilot does not mean rejecting automation.
Automation can inventory public sources, propose research questions, detect claim-like sentences, fetch authorised evidence, verify locators mechanically, compare versions, generate layouts, recompose ratios, burn captions, run contrast checks, validate platform limits, and prepare delivery candidates.
It can reduce the amount of human time spent on mechanical work.
What it cannot do is turn that efficiency into authority.
The person must still decide whether the words are theirs. The evidence gate must still decide whether the material claims are releasable. The destination adapter must still receive a current, bounded request.
This is the product thesis in one sentence:
Automate the work around judgment. Do not automate away the owner of the judgment.
Honest limits
No approval architecture can guarantee factual accuracy, good judgment, platform delivery, audience reception, or business outcomes. A human can approve a misleading argument. A released source can later be corrected. A database constraint can contain a defect. A provider can fail after accepting a request.
Separate gates also create cost. Reviews take time. Versions proliferate. A strict hold can delay useful work. The system has to make those costs manageable without hiding them.
The internal-ground-truth claims in this draft remain pending role-distinct verification against current code, tests, and runtime evidence. The presence of an architecture document or a passing test alone is not enough.
The promise is not “nothing can go wrong.”
The promise is that publication is an attributable transition. The system records what was approved, what evidence supported it, what destination received it, and where the process refused to proceed.
Our product refuses to post on its own because the post belongs to someone.
The decision should too.