Content approval without the email chain

Content approval is a state a version can be in, not a conversation about a draft. The email chain exists because the file lives in one place and the decision in another, tied together by a subject line that slowly stops matching the attachment. Put the decision next to the version and most of the thread disappears.

What does "approved" mean for each kind of content?

Approved means the version may now do something it could not do before. Write that sentence four times and it stops being trivial, because each artifact unlocks a different action for a different audience.

A price list becomes effective: from a stated date it is the list the shop, the quote template and the sales team read, and the previous list retires the same day. A product description may go live and travel through the catalogue export that feeds every channel. A social post may be published at its slot — approval that lands after the slot is not a late post, it is no post. A contract may be sent for signature, after which it is an obligation rather than content.

Artifact	Who approves	What "approved" unlocks
Price list	Commercial owner, with finance	Publication from an effective date; the old list retires
Product description	Merchandiser, with the brand owner	The page goes live and the catalogue export carries it
Social post	Whoever owns the account	The scheduler may publish it in its slot
Contract	Legal, then the signatory	Sending for signature; the countersigned copy files itself

If you cannot name what the approval unlocks, you are describing a queue, not a decision.

Why does the comment belong to the version, not the inbox?

A comment written in an email is addressed to the draft that existed when the reviewer opened it. By the time anyone reads it the file has moved, so a note about the second paragraph points at a paragraph that has been rewritten or deleted. Nobody is lying, and nobody can act on it.

Attach the comment to the version and three things become possible: you can tell whether the current draft has actually been read, you can list unresolved comments beside the text that carries them, and you can close a version, open the next and keep the history.

A comment on a version also has to name the passage: "this is wrong" survives in an inbox for weeks, while "the delivery term in clause four is wrong" is either true or false.

What happens when the approver is on holiday?

Nothing, if the approval belongs to a role rather than a person. The failure is rarely the absence — it is discovering it on the morning the thing was due to ship.

Model it as three facts: the role owns the decision, a named person holds the role with a substitute who has the same authority rather than a colleague who promises to check later, and the delegation carries dates, so the record shows who approved and in what capacity.

Then decide what happens when nobody answers: escalate to a second role, or let the request expire as an explicit "not approved". What is not honest is a request that sits until someone publishes the draft because the deadline arrived: approval by silence, teaching the team the step is decorative.

What must a rejection carry?

A rejection without a condition is a request to guess, and guessing is what the next version will be.

Four fields make it actionable: the version, the passage, the condition that would make the version acceptable, and who owns the next action. "The tone is off" is not a condition. "Remove the comparison with the previous model; the claim is not supportable" is.

Keep rejected and changes-requested apart. A rejection ends the version and sends the work back to be rebuilt. Changes requested keeps it open and returns it with a list. Collapse the two and authors cannot tell whether they are fixing or starting over, while approvers reject because the other button said yes.

What will an auditor or a client ask for later?

Not "was there an email". The question is who approved this, in what capacity, on which version, and what exactly they saw.

Five things must be kept together: an immutable version, a named account with a role, a timestamp, the decision and its comment, and the artifact as it looked at that moment. Without the immutable version, the answer to "what was in force on that date" is a printout somebody kept in a drawer.

A shared login ruins that chain, because it turns an approval into a claim about a mailbox. The OWASP authentication guidance treats shared and generic accounts as a defect for the same reason: an action that cannot be attributed to a person is not evidence of a decision.

How do you set this up?

1. List the artifacts, not the departments: price list, description, post, contract — whatever the business publishes.
2. Write "approved means…" for each, plus the action it unlocks. If you cannot finish the sentence, that artifact has no approval step, only a habit.
3. Name the role, the holder and the substitute, with dates on the delegation.
4. Define what a version is. Minting a new one for a typo makes the trail unreadable.
5. Design the rejection form before the approval button. The rejection is where work restarts.
6. Store the rendered artifact at approval, not a link to a page that changes.
7. Pilot where a mistake is cheapest, then check the approver can answer "what did I approve" a month later without their mail.

The integration matters for one reason: publication can only start from an approved version, so state and action cannot drift apart.

Where this goes wrong

• Approval is a button with no version behind it. The record says someone clicked, not what they saw.
• The thread becomes the archive. Nobody can reconstruct it, and whoever held it has left.
• Approval recorded on the published copy. That is a confirmation, not a permission.
• Silent expiry read as consent. An unanswered request becomes approved because the draft went out anyway.
• "Approved" means something different on each side. Marketing hears "legally clear", legal hears "final wording".

What this does not cover

It does not say how long to keep approved versions — that depends on your sector and your accountant. Nor does it judge whether the copy is any good; an approval step records a decision, it does not improve one. And it assumes the approver will use the tool: where a client refuses to log in, the honest design is a single-record link with an expiry, not a parallel email process that becomes the real one.

We build approval as a property of the version: one record per decision, a named approver with a substitute, and a trail that answers "what was in force on that date" without anyone searching a mailbox.