How the Registry Processes a Submission

How the Registry Processes a Submission

Audience: Developers and Solution Architects

Every registration submitted to the EIDR Registry passes through a series of processing stages before a new identifier is created. Understanding this workflow helps explain validation results, deduplication behavior, and why seemingly similar records may be processed differently.

This article describes the Registry's processing model. It does not describe the metadata required for registration. See Minimum Required Metadata for Content Registration for field requirements.


Registration Processing Overview

When a registration request is submitted, the Registry performs the following steps:

  1. Schema Validation

  2. Business Rule Validation

  3. Metadata Inheritance

  4. Creation Type Determination

  5. Deduplication

  6. Record Creation

Each stage must complete successfully before processing continues.


1. Schema Validation

The Registry first validates that the submitted XML conforms to the EIDR schema.

Typical validation includes:

  • Required XML elements

  • Valid data types

  • Proper identifier formats

  • XML structure

Requests that fail schema validation are rejected before any business logic is applied.


2. Business Rule Validation

After the XML is validated, the Registry evaluates business rules that cannot be expressed in the XML schema.

Examples include:

  • Required participant rules

  • Parent-child relationship rules

  • Language validation

  • Date validation

  • Controlled vocabulary validation

Business rule validation determines whether the submitted metadata represents a valid EIDR record.


3. Metadata Inheritance

If the record has a parent, the Registry evaluates inheritable metadata.

Fields not explicitly supplied by the child may inherit values from the parent record.

Examples include:

  • Original Language

  • Country of Origin

  • Associated Organizations

  • Credits

  • Approximate Length

Inheritance reduces duplicate metadata while maintaining consistency throughout the registration hierarchy.


4. Creation Type Determination

One of the Registry's internal processing steps is determining the Creation Type of the submitted record.

Creation Type is an internal processing classification used by the Registry to apply validation rules and perform deduplication. It is not the same as Referent Type or Structural Type.

Although developers may encounter Creation Type in API interactions or Registry documentation, it is not intended to describe the business meaning of the content. Instead, it tells the Registry how the record should be processed.

Creation Type is determined from the submitted metadata, including the Referent Type and the record's position within the registration hierarchy.

Because validation and deduplication operate on Creation Types rather than Referent Types alone, two records with different Referent Types may follow the same processing path.


5. Deduplication

Before creating a new identifier, the Registry determines whether the submitted content has already been registered.

The deduplication process:

  • Selects candidate records

  • Compares weighted identity fields

  • Calculates confidence scores

  • Applies decision thresholds

  • Routes uncertain matches for Manual Review

If the Registry determines that an existing record represents the same work, the existing EIDR ID is returned instead of creating a duplicate.


6. Record Creation

If validation succeeds and no existing record is identified, the Registry creates a new EIDR record.

During creation the Registry:

  • Assigns a new EIDR Content ID

  • Stores submitted metadata

  • Records administrative information

  • Establishes parent-child relationships

  • Makes inherited metadata available to child records

The new record can then participate in future registrations, inheritance, and deduplication.


Why This Matters

Understanding the Registry processing model helps explain why registrations may behave differently than expected.

For example:

  • A request may pass XML validation but fail business rule validation.

  • Two different Referent Types may be processed similarly because they share the same Creation Type.

  • Metadata inherited from a parent record may affect deduplication results.

  • Additional metadata may improve matching accuracy even when it is not required for validation.

Understanding these processing stages makes it easier to troubleshoot registration issues and build reliable integrations with the Registry.