1. Purpose of this document

This document explains the validation approach applied to Hoodin Compliance Studio.

It has two explicit purposes:

• to explain how organisations can assess and qualify Hoodin Compliance Studio for use in regulatory work,

• to explain how Hoodin, as the system provider, ensures that the system remains controlled, predictable, and fit for its intended use over time.

The document is intended to support QA, IT, procurement, and audit discussions. It does not position Hoodin Compliance Studio as a validated quality management system or as a

system of record.

2. Positioning of Hoodin in a validation context

From a validation perspective, Hoodin Compliance Studio is a regulatory reasoning and

decision-support workspace.

The system supports regulatory analysis, applicability reasoning, and governance activities, but it does not perform binding regulatory decisions, approvals, classifications, or submissions. It does not function as an eQMS, a document control system, or a system used for regulated production or release activities.

Because of this positioning, Hoodin Compliance Studio is typically assessed using a risk-based and proportionate approach rather than through full computer system validation activities.

The intended use, system scope, and explicit exclusions are defined exclusively in the System overview & intended use document and are not repeated here.

Verification and validation activities are applied in a manner proportionate to the system’s intended use, with a focus on functional correctness, data reliability, and support for regulatory reasoning rather than validation of regulatory decisions.

3. How customers typically qualify Hoodin for use

This section describes how organisations typically assess and qualify Hoodin Compliance Studio for use as part of regulatory work.

Qualification activities are generally focused on scope, risk, and reliance rather than on formal validation testing. Hoodin Compliance Studio does not replace regulatory decision-making, quality management systems, or validated systems used for submissions, approvals, or controlled documentation.

In practice, organisations commonly address the following areas.

First, alignment with intended use is confirmed. Organisations review the System overview & intended use document to ensure that Hoodin’s defined purpose and limitations are consistent with the planned use of the system.

Second, a risk-based assessment is performed. This typically considers whether the system produces binding outputs, whether it stores regulated quality records, and whether incorrect system behaviour could directly result in regulatory non-compliance. Given Hoodin’s role as a support system rather than a system of record, this assessment is usually limited in scope and proportionate to the identified risk.

Third, available vendor documentation is reviewed. This commonly includes this validation approach, the System overview & intended use, AI literacy and governance information, and security or procurement-related material. The purpose of this review is to understand how the system is governed and maintained rather than to verify individual functions.

Finally, organisations determine acceptance of vendor-controlled processes. This step is typically limited to acknowledging Hoodin as the responsible party for system development, change management, and release communication, rather than establishing customer-specific controls. This includes acknowledging that Hoodin maintains control over system development, change management, and release communication, and that customers rely on these controls to support continued confidence in the system.

Taken together, these activities support a documented and defensible decision to use Hoodin Compliance Studio. In practice, organisations typically record this decision as part of a vendor assessment or procurement review, without performing formal IQ/OQ/PQ activities or detailed functional testing.

4. How Hoodin maintains a controlled system state

This section describes how Hoodin maintains control over Hoodin Compliance Studio throughout its lifecycle.

Hoodin applies structured but proportionate development and change management practices appropriate for a regulatory support system. The objective is to ensure that the system continues to function within its defined intended use and that changes do not introduce unintended behaviour from a regulatory perspective.

System development follows a structured lifecycle model aligned with a V-model / W model approach, where requirements, design, implementation, and verification activities are explicitly linked. This supports traceability between intended behaviour and verification activities without positioning the system as a validated QMS or system of record.

Hoodin also considers applicable horizontal requirements, including European accessibility legislation, as part of its general responsibilities for system quality and usability. These considerations do not transfer regulatory compliance obligations to customers and do not require customer-specific validation or assessment activities.

System changes are assessed prior to release to determine whether they affect system behaviour, user interaction, or how the system should be understood in regulatory work. Changes that may influence customer reliance on the system receive additional scrutiny.

Relevant changes are communicated through curated release notes. These release notes focus on changes that may impact regulatory reasoning, system usage, or interpretation. Minor technical updates, performance improvements, and internal refactoring are intentionally excluded.

Hoodin maintains traceability between system changes and communicated releases in order to support transparency and reduce the risk of unnoticed system drift.

Internal quality controls, testing activities, and development procedures are maintained by Hoodin but are not exposed as operational artefacts. Customers are not expected to validate individual system functions and instead rely on Hoodin’s controlled development and release processes as part of their qualification decision.

4A. Verification activities

Verification activities are integrated into the development process and performed to ensure that Hoodin Compliance Studio functions as intended at a technical and functional level.

These activities are integrated into the development lifecycle and include:

Functional verification

Core system functionality is tested to confirm expected behaviour in relation to defined requirements. This includes functionality related to Profiles, Applicable Lists, and Regulatory Updates.

Regression testing

Changes to the system are assessed to ensure that existing functionality remains stable and that no unintended behaviour is introduced.

Release verification

Prior to release, system behaviour is reviewed to confirm that implemented changes align with intended functionality and do not adversely affect user interaction or regulatory reasoning.

AI behaviour verification

AI-supported functionality is verified to ensure that outputs remain within defined system boundaries. This includes ensuring that outputs are presented as proposals, that no autonomous decisions are made, and that human oversight remains required.

4B. Regulatory data validation

Given the role of Hoodin Compliance Studio in supporting regulatory reasoning, validation of regulatory data is a key component of the overall validation approach.

Data validation activities focus on ensuring that regulatory information used within the system is relevant, traceable, and suitable for its intended use.

These activities include:

Source validation

