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:
Schema Validation
Business Rule Validation
Metadata Inheritance
Creation Type Determination
Deduplication
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.