The Complete Guide to Song Structure and Parts

Song Structure and Parts determine how musical ideas communicate with listeners and how those sections are documented and monetized. This guide maps every common part to its musical function, typical timing, and real-song examples, then translates those elements into actionable metadata, registration steps, and publishing practices you can use to protect and collect royalties. Expect practical templates, DDEX and identifier recommendations, and checklists for songwriters, publishers, and developers building catalog and rights-management systems.

What counts as a song part and why parts matter to publishing

Direct definition: A song part is any identifiable, repeatable musical or lyrical segment - verse, chorus, bridge, intro, outro, riff, hook, tag, instrumental break - that a listener can point to and that contributors can claim responsibility for. For musicology this is about function and form; for publishing it is about provenance, contributor attribution, and commercial value.

Why this matters commercially: Parts do not create separate copyright units in most registration systems, but they drive licensing value and auditability. A short phrase or riff often becomes the reason for synchronization requests, samples, or interpolations. If that element is undocumented, matching engines and PROs struggle to allocate income correctly and revenue goes unclaimed.

Operational checklist - what to capture about a part

• Canonical name: normalized part label such as verse, chorus, hook, bridge, riff
• Timecode or bar range: start and end timestamps plus measure numbers when available
• Lyric excerpt or motif: 3 to 12 words for hooks; melodic contour note for instrumental motifs
• Contributors and IPI numbers: map each part to IPI/CAE IDs and provisional split percent
• Version note: demo ID and master ISRC, with a note if the part changed between versions

Practical tradeoff: Capture more metadata early and you reduce reconciliation errors later, but you increase administrative overhead and the chance of disputed splits as the song evolves. In practice the balance that works is to require minimal, structured part metadata at the demo stage - canonical name, timestamp, and contributor IDs - and expand details once the composition is locked for release.

Concrete example: A publisher registered a demo with clear timestamps and an explicit hook credit mapped to an IPI. Months later a major artist interpolated that hook. Because the hook was recorded in the work record and linked to an ISWC via DDEX messages, the clearance routed to the correct publisher and mechanical split was negotiated before release, avoiding a delayed invoice and unclaimed performance income.

Common misunderstanding: People assume that repeating a lyric automatically entitles the original writer to proportionate royalties. Royalties are paid on the full composition or master, not on isolated parts. The operational value of part-level metadata is not creating new payments per section but making sure the existing payments reach the right owners and that hooks and riffs are documented for licensing.

Canonical list of song parts with functions and examples

Practical point: treat this list as an operational vocabulary you will use in metadata, contracts, and catalogs. Below are the canonical parts, their musical function, typical timing or placement, a real song example, and the metadata action you should take when capturing them.

Core structural parts

Micro parts, motifs, and hooks

• Hook or riff: the short melodic phrase that sells the song. Example Deep Purple Smoke on the Water guitar riff. Capture as separate entry when it recurs or drives licensing.
• Motif / ostinato: repeated pattern underpinning sections. Example Queen Another One Bites the Dust bassline. Useful for sample clearance and identification.
• Vamp / fill / tag: short connective or decorative material inside bars. Often not worth separate registration but worth noting in demo metadata for provenance.

Tradeoff to manage: finer segmentation improves sync and reporting accuracy but increases maintenance and mismatch risk across catalogs. In practice choose a granularity that your publisher or distributor will actually consume; too many micro segments become noise in PRO exports.

Concrete example: when preparing a demo for registration, timestamp the chorus of Katy Perry Roar with start and end time, list contributing writers with IPI numbers, and mark the chorus as primary hook in your ERN payload. That single disciplined action prevents the chorus from being missed during PRO matching and speeds up split application in licensing.

Next consideration: pick your canonical names now and enforce them in ingestion rules; the small discipline saves lost income and long reconciliation work later.

Common song forms and templates

Most modern songs fit a small set of structural templates; choosing among them is a production and metadata decision, not just a creative one. The template determines where hooks land, how often themes repeat, and how easy it will be to map parts to timestamps and contributor records in catalogs.

Common templates and what they do

