Publishing the Version That Was Reviewed

1. Approval has to identify an object

A familiar publishing workflow stores a post and an approval flag. An editor reviews the post, sets the flag, and another process makes the post public. The workflow is safe only if the content cannot change between those steps, or if every relevant change invalidates the flag reliably.

That condition becomes difficult when a release contains several reading levels, tags, charts, captions, and media. A body revision can remain unchanged while an image or chart changes underneath it. The editorial interface may show the same title and slug even though the reader will receive a different artifact.

The engineering question is whether approval describes a mutable record or an identifiable release. This paper argues for the latter. The release boundary should ask whether the exact proposed public payload has an applicable approval, rather than whether the post has ever been approved.

2. Evidence and scope

The inspected tuckerl.ee implementation defines a release review with a payload digest, an explicit decision, required privacy checks, and structured findings. Its review contract rejects an approval when findings remain or a required check fails. The accompanying database migration defines the payload construction and publication enforcement. These are source-level observations; they do not establish how accurately a reviewer identifies sensitive content.

The application also represents a canonical article and authored reading-depth variants, together with referenced charts and media. The source inspection supports treating the release as a bundle. It does not justify extending a blog release guarantee to every page on the site: the file-backed white-paper loader has a separate validation path.

The analysis uses a synthetic editing sequence to reason about stale approval, then sets out validation cases for the implementation. It is not a claim that the hypothetical race occurred in production. All system descriptions are at the architectural level; the mechanism can be evaluated without publishing private content or infrastructure details.

3. A release manifest crosses the review boundary

The manifest is the finite description of what is being approved. At minimum, it must cover the public article bodies, relevant metadata, and the content identities of referenced resources. It should also declare a manifest format version so that a future change in canonicalization cannot silently reinterpret an earlier approval.

1. 1. AssembleBuild the public release manifest.
2. 2. ReviewAttach a decision to its digest.
3. 3. CompareRecompute at publication time.
4. 4. ReleasePublish only a matching approval.

A digest is useful because it compactly identifies a canonical representation. It is not a quality score, a signature by itself, or proof that the underlying content is safe. The review record provides the decision; access controls determine who may create that decision; the comparison determines whether it still applies.

Canonicalization deserves explicit tests. Semantically identical inputs may have different object ordering or whitespace. Conversely, a serializer that omits a meaningful field can make two different public payloads appear equivalent. The safe engineering question is not simply whether hashing works, but whether the manifest covers the complete public meaning being approved.

For resource references, a mutable identifier is insufficient. If an article points to an image record and its bytes can be replaced, the release must account for the changed bytes and any public caption or alternative text. The same principle applies to chart data, axis labels, and units.

4. Worked example: an image changes after review

Suppose an editor reviews a release with a canonical body, five depth variants, and an illustrative chart. The review approves manifest A. Before publication, a second editor replaces the chart and changes its caption. The post identifier remains the same.

A post-level approval flag remains true unless the second edit triggers perfect invalidation across every affected field. Under the proposed contract, the publisher constructs manifest B and compares its digest with the approved digest. If the chart and caption are included correctly, the mismatch blocks release and requests review of B.

Keeping A's review is useful: it records a legitimate decision about an earlier artifact. Deleting the approval would lose that history. The important distinction is applicability, not whether an approval record exists.

The publication check must also be protected from concurrent writes. If a publisher checks B, another writer creates C, and the publisher then exposes “the current post,” the race has merely moved. The manifest comparison and the publication transition need a shared transactional boundary, or publication must reference an immutable release object. Database isolation has specific semantics and retry obligations that must be tested against the chosen implementation. [1]

5. Content safety and editorial truth are different checks

The application constrains public MDX by rejecting executable expressions, imports, unsafe URL schemes, and selected dangerous markup. That is a rendering boundary. It reduces the accepted language; it does not assess whether the article's argument is correct or whether a harmless-looking sentence discloses a private fact.

Privacy review has a different subject: identifying sensitive material in the exact public payload. Editorial review asks whether claims are supported, examples are labeled, and conclusions follow. Accessibility review asks whether the same payload remains understandable through alternative text, chart descriptions, and usable structure. A release can pass one category and fail another.

These distinctions should appear in the internal review model. A single “safe” label conceals what was actually checked. The public reader usually needs provenance, dates, limitations, and references rather than a description of internal gate mechanics.

W3C PROV supplies a useful way to describe a release artifact, the activity that generated it, and the agent associated with a review. It does not prescribe the application's approval policy. [2] This paper's recommendation is to retain those relationships privately and expose only the attribution that helps readers assess the published work.

6. Alternatives and operating costs

A Boolean approval flag is easy to understand and cheap to operate. It can be adequate when an article is frozen for review and published as a single immutable object. It becomes fragile as multiple independently mutable resources enter the release.

Approving a body revision improves traceability, but leaves a gap if the public result includes resources outside that revision. Extending the revision to include immutable references for every public dependency can close that gap; at that point it performs much of the work of a release manifest.

Exact-payload approval has costs. Small changes may require another review. Reviewers need a useful difference view so a corrected typo does not require rereading every unrelated resource. Canonicalization changes require deliberate versioning. An unavailable reviewer can delay publication even when the change is small.

The solution is to improve the review experience and define explicit review policies, not to silently reuse an inapplicable approval. For example, a tool can show the exact fields that changed while still recording a new decision for the resulting manifest. Whether that abbreviated review is appropriate remains an editorial policy choice.

7. Evaluation and limits

A meaningful validation matrix changes each public field after approval and attempts publication. Include titles, tags, every reading level, captions, alternative text, chart definitions, and resource bytes. Each covered change must either generate a different manifest or be demonstrably excluded from public output.

Concurrency testing should interleave edits and publication around the comparison point. The acceptable outcomes are publication of the approved immutable release or rejection of the stale candidate. Publication of an unreviewed composite is a failure, even if each component once appeared in a separately reviewed draft.

Repeat requests should have defined behavior. A retried review submission must not create contradictory decisions for the same request identity. A retried publish operation should return the existing result or an explicit conflict rather than accidentally changing the release subject.

These tests evaluate enforcement. They do not measure reviewer recall, factual correctness, or whether all sensitive information has been detected. A digest faithfully binds a mistaken approval just as it binds a correct one. The model therefore needs both strong transactional enforcement and an editorial process capable of making sound decisions.

8. Conclusion

A publishing system can make review durable only if it preserves what was reviewed. Binding approval to a complete public release manifest closes the gap between a familiar post identifier and a changing set of reader-visible artifacts. The essential test is straightforward: change the candidate after review and demonstrate that the old approval cannot publish it.

For tuckerl.ee, this makes release identity a useful organizing principle for bodies, reading levels, and resources. It also makes the remaining limitation clear: technical enforcement can ensure that an approval applies, while the quality of that approval still depends on evidence and editorial judgment.

References

1. PostgreSQL Global Development Group. Transaction Isolation. Transaction behavior relevant to the race in Section 4; consulted September 6, 2026.
2. W3C. PROV-Overview, 2013. Provenance relationships discussed in Section 5.