An image-generation interface can look simple while hiding an important product distinction: a request to repair part of an image is not the same as a request that changes who the viewer believes is present. Treating both as generic “edit” operations produces weak requirements and unsafe review habits.
This is a black-box memo. It uses public UI information only; it does not infer a model, implementation, queue, or output guarantee.
Identify the input roles
The public VEME interface exposes separate image workflows. The Image Edit page visibly offers Describe, Area Edit, Annotate, and References. The page’s public copy describes named-area changes and reference-supported editing. This leads to an input contract with a source, an allowed region or annotation, a request, optional references, and preservation conditions.
The Face Swap page visibly separates the image to be edited from the image supplying the face, and exposes Swap Face and Swap Head. That second input carries a different risk: it is a likeness source, not merely an art reference.
type Preservation = 'subject' | 'logo' | 'lighting' | 'layout' | 'expression';
type LocalEditRequest = {
kind: 'local-edit';
sourceId: string;
region?: string;
instruction: string;
references: string[];
preserve: Preservation[];
};
type LikenessRequest = {
kind: 'likeness-change';
targetImageId: string;
faceImageId: string;
mode: 'swap-face' | 'swap-head';
authorizationConfirmed: boolean;
intendedContext: 'internal-concept' | 'labelled-fiction' | 'other-approved-use';
};
These types are a proposed product contract, not a representation of the site’s code.
Validate before generation
The UI should surface different failures for different requests. A local change cannot be meaningfully reviewed without an instruction. A region-specific change should explain what region is active. A likeness-related request should not proceed through a generic warning that leaves consent and context unrecorded.
| State | Required feedback | Why it matters |
|---|---|---|
| Missing source | Name the missing input | prevents ambiguous generation |
| Area edit without marked area | Explain whether the request applies globally | protects the rest of the image |
| Empty instruction | Request a describable change | produces a reviewable intent |
| Likeness source without authorisation record | Stop or route to approval | a face is not a generic texture |
| Unlabelled deceptive context | Escalate to policy review | technical plausibility is not permission |
Review preservation separately from plausibility
An output can look seamless and still fail the brief. For a product image, the label may change. For a local background replacement, a contact shadow may become inconsistent. For a person, the scene may imply an event or endorsement that never happened.
Write a reviewer checklist before looking at outputs:
[ ] The intended region changed.
[ ] Listed preservation items remain readable.
[ ] No unintended text, logo, or object appeared.
[ ] The result makes sense at delivery crop and size.
[ ] For likeness changes, permission and disclosure conditions match the destination.
The last item is deliberately not a visual-quality check. A result should never be approved merely because it is convincing. Do not use likeness changes to impersonate people, create deceptive evidence, or make non-consensual intimate imagery.
Make requests reproducible
A result is difficult to investigate if it has no traceable context. Capture the source identifiers, the request type, the instruction, selected region, reference identifiers, and the final approval decision. Do not assume an internal asset identifier is enough; a reviewer needs the creative intent too.
type ReviewRecord = {
requestId: string;
request: LocalEditRequest | LikenessRequest;
resultId: string;
deliveryCrop: 'square' | 'portrait' | 'landscape';
decision: 'approved' | 'revise' | 'rejected';
reason: string;
};
This record supports a productive correction. “Revise: logo is unreadable in portrait crop” is actionable. “Not quite right” is not.
Test the boundary conditions
Use a small, approved test set rather than production assets. Include a local-edit case with a clearly bounded object, a background case with a visible shadow, and a likeness case only where permission and labelling are explicit. Review at actual output dimensions, not only a large preview.
The main principle is uncomplicated: classify the request before you generate, preserve the conditions that make the asset usable, and give likeness-related changes their own approval path. That creates a better product experience without pretending that a black-box UI reveals more than it does.
Top comments (0)