• Verse–Chorus (ABABCB): The workhorse for pop and rock. Verses deliver narrative detail; choruses deliver the hook and repeat. Best for streaming because repetition strengthens recognition and playlist placement.
• AABA (32-bar Tin Pan Alley): Two similar A sections, a contrasting B (bridge/middle eight), then return to A. Strong for lyrical storytelling and sync placements that need a clear lift and return.
• Strophic: Same music repeated for each stanza. Common in folk and country. Economical to register but can bury a short hook if not varied.
• Through-composed / Linear: Sections evolve without strict repetition. Useful when narrative or cinematic flow is the priority, but harder to index in catalogs and harder for casual listeners to remember.
• Drop-centric / EDM form: Intro → build → drop → breakdown → drop. The hook may be instrumental; that matters because licensing discussions will hinge on the recorded riff rather than lyrics.

Practical tradeoff: Templates that maximize hook repetition (verse–chorus) usually increase performance and streaming royalties because plays concentrate on the same section. Nonrepetitive forms (through-composed, long bridges) are better for artistic storytelling or sync cues, but they require more diligent part-level metadata so revenue and credits don't get lost.

Concrete Example: Adele Rolling in the Deep maps cleanly to an ABABCB timeline: intro, verse, pre-chorus, chorus, verse, pre-chorus, chorus, bridge, final chorus/outro. For registration and cataloging you can assign timestamps for each chorus instance so publishers and PROs can reliably identify the repeated hook and attribute its writers when routing claims.

Metadata and operational implications

In practice, nonstandard sections create the most operational cost. Extended outros, multiple bridges, or interludes often show up as mismatched or unnamed segments in PRO exports. Judgment: when you depart from a common template, plan extra metadata up front — bar ranges, start/end timecodes, and contributor IPIs — or you will pay for reconciliation later.

Final consideration: Templates shape legal and financial outcomes. If you want your hook to drive sync value or be defensible in clearance talks, design the structure so the hook appears early and repeatedly, and document it with timestamps and contributor IDs. That small administrative discipline saves weeks of reconciliation and lost revenue later.

How to document parts during songwriting and production

Document parts as a deliverable, not an afterthought. Poorly recorded section metadata is the single most common operational cause of unmatched royalties and disputed splits during catalog ingestion.

Minimum metadata to capture at the demo stage

• Identifiers: include composer names and IPI numbers, provisional publisher names, and a working title.
• Timestamps and bar numbers: start and end timecode plus bar-beat positions and tempo map so sections remain valid if tempo changes occur.
• Section labels: canonical names using a controlled vocabulary - for example Verse, Pre-Chorus, Chorus, Bridge, Outro - and a freeform notes field for novel parts.
• Lyrics by section: paste the exact lyric lines for each labelled section to lock provenance of hooks.
• Contributor role and provisional splits: list contributions per section when relevant and a provisional percent table in machine readable form such as JSON.
• File provenance: MD5 or SHA256 for each demo file, DAW project export, and the date/time stamp.
• Change log: who changed what and when, with links to successor demo versions.

Tradeoff to accept: capture more metadata upfront and you reduce reconciliation load later, but do not use provisional splits as legal finality. Early splits speed registration and reduce lost income, however they must remain editable until formal agreements are signed.

Bar numbers versus absolute timecodes. Use both. Bar-beat references survive tempo edits and DAW rewarps better than plain seconds. Absolute timecodes are required when issuing stems, creating rough cuts, or aligning to a video timeline.

Concrete example: a producer exported a MusicXML and a small timeline CSV with the table above, plus MD5 checksums. When a later release revisited the hook, the preserved lyric-by-section entry and the original demo file proved authorship and avoided a split dispute during PRO registration.

Version control and naming conventions. Keep a single canonical repository for session exports and metadata. Use filename patterns that include version, date, and a semantic tag such as v1demo, v2patched, v3_master. Store both a human readable PDF lead sheet and a machine readable JSON manifest so publishing administrators and ingestion systems can consume the same truth.

What people get wrong in practice. Teams often annotate DAW sessions without exporting structured metadata. That makes automatic ingestion fragile because distributors, labels, and PROs cannot parse session comments. Export and attach an explicit manifest instead of relying on session notes.

Operational next consideration: feed the manifest into your publisher or administration process and register the work with PROs. If you need a place to start with catalog cleanup and registration, consider leveraging publishing administration services such as UniteSync to ingest these manifests and convert them to PRO and ISWC registration packages.

Publishing and royalty implications of parts

Direct point: song parts themselves are not separately paid by collecting societies; royalties flow to registered works and recordings, but parts determine value, negotiation leverage, and proof when disputes arise. Documenting parts deliberately changes outcomes in claims, licensing negotiations, and catalog reconciliation even though societies pay on the whole work or master.

