Validation Module

This optional feature is part of version 25.2 and is subject to change

Introduction

The purpose of the validation module is to allow for selective validation of certain Formats by checking their validity and optionally their adherence to certain profiles (for example a PDF validator that only allows PDF 1/A files).

Configuration

A validation module has the following additional properties beyond the general Module Plugins | Properties stored in the custom properties.

Property	Description	Custom properties	Required	Default

Property	Description	Custom properties	Required	Default
Formats	The list of pronom formats for which to call this validator An empty list implies all formats	`{"PronomIds": ["x-fmt/387", "x-fmt/388", "x-fmt/399"]}`	No	[ ]
Premis event sub type	The premis event type to generate for finished validation	`{"PremisEventSubType": "VERA-PDF"}`	No	““

Example

{
  "Category": "InternalValidation",
  "Uri": "InternalValidationVeraPdfTask"
  "CustomProperties": {
    "PronomIds": ["x-fmt/387", "x-fmt/388", "x-fmt/399"],
    "PremisEventSubType": "VERA_PDF"
  }
}

Events

The result of the validation generates the following Events

Event Type
- Form: RECORDS.VALIDATION.<SUB-TYPE>
- Example: RECORDS.VALIDATION.VERA_PDF
Event comment
- Successful validation
  - Form: Validated by <Validater name> version <Validator version>
  - Example: Validated by veraPDF version 1.26.5 using profile "PDF/A-1A validation profile"
- Rejected validation
  - Form: Rejected by <Validater name> version <Validator version>: <Reason>
  - Example: Rejected by veraPDF version 1.26.5 using profile "PDF/A-1A validation profile"

Record rejections

When a validation rejects the object, it will add the following rejection to the metadata field Metadata 25.1 | RecordRejectionshaving the properties

Motivation
- Form: Rejected by <Validater name> version <Validator version>: <Reason>
- Example: Rejected by Vera PDF version 8.5: Corrupted header at byte 0x85
Reason: The literal string INTERNAL_VALIDATION

Workflow

During the Ingest Flows of the object, a new validation step is added that does the following

Obtain the list of validation connectors that apply to the object (based on whether the module plugin is active for the organisation and applies to the source pronom format)
Call each validator sequentially
1. Perform the validation
2. Log the result of the validator as one of the Events(include both positive and negative evaluations)
If at least 1 validator declared the object invalid, reject the object as a whole

The validation connectors work synchronously because the validators must be light weight