A rendering can be approved and still become outdated.
A final image is final only against a particular design revision. Once a development is marketed, a change to the building may invalidate an image that was perfectly correct on the day it was signed off. The visualisation team might know about the change; the website editor, sales agent and print supplier might not.
The problem is not solved by renaming a file “final-v7”. A buyer sees a specific balcony, window, garden or view. They do not see the model revision behind it. The practical goal is to make the relationship between approved design, rendered image and published placement traceable, so that an outdated promise is not left circulating unnoticed.
This is a post-publication workflow. For review comments before an image is approved, use the separate architectural rendering feedback checklist. For preparing model revisions for the artist, see the BIM/CAD handover guide.
Agree which design changes trigger a visual review.
Not every drawing revision requires a new render. A hidden technical detail might have no visible effect. A small change to a balcony balustrade, on the other hand, may appear in several prominent views and on a sales floor plan. Decide the trigger categories before a late-stage change arrives.
| Change type | Typical visual consequence | First action |
|---|---|---|
| External geometry | Openings, terraces, roofline, façade rhythm | Identify every camera where the element is visible |
| Specified materials | Cladding, window frames, paving or finishes | Compare image against the newly approved schedule |
| Landscape and public realm | Planting, paths, boundaries, neighbouring context | Check what is approved versus illustrative |
| Unit configuration | Partitions, kitchen, glazing, room layout | Cross-check interiors, plans and unit references |
| Construction or sales status | Claims in captions, labels and overlays | Update factual text even if the image remains usable |
Record the date when the new design information became authoritative and who approved it. An email suggesting a possible material swap is not the same as an issued specification. Mark pending decisions as pending rather than quietly choosing the most attractive version.
Give every published visual a stable ID and an owner.
Create a compact visual asset register. It can be a spreadsheet, a CMS collection or another shared system; the important part is that the same image can be found across its source scene, final export and every place it is used. Do not rely on filenames alone, because web optimisers and agencies often rename exports.
For each visual, record a view ID, design revision, approval status, approved date, source file, output variants and publication locations. Add the person who can confirm architectural accuracy and the person responsible for replacing the image online. Include the image's explanatory caption or disclaimer as part of the asset record, not an afterthought.
The project, IDs and dates above are fictional. The format is the reusable part; no actual development or client is being described.
If the site uses multiple crops of one master image, treat them as related variants of one view ID. A revised landscape master does not automatically fix an old portrait crop cached in a campaign asset library.
Check the impact across views, not just the image that exposed it.
Start with the latest approved plan, elevation, section or model revision and locate the changed element in space. Then inspect the camera map. A façade modification may appear in an exterior, a courtyard view, reflections in glazing and the background of an interior looking out. A relocated garden boundary may affect both an aerial and a ground-level scene.
Classify each affected image as unaffected, needs verification, needs update or must be withdrawn. A single owner should sign off the classification. This is more useful than sending a blanket instruction to “update all renderings”, which can create work without improving accuracy.
Keep architectural and presentation changes separate.
When replacing a render, preserve the approved camera unless there is a deliberate reason to change it. Otherwise a design update becomes entangled with a different perspective, and reviewers cannot tell whether the apparent difference is geometry or composition. The same applies to daylight, entourage and vegetation: change them only when the brief requires it, and record the decision.
For images placed in site photographs, recheck alignment and occlusion after the model changes. The separate camera-matching checklist covers the technical validation of a proposed building against a real viewpoint.
Choose between correction, replacement, qualification and withdrawal.
There is no universal rule that every changed element requires a complete new image. The decision depends on whether the current visual is materially misleading for its purpose, whether the difference is visible, and whether the image is used to communicate a specific purchasable feature. Document that assessment; do not let a convenient deadline make it implicitly.
- Correct and republish: the viewpoint remains valid and the changed geometry or material can be accurately updated.
- Replace with a different view: the old camera no longer explains the approved design or obscures a relevant change.
- Qualify clearly: a conceptual illustration remains useful, but its status and limitations need to be stated next to the image.
- Withdraw temporarily: the current visual risks communicating an unsupported feature and no approved replacement exists yet.
A generic “images for illustration only” footer is not a substitute for reviewing a visible discrepancy. Local advertising, sales and disclosure requirements differ; have the responsible legal or sales team review any claims that may affect a purchase decision. This guide is an operational checklist, not legal advice.
Walk one change from drawing to published image.
Imagine a fictional residential building where the approved design moves a courtyard privacy screen and changes the terrace railing from transparent glass to vertical metal bars. The old marketing render shows a continuous glass edge and an open view toward the neighbouring garden.
First, the architect issues the revised elevation and terrace plan with a revision identifier. The visualisation lead marks which existing views contain the changed edge. The marketing editor checks where those views appear: website hero, apartment detail, printed brochure and an agency download folder. The sales lead checks whether accompanying text promises a particular view or terrace finish.
The example illustrates an audit trail, not a claim that any particular correction is always sufficient. The team should decide whether an already distributed printed item requires additional action based on its use and applicable obligations.
Notice what the change log does not ask for: a prettier sunset, more people or a larger-looking terrace. Those are separate creative decisions. The task is to bring the published representation back into line with the design that has actually been approved.
Approve the replacement against a fixed design baseline.
For the replacement preview, attach the design revision and the affected view IDs. Compare the new render against the issued drawings, then compare it against the previous render at the same camera. A side-by-side or overlay makes a missing change easier to detect than a standalone polished image.
Review geometry first: openings, parapets, railings, levels, boundaries and visible neighbouring structures. Then verify specified materials, lighting assumptions and annotations. Check repeated elements in the rest of the image set so the new image does not contradict still-published views. Record an explicit approval date and approver.
Export a new immutable master file with a revision ID. Do not overwrite the only archived approved source. The archive should make it possible to reconstruct what the public saw at a given time, while the current publishing folder should make the approved version unambiguous.
Republish everywhere the old image was distributed.
Replacing the image on the project website is only one step. Check sales portals, downloadable brochures, property agent folders, investor decks, social advertising assets, signage production files and email templates. Some channels cannot be edited after distribution. Record those as exceptions with an owner and a next action rather than treating them as complete.
Use a release checklist for the new export variants: desktop hero, mobile crop, unit thumbnail, social format and print-resolution file where relevant. Confirm that the revised subject remains visible in every crop. A CDN or browser may still serve an older image when a file is overwritten at the same URL; use the site's asset versioning or cache invalidation process and verify the public result.
Do not confuse a design change with a search-indexing task. If the page URL is unchanged, replacing a correctly referenced image does not require submitting a preview URL for indexing. If project pages themselves move, follow the separate URL migration checklist for redirects and canonical signals.
Test the live campaign and leave an audit trail.
After publishing, open the real public page on desktop and mobile. Check the hero, gallery, enlarged image and downloadable PDF. Confirm that the updated image and caption match the approved revision, and that old assets are not still exposed through visible links. Verify the production page rather than assuming a successful upload or preview means the update is live.
- The authoritative design revision and issue date are recorded.
- Every relevant camera and image variant has an impact decision.
- Factual descriptions, unit data and image captions were checked alongside the visuals.
- The replacement render was approved against the specified design revision.
- Old exports are archived with status, not mixed into the live publishing folder.
- Website, brochure, agent and advertising placements have named owners.
- Public desktop and mobile URLs show the approved image after cache checks.
- Uneditable or previously distributed materials are logged as exceptions.
- Conceptual or provisional elements are clearly qualified where shown.
- The next design-change review date or trigger is assigned.
For a development that has not launched yet, the residential development website checklist covers the earlier content and sales-readiness decisions. Once the site is public, keep this visual change register alongside the availability source of truth. Both are ongoing publishing responsibilities, not tasks to finish once at launch.