The stem handoff contract

Stems are a contract, not a favor

When someone asks for stems, they are asking for decision rights they can load in another session. If you export without naming, ordering, processing state, and headroom rules, you did not hand off production. You handed off a Rorschach test.

What the receiving side needs

| Field | Why it matters | |-------|----------------| | Sample rate and bit depth | SRC in the wrong place sounds like a new mix | | Start alignment | Bar 1 beat 1 vs session start; any preroll for sync | | Processing state | Print effects or leave inserts live; commit or document bypasses | | Bus glue | If mix bus compression is baked into stems, say so. If not, say that too | | Reference bounce | One stereo print that is the approved balance target |

What breaks

• Double limiting. Stems that already hit a loud master chain get limited again downstream. Snare becomes a pillow; vocals pump against nothing.
• Hidden sidechains. Ducking keyed to a bus that did not print. Opens in a new session and the pump disappears or inverts.
• Phase-shifted duplicates. M/S “width” tricks that collapse when summed wrong.
• Naming chaos. Stem_07_final_FINAL_v9.wav is not a handoff. It is a hostage situation.

What to do next

• Define a stem map in writing: instrument groups, mono vs stereo, mute rules, and what is intentionally left out of each stem.
• Choose print vs live per stem type (vocals often print tuning; drums sometimes print room). Put it in the map.
• Leave 6–10 dB of peak headroom on printed stems unless the downstream engineer explicitly asked for something else—and log that exception.
• Send a checksum or zip manifest if the package crosses email or drive links that like to eat files.

Bottom line

Good stems cost an hour. Bad stems cost a week of messages and a relationship.

One thing to try this week

Pick one finished mix and write a five-line stem contract before you bounce: sample rate, headroom rule, bus print yes/no, one reference bounce filename, and the single person who can approve changes. Paste it at the top of the delivery email or zip README. Next time, reuse the template instead of improvising.