Same Trip, Two Outputs: Portfolio Metadata vs. Client Deliverable¶
The short answer
The same trip feeds two different readers. Your portfolio edit wants long-tail keywords and a stock-ready caption; the client deliverable wants a project ID and a clean rights line. Both live in the same IPTC and XMP fields, so you can write them in one pass over one ingest, then export two branches without re-keywording a single frame.
You flew home from the assignment with one card full of frames and two jobs waiting for them. The tourism board that commissioned the shoot wants its deliverable: the frames it paid for, labeled with the project reference, the usage it licensed, and nothing it did not ask for. Your own site, your stock portal, and the book you are slowly assembling want the other edit: the long-tail keywords, the searchable caption, the full copyright line that keeps the image yours.
It is one trip. It becomes two outputs, and the difference between them is almost entirely metadata. The pixels are the same. What you write into the file is not.
Most travel photographers I talk to keyword this twice. They build the client deliverable, deliver it, then come back weeks later and re-tag the same frames for the portfolio because the two jobs felt like two projects. They are not. A good travel photography delivery workflow treats them as one ingest with two export branches, and the split is cleaner than the double-handling makes it look.
A note on who this is for and where it comes from. I am a photographer, but I do not shoot tourism-board or magazine commissions. This split-workflow walkthrough is assembled from the standards bodies that define the fields (IPTC, ASMP, APA), from contributor specs at Adobe Stock and Shutterstock, and from how working travel and commercial pros describe the portfolio-versus-commission divide in places like A Photo Editor and Thomas Heaton's blog. The legal pieces below are general information, not legal advice. Your contract and your lawyer outrank any blog post.
Why does the same trip need two metadata profiles?¶
Because two different people read the metadata, and they are looking for opposite things.
The client reads the deliverable to confirm they got what they commissioned. They want the project reference so the file lands in the right job folder, the usage terms so their legal team knows what was licensed, and a credit line. They do not want your stock keywords, your competitor-adjacent search terms, or an internal note to yourself about which frames are exclusive. Extra metadata on a client file is at best noise and at worst a licensing question you did not mean to open.
The portfolio reads the other edit to be found. A stock buyer or a search crawler never meets you; they meet your caption and your keywords. Shutterstock tells contributors to stay between 7 and 50 keywords and to write captions that answer who, what, when, where, and why. Adobe Stock's submission guidelines lean on the same caption-and-keyword discipline plus release and IP rules. Recording those releases as a machine-readable signal is its own pass: model and property release status in IPTC. That is a lot of descriptive metadata, and almost none of it belongs on the client's copy.
So the divergence is not cosmetic. It is two audiences with non-overlapping needs, served from one set of pixels.
| Portfolio edit | Client deliverable | |
|---|---|---|
| Reader | Stock buyer, search crawler, you | The commissioning client |
| Keywords | 7 to 50 long-tail, stock-style | Few or none; internal tags stripped |
| Caption | Full who/what/when/where/why | Short, factual, or omitted |
| Rights line | Full copyright, all rights reserved | Rights-transfer or license language |
| Identifier | Stock collection or set name | Project ID and shoot reference |
| Internal notes | Your own pick flags | Removed before delivery |
Which IPTC and XMP fields actually diverge?¶
The good news: both editions live in the same metadata slots. You are not learning two schemas. You are writing different values into the same well-defined fields, most of which the IPTC Photo Metadata Standard has defined and Lightroom, Bridge, Capture One, and every delivery platform already read.
Here are the fields that carry the split, by their XMP property name so you can find them in any tool:
| Field (friendly name) | XMP property | Portfolio value | Client value |
|---|---|---|---|
| Creator | dc:creator |
Your name (same) | Your name (same) |
| Copyright Notice | dc:rights |
Full copyright string | Per contract; may stay yours |
| Rights Usage Terms | xmpRights:UsageTerms |
"All rights reserved" or stock license | The licensed usage, in plain words |
| Job Identifier | photoshop:TransmissionReference |
Stock set or collection slug | The client project ID and shoot reference |
| Instructions | photoshop:Instructions |
Empty or stock notes | Delivery or usage instructions |
| Description (caption) | dc:description |
Full stock caption | Short factual caption or blank |
| Keywords | dc:subject |
7 to 50 long-tail terms | Stripped to a safe minimum |
Two of these do the heavy lifting and are worth naming plainly.
photoshop:TransmissionReference, surfaced in most software as Job Identifier or "Job Reference," is where the client's project ID lives. Tourism boards, magazines, and agencies hand you a job number; this is the field it belongs in, so the file self-identifies inside the client's system. On the portfolio side you can repurpose the same slot for your own collection or set name, or leave it empty.
xmpRights:UsageTerms, surfaced as Rights Usage Terms, is the human-readable license. For a portfolio frame this is your "all rights reserved" line or your stock agency's license summary. For a client deliverable it is the plain-language version of what your contract granted: the usage, the territory, the term. The machine-readable cousin is xmpRights:WebStatement, a URL pointing at the full license; pros who publish a standard license page link it there so the terms travel with the file.
A working note on the copyright line itself. Whether dc:rights changes between editions depends on your contract, not on the software. Many commissions are licensed, not bought, so the copyright stays yours on both copies; some are work-for-hire or full buyouts where the rights transfer. Trade bodies built precisely for this question are worth reading: ASMP maintains business-practice and copyright guidance, and APA (formerly Advertising Photographers of America) focuses on copyright, licensing, and contracts for commercial work. Decide the rights question in the contract, then let the metadata reflect it. Do not let a default template decide it for you.
How do you build a travel photography delivery workflow from one ingest?¶
The mechanic is the part I can speak to directly, because it is software, not field practice. The goal of this travel photography delivery workflow is to write the shared fields once, branch the two that differ, and export twice without ever re-keywording.
1. Ingest once and write the shared fields¶
Open Jade GT in your browser and drop the trip's folder onto the page. Nothing uploads; the frames stay on your machine. Write the fields both editions share: dc:creator (your name), your base dc:rights copyright string, and the GPS and capture data that came off the card. If a destination day moved across locations, that is also where you match a GPX track to the frames by timestamp. This is the same single-pass idea behind doing the whole metadata pass before Lightroom opens, and it is the spine both branches hang on.
2. Branch the portfolio edit¶
Select the frames bound for your site, your book, or the stock portal. Load the long-tail keyword set into dc:subject, staying in the 7-to-50 range stock agencies expect, and write the full who/what/when/where/why caption into dc:description. Set xmpRights:UsageTerms to your standard portfolio or stock line. If you are pushing to an agency, this is the edition that has to satisfy Adobe Stock's keyword, caption, release, and IP rules before it clears review. If the trip crossed several countries, the bulk country and city location schema is the part of dc:subject that makes the set filterable later.
3. Branch the client deliverable¶
Now select the frames the client commissioned. Write the project ID and shoot reference into photoshop:TransmissionReference (Job Identifier). Put the licensed-usage language into xmpRights:UsageTerms, and delivery or usage notes into photoshop:Instructions. Strip dc:subject down: the client almost never needs your stock keywords, and your internal pick flags should not ship. Trim dc:description to a short factual line or clear it. This edition's job is to be clean, correct, and free of anything you did not mean to hand over.
4. Export two branches, not two projects¶
Export the portfolio frames, then export the client frames. One ingest, two passes over the metadata, two output sets. The pixels were decoded once; only the fields differed.
If you live in Lightroom for the keyword side, the same separation exists there. Julieanne Kost's keyword guide covers the "Include on Export" toggle, which lets you keep internal keywords in your catalog while preventing them from being written into the exported file. That is the Lightroom-native way to strip the client's copy without losing your own organization. The principle is identical: tag richly for yourself, export selectively for whoever is reading the file next.
What goes wrong when you do not split?¶
Three failures show up over and over when one trip ships as one undifferentiated batch.
The client gets your stock keywords. Fifty long-tail terms aimed at search buyers end up embedded in a tourism board's deliverable, which at best looks unprofessional and at worst seeds confusion about whether those frames are also for sale elsewhere. A client file should say what it is and nothing more.
The portfolio loses its caption. Run it the other way and the stock edition ships with the terse client caption, or no keywords at all, and the frames sink because stock discovery is keyword-and-caption driven. An unkeyworded stock frame is a frame nobody finds.
The rights line is wrong on one copy. A single template applied to both editions writes the same xmpRights:UsageTerms onto a licensed client file and a full-rights portfolio file, when those two lines should differ. Getting the license language right per edition is exactly the kind of thing ASMP and APA exist to help photographers think through.
None of these is catastrophic on its own. Together they are why the "keyword it twice" habit persists: people get burned once, then over-correct into doing everything twice. Splitting the fields from one ingest is the version that is both correct and fast.
Where the deliverable goes next¶
Embedding the right fields is half the job; getting the file to the client is the other half, and that is a delivery-platform question, not a metadata one. PhotoShelter's file-delivery workflow is a good reference for the back half: password-protected galleries, outbound FTP, resolution and format controls, and time-limited links that expire after a week. Jade GT writes the metadata; the gallery platform handles the handoff.
On the portfolio side, the Format commercial photography guide is a reminder that the portfolio edition serves a different reader again: the art buyer browsing your book, not the client checking a deliverable. Same trip, third context, and the metadata you wrote in step 2 is what makes those frames findable when that buyer searches.
One quiet note on where your files go¶
Jade GT runs entirely in your browser. The trip's frames, the keywords, the client project IDs, and the rights language you write never leave your machine. Nothing uploads to a server. Nothing trains an AI on a client's commissioned work, because the tool cannot see the files in the first place. For a commercial deliverable with a confidentiality clause, that is not a nice-to-have; it is the difference between a tool you can use on the job and one you cannot.
FAQ¶
Do I have to keyword the trip twice?
No. That is the whole point of splitting from one ingest. Write the shared fields once, then branch only the fields that differ between the portfolio and the client edition: keywords (dc:subject), caption (dc:description), rights terms (xmpRights:UsageTerms), and the Job Identifier (photoshop:TransmissionReference). Two exports, one keywording pass.
Where does the client's project ID go?
Into photoshop:TransmissionReference, shown in most software as the Job Identifier or Job Reference field. It is the IPTC-defined slot for a job number or shoot reference, so the file self-identifies inside the client's system without polluting the descriptive fields.
Does the copyright change between the two editions?
That depends on your contract, not the software. Many commissions are licensed rather than bought, so dc:rights stays your copyright on both copies and only xmpRights:UsageTerms differs. Work-for-hire or full buyouts are the exception. Settle it in the contract, then write the metadata to match. General info, not legal advice.
Will these fields survive into Lightroom and delivery platforms?
Yes. They are standard IPTC and XMP properties that Lightroom, Bridge, Capture One, and the major delivery platforms read and write natively. The Job Identifier, usage terms, caption, and keywords all travel with the file.
Try it on one trip¶
Take the last assignment that became two jobs. Drop the folder into Jade GT, write the shared fields once, then branch the portfolio keywords and the client project ID into their own fields. Export both. If the two editions come out the way each reader needed them, your next trip is already a two-branch job instead of a double-keywording one.
Sources¶
- IPTC Photo Metadata Standard - defines Creator, Copyright Notice, Rights Usage Terms, Job Identifier, and Instructions, the exact fields that diverge between the two editions.
- American Society of Media Photographers (ASMP) - business-practice, contract, copyright, and licensing guidance for the commissioned side of the split.
- American Photographic Artists (APA) - copyright, licensing, and contract resources focused on commercial photographers.
- Adobe Stock contributor submission guidelines - authoritative rules on keywords, captions, releases, and IP for the portfolio/stock branch.
- Shutterstock description and keyword best practices - the 7-to-50 keyword range and who/what/when/where/why caption rule.
- PhotoShelter file delivery workflow - galleries, FTP, resolution and format controls, and time-limited delivery links.
- Julieanne Kost: Working with Keywords in Lightroom Classic - keyword sets and the "Include on Export" toggle for stripping internal keywords.
- A Photo Editor (Rob Haggart) - editorial and commercial pricing and licensing from the buyer side of the commission relationship.
- Format: Commercial Photography Guide - what the portfolio edition has to present to an art buyer, a different reader than the client.
- Thomas Heaton's blog - a working travel and landscape photographer whose documented workflow makes the portfolio-versus-commission split visible.
Reply to Kenny
Questions, corrections, or a workflow story of your own? Send a note. It goes straight to my inbox.