A release can be well-formed, schema-valid, and still bounce back marked metadata invalid, because a partner profile wanted a field the base schema left optional or refused a territory code. One green tick hides which layer actually failed. A good validator tells you whether to fix the XML, the source metadata, or the delivery agreement, and those are three different jobs for three different people.

A delivery file can pass XML and still fail

A label can upload a release, receive metadata invalid, and find its XML well-formed and schema-valid. Delivery can still fail when a profile requires a field the base schema allows omitted, a recipient rejects a territory code, or a rights relationship is inconsistent.

Treat a DDEX ERN validator as a preflight stack, not one green tick. It must show that a message is structurally readable, valid for its declared ERN version, compatible with the agreed profile, and accepted by the receiving partner. Separating layers tells staff whether to edit XML, source metadata, or delivery policy.

Every outgoing ERN needs a repeatable validation record before reaching a distributor, DSP, or direct endpoint, including version pins, fixture results, and an owner for failures outside the message.

Six gates separate failure types

Classify an error before fixing it. A missing closing tag and a missing commercial territory can both block delivery but need different responses.

Validation gate What it tests Typical failure Who usually fixes it
XML well-formedness Legal XML syntax and encoding Unclosed element, duplicate attribute, invalid character Feed or engineering owner
XSD schema ERN structure for the declared version Element in wrong order, missing mandatory child Feed or metadata engineering
Profile rules Recipient’s permitted ERN subset Profile-required identifier absent Delivery operations and metadata owner
Controlled vocabulary Approved codes and formats Unsupported genre, territory, use type, or date format Metadata operations
Business rules Relationships that must make sense together Deal refers to a resource absent from the release Rights and delivery operations
Partner rules Recipient-specific acceptance checks DSP requires a local identifier or rejects a territory combination Partner operations, sometimes the partner

XML and XSD are deterministic technical gates. Profile and business checks expose relationships among release, resource, deal, rights controller, territory, and date. Partner rules may appear in onboarding documents, a portal, or only through rejection.

Pin the contract before testing files

Results are meaningless without the contract used to create them. An ERN 4.3.2 message cannot be judged against an ERN 3.8.2 schema, and an internal profile may not match every recipient. Keep validation-contract.yml with each feed repository or pipeline.

For the fixture set below, the contract is explicit:

  • Message standard: DDEX ERN 4.3.2, using the ERN 4.3 namespace and complete XSD bundle supplied for that version.
  • Schema runner: xmllint from libxml2 2.12.7 for XSD; Java 21.0.2 and Saxon-HE 12.4 for Schematron-derived profile checks.
  • Profile assumption: a label-to-distributor audio-release profile requiring one main release, at least one sound recording, a commercial deal, release and resource references, and ISO-style territory and language values.
  • Local rule pack: label-rules 1.3.0, covering identifier uniqueness, reference resolution, date ordering, territory intersections, and internal catalog policy.

This is an example contract, not a claim that all partners support that ERN release or rule set. A distributor specifying ERN 4.2, its own profile, or a portal template takes precedence. Archive the schema and rule pack with a checksum or immutable build reference; a log saying only “passed” is hard to audit after an upgrade.

Keep synthetic-contribution disclosures in a separate metadata review stream; this guide covers generic delivery validation. For field context, see DDEX AI music metadata fields for independent labels.

Build fixtures that fail on purpose

Test validators with deliberately broken messages. One successful file proves only that one release did not trigger an obvious error. A fixture suite makes each layer observable and protects mappings, schema bundles, and code lists from regressions.

The anonymised baseline, release-valid-432.xml, describes one digital single, one primary sound recording, one contributing party, one label, and one commercial deal. Placeholder names use production-format identifiers. It has a stable ReleaseReference, matching recording ResourceReference, a deal pointing to the release, an availability date later than message creation, and territory and language values from pinned lists.

Do not treat a stripped XML snippet as proof of a valid ERN fixture: element order, wrappers, namespaces, and references are easily lost. Keep the complete baseline in source control and mutate that file. Record expected outcomes alongside XML:

Fixture Deliberate mutation Expected gate Captured result
release-valid-432.xml None All local gates PASS: xml, xsd, profile, vocabulary, business
broken-xml-unclosed-title.xml Closing DisplayTitleText removed XML FAIL XML: Opening and ending tag mismatch
broken-xsd-resource-order.xml ResourceReference moved after an element that must follow it XSD FAIL XSD: Element ... is not expected
broken-profile-missing-isrc.xml ISRC removed from a profile-required recording Profile FAIL PROFILE: recording identifier required
broken-vocab-territory.xml Free-text territory instead of a code Vocabulary FAIL VOCAB: territory value not in pinned list
broken-rule-orphan-deal.xml Deal references absent R99 in ReleaseList Business rule FAIL RULE: DealReleaseReference does not resolve
broken-partner-label-code.xml Partner-required label code empty Partner rule BLOCKED PARTNER: recipient rule requires label code

This distinguishes “validated on my machine” from “passed agreed rules.” Failure-named fixtures also let an engineer changing the vocabulary parser confirm that invalid territories still fail.