How parts map to revenue streams

Practical trade-off: you can register extremely granular part-level metadata (timestamps, bar ranges, micro-splits) to reduce future disputes, but doing so increases administrative overhead and the chance that downstream systems will drop or alter fields. For most catalogs the pragmatic choice is to capture granular proof internally while publishing a single canonical work registration with clear splits and hook documentation.

Concrete example: a credited hook interpolation

Use case: An artist uses a two-line hook from an earlier composition as the post-chorus of a new single. First, the new artist negotiates an interpolation license and records the agreed split in writing. Then update PRO registrations with the agreed shares and add the original work as a referenced composition using ___CODE0 and the contributing writers' CODE1___ numbers; deliver timestamps and a short audio clip to the publisher and licensor to avoid ambiguity during royalty allocation.

1. Registration checklist: capture final lyric sheet with section labels, start-end timestamps (mm:ss), ___CODE0 for the work, CODE1 for masters, and contributor CODE_2___ numbers.
2. Clearance step: obtain written interpolation or sample license before release and attach the license to PRO and distributor registrations.
3. Delivery step: send DDEX ERN updates to distributors and publishers with segment metadata and a controlled vocabulary for part names to reduce catalog mismatches. See DDEX for message specs.

Judgment: insisting on changing published splits later because a hook proved valuable is a lose-lose. Lock provisional splits at release and capture granular evidence in your publisher records. In practice, late renegotiations create blind spots in PRO databases and cost more in recovered royalties than getting documentation right upfront.

Next consideration: map your part metadata into catalog schemas so reconciliation queries can link a credited hook or riff to payments. If you need help operationalizing that mapping, start by exporting your demo timeline as a CSV and aligning columns to ___CODE0, CODE1, and contributor CODE_2___ for ingestion into publishing administration systems like UniteSync — see UniteSync for catalog audit guidance.

Standards and technical implementation for parts metadata

Start with identifiers, not prose. The operational unit for any parts workflow is the canonical identifiers you can join on: ___CODE0 for the work, CODE1 for each recording, and contributor CODE_2___/CAE numbers. Without those you will be matching fuzzy names forever and losing money in reconciliation.

Identifiers, where they live, and how to reference parts

Practical mapping: store a parent work record keyed by ___CODE0, then a parts table that references that CODE1 plus the CODE2 for the specific master. Each part row should include CODE3 (controlled vocabulary), CODE4, CODE5, CODE6, CODE7, CODE8, and contributor CODE9___ references. This lets you join composition metadata to recordings and to PRO exports reliably.

DDEX, ERN, and practical implementation notes

Use DDEX ERN segments but expect gaps. DDEX supports segment-level metadata via ERN and Part-related elements; use RelatedResource/Segment/ResourceContributor to attach ___CODE0 and CODE1___ to a time-ranged element. Many distributors omit detailed segment fields, so plan for partial ingestion and fallbacks.

• Best practice: require DDEX ___CODE0 times in seconds and a CODE1___ field in your ingestion schema.
• Fallback: if no DDEX segments are present, accept a validated CSV upload from the publisher with ___CODE0, CODE1, CODE2, and CODE3___.
• Controlled vocabulary: normalize incoming part labels using a mapping table to avoid variant labels like pre-chorus / prechorus.

Concrete example: An independent publisher receives a distributor ERN lacking segments. They ingest the master (___CODE0), register the composition (CODE1), then upload a CSV that maps CODE_2___ from 00:45 to 01:10 with contributors A-IPIs and B-IPIs. The publisher uses those timestamps to match PRO performance reports and to prioritize split audits for high-usage sections like hooks.

Example JSON snippet for a parts record

Use this as a schema fragment when designing APIs or database exports. Store both timecode and musical positions to improve cross-master matching: {iswc:T-123.456.789-0,isrc:US-ABC-20-00001,parts:[{part_type:chorus,start_time:45.0,end_time:70.0,start_bar:17,end_bar:28,bpm:120,contributors:[{ipi:00000000001,share:50},{ipi:00000000002,share:50}]}]}

Audio alignment, fingerprinting, and trade-offs

Expect mismatch between demos and masters. Tempo shifts, edits, and different mixes break time-based joins. Fingerprinting helps but is noisy for short parts and for melodic motifs that are reused across songs. Store both audio fingerprints and bar-based positions to hedge risk.

