Decision commit
Every Cenelira external review link captures a SHA-256 fingerprint of the schedule's content, delivery settings and verified media at issue time. That fingerprint is the schedule's current reviewVersion. The reviewer's decision is committed inside a transaction that recomputes the fingerprint and whose WHERE clause also matches the current reviewVersion.
If the schedule or the media it sends changed after the link was issued, the fingerprint changed. No decision is saved, the link is reclassified as SUPERSEDED, and the external decision endpoint returns HTTP 410 with a named supersessionReason. This page describes that binding, names the code that enforces it, and maps it to the proof fields you keep when you export.
A reviewer's decision on a Cenelira external review link is bound to the SHA-256 fingerprint of the schedule's content, delivery settings and verified media at the moment the link was issued. The fingerprint is written as rv2: followed by the digest.
It is enforced in the decision transaction. The link carries the captured scheduleVersion. The server recomputes the fingerprint of the post as it is now and compares the two, and the update targets the schedule row with a WHERE clause that also matches the current reviewVersion. If the content, the settings or the selected media changed, the link is marked SUPERSEDED and no decision is saved.
On a shared review link, reviewer identity is self-declared: the reviewer types their own name and email, which are not verified. A saved client contact on a personal link types nothing and is identified only by holding that link. A decision already saved against a matching earlier version stays saved, and this page is about refusing a new decision whose captured version has since changed. An approval is bound to the verified original file, or the verified rendition that publishing selects, together with a versioned ID for the rules that prepare media at publish time. It does not claim that the bytes a platform displays, or the bytes produced by on-the-fly image preparation at publish time, are identical to what the reviewer saw.
Who this is for
Version-bound approval helps most where an approval of the version someone read must be kept apart from a general yes. It helps less when the content rarely changes between approval and publishing.
Failure scenario
A tool without version-bound approval attaches the "yes" to the schedule rather than to the version. The reviewer approves Monday's draft, an operator changes the caption on Tuesday, and on Wednesday the changed draft publishes under Monday's approval, so the reviewer never saw the copy that went out.
reviewVersion as scheduleVersion and writes that value onto the link record.refreshScheduleReviewVersion in src/lib/schedules/reviewVersion.ts recomputes the SHA-256 fingerprint and writes a new reviewVersion onto the schedule row.scheduleVersion; its updateMany also has a WHERE clause that matches the schedule id, the item state, and reviewVersion: item.scheduleVersion. Because the current reviewVersion has changed, no decision is saved.SUPERSEDED with supersessionReason: 'review_version_changed', and the external decision API returns HTTP 410 Gone. The reviewer sees a final card titled "Content changed" with the badge "Superseded".Mechanism
The fingerprint is computed by computeScheduleReviewVersion and written by refreshScheduleReviewVersion in src/lib/schedules/reviewVersion.ts. The review link service carries the captured scheduleVersion on the link record. When the decision is saved, the decision transaction recomputes the fingerprint and refuses to update any row whose current reviewVersion does not equal the captured one. The ScheduleReviewLinkSupersessionReason union has eight values, and the three below are the ones about the version.
When the external decision is saved, the server recomputes the reviewVersion of the post as it is at that moment, from its content, delivery settings and verified media. It does not equal the scheduleVersion captured on the link, so the link is superseded before a decision is recorded.
HTTP 410 link_supersededThe schedule has no reviewVersion when the decision is saved, because the media that publishing would send is not a verified copy, so the link cannot check the captured fingerprint against the current one and the decision is refused.
HTTP 410 link_supersededThe delivery set captured on the link no longer matches the schedule's current scope, because a delivery was added or removed after the link was issued.
HTTP 410 link_supersededProof record
The binding is visible outside the server. Five fields in the 17-field proof record carry the version and the approval state, and they are kept in every export.
versionFingerprint is resolved by collectWorkspaceProofRecords in src/lib/exports/workspaceProofExport.ts as the first non-empty value in this order: the SCHEDULE_HANDOFF_COMPLETED event's reviewVersion, the latest REVIEW_APPROVED or EXTERNAL_REVIEW_APPROVED event's reviewVersion, or the current schedule row's reviewVersion. When none of those sources carry a value, the field is null.
approverIdentity stores the label of who decided, read from the latest approval event. For an internal decision that is the workspace user label, and for a decision on a shared review link it is the self-declared reviewer label captured on the link. For a saved client contact using a personal link it is the contact's name, and for an approval recorded for the client it is the team member who recorded it.
approverSource records how the decision was captured. It is internal for REVIEW_APPROVED events and external_self_declared for EXTERNAL_REVIEW_APPROVED events made on a shared review link. It is client_contact when a saved client contact approved through the personal link issued to them, and team_on_behalf_of_client when a workspace owner or admin recorded that the client approved, in which case the approver named is that team member. The row always shows where the decision came from.
approvalTimestamp records when the decision was committed, taken from the approval event's createdAt. Paired with versionFingerprint, it answers "which version was approved, and when" from a single row.
invalidationReason is derived from a REVIEW_LINK_EXPIRED or REVIEW_LINK_SUPERSEDED event for the same schedule. Expired links write expired; superseded links write the supersession reason recorded on the event. The field is null when no such event exists for the schedule. The signed PDF and the unsigned CSV file both carry these columns. See the proof record schema for all 17 fields.
What this does not claim
Version-bound approval is one check on the way to publishing, and this page says where it stops.
reviewVersion remains committed. The later edit does not erase the prior approval from the proof record.ScheduleReviewVersionPayload, and an edit to a field outside that payload does not supersede a link on its own.FAQ
Anything that changes the schedule's reviewVersion fingerprint: caption, first comment, publishAt, destination, publish mode, connected account, media bundle order, the verified digest of each media file or of the rendition that publishing selects, per-platform settings (for example TikTok privacy level and YouTube upload kind), composition signatures, and the versioned ID of the publish-time media rules. These are the fields in ScheduleReviewVersionPayload that the SHA-256 fingerprint is computed from.
The review page replaces the content with a final card that carries the badge "Superseded" and the title "Content changed", and tells the reviewer that a newer link is needed to review the current version. Below the card the page shows the 8-character link fingerprint, the target account label and the decision timestamp when they were recorded, the supersession reason with underscores replaced by spaces, and a prompt to contact the team that sent the link. The original caption, media and version are no longer shown, so the link becomes a receipt rather than a copy of the content the reviewer first saw.
No. A decision already saved against a matching reviewVersion stays saved. Version-bound approval refuses a new decision whose captured version no longer matches, and the later edit does not erase the earlier approval from the proof record.
In the 17-field proof record, versionFingerprint is resolved by collectWorkspaceProofRecords in src/lib/exports/workspaceProofExport.ts as the first non-empty value across the SCHEDULE_HANDOFF_COMPLETED event's reviewVersion, the latest REVIEW_APPROVED or EXTERNAL_REVIEW_APPROVED event's reviewVersion, or the current schedule row's reviewVersion. approverIdentity, approverSource, and approvalTimestamp are read from the latest approval event. approverSource defaults to internal for REVIEW_APPROVED events and external_self_declared for EXTERNAL_REVIEW_APPROVED events. invalidationReason is derived from a REVIEW_LINK_EXPIRED or REVIEW_LINK_SUPERSEDED event for the same schedule: expired links write 'expired'; superseded links write the supersession reason. The field is null when no such event exists.
This page describes how Cenelira enforces the version binding when a decision is saved, and it makes no claim about what other approval tools store in their own version history. The difference you can test is that the decision transaction refuses to save when the captured fingerprint does not equal the current one.
Last reviewed 2026-04-24
A short checklist for teams whose clients approve by link. It covers what should cancel an approval, how to read the proof fields that record the decision, and what an external reviewer sees on an out-of-date link. Leave an email and we will send it when the checklist is ready.