1. Purpose and scope

This document defines the verification and validation approach for Compliance Studio and explains how it supports customer assessment of the system.

It distinguishes between:

• Verification: evaluating whether implemented functionality meets defined requirements.

• Validation: evaluating whether functionality supports intended user needs under representative conditions.

• Customer qualification: determining whether the system and available evidence are suitable for a specific organisational use.

This document supports regulatory, quality, IT, procurement and audit discussions. It describes the assessment framework rather than certifying the validation status of every function or release. Evidence of completed activities is held in the corresponding assessment records.

The system’s intended use and boundaries are defined in System overview & intended use. References to functions in this document apply to their implemented and released scope.

2. Intended use and validation principles

Compliance Studio supports regulatory professionals in establishing and maintaining Regulatory Positions for products and companies across markets.

Assessment follows six principles:

• Intended use: requirements and evaluations relate to defined regulatory activities and user needs.

• Risk proportionality: assessment depth reflects the consequences of incorrect behaviour, omissions, data loss or inappropriate access.

• Traceability: requirements, assessment methods, results, findings and acceptance decisions are linked.

• Professional oversight: AI-generated proposals remain distinct from user-reviewed regulatory conclusions.

• Evidence-based acceptance: conclusions are limited to the functionality, configuration and conditions assessed.

• Lifecycle control: changes, defects and user experience inform further assessment.

  
  

Decision-support status does not remove the need to assess risk. Incorrect or missing information may influence regulatory work even where a person makes the final decision.

Relationship to customer frameworks

Customers may assess Compliance Studio within frameworks such as ISO 13485, GAMP 5, applicable EU GMP requirements or requirements for electronic records.

Their relevance depends on the customer’s intended use and applicable obligations.

These references do not constitute a claim of certification, conformity or universal applicability.

Functional descriptions relevant to records, access and traceability are provided in the applicable system and security documentation. Customers determine whether these capabilities, together with their configuration, procedures and validation evidence, are sufficient for their intended use and applicable requirements. For 21 CFR Part 11, this includes identifying the electronic records and signatures subject to applicable predicate rules.

This document does not provide a clause-by-clause compliance assessment against these frameworks.

3. Hoodin’s verification and validation approach

3.1 Requirements and assessment planning

Assessment starts with defined user needs, user stories, requirements and observable acceptance criteria.

The assessment record identifies:

• The function and intended user activity.

• Relevant risks and foreseeable failure conditions.

• The assessment method and required evidence.

• The system version, configuration and environment.

• Responsibilities for execution, review and acceptance.

The method must be capable of demonstrating the relevant requirement. A recorded demonstration may support usability validation but cannot replace technical testing of permission boundaries or data integrity.

3.2 Risk and assessment depth

Assessment considers the consequence of failure, the likelihood of occurrence and the ability of established controls to detect or contain the failure.

The following examples illustrate proportionality. They are not formal software safety classes or EU AI Act risk classifications.

Simple presentation changes may require limited assessment. Changes affecting access, record integrity or material regulatory reliance require stronger evidence and scrutiny.

3.3 Functional verification

Verification covers the requirements relevant to implemented functionality.

Methods include scenario-based testing, automated or manual checks, negative testing and inspection of outputs. Regression testing targets existing behaviour that could be affected by a change.

3.4 Validation against user needs

Validation evaluates whether users can complete representative regulatory activities and understand the resulting information.

Scenarios include establishing a position, reviewing regulatory scope, documenting rationale, investigating provisions, assessing Signals and using Studio Agent for analysis or planning.

Evaluation considers whether users can:

• Complete the intended task.

• Understand the available context and evidence.

• Recognise missing information and uncertainty.

• Distinguish proposals from reviewed conclusions.

• Retrieve and use the resulting records appropriately.

Methods may include structured evaluation by regulatory professionals, realistic task walkthroughs and review of user feedback against defined needs.

3.5 Test environments and configuration

Assessment records identify the environment and relevant configuration used, including the application build or other available version identifier.

Where AI behaviour is assessed, relevant configuration includes model identifiers, system instructions, context handling and connected processing components where these are identifiable. Known limitations in identifying or fixing a third-party configuration are recorded.

Differences between the assessment environment and production are evaluated for their effect on the results. Test data must be suitable for the scenario and handled in accordance with applicable security and privacy controls.

Release assessment establishes the relationship between the tested build and the build selected for deployment. Changes made after testing require an impact assessment and additional testing where necessary.

3.6 Findings, deviations and acceptance

A failed acceptance criterion or unexpected result is recorded with the affected requirement, observed behaviour, supporting evidence and potential consequence.

Handling comprises:

1. Assessing the significance and affected scope.

2. Assigning responsibility for investigation and correction.

3. Determining whether release or use must be restricted.

4. Implementing and verifying the correction.

5. Assessing relevant regression and retrospective effects.

6. Recording review and closure.

Acceptance with an unresolved finding requires a documented justification, authorised decision, any interim controls and responsibility for follow-up. Findings that prevent acceptable use of affected functionality must be resolved or that functionality restricted before release.

