Approval workflows
An approval is only worth something if the thing approved is the thing that goes out.
This describes a design, not a running service
The problem
Approvals usually live outside the tool that publishes. A screenshot goes to a client, the client replies yes, and then the copy changes. The approval now refers to a draft nobody has, and the tool has no idea, so it publishes whatever it was last given.
How the product is designed
- An approval is attached to the exact content that was reviewed. Editing an approved draft invalidates the approval and says which field changed, rather than quietly carrying the old decision forward.
- A reviewer can approve, request changes or reject, and a comment is required for anything other than approval, so the author is never left guessing what to fix.
- The rule lives in the shared application layer, so the web app, the REST API, the MCP server, the CLI and webhooks all obey it. No surface has a shortcut around review.
What is actually built
The approval states, the review surface, the re-approval rules and the audit events behind them are built. What is not built is the last step, because no connector has passed its definition of done, so an approved post has nowhere to go yet.
Found something wrong on this page
Contact channels will be published here before general availability. No legal or support inbox is operating during this preview.