1. Trade-off: granular part metadata improves matching and licensing precision but raises ingestion costs and increases false negatives when labels skip segment fields.
2. Operational constraint: require contributor IPI on part records for any claimable hook or riff; otherwise PRO matching will fail.
3. Developer consideration: index ___CODE0+CODE1+CODE_2___ for fast queries that return all works containing a credited hook.

Next consideration: decide the minimum viable part payload your catalog will require from ingestion partners and enforce it in contracts — that decision determines whether your reconciliation improves or remains an expensive manual process. See UniteSync for help operationalizing registration and audits: UniteSync.

Songwriter and producer tips for writing parts that register and collect value

Start with the hook as a legal and commercial asset, not just a catchy moment. If the melodic or lyrical fragment will carry licensing value later, treat it like a mini-work: isolate it, notate it, and give it a provenance trail before you polish production.

Distinctive melodic contour matters more than complexity. A two- or three-note leap plus a rhythmic idiosyncrasy is easier to identify in cue-sheets, fingerprints, and human memory than a long, florid line. That recognizability is what converts hooks into sync and sampling income.

Practical production and writing actions

• Capture the kernel: Record a short, dry reference of the hook (vocal hum or single instrument) and save as a labeled file — e.g., chorushookv1.wav — with BPM and timecode in the filename.
• Transcribe quickly: Put the hook into a lead-sheet (melody + chords + lyric line) within 24 hours. Notation is the single most useful asset when a sync brief or rights question appears.
• Separate composition from sound: Produce a stripped-down take of the part that demonstrates melody and harmony alone. That file is evidence of authorship distinct from the master arrangement.
• Decide credits at the session: If a producer or session player invents a melody, resolve credit immediately. Waiting until release multiplies disputes and lost royalties.
• Name parts consistently: Use canonical labels in session and deliverables (verse, pre-chorus, chorus, hook) so ingestion systems and PROs match when you register.

Trade-off to accept: heavy production can make a part iconic on the master but blur composition ownership. If a synth sound or drum pattern is integral, either keep a clear compositional reference or accept that value may remain with the master and require negotiated splits for reuse.

Real-world use case: A producer creates a succinct synth motif during a session that becomes the earworm. The team recorded the motif dry, notated it, and agreed a provisional split documented in email. When a label pitched the track for a commercial, the documented lead-sheet and agreed split allowed immediate clearance and payment without a rights hold-up.

Hard judgment: most creators under-document hooks. Collecting societies pay composers on the whole work, but the hook drives licensing. Documenting hook authorship and provisional splits early is low-effort and high-return; leaving it vague guarantees friction and lost revenue.

Next consideration: If you need help turning documented parts into registered works and recoverable royalties, consider publishing administration or a catalog audit as the operational next step — see UniteSync for audit options and DDEX for technical messaging standards.

Developer and catalog manager playbook

Make parts first class objects in your catalog. Treat a song part as a discrete record with timestamps, canonical part type, contributor links, and provenance instead of as freeform text on the track. That design decision changes everything downstream: matching, auditability, reporting, and the ability to attach provisional splits or claims to specific hooks and riffs.

Minimal data model to store for each part

Validation and normalization rules matter more than you think. Require ___CODE0 and CODE1___ for any part ingested from distributors. Normalize names to a controlled vocabulary and reject ambiguous labels like section A or chorus one unless they map to a canonical_name. This reduces false positives when joining PRO exports, DDEX ERN messages, and distributor metadata.

• Required at ingest: partid, canonicalname, start_ms, contributors with IPI where available
• Recommended: barstart, barend, provisional_split decimal, source and provenance
• Reject or flag: parts with endms less than startms, overlapping identical canonical_name windows without provenance

Tradeoff to accept. Finer granularity yields better claims mapping but increases noise and reconciliation work. If you tag every 2-bar vocal fill as a separate part you will double the number of records to maintain and create more ambiguous matches in PRO reports. Our practical recommendation: adopt a two-tier approach where high-value micro parts such as hooks, riffs, and named motifs are stored as separate part objects and generic filler sections are grouped under the main canonical part.

Concrete example: A distributor CSV labeled a segment as verse and a second line as verse 1 with different timestamps and no contributor IDs. Map both rows to canonical_name chorus or verse using your normalization table, merge overlapping windows by provenance, and attach contributor IPIs from the master registration record. In practice this workflow fixed a mismatch where a credited hook was being missed in PRO reporting because it had been ingested as a nameless segment.