Assessment records distinguish acceptance, conditional acceptance and non-acceptance. They identify the executor, reviewer, date, result and unresolved conditions.

4. Evaluation of AI-supported functionality and regulatory data

4.1 AI-supported functionality

AI evaluation addresses both output quality and the controls governing its use.

Relevant assessment areas include:

• Correct use of available product, company, market and regulatory context.

• Relevance and source support for proposed applicability or interpretation.

• Material omissions, unsupported claims and inappropriate certainty.

• Handling of incomplete, conflicting or ambiguous information.

• Separation of exploratory assumptions from established facts.

• Preservation of the distinction between proposals and user-reviewed decisions.

Representative scenarios use defined review criteria. Repeated evaluation is appropriate where output variability could materially affect the assessment.

Successful evaluation does not establish that every future answer will be correct. Professional review remains necessary.

4.2 Regulatory data quality

Data assessment concerns how Compliance Studio obtains, associates and represents regulatory information.

Checks address source identity, reference integrity, jurisdiction, recorded legal status, dates, amendments and associations between instruments, provisions and Signals.

An accessible official source does not establish that the system has represented or interpreted it correctly. Where sampling is used, its scope, selection basis and limitations are recorded.

Findings inform correction and consideration of whether similar records or processing steps may be affected. These activities do not guarantee exhaustive regulatory coverage.

4.3 Traceability and data integrity

Assessment addresses supported operations for saving, retrieving, modifying, versioning and exporting information.

Register history does not imply comprehensive logging of all AI interactions, reviews or formal approvals. Claims about traceability must match the records captured by the relevant function.

For exports or integrations, responsibilities and assessment boundaries must be defined. Verification of an output does not validate the receiving system or the customer’s complete workflow.

4.4 AI-related requirements

Applicable AI requirements are considered when defining system and organisational controls.

For example, relevant Article 50 transparency obligations under the EU AI Act can require assessment of user information and output identification mechanisms. Article 4 competence measures require appropriate instruction and organisational evidence; functional testing alone does not demonstrate their fulfilment.

The AI Literacy Statement addresses user understanding, output status and professional review. This document does not constitute an EU AI Act conformity assessment or risk-classification decision.

5. Change assessment and continued suitability

Changes are assessed for potential effects on intended use, information integrity, access, user understanding and reliance on outputs.

Assessment includes relevant changes to application functions, AI models or instructions, context handling, data processing, sources, permissions, infrastructure, exports and integrations.

The outcome determines necessary verification, regression testing, validation and communication. A technical or visual change can require assessment where it affects a relevant control.

Release information supports customer awareness of changes affecting use. It complements internal change and assessment records.

Reported problems inform investigation and correction. Where existing records or earlier outputs may be affected, retrospective impact is considered and relevant communication determined.

This document is reviewed when significant changes occur in intended use, assessment methods, functionality or applicable requirements, or when material findings indicate that the approach requires revision. An unchanged document date is not evidence that a particular software release has been assessed.

6. Customer assessment and qualification

Customers define their organisational use and determine the evidence necessary to support it.

Supplier acceptance does not automatically establish suitability for every customer workflow.

This document asserts no general exemption from computerised system validation. Formal validation activities and their documentation depend on intended use, applicable requirements and customer procedures.

Where outputs support QMS activities, customers define how they are reviewed, approved, transferred and maintained, including relevant references, rationale, status, ownership and version information.

7. Responsibilities and available evidence

7.1 Responsibilities and competence

These are functional responsibilities and may be combined within a small team.

Review arrangements reflect risk. Where risk warrants review by someone other than the implementer or assessment executor, that review is assigned and recorded. External expertise may supplement internal competence where needed.

7.2 Supporting evidence

Relevant evidence categories include:

• Requirements and acceptance criteria.

• Risk and change assessments.

• Verification results and user-validation records.

• Identification of tested versions and configurations.

• Findings, corrective work and retest results.

• Acceptance decisions and unresolved conditions.

• Release information and known limitations.

This list describes evidence categories within the approach. Availability for a particular function or release must be confirmed from actual records. Planned activities are distinguished from completed assessments.

Customers may request supporting evidence through quality@hoodin.com, identifying their intended use and assessment needs.

Disclosure may take the form of summaries, selected records or controlled review, subject to availability, confidentiality, security and third-party restrictions. If requested evidence is unavailable or does not cover the intended use, that limitation is identified so the customer can determine any additional assessment required.

8. Limitations and related documents

Verification and validation provide evidence within defined conditions. They do not guarantee complete regulatory discovery, correctness of every AI output, suitability for unassessed uses, regulatory approval or a particular audit outcome.

These limitations do not remove Hoodin’s responsibility for system quality within its defined scope and contractual commitments.

Related documentation includes:

• System overview & intended use.

• AI Literacy Statement.

• Security & data handling overview.

• Privacy Policy and applicable data processing terms.

• Procurement & vendor information.

• Procurement questionnaire companion.

• Terms and Conditions and relevant release information.

Document revision history