Regulatory sources are identified and reviewed to ensure they originate from credible and authoritative bodies.

Reference integrity

Links to official regulatory sources are verified to ensure accessibility and correctness.

Jurisdictional mapping

Regulatory instruments are associated with the correct jurisdictions and regulatory domains to support accurate scope identification.

The purpose of these activities is not to guarantee completeness of all regulatory frameworks, but to ensure that the data used within the system is sufficiently reliable for its intended use.

Verification activities are linked to system behaviour and requirements through the structured development lifecycle, supporting traceability between intended functionality and implemented features.

These activities are designed to support regulatory reasoning with reliable source-based information, rather than to establish exhaustive regulatory coverage.

4C. Validation against intended use

Validation of Hoodin Compliance Studio focuses on confirming that the system is fit for its intended use as a regulatory decision-support system.

Validation activities assess whether the system supports users in:

• identifying relevant regulatory frameworks

• structuring regulatory scope

• documenting regulatory reasoning and rationale

• maintaining awareness of regulatory changes

Validation is performed through a combination of internal testing and user-based evaluation under realistic usage conditions.

These activities confirm that the system supports regulatory work in a controlled and predictable manner, without performing regulatory decisions or replacing professional judgement.

5. Relationship to release notes and system transparency

Release notes are used as a transparency and governance mechanism in relation to validation and continued qualification of Hoodin Compliance Studio.

Release notes highlight changes that may affect how the system is understood or used in regulatory work. They are not intended to serve as a complete technical change log or as a record of internal development activity.

Changes communicated through release notes typically include:

• modifications to system behaviour that may influence regulatory reasoning,

• changes to workflows or interactions that affect how users rely on the system,

• clarifications related to system scope, limitations, or usage assumptions.

Minor technical updates, visual refinements, and internal refactoring that do not affect regulatory use or interpretation are intentionally excluded.

By distinguishing regulatorily relevant changes from purely technical updates, release notes enable organisations to maintain awareness of system evolution and assess whether internal review is warranted. Release notes function as a governance artefact rather than as a product marketing channel.

5A. Ongoing verification and validation

Verification and validation are continuous activities performed throughout the system lifecycle.

This includes:

Change assessment

System changes are reviewed prior to release to determine whether they affect system behaviour, user interaction, or reliance on system outputs.

Release-based verification

Each release is subject to verification activities to ensure that implemented changes function as intended and do not introduce unintended effects.

Monitoring of system behaviour

System behaviour, including AI-supported functionality, is monitored to ensure continued alignment with defined system boundaries and intended use.

This approach ensures that the system remains controlled, predictable, and aligned with its intended use over time.

This ensures that verification and validation remain aligned with system evolution without introducing unnecessary process overhead.

6. Limitations and exclusions

This section defines the boundaries of the validation approach described in this document.

The validation approach does not cover, and is not intended to replace:

Customer-specific validation or qualification activities. Organisations remain responsible for determining whether and how Hoodin Compliance Studio should be qualified within their own quality management systems, based on internal procedures and risk assessments.

Validation of regulatory decisions, conclusions, or applicability determinations made by users. Hoodin Compliance Studio supports regulatory reasoning but does not generate binding outcomes.

Validation of external regulatory sources, standards, guidance documents, or third-party content referenced through the system.

Validation against specific regulatory frameworks or compliance standards unless explicitly stated in separate documentation.

Any form of compliance guarantee, regulatory approval, or audit outcome. Responsibility for regulatory compliance remains with the user organisation.

These exclusions are intended to clearly delineate responsibilities between Hoodin as a system provider and customers as regulatory actors, not to disclaim accountability for system quality within Hoodin’s defined scope.

Verification and validation activities performed by Hoodin are limited to ensuring system quality, behaviour, and suitability for intended use, and do not extend to guaranteeing regulatory correctness across all possible use contexts.

7. Use of this document in audits and procurement

This document is intended to support structured discussions during audits, procurement reviews, and internal assessments related to the use of Hoodin Compliance Studio.

For procurement and vendor assessment purposes, the document explains how Hoodin positions the system from a validation perspective, what vendor-level controls are in place, and what level of customer qualification is typically appropriate. It is designed to support informed decision-making without requiring access to internal development or quality system documentation.

For audit and inspection contexts, the document may be used to demonstrate that a proportionate, risk-based approach has been applied when assessing Hoodin Compliance Studio as a regulatory support system. It supports justification of why formal computer system validation activities are not required for this type of system, while evidencing awareness of system scope, limitations, and governance.

This document is not intended to be submitted as evidence of system validation and does not replace customer-specific documentation or internal procedures. It serves as a reference to support transparency, understanding, and alignment between Hoodin and its customers.

7A. Verification and validation responsibilities

Verification and validation activities are performed within Hoodin’s controlled development and quality framework.

Responsibilities are distributed as follows:

Development team

Responsible for implementation-level verification, including functional testing and regression control.

Quality function

Responsible for oversight of validation approach, review of system behaviour in relation to intended use, and ensuring alignment with defined system boundaries.

Product and domain expertise

Supports validation of regulatory relevance and system behaviour in realistic regulatory contexts

7B. Verification methods

Verification is performed using a combination of:

• scenario-based functional testing aligned with system use cases

• regression testing to ensure stability across releases

• review of system outputs in controlled contexts

• validation of system constraints, particularly for AI-supported functionality

The objective is to confirm that system behaviour is consistent, predictable, and aligned with defined requirements and intended use.

The methods applied are intentionally pragmatic and aligned with the scale of the system and organisation.