How does superintelligence work when an AI can not only write a document but also publish, send or delete it? Those operations look similar in a menu, yet they have very different consequences. An editable draft can be changed privately. An email may reach recipients before the sender notices an error. A published notice can be copied even after it is removed. Intelligent assistance requires knowing when an action can be previewed and when it needs a verified, authorised commitment.
The mechanism is reversibility-aware action planning. A system distinguishes proposed content from external effects, checks the intended target and approval, considers likely consequences, and confirms an action’s actual outcome before reporting success. An AI that can generate a fluent publication announcement is not automatically entitled to carry out the publication.
This easy guide follows a fictional school communications desk with sixteen requests and twenty checkable claims. We separate drafting, previewing, sending, publishing and deleting; test the difference between READY and DONE; and show how to use confirmation and receipts responsibly. All cases and operational states are invented, not observations of live accounts or measurements of model safety. “How Superintelligence Works” names this educational series, not a claim that today’s AI has achieved artificial superintelligence.
1. What does reversible mean?
An action is reversible when its effect can be undone under the relevant circumstances. Changing a heading in a local draft is usually easy to reverse. A published article can often be edited or unpublished, but readers may already have downloaded or shared its earlier form.
Reversibility therefore is not simply a yes-or-no property. The same technical operation may be reversible in a software database but difficult to undo in the minds or devices of people who already received the information.
2. Drafting is not sending
A user can ask an assistant to draft an email. The model returns proposed wording. No recipient needs to receive anything. A person can correct the draft before deciding whether to send it.
Sending is a separate external action. It needs a recipient, an appropriate account and authorisation. A system that treats the sentence “Here is your email” as proof that the message was delivered has confused content generation with provider execution.
3. Previewing reduces avoidable mistakes
A preview allows someone to inspect a document or message in a representation close to its intended output. It may reveal a missing attachment, awkward formatting, an incorrect title or accidental inclusion of personal details.
Previewing is not perfect verification. Some problems only become visible after publication, and a rendered preview may not display every delivery or access condition. It remains a useful gate before actions with external consequences.
4. Publication changes the audience
A private draft may be visible only to its author or authorised collaborators. Public publication makes material accessible to a wider audience under the chosen system’s settings. That can be useful and intended, but it changes the information’s exposure.
An AI should know which specific page is to be published, which revision is approved and whether the account permits the action. The fact that a file has finished rendering does not by itself provide publication approval.
5. Deletion is not always full erasure
A deleted file may be recoverable from a trash folder or backup. A shared copy may remain with another person. A public search engine may retain cached snippets for some time. These possibilities depend on the service and should not be assumed to apply identically everywhere.
For this reason, “delete” is often more consequential than “edit draft”. A safe workflow identifies exactly which object will be affected and what recovery or retention constraints apply before executing the change.
6. The difference between intent and authority
A teacher may intend to send a reminder, but the application still needs the authorised sender and verified recipients. A student may ask to delete a shared file without owning it or having rights to remove it.
Intent explains what the person wants. Authority explains whether the system is permitted to do it. Both need to be considered independently. An AI should not invent permissions from confident wording.
7. The fictional Cedar Communications Desk
Imagine Cedar School uses a simple teaching policy for a hypothetical assistant. Requests fall into DRAFT, PREVIEW, SEND, PUBLISH or DELETE. DRAFT and PREVIEW create only proposed material or a local display without external effects. The other three are treated as external actions.
For every external action, three checks must be complete: the exact target is verified, an authorised person has approved this specific action, and an impact review has been completed. The fictional policy does not claim to capture every real legal or school requirement.
8. Freeze the fictional rule
If the request is DRAFT or PREVIEW, the appropriate next step is PREPARE WITHOUT EXTERNAL EFFECT. If the request is SEND, PUBLISH or DELETE and all three gates are YES, the status is READY FOR CONTROLLED ACTION.
If any gate is NO or unknown in our toy record, the action status is HOLD AND VERIFY. Importantly, READY is still not DONE. Completing a permitted operation requires an actual tool call and an independently checked result.
9. Three gates for external effects
- Target verified: the exact message, page or file and destination have been identified.
- Action approval verified: an authorised person approved the specific operation.
- Impact review complete: relevant privacy, audience, retention and possible consequences have been considered.
- PREPARE: local draft or preview, with no external side effect.
- READY: the fictional preconditions for an external operation are satisfied, but no execution is implied.
- HOLD: an external operation is blocked until its unresolved requirements are addressed.
10. Sixteen invented communications requests
The reference packet specifies a requested operation and three gate values for every case. The labels are teaching classifications, not live tool results. All content and recipients are fictitious and no message is actually sent.
The short records use Y for verified YES and N for NO. When the operation is DRAFT or PREVIEW, the three external gates are not required by the frozen policy, though ordinary content safety checks still apply.
- A — DRAFT; target N, approval N, impact N: PREPARE.
- B — PREVIEW; target Y, approval N, impact Y: PREPARE.
- C — SEND; target Y, approval Y, impact Y: READY.
- D — SEND; target N, approval Y, impact Y: HOLD.
- E — PUBLISH; target Y, approval Y, impact Y: READY.
- F — PUBLISH; target Y, approval N, impact Y: HOLD.
- G — DELETE; target Y, approval Y, impact Y: READY.
- H — DELETE; target Y, approval Y, impact N: HOLD.
- I — DRAFT; target Y, approval Y, impact Y: PREPARE.
- J — PREVIEW; target N, approval N, impact N: PREPARE.
- K — SEND; target Y, approval Y, impact N: HOLD.
- L — SEND; target Y, approval Y, impact Y: READY.
- M — PUBLISH; target Y, approval Y, impact N: HOLD.
- N — DELETE; target Y, approval N, impact Y: HOLD.
- O — DRAFT; target N, approval Y, impact N: PREPARE.
- P — PUBLISH; target Y, approval Y, impact Y: READY.
11. Reconcile the results
Five cases produce only a draft or preview: A, B, I, J and O. Five external requests are READY: C, E, G, L and P. Six external requests remain on HOLD: D, F, H, K, M and N.
The totals are 5 + 5 + 6 = 16. Each request reaches one defined next step and none is counted twice. The ledger demonstrates state selection, not a record of sixteen completed real-world actions.
12. Why B does not require send approval
B asks for a preview, not a send. Its approval gate is N, but under the fictional rule it can still prepare a local preview without causing an external side effect.
If the user later asks to send the preview, the request changes class and must pass the external-action checks. An assistant should not quietly upgrade a preview into a delivered notice.
13. Why C is READY rather than SENT
C asks to send a message with a verified target, approved action and completed impact review. The preconditions for attempting the send are satisfied under the toy policy.
However, a send provider may fail, time out or reject the message. The assistant must wait for an actual provider outcome or reliable status record before saying that the message was sent. A planned operation is not proof of its effect.
14. Why D stays on HOLD
D has approval and impact review but lacks a verified target. Sending without knowing the correct destination can expose information or contact the wrong person. The appropriate result is HOLD.
The missing target should be established through reliable context or a specific question. It is not enough to guess a recipient from an old example or a name that happens to appear in a document.
15. Why F stays on HOLD
F is a publication request with a verified target and completed impact review, but the action approval is N. It cannot be treated as publish-ready under the defined rule.
An assistant may explain what would be published or prepare an editorial preview. It cannot use the quality of the text or the apparent urgency of a deadline to invent approval.
16. Why H stays on HOLD
H asks to delete an identified file and has approval, but the impact check has not been completed. Depending on the file and application, deletion may affect records, people, links or retention requirements.
Identifying the object and receiving approval are necessary parts of the toy process, but they are not sufficient when the policy explicitly requires impact review as well.
17. Why G is READY but still needs execution
G is a deletion request with all three gates marked YES. The decision tree can label it READY. That does not mean the assistant has deleted anything.
A separate controlled operation must use the correct file identifier, check access permissions at the provider and confirm the result. The distinction matters for every external operation, especially those with potentially difficult-to-reverse effects.
18. Twenty claims to inspect
The Cedar desk asks a fictional classifier to label statements SUPPORTED, CONTRADICTED or NOT ESTABLISHED using the frozen policy and case records. A claim about readiness may be supported. A claim that a provider actually completed an action requires execution evidence absent from this teaching packet.
The exercise intentionally combines easy drafts with more consequential effects to show why a single generic response is inadequate.
- 01. “A can proceed as a draft.” — SUPPORTED.
- 02. “B is a SEND request.” — CONTRADICTED; B is a preview.
- 03. “C is READY under the fictional preconditions.” — SUPPORTED.
- 04. “C’s message was actually delivered.” — NOT ESTABLISHED.
- 05. “D must stay on HOLD because its target is not verified.” — SUPPORTED.
- 06. “E is READY for a controlled publish attempt.” — SUPPORTED.
- 07. “E’s page is definitely already live.” — NOT ESTABLISHED.
- 08. “F is READY because its content looks finished.” — CONTRADICTED.
- 09. “G is READY for a controlled delete attempt.” — SUPPORTED.
- 10. “H is on HOLD because its impact review is incomplete.” — SUPPORTED.
- 11. “I can proceed as a draft.” — SUPPORTED.
- 12. “J can proceed as a preview.” — SUPPORTED.
- 13. “K stays on HOLD.” — SUPPORTED.
- 14. “L is READY for a controlled send attempt.” — SUPPORTED.
- 15. “M stays on HOLD.” — SUPPORTED.
- 16. “N stays on HOLD.” — SUPPORTED.
- 17. “O is a drafting request.” — SUPPORTED.
- 18. “P is READY for a controlled publication attempt.” — SUPPORTED.
- 19. “Every external request in the packet is READY.” — CONTRADICTED.
- 20. “There are six requests on HOLD.” — SUPPORTED.
19. Check the claim totals
Supported claims are 01, 03, 05, 06, 09, 10, 11, 12, 13, 14, 15, 16, 17, 18 and 20: fifteen. Contradicted claims are 02, 08 and 19: three. Not-established claims are 04 and 07: two. Fifteen plus three plus two equals twenty.
These labels keep a necessary distinction visible: a READY result is a verified precondition under a hypothetical policy, while an actual delivery or publication is a real-world state that would need its own receipt.
20. Why external effects change the risk
A local document draft primarily affects the current workspace. A sent email may notify an entire audience. A public page can be discovered and copied. A deleted file may be difficult to restore depending on backup and retention systems.
The likely impact depends on the specific case. A model should not assume every email is harmless or every file is irreplaceable. It should identify the real audience, data sensitivity and reversibility before carrying out the action.
21. A confirmation should be specific
“Yes, do it” may be unambiguous in a short interaction with one clearly identified action. In a conversation involving several drafts, multiple destinations and different files, confirmation needs an identifiable referent.
An application should tie approval to the intended object and operation rather than interpreting an old or unrelated sentence as perpetual permission. This is particularly important if the content or recipients changed after approval.
22. Preview is a checkpoint, not a guarantee
A preview can expose incorrect headings, spelling, formatting and content. It may not reveal whether the final recipients are correct or whether an email will be filtered into a spam folder.
Therefore a preview should be combined with verification of action parameters and provider outcomes. One visual check cannot replace all operational safeguards.
23. What an action receipt proves
A send provider may report that it accepted a message for delivery. That is not necessarily confirmation that the recipient read it. A publishing platform may report that it saved a page with status publish. That still does not prove every reader can access it under every network condition.
A careful assistant describes the outcome at the level actually confirmed: submitted, accepted, published in the content system, delivered according to provider records or read according to a suitable signal. These states should not be collapsed into one word.
24. Timeouts are not proof of failure
Suppose an agent attempts to send a message and the network times out. It might not know whether the provider received the request. Blindly retrying may cause a duplicate message if the original operation succeeded.
Some applications support idempotency keys or other mechanisms for safe retries. When the outcome is uncertain, the system should reconcile provider state rather than announce failure or success without evidence.
25. Compensation is not the same as undoing
An agent may publish an incorrect notice and later post a correction. That compensating action can reduce confusion, but it does not erase every copy of the original notice. A sent follow-up email likewise does not retract the first message from all recipients.
This is why reversibility-aware planning evaluates consequences before the initial external action. Recovery procedures remain valuable, but they do not make every operation harmless.
26. Why deletion deserves source review
A request such as “Delete old drafts” may describe several objects. The assistant needs to know which files qualify as old and whether any are protected by a retention rule. A vague category is not a verified target.
Even if the user is the owner, the system should obey the application’s actual access and safety checks. It should not promise permanent erasure if the provider has backups or retention features that the assistant cannot control.
27. Publication does not confer factual truth
Publishing an article changes its availability, not automatically its correctness. A fluent AI-generated article still needs accurate explanations, verified sources and appropriate review. A WordPress status of publish is an operational state, not a certification of scientific reliability.
The two verification streams should be separate: is the content factually and editorially sound, and did the platform actually perform the publication action? Both matter for a trustworthy workflow.
28. An invented baseline error pattern
Imagine a fictional assistant that treats every drafted message as sent and every READY publication as live. It also ignores a missing target and attempts an unnecessary deletion before checking the file’s importance.
These are invented failure scenarios, not evidence about a deployed model. Their common flaw is collapsing proposal, approval, attempted execution and verified outcome into one undifferentiated notion of done.
29. The repaired workflow
First identify the requested operation. Second verify the exact object and destination. Third confirm authority and impact checks. Fourth prepare a preview where useful. Fifth perform only the authorised tool action. Sixth inspect the provider result and current state. Seventh report exactly what was confirmed.
This workflow is not a universal sequence for every trivial task. A harmless draft may proceed immediately. The strength and number of checks should match the consequences while always respecting required permissions.
30. A transfer exercise with a school newsletter
A teacher asks an assistant to prepare the monthly newsletter in an editable document. The assistant can draft it. The teacher then asks to see the final layout; the assistant can preview it. The teacher later approves a specific final version for publication.
Only after the publication target, permissions and review conditions are satisfied should the platform be asked to publish. The assistant should then inspect the result rather than simply saying the newsletter is live because an approval was given.
31. A transfer exercise with a parent reminder
A parent asks an AI to write a message about an upcoming homework deadline. That is drafting. If the parent later requests sending the message to a named teacher, the system must use an authorised messaging account and a verified destination.
An AI that does not have access to an appropriate send function can provide the finished text without pretending it delivered the message. The limitation is more honest than an invented completion claim.
32. How to build a safe demonstration
Use a sandbox account and harmless sample documents for testing. Prepare cases with verified and unverified targets, missing approvals, changed destinations, unclear outcomes and repeated requests. Label the expected next step before running the model.
Then check whether external tool permissions prevent disallowed operations even if the model proposes them. A safe-looking sentence is not enough when the execution layer can make changes.
33. What to record for an audit
Keep the exact object ID, requested operation, approval, source version, impact review result, tool invocation and returned status. If an action was retried, record the request identity and reconciliation outcome.
Such a record lets reviewers distinguish content creation from approval, an attempted operation from a successful one, and success at the provider from later delivery or human use.
34. Why this matters as AI becomes more capable
A system that can only draft text has a narrower impact than one that can edit repositories, send messages, manage finances or change published records. The need for precise authority and verified effects increases as the number and consequence of available actions grow.
Useful agent design therefore combines natural-language understanding with permission checks, isolated tools, previews, recoverable stages and post-action verification. Capability does not eliminate the need for operational boundaries.
Frequently asked questions
Is a draft a completed send? No. A draft is proposed content; sending needs a separate real action.
Can a published page be fully undone? It may be editable or removable, but external copies and earlier readership may persist.
Does READY mean DONE? No. READY means defined preconditions are met; DONE requires verified execution.
Why verify the target? A wrong recipient, file or page can make an otherwise authorised operation harmful.
Can an AI delete a file just because it was asked? It needs the appropriate access, target identification and applicable approval or retention checks.
What if a tool times out? The outcome may be unknown; reconcile provider state before assuming success or retrying blindly.
Does a platform’s published status prove the article is accurate? No. Editorial accuracy and platform state are separate checks.
The central lesson
Not every AI action has the same consequences. Drafting, previewing, sending, publishing and deleting occupy different positions on a spectrum of external effects and practical reversibility. A reliable system keeps those states separate and applies the right level of verification.
The habit is to ask three questions before acting: what exactly will change, who has authorised it and how will we know it happened? Those questions turn an AI’s ability to propose actions into a safer, more accountable process.
Connected learning and source references
- How Super Intelligence Works — main educational curriculum.
- Quoted Text and Instructions — why source content is not operational permission.
- Order and Dependencies — plans versus confirmed actions.
- Feedback Loops — repairs, regressions and receipts.
- Agent Sagas — technical compensation and partial-failure recovery.
- OWASP: LLM Prompt Injection Prevention Cheat Sheet — permission boundaries and least privilege.
- NIST AI Risk Management Framework — oversight, evaluation and action risk.