1. How it usually happens
"Involuntary" theft is almost always a matter of context, not malice.
A client receives your detailed technical document. Passes it internally. Someone uses it as a base for another project. Or passes it to another supplier with the innocent phrase: "Here is everything, just implement".
In agencies it happens often between different teams. For freelancers it happens when client changes supplier. For consultants when document becomes "internal material".
A typical case:
a UX designer delivers highly detailed wireframes. Months later discovers they were reused for another product, with small modifications. Nobody thinks they did anything wrong.
Real problem is that technical attachments:
- are made to be used
- are easily copiable
- often lack clear ownership or context signals
2. What you need to prove
Here it's not just saying "it's mine". You need to prove that content existed beforehand and was linked to a specific assignment.
Concretely:
- that technical document was created by you
- that it already existed in a certain form
- that it was destined for a specific project
- that any reuses derive from that material
- that detail level is not generic but distinctive
In practice you want to claim:
"This material originates in this context, in this version, before being reused elsewhere."
3. What to collect
To truly protect yourself, you must combine content and context.
Collect:
- original technical attachment files (not just exports)
- intermediate versions showing work evolution
- delivery emails or messages
- initial briefs and client requests
- documents linking that attachment to that project
- any comments or revisions received
- collaborative tool screenshots (Figma, Notion, etc.)
- complete project exports (not just online links)
An often-underestimated detail: metadata and file structure (layers, comments, history) tell much more than a simple PDF.
4. How to proceed
Effective protection starts before sharing, not after.
When preparing technical attachment:
- insert clear project references (client name, date, version)
- avoid "neutral" documents reusable without context
- keep complete original copy in your archive
Before sending:
- save definitive version
- optionally create "shared" less reusable version (e.g., flattened, no editable elements)
- timestamp file with ExistBefore to fix its existence
After sending:
- keep transmission proof (email, platform, chat)
- avoid retroactively modifying already shared file
- if updating, create new tracked version
A small operational trick:
many professionals maintain two file levels — complete (internal) and "operational" (shared). This reduces direct reuse risk.
5. Mistakes to avoid
Some behaviours make "involuntary" reuse almost inevitable:
- sending fully editable, reusable files without context
- using overly generic templates without customisation
- never linking document to specific project
- sharing only editable links (which change over time)
- losing original versions
Other useful precautions:
- avoid neutral, reusable file names
- don't deliver all structured "know-how" if not part of agreement
- separate strategic materials from execution ones
Free timestamping helps you because it fixes a point in time where the document's story starts.
6. After documenting
Once you have correctly documented your technical attachments, you can use them more consciously.
You can:
- clarify material usage scope to client
- reuse those contents yourself with more control
- better manage transition between suppliers
- face potential discussions with concrete base
If unpredicted reuses emerge:
- gather reused material examples
- compare them with your original versions
- evaluate direct confrontation or with consultant
In the end, it's not about blocking document use, but preventing your work from becoming "everyone's" without anyone noticing.