Key takeaways
- Match approved stills and animation to the agreed editable scene revision. Record exactly what belongs in the handover, including exclusions.
- Open the delivered copy, check its dependent files and confirm permissions for intended uses. A successful opening alone does not establish completeness.
- Connect the practice’s approval to the package location, task and invoice. Contractual acceptance follows the agreement; design decisions and professional responsibility remain with the practice.
Close the agreed package, one version at a time
Close a visualization stage against an identifiable package. Consider a hypothetical competition entry: overseas freelance specialists deliver exterior stills, a fly-through and expressly agreed editable scenes. The practice approves a still showing a revised entrance canopy, but the delivered scene contains the earlier design. The image approval and the scene handover now refer to different revisions.
The handover also needs a record of who commissioned the work and which agreement governs completion. When browsing contractor management platforms, compare who holds the contractor agreement and how task and invoice records connect to the delivery. That category search addresses administration; the practice still checks the visualization itself.
Define what closes the stage: the ordered outputs, any included source files, the agreed check and the person authorized to approve for the practice. A request for a different camera view after delivery should be distinguishable from a missing agreed view. Defining a task does not, by itself, establish independent-contractor status or service eligibility.
A manifest connects final outputs to editable scenes
A package manifest is a short index of the delivery. For the hypothetical competition entry, it should connect the approved canopy image to its scene, and the fly-through to the animation revision actually supplied. Adapt the fields to the commission:
- Outputs: filenames or IDs for each still and animation, their revisions and the corresponding approval reference.
- Editable files: agreed scene filenames and revisions, with a clear note where source files were excluded from the commission.
- Working setup: software, render-engine and plugin versions needed for the agreed reopening check.
- Dependencies: locations of referenced textures, linked scenes and other required inputs; identify anything the practice must obtain separately.
- Inclusions and exclusions: distinguish delivered components from separately licensed or omitted assets.
- Delivery location: the particular archive or project-folder version under review.
A folder labeled final says little about its contents. The manifest should identify the approved output and its matching scene.
Autodesk’s 3ds Max 2026 Archive command packages the current scene and referenced files, including textures, containers and external references (XRefs), into a compressed archive. The archive is a delivery method; check its contents against the agreed components and their permissions.
Reopen the delivered copy before recording completion
Check the copy that the practice received, using the agreed software setup. A screen share of the artist’s working folder shows what works on the artist’s machine.
For the competition package, reopen the delivered scene, review dependency warnings and compare the entrance canopy with the approved still. Then produce a small agreed sample output, such as a crop of that view or a selected animation frame. Record what was checked and any unresolved difference. Use this as a closeout check; identical rendering across systems is not guaranteed.
Autodesk’s documentation for 3ds Max illustrates why opening alone is insufficient. Missing bitmap or photometric paths can trigger warnings during opening or rendering, including after files move or drive mappings change. Continuing can leave maps absent or alter lighting associated with missing photometric files.
Separate correction of the agreed delivery from a new creative instruction. A missing referenced texture or an outdated canopy belongs on the delivery issue list. A newly requested evening atmosphere should be assessed against the agreed scope. Assign each open item to a person and agree how it will be resolved.
Separate rights in original work from library asset permissions
Check intended uses against the agreement and asset licenses before treating the scene as reusable. The competition submission, later website publication and editing for a subsequent presentation may require different permissions. Record the uses the practice actually needs.
In the hypothetical package, distinguish the specialist’s original visualization work from third-party models and textures embedded in the scene. For each relevant library component, ask:
- May it appear in the intended rendered output?
- May its underlying file be included in the scene handover?
- Does the practice need its own license for further editing or use?
- Which components are excluded, and how will the agreed handover accommodate that exclusion?
A landscape model visible in an approved still deserves this check even if it was incidental to the design review. Agreement about the rendered image does not settle every permission associated with its source assets.
Chaos’s guidance on commercial use of Cosmos assets ties that use to the rights in the accepted end-user license agreement (EULA). It does not, on its own, establish permission to redistribute raw models or textures. Inspect the applicable license for the proposed handover.
Record the original-work rights terms and library-asset permissions separately. Ownership and assignment depend on the actual agreements and applicable law; an invoice reference alone cannot answer those questions.
Acceptance should identify the package and its open items
Write an acceptance entry that a colleague can trace back to the files. Reference the manifest rather than copying it. Identify the version reviewed, the check result and the person making the practice’s decision.
For the hypothetical competition package, a practice-created entry could contain:
- Stage/task: [commission reference and agreed deliverables].
- Package: [archive or folder location, scene and output revisions].
- Check: [agreed setup and sample-output result].
- Decision: [accepted items and any unresolved items].
- Approval: [authorized practice approver and date].
- Commercial record: [related invoice reference and agreed follow-up].
If the stills are approved but the editable scene has the earlier canopy, name both facts. Describe the outstanding scene correction precisely and agree how it affects stage closure under the contract. Leave the scene correction visible in the completion record.
Technical completion, contractual acceptance and payment timing each need attention. Follow the particular agreement’s review and acceptance mechanism, including any automatic or time-based provisions. A practice’s internal checklist does not replace those terms or create a payment-withholding right.
Store the entry beside the manifest and permission notes. The colleague handling the invoice should be able to identify the package concerned without reconstructing a chat history.
Three contractor-operation options for the record trail
Compare three arrangements through the same questions: who contracts with the specialist, which records the service supports, how rights terms are documented and which decisions remain with the practice. For the competition package, keep the technical manifest and named approval in the practice’s project repository, connected to the relevant engagement records.
4dev.com
- Contracting: Under 4dev.com’s Master Service Agreement (MSA), the Contractor Platform’s client contracts with Fourdev LLC, which may engage subcontractors. Available service categories are account-specific; the client specifies and accepts tasks.
- Records: The MSA permits external delivery; electronic invoices identify the contractual entity and applicable rights assignment. Acceptance can follow a click, expiry of the task’s Review Period without refusal or reported deficiencies, or enabled automatic acceptance. Plan the file check around the applicable mechanism.
- Rights: Unless the task states otherwise, rights in deliverables created pursuant to the task and delivered to the client pass directly from subcontractor to client upon creation and no later than task completion. A task may instead retain rights with the subcontractor. Third-party asset permissions still need checking.
- Boundary: Confirm the permitted scope. The MSA excludes services requiring licensing or mandatory professional qualifications in US states, EU member states and Singapore; a visualization label alone does not settle eligibility.
Remote
- Contracting: Standard Contractor Management leaves the customer as the contractor’s legal counterparty. The customer may upload its agreement or execute a local agreement through the platform; Remote is not a party to it. Remote’s separate Contractor of Record product uses a different engagement model.
- Records: The product supports contract generation and e-signature, onboarding documents, and generating and approving invoices. Approved invoices are compiled in a Transaction Receipt. The customer handles contract and invoice issues.
- Rights: Inspect the selected customer–contractor agreement for the original deliverables, intended uses and asset exclusions. Keep the scene handover requirements connected to that agreement.
- Boundary: Retain the manifest, dependency-check result and practice approval separately. A Transaction Receipt records the invoice trail; the practice must decide whether the agreed files are complete.
Oyster
- Contracting: Under Global Contractors, the customer directly engages the contractor. Oyster manages agreements and acts as the contractor’s limited payment agent in an administrative role.
- Records: The product describes in-app contracts, customer templates, automated/manual invoice workflows and contractor/invoice reporting. Its terms provide for invoice review, dispute and approval.
- Rights: Country-specific confidentiality and intellectual property (IP) agreements are available for supported countries. Confirm the applicable country and document, then inspect coverage of original work and separately licensed components. Modified forms and customer documents are used at the customer’s risk; additional agreements can take precedence.
- Boundary: Oyster’s terms leave engagement negotiation, contractor suitability and service-performance issues with the customer, alongside business and licensing obligations. The practice should record the canopy correction and its acceptance decision in its own project record.
Questions to resolve before closing the stage
Are editable scenes automatically included?
Only include them in the closeout requirement when the agreement calls for them. State the required scene version and exclusions alongside the rendered outputs.
Does opening a scene prove all dependencies arrived?
No. For example, 3ds Max can continue with missing external inputs. Review warnings, check dependency locations and run the agreed sample-output check on the delivered copy.
Does paying transfer all model and texture rights?
Payment alone does not establish every asset permission. Check the original-work agreement and the licenses governing third-party components, including any scene-file redistribution.
Does a contractor platform approve architectural design?
The practice remains responsible for its design decisions and applicable professional obligations. Engagement and invoice records do not supply architectural certification or statutory sign-off.
What should be recorded if one agreed item is still missing?
Identify the item, affected version, responsible person and agreed follow-up. Record the acceptance decision under the actual contract. For the competition package, reconcile the delivered canopy scene with the approved image, then update the manifest and closeout entry together.
