Choose what the person needs to be able to do
A person may receive the same results for different reasons: checking their quality, integrating the files into another tool or resuming production. Define that action before sending a link. A preview is sometimes enough to discuss a framing; it is not necessarily enough to check an export at its full size.
Ask for a specific review: which files to open, which criteria to examine, where to leave feedback and the desired date. Don't send the entire working directory by default. Excluded variants, complete logs and unnecessary resources make the selection harder and can expose information unrelated to the delivery.
The sharing described here takes place in your own tool or destination. It does not assume a team feature, a messaging service or a file space provided within BriefGPU tracking. Choose a destination your recipient is authorized to use.
Assemble a package that makes sense without a spoken explanation
Give the package a project name and a version number, for example collection-v01. Attach a short note explaining the content and the status: to be reviewed or accepted. An inventory should make it possible to count the outputs and see the exceptions. Cornell's README guide recommends documenting the files and the information needed to use them; your note can be much shorter than a research folder.
To resume production, add the necessary settings and dependencies separately. For simple use of the finished results, keep the working archive on your side.
| Package item | Question it answers |
|---|---|
| Delivery note | Which project, which version and which action are expected? |
| Selected results | Which files should be examined or used? |
| Inventory | How many outputs are present, and which inputs do they represent? |
| Identified exceptions | What is missing or still needs to be decided? |
| Feedback grid | How do you attach a review to a file and a criterion? |
Example: a review of eighteen images by three people
In this fictional example, one person produces eighteen images, a colleague checks the references, and a manager approves the render for distribution. The v01 package contains the eighteen outputs to be reviewed and an inventory. The colleague can view the images and fill in the grid; they do not need to modify the deliverable files.
The brief asks to check the references and the text, then to note any discrepancies along with the image identifier. The manager then compares the render against the agreed criteria. The feedback is gathered in a single table before deciding on corrections. A suggestion does not automatically change the version made available.
| Reviewed version | File | Observation from the example | Decision |
|---|---|---|---|
| v01 | image-004.png | The printed reference has become illegible. | Fix before approval. |
| v01 | image-011.png | Two people suggest a different framing. | The manager chooses the reference to follow. |
| v01 | Other images | No discrepancy found in the planned review. | Keep, subject to the final check of the package. |
Set permissions for the task at hand
In a shared space, invite the people concerned with their own access and choose the rights that match the work. To review outputs, favor viewing the files and a separate location for comments. Reserve modification of the package for the person responsible for preparing the delivery.
The names and effects of permissions depend on the service. For example, OneDrive distinguishes links intended for specific people from links usable by anyone who receives them. Its documentation also notes that read access can allow copying or downloading. So "read-only" does not mean "impossible to take away." Check the options actually available in your account and your team's rules.
Check the shared folder as a whole. Adding a file to a location that is already accessible can expose it to the same recipients. Prepare a folder reserved for delivery so that confidential originals, contracts, and access credentials stay out of the package.
Keep passwords out of the review loop
Don't lend your BriefGPU account password to show results. It gives access to account tracking; it is not a limited right to a file. Use the sharing features of your own destination or hand an authorized recipient a standalone package.
Also don't slip a service password, a private key, or an access token into the delivery note, a screenshot, or an order history. For a handoff involving several people, each person must have the access method appropriate to their role. If your sharing tool doesn't allow the necessary rights, choose another delivery method with the team.
The person responsible for the order can share a summary useful to the project without giving out their login credentials.
Publish a new version when you make corrections
After the feedback from the example, the v02 package replaces the two corrected images and keeps the other sixteen. Its note states precisely the two changes and asks to check these corrections. It also asks to verify that the package still contains eighteen distinct references. Reviews of v01 remain attached to v01.
Do not silently replace a file in the middle of a review without notifying the people concerned. They could comment on different content under the same name. Identify the current version in your message and in the note, then clearly state which version is authorized for use once approved.
One person gathers the decisions, their reasons, and their statuses in the shared grid, including after a verbal exchange.
Check the recipient's journey
Before the full handoff, have someone with the intended rights open a file using their own account. Check access to the right folder, the visible version, opening it in the destination tool, and the ability to send feedback. Your own owner session does not prove that others will have the same access.
For an archive, also check its extraction and the opening of a sample from the copy you obtained. A "link received" message confirms neither access, nor download, nor acceptance. Ask for a reply that matches the step: access verified, review completed, or version accepted.
After handoff, review the access rights that are no longer needed. Some services combine a link with permissions inherited from a parent folder, so removing a link may not remove all access. Microsoft documentation details these paths in OneDrive and SharePoint. A copy that has already been downloaded is not recovered by simply deleting the link.
Finish with an accepted version and a recorded decision
A delivery is clear when its recipient knows which version to use, any agreed limits, and where to find the files. Keep the decision together with the inventory. For the example, acceptance covers collection-v02 and its eighteen images; it does not validate every variant in the project.
Reading the package does not replace backing it up. Keep the copy you need for your own resumption and verify it before ending the rental. This handoff method makes no claim about any sharing feature, retention period, or specific permission on the rented server: those settings must be checked in the tools you use.