1. Integration checklist: Map distributor fields to your part schema, apply normalization, enrich contributors with IPI from master records, persist provenance, emit DDEX-ready part segments in ERN payloads
2. Query patterns to support: find works containing a specific contributor in any hook; list masters where a given canonicalname overlaps with ISRC startms ranges; calculate aggregate playtime of chorus sections across catalog
3. Monitoring: run nightly joins between PRO exports and your parts table and surface unmatched segments for manual review

Key operational rule: store provenance with every part record. If a part is contested years later, the notes and source often determine the outcome faster than a subjective musical argument.

If you want a grounded starting point, export the parts table as JSON with the fields above and include it in your DDEX ERN Part segment mapping. For implementation guidance review DDEX and map part_type to your canonical_name. When in doubt, attach the part to the work ISWC and record the provenance; that is what publishers and PROs will ask for during audits or split disputes. For help operationalizing this mapping at scale see UniteSync.

Visual diagrams and suggested audio examples

Concrete point: You must produce at least three visual artifacts for each work you register — a timeline, an annotated lead sheet, and a waveform-aligned timestamp map — because they resolve the single biggest friction between creative teams and metadata systems: differing references (bars vs timecodes) across versions.

Use bar-based anchors (bar 1 = intro, bar 33 = chorus) as the canonical reference and store timecodes as derived fields. Why: timecodes drift between demos and masters; bar counts stay meaningful across tempo changes and edits. The tradeoff is simplicity versus precision: bar anchors are robust for publishing and PRO registration, but precise sync licensing or sample clearance needs aligned timecodes and waveform snippets.

Timeline template (3:30 pop ABABCB)

Concrete examples: Use public recordings to teach part recognition but link to official sources and keep clips short. Practical picks: Hey Jude demonstrates an extended coda useful for tagging outros (The Beatles — Hey Jude); Smells Like Teen Spirit is an intro-riff case for riff-as-hook (Nirvana — Smells Like Teen Spirit); Hello shows pre-chorus to chorus dynamic contrast (Adele — Hello); Halo demonstrates vocal build and bridge usage (Beyoncé — Halo); Smoke on the Water is a riff/motif micro-part example (Deep Purple — Smoke on the Water).

• Use case: Create a single ZIP per work that contains the lead sheet PDF, the timeline CSV, and three 10-second waveform-aligned clips (intro, hook, bridge) for clearance and dispute evidence.
• Limitation: Embedding full-length audio in a catalog for reference breaks licensing rules and bloats ingestion pipelines; keep short clips plus fingerprint hashes instead.
• Judgment: Timestamp precision beyond one bar rarely improves PRO matching; it does help sync and sample clearance. Store both but prioritize bar anchors for publishing workflows.

Metadata practice: Include a segment table linking part name to start/end bars and start/end times, then map each segment to ISWC/ISRC and contributor IPIs. Follow DDEX guidance when sending part-level editorial metadata — see DDEX — and attach your visual artifacts to the ERN where possible.

Next consideration: attach these artifacts to your PRO registration and publisher intake packet so the people who handle ISWC assignment and split ingestion see the same canonical references you used during writing and clearance.

Operational next steps for protecting parts and collecting royalties

Start registration before release. Capture timestamps, credited contributors, and provisional splits on the demo you plan to distribute. If you wait until after release you will still get paid, but resolving mismatches becomes slower and expensive.

Registration checklist you can run in one sitting

1. Lock authorship data: collect legal names, IPI numbers, and contact emails for every writer and arranger.
2. Annotate parts: produce a simple CSV or MusicXML mapping part name to ___CODE0 and CODE1___ timestamps and include lyric excerpts for hooks and chorus lines.
3. PRO registration: submit the work to relevant PROs with declared splits and the annotated parts attached, request ISWC or note pending status.
4. Mechanical documentation: prepare mechanical licensing details with HFA or local mechanical body before distribution if you expect physical or download income.
5. Master registration: ensure the master has an ISRC and register with SoundExchange for US digital performance income.
6. Distribute with metadata: push DDEX ERN-compliant feed to distributors including segment metadata fields like ___CODE0 and CODE1___ where supported.
7. Archive evidence: save demos, timestamped session exports, and split agreements indefinitely.

Practical tradeoff: doing registrations yourself saves fees but increases reconciliation risk if your metadata is inconsistent. Using a publishing administrator costs a percentage but materially reduces unclaimed royalties and speeds dispute resolution when hooks, interpolations, or sample credits appear.

