A practical review contract for visual drafts

A small team creating images for a public-facing project often discovers that the hardest part is not choosing a file format. The difficult part is knowing which draft was reviewed, which changes were requested, and whether the approved version is the one that ultimately appears. A lightweight review contract can make those decisions visible without requiring a large project-management system. This post proposes one such contract for a hypothetical illustration workflow; it is not a description of a deployed governance protocol.

I am associated with Caricature Maker at https://caricature-maker.online/, a web-based project for playful portraits, and AI assistance helped prepare this discussion. The site describes one free 1K generation, with paid options for additional use. Product details, privacy information, and prices may change. The engineering suggestions below are general ideas and do not assert that the project implements every control described here.

Begin with a bounded purpose

A request should explain where the image will be used and who can approve it. A private thank-you card and a public launch announcement differ in audience and duration. Store the intended destination as a distinct field rather than burying it in a long design note. The field can use ordinary language, such as "internal slide" or "event page," as long as the team understands what it means.

If a real person is represented, the workflow should also record who is responsible for seeking permission. A software field cannot itself prove consent, and a team should not interpret a check mark as a universal legal authorization. Its practical value is that it reminds the requester to consider the issue before a source photo is passed to a designer or service. A later change from private to public use deserves a new review.

Define the unit of review

A reviewable unit is a particular image and the surrounding text that will accompany it. If the same image is used with different captions, each caption can change the meaning. An illustration presented as a decorative caricature should not be mistaken for a photograph documenting an actual event. The review record should therefore reference both the image version and the intended context.

A simple version identifier can be an opaque string assigned when a draft is created. It should not expose a person's name or private source filename in a public URL. Store a human-readable label separately so reviewers can distinguish "first sketch" from "caption revised." The label is helpful for conversation, but the stable identifier is what lets a system bind an approval to the correct version.

Separate source and derivative files

A source photograph may contain more information than the final illustration needs. Before upload, provide a preview so the user can remove unrelated people, badges, or background documents. Cropping can reduce unnecessary detail but does not guarantee anonymity. Describe whether the original or the cropped version is actually sent to the server, and avoid making privacy promises that the implementation cannot support.

Derived files should have their own lifecycle. A thumbnail, preview, exported image, and backup copy may be stored in different places. If a deletion request arrives, the system needs an inventory of those locations. The retention interval should be documented accurately for each processor and should not be inferred from an interface label. Logs and error reports should avoid embedding source images or sensitive prompt text by default.

Model state changes explicitly

A straightforward state model might include draft, review_requested, changes_requested, approved, exported, and withdrawn. Each state should describe a business condition rather than a loading spinner. A transition from draft to review requested means the content is ready for someone to inspect; it does not mean the content is approved. Likewise, exporting a file should not automatically authorize a new public destination.

Record the actor and the version involved in a transition. When the content changes after approval, create a new version or otherwise mark the prior approval as no longer applicable. A reviewer can then see that the current file differs from the one they accepted. If only a formatting change is made, the product team can define a proportional review rule, but that rule should be explicit and consistently applied.

Handle retries without creating duplicate work

Network errors are not a reliable indication that a server did nothing. A browser may lose the response after the server has created a draft or started a generation job. Associate an idempotency key with one logical request and offer a status lookup before sending an identical request again. The same principle applies to a publish button: a timeout after dispatch should trigger observation, not an immediate second click.

A useful error message distinguishes "not sent," "rejected," and "outcome unknown." Those states lead to different actions. A validation error may be corrected and submitted again; an unknown outcome requires checking the existing record. The design should make the safe action the obvious one and preserve enough context for a support person to understand the sequence without collecting unnecessary personal data.

Make the review screen comparable

Reviewers benefit from seeing what changed. A simple side-by-side comparison can show the prior draft and the current draft with labels that remain legible at small sizes. A text description of the change can supplement the images. Avoid making the reviewer infer approval from a thumbnail alone, especially when the intended output is a printed card or a small mobile banner.

For AI-assisted work, the review should identify generated material as a draft and invite inspection of invented details. A model can add an accessory, alter a logo, or imply an event that did not occur. Those changes should not be described as facts about the subject. A reviewer should have an easy way to reject a version and explain a concern without having to provide a detailed justification for a personal boundary.

Keep the contract testable

A small set of tests can cover the important boundaries. Create a draft, request review, approve it, then change the content and verify that the changed version is not treated as approved. Attempt a duplicate creation with the same idempotency key and confirm that it resolves to the existing operation. Simulate a lost response after server acceptance and ensure that the client offers a status check rather than a blind retry.

Test access controls as well. A user who can view an approved public image may not need access to the original source photo or internal review notes. Verify that a private preview cannot be opened as a public record and that a logged-out visitor sees only the intended content. Include accessibility checks for file selection, review controls, status messages, and any pricing information presented at export.

Document limits and handoff

The contract should name what it does not guarantee. It does not determine whether a particular use is lawful, whether an AI-generated image is accurate, or whether a service's current terms permit a requested distribution. It can give a team a repeatable way to surface those questions and retain the decision attached to a specific version.

At handoff, include the approved version identifier, the intended destination, the dimensions, and the name of the person who can answer questions about the file. If the destination changes or the caption is rewritten, the recipient knows which decision must be revisited. This is more useful than a folder full of files named final, final-new, and final-really-final.

A review contract works best when it is small enough to use and precise enough to verify. Separate input from permission, bind approval to an exact version, distinguish unknown outcomes from failures, and keep the public artifact separate from private materials. Those habits support creative experimentation while making the resulting decisions easier to understand and audit.