Keeping a release tied to the reviewed draft

Keep writing without changing the public page#

A review is about a particular version of the text. If another edit arrives before publication, publishing whatever is latest would break that connection. The content service therefore keeps a document's draft pointer separate from the revision readers can see.

Each save inserts canonical JSON and its SHA-256 hash under a new revision number. Saving moves only the draft pointer. Database triggers reject changes and deletions to stored revisions, so later edits cannot rewrite the content that was reviewed.

Check the version when it matters#

A publish request carries the expected draft revision and content hash. Our release workflow also supplies the expected publication pointer. The service compares these inside the mutation transaction, so a conflicting edit, publication or withdrawal stops this release before the public pointer changes. The publication-state guard is optional in the service API; callers must supply it to get that additional check.

The pointer change, audit entry and retry receipt commit together. An identical request with the same actor-scoped key returns its earlier result; reusing that key with different arguments is rejected. Publisher identity, the local publishing gate and explicit confirmation are required independently.

Preserve the surrounding record#

Restoring an old revision creates a new draft. The old revision remains unchanged, and the restored text still goes through the normal publication checks.

Links are part of the release too. A note cannot reference an unpublished build, and a build cannot be withdrawn while published notes still refer to it. These checks let saving, restoring and publishing remain distinct operations with consequences the service can enforce.