Run validators in failure order

Run cheap, unambiguous checks first. Malformed XML cannot yield trustworthy schema or profile results; fix schema errors before debating business meaning because later checks may see an incomplete tree.

A command-line preflight can be small when the pinned schema bundle, compiled profile stylesheet, and local rule pack are in the repository. The commands below assume the pinned schema bundle and local rule files are available. Treat the shown messages as expected output until you run and retain the fixture results.

“`bash

1. Syntax and XSD structure

xmllint --noout \ --schema schemas/ern-4.3.2/ern-main.xsd \ fixtures/release-valid-432.xml

release-valid-432.xml validates

2. Profile rules, emitted as SVRL

java -jar tools/saxon-he-12.4.jar \ -s:fixtures/release-valid-432.xml \ -xsl:rules/profile-432-label-distributor.xsl \ -o:out/release-valid-432.svrl

failed-assert count: 0

3. Vocabulary and cross-reference rules

node tools/validate-ern-rules.mjs \ --contract validation-contract.yml \ --file fixtures/release-valid-432.xml

PASS vocabulary=0-errors references=0-errors business=0-errors

“`

For broken-rule-orphan-deal.xml, do not report a schema defect. Its final line should be FAIL business E-BR-014: DealReleaseReference R99 has no matching ReleaseReference, directing the editor to correct the deal reference or add the intended release rather than inspect namespaces.

In a portal workflow, preserve the sequence: select ERN version, upload, run schema validation, select recipient profile, then save or export the report. Record the displayed portal rule-set date. Screenshots help setup, but a text log with input filename, result, validator version, and timestamp is easier to compare.

Schema-valid is not delivery-ready

XSD validity is not the finish line: it defines legal document shapes, not every commercial agreement, recipient convention, or policy decision.

A single can have one recording, one deal, valid XML, an identifier, and a deal pointing to an existing release, yet fail because a distributor requires a proprietary label identifier, does not support the territory, or rejects the requested availability window under its ingestion rules. ERN has not failed; the recipient contract adds rules beyond base schema validation.

Do not put every partner condition in a global ERN mapper: that makes a feed tailored to one destination and fragile for another. Keep canonical catalog mapping separate from recipient adapters. Shared preflight checks include references, stable identifiers, compatible dates, code-list values, and a coherent release-resource-deal graph. Name, version, and enable recipient checks only on the relevant route.

Choose tools by the rule layer

No tool responsibly validates every ERN-delivery aspect. Ask which tool owns a failure type and whether its result is reproducible.

An XML parser catches syntax; an XSD processor checks grammar. Schematron or equivalent logic handles cross-tree profile assertions, such as an ISRC required by a profile. A code-list validator should identify vocabulary source and version. A local business engine can resolve references and compare dates after parsing into a model. Partner portals remain necessary where rules are private or change without a public machine-readable package.

A small label can use a scripted pipeline with archived fixtures and a manual portal step; a larger operation can use CI to block delivery builds and send structured errors to metadata. Useful output includes classification, source location, rule ID, and remediation note.

Avoid tools that hide ERN version, silently normalize invalid values, or return one generic failure for all layers. Silent correction may suit whitespace or encoding but is dangerous for identifiers, rights dates, territories, and deal relationships. State every change and retain the original submitted message.

Public checks end before DSP acceptance

Public XSD bundles, profile specifications, and third-party validators provide confidence but cannot promise every DSP’s acceptance. DSP rules can add code lists, mandatory identifiers, audio-asset requirements, territorial policies, editorial constraints, ingestion schedules, and account-level configuration.

Use rejection feedback as new tests. Classify it first: XML or XSD failures require a shared mapper or fixture fix; profile failures require a route-contract update; recipient-only conditions require a partner-rule test and documentation of whether they are stable, optional, or catalog-type-specific. Do not turn a one-off portal issue into a universal ERN rule without evidence.

Automation can confirm that a contributor reference resolves, not that contributor data is contractually correct; it can compare dates, not settle rights disputes. Validation reduces preventable format and consistency errors but does not replace rights review, commercial approval, or final partner ingestion.

Make preflight part of release operations

Run preflight before a release is urgent: when a catalog record becomes a delivery candidate, and again after changes to rights, identifiers, dates, track order, or territory. A file generated weeks earlier may no longer match the active recipient contract.

Use this handoff checklist:

  1. Confirm recipient route, ERN version, schema bundle, and profile version.
  2. Generate ERN from the approved catalog snapshot and retain its source revision.
  3. Run XML, XSD, profile, vocabulary, and business checks in that order.
  4. Save fixture or pipeline output with rule IDs, not only pass/fail.
  5. Run partner or portal validation and attach any recipient report to the release record.
  6. Turn recurring rejection patterns into a named fixture before the next delivery.

The key decision is not whether to buy a larger validator, but whether the team can explain each queue failure, reproduce it from a pinned contract, and prevent recurrence. With that discipline, ERN validation becomes dependable catalog quality rather than a last-minute upload ritual.