Team
Provenance for compliance
Legal asks where an image came from. The answer is on the asset, written automatically, and it survives the person who made it.
"Where did this come from, and can we use it?" That question arrives weeks after the work shipped, usually from somebody who was not in the room, and usually about an asset whose maker has moved on. Every asset here carries its own answer. ## What every asset can tell you | Recorded | Answers | |---|---| | Tool and model | Which system generated it, and therefore whose terms apply | | The exact prompt | What was asked for, in the words that were used | | Full settings | The parameters of the run, not a summary | | Source assets | What it was made from, and what that was made from | | Who and when | The person and the timestamp | | Board and workspace | Where in the account it happened | Right-click any asset and open **Properties**. It is all there, on assets nobody remembers making. ## Nobody has to tag anything The record is written when the asset is created, which is what makes it trustworthy: a process that depends on people filling in a field produces a library that is complete for three weeks. It is also **only ever added to, never reduced**. If a lookup cannot resolve a detail, the asset keeps what it already had rather than falling back to **Uploaded**. ## The whole chain Most compliance questions are about lineage rather than a single step. An asset made from another asset knows its parent, so an upscaled, background-removed, composited final frame walks back to the original generation. That is what lets you answer "was anything in this derived from material we did not have rights to", which is the question underneath most of the ones actually asked. ## Why it matters more in a team One person can hold their own history in their head. A team cannot, and the gap between the work and the question is measured in months and staff changes. - The maker has left, and the record has not - The asset is in the **team** library rather than a personal one, because work made in a team workspace belongs to the organisation - Removing somebody from the workspace does not remove what they made :::caution[The guest case is the hole to know about] Work generated by a **guest** on a board, somebody invited to the board rather than the workspace, lands in that person's own personal library. The asset appears on your board and its record lives in an account you do not control. For any engagement where provenance matters, give people a seat in the workspace rather than a board invitation. That is the difference between a complete record and a complete-looking one. ::: ## Handing the record over The record lives with the asset in Plnty rather than being embedded in a downloaded file. A client or an auditor who needs to read it themselves needs either access or an export you prepare. It does come back, though. A file that left and returns is recognised by its bytes and reattached to its full record, months later and through somebody else's hands. That match requires the bytes to be untouched, so a re-compressed or re-saved copy arrives anonymous. See [when a file comes back](/docs/using-plnty/the-asset-library/when-a-file-comes-back/). The whole-board bundle helps here: alongside the media it writes out the notes as `notes.md`, the references as `links.md` and the palettes as `palette.txt`, so a handover carries the reasoning as well as the artwork. See [downloading](/docs/using-plnty/get-the-work-out/downloading/). :::note[What this does not do] It records what was used, not whether you were allowed to use it. Naming the model is what makes the licence question answerable, and answering it is still a decision somebody has to make. :::“Where did this come from, and can we use it?”
That question arrives weeks after the work shipped, usually from somebody who was not in the room, and usually about an asset whose maker has moved on. Every asset here carries its own answer.
What every asset can tell you
Section titled “What every asset can tell you”| Recorded | Answers |
|---|---|
| Tool and model | Which system generated it, and therefore whose terms apply |
| The exact prompt | What was asked for, in the words that were used |
| Full settings | The parameters of the run, not a summary |
| Source assets | What it was made from, and what that was made from |
| Who and when | The person and the timestamp |
| Board and workspace | Where in the account it happened |
Right-click any asset and open Properties. It is all there, on assets nobody remembers making.
Nobody has to tag anything
Section titled “Nobody has to tag anything”The record is written when the asset is created, which is what makes it trustworthy: a process that depends on people filling in a field produces a library that is complete for three weeks.
It is also only ever added to, never reduced. If a lookup cannot resolve a detail, the asset keeps what it already had rather than falling back to Uploaded.
The whole chain
Section titled “The whole chain”Most compliance questions are about lineage rather than a single step. An asset made from another asset knows its parent, so an upscaled, background-removed, composited final frame walks back to the original generation.
That is what lets you answer “was anything in this derived from material we did not have rights to”, which is the question underneath most of the ones actually asked.
Why it matters more in a team
Section titled “Why it matters more in a team”One person can hold their own history in their head. A team cannot, and the gap between the work and the question is measured in months and staff changes.
- The maker has left, and the record has not
- The asset is in the team library rather than a personal one, because work made in a team workspace belongs to the organisation
- Removing somebody from the workspace does not remove what they made
Handing the record over
Section titled “Handing the record over”The record lives with the asset in Plnty rather than being embedded in a downloaded file. A client or an auditor who needs to read it themselves needs either access or an export you prepare.
It does come back, though. A file that left and returns is recognised by its bytes and reattached to its full record, months later and through somebody else’s hands. That match requires the bytes to be untouched, so a re-compressed or re-saved copy arrives anonymous. See when a file comes back.
The whole-board bundle helps here: alongside the media it writes out the notes as
notes.md, the references as links.md and the palettes as palette.txt, so a
handover carries the reasoning as well as the artwork. See
downloading.