Limitation to expect: PROs and collecting societies pay against the registered work as a whole not per part. Documenting parts improves matching, sync negotiation leverage, and auditability, but it will not create separate per-part royalty lines in the standard performance or mechanical flows.

Concrete example: A songwriter records a demo with a distinctive post chorus hook they want protected. They collect all IPI numbers, map chorus timestamps in a CSV, register the work with their PRO listing the hook as a noted motif, request ISWC assignment, register the master with an ISRC, and distribute with DDEX segment fields. When an ad agency later requests the hook only, the publisher has the timestamps, splits, and ISWC to clear the sync faster.

When to bring in a publisher or administrator

Bring one in when: you have multiple writers across territories, expect third party uses of a hook, or lack time to maintain snapshot metadata. If you plan international exploitation, professional administrators know local mechanical processes and speed ISWC propagation.

What they solve: they standardize part names, push correct DDEX payloads, reconcile PRO statements against actual plays, and run targeted audits to recover missed income. They do not create legal ownership where none exists; you still need documented splits and provenance.

Next consideration: after registration monitor PRO statements and distributor reports monthly and run a reconciliation for any play counts that reference timestamps or clip uses. If you find mismatches treat the timestamped demo and split agreement as primary evidence when escalating with a PRO or distributor.

For implementation details see DDEX guidance at DDEX and basic legal context at the United States Copyright Office. If you want a practical audit to find missing royalties, start with a catalog-level check and a prioritized set of unreconciled hooks and choruses recorded in your metadata. For professional admin support see UniteSync.

Frequently Asked Questions

Straight answer up front: metadata and registration happen at the work and recording level, not at the phrase level, but documenting parts precisely is the operational difference between recovered and lost royalties.

Top operational FAQs

• Can a single hook or phrase be registered separately? Work registries generally will not accept isolated short-phrase registrations. Practical step - include the hook as an annotated section in the main work record, assign contributors and provisional splits, and preserve demo evidence to prove provenance if disputes arise.
• Do different song parts generate different royalties? No. Performance, mechanical, and master royalties pay against the composition or the master, not sections. That said, hooks and signature riffs drive licensing demand, so record them in metadata and negotiations as high-value elements.
• Which identifiers should I attach to parts? Use ___CODE0 for the composition, CODE1___ for recordings, and IPI/CAE numbers for contributors. Attach start/end timestamps or bar ranges so systems can reconcile segments across catalogs and recordings.
• How granular should part metadata be for ingestion systems? Balance accuracy against operational cost. Excessive micro-segmentation increases mismatch risk when external feeds lack the same granularity. Use a controlled vocabulary and required fields - canonical part name, start/end time, contributors - then accept sparse external data rather than reject it.
• What do I do when another artist interpolates my hook? Document the interpolation in writing, negotiate a split or license, and update PRO registrations before release. If you skip registration updates you leave a gap that often translates into missed performance income.
• Are there standards that handle part-level metadata? DDEX supports segment and editorial metadata in ERN messages; combine that with internal controlled vocabularies. See DDEX for the fields and ASCAP or SoundExchange for registration workflows.
• How long should I keep demos and annotated notes? Indefinitely. These are primary evidence in ownership or split disputes and frequently required during catalog audits.

Tradeoff to accept: extremely granular part maps reduce ambiguity but increase maintenance. In practice, teams that standardize on 6-10 canonical part names and require IPI plus timestamps achieve the best balance between match rates and operational overhead.

Concrete example: A publisher ingested a distributor feed where chorus timestamps were missing. By matching the distributor ISRC to the publisher ISWC and using an internally standardized part table, the team recovered withheld performance income that had been misassigned for six quarters. The fix was procedural - require timestamps at ingestion and surface mismatches in a nightly report.

1. Immediate actions you can implement: Require ISRC + timestamps from distribution partners and enforce IPI collection on sign-up forms.
2. Mid-term workflow change: Add a nightly reconciliation job that flags works with high play counts but missing part-level metadata for manual review.
3. Policy to adopt: Use a controlled vocabulary for part names and store both raw incoming labels and normalized labels to preserve provenance.

Next consideration: combine DDEX ERN segment fields with your internal part table and include links to the parent work ISWC in every segment record. If you need help mapping feeds or auditing gaps, run a catalog audit and include demos and annotated lead sheets in the evidence packet - that materially shortens dispute resolution.