Having a before photo and an after photo does not automatically justify a comparison. Put them side by side and a visitor reads a claim: this same space changed in this way. In reviewing the actual portfolio program, I focused on how that claim was handled separately in code. An after photo could remain useful on its own even when a proposed comparison lacked sufficient evidence.
Selecting a picture is different from verifying a relationship
An ordinary gallery presents after-construction scenes from a job. A before-and-after comparison adds another assertion: both frames show the same physical place from a comparable direction. A shared room label or adjacent filenames cannot establish that relationship. Correctly identifying one image's construction phase is a different judgment from approving the two images as a pair.
The selected review record illustrates that distinction: after scenes were retained, before views with unsuitable directions stayed private, and only a separately verified kitchen pair was connected. This article does not report a fresh visual inspection of those original photographs. It compares the recorded review, current selection logic and test source to explain how the maker's decision was represented in the program.
Do not use one visibility switch for both contexts
The original renderer takes selected, unheld after photos as ordinary gallery candidates. Its comparison path additionally checks a reviewed pair record, the before-to-after phase order, shared case and physical-space identifiers, room categories and displayed orientation. Failure to establish a comparison does not erase an independently usable after-photo gallery.
The opposite distinction matters too. An after image intentionally left out of the ordinary gallery may still appear as one side of a comparison. Public data therefore carries gallery_photo_keys and comparison_photo_keys separately. Context is not collapsed into a single visible flag. The new shared example preserves that separation while deliberately narrowing its accepted inputs to already-reviewed synthetic metadata.
Matching orientation does not replace scene review
The orientation check is based on the upright displayed frame rather than simply the raw file dimensions. The program applies reviewed rotation first and then uses the resulting width and height to classify landscape, portrait or square. Failing to distinguish stored dimensions from displayed dimensions can misclassify the very same picture.
Two landscape frames still do not prove that the camera faces the same wall or window. A reviewed comparison record remains a separate prerequisite, along with the case, physical-space identifier and room category. A broad room label does not manufacture a physical-space identity. I wanted to explain that boundary between automatic consistency checks and actual scene judgment before presenting the visual comparison effect.
A hold changes publication eligibility rather than construction phase
Pictures awaiting source attribution, reflection review, finishing or cleanup review are handled through holds. A hold does not turn an after photo into a before photo and does not delete its original. The selection module retains phase and ownership while applying a separate publication_hold so the same image can be reconsidered when the issue is resolved.
Hiding it only in the article body would be insufficient. A held cover needs another after-photo candidate; a comparison with either endpoint held must disappear; and the public lightbox list must exclude the image as well. The test source checks not only identifiers but also whether original and small-image paths remain in generated output. A CSS-hidden element and an image removed from public data are different outcomes.
Build lightbox data from the current public projection
The public-data function combines the keys used by the gallery and reviewed comparisons, then places only those photos in its photos map. That differs from sending the entire working inventory to the browser and hiding selected entries in the interface. A before photo enters this public set only through an eligible reviewed comparison; clearing it from the gallery must not leave it accessible through the lightbox data.
This structure addresses the consistency of public lists. It does not automatically establish access control at the image file server. An adaptation should separately inspect metadata responses, thumbnails, lightbox data, direct file serving and cache policy. The article and module explain selection and the reviewed generation code; this routine did not perform fresh checks of the original site's operational image addresses.
An empty gallery need not erase the job record
A case with only before photos or with every image held can remain in the list with a pending-after-photo state. The original code and tests retain the individual case entry without substituting a before thumbnail. Pulling in an unverified image merely to fill that space would weaken both the underlying record and its presentation.
The wording should distinguish absence from pending verification. No material, before-only material and material awaiting publication review require different next actions from an operator. A visitor needs a short preparation message that does not promise an unverified result. Private source inventory and the reasons for selection or holds remain in the working ledger even when no image can currently be shown.
Reuse the separation of decisions before reusing the effect
Rather than publish customer originals, I reproduced the decision with independently authored synthetic metadata. Saved records show which lists change when a pair is unreviewed, physical spaces differ, or an endpoint is held. This responsibility differs from the existing asset-to-claim evidence module, and the two can work together: one records support for an explanatory statement; this one calculates the contexts in which a photo appears.
Nineteen tests and a repeat after ZIP extraction check this narrow example contract. They are distinct from historical regression evidence for the original application, visual review of source photographs and real-browser verification. A convincing portfolio is not simply a larger collection of images. A maker who can explain what is shown and which relationship is still unverified gives each displayed comparison a clearer meaning.