Document Control

Purpose

This procedure establishes requirements for the control of documents within the the Rygen AI Management System.

Scope

This procedure applies to all AIMS documents including policies, procedures, records, and forms. The specific identification and formatting rules in Section 3.1 apply to core governance documents classified as the AIMS Handbook (e.g., policies, procedures, processes). Other records (e.g., risk assessments, meeting minutes) must be identifiable and controlled, but may follow tooling-specific formats.

Document Control Requirements

Document Identification and Formatting

All documents within the AIMS Handbook shall be created as markdown (.md) files and include the following:

Front Matter

Each document must begin with a YAML front matter block containing at least these fields:

• id: A unique identifier matching the filename convention (e.g., AI-006).
• version: The document version number (e.g., 1.0, 1.1).
• visibility: The document’s classification (e.g., Public, Internal, Confidential).
• authors: The names of the individuals responsible for the document’s content.
• reviewers: The roles with authority to review the document.
• next_review_date: The date by which the next periodic review must be completed.

Filename Convention

AIMS Handbook documents must follow a standardized filename format: [ID]-[document-slug].md.

• ID Format: AI-XXX, where AI is the prefix for AIMS documents and XXX is a unique, zero-padded three-digit number (e.g., AI-001).
• Example: AI-006-document-control-procedure.md

Storage and Access

Primary Location: The AIMS Handbook is maintained in the “AIMS Handbook” GitLab repository.

• Access: Read access for all employees. Write/merge access is restricted to the Principal AI Engineer and designated administrators.
• Backup: Version history and backups are managed automatically through GitLab.

Version Control and Change Management

Version control is managed via GitLab. The following process applies to changes in the AIMS Handbook:

Minor Changes (e.g., typo fixes, clarifications): Increment the version number by a minor step (e.g., 1.0 to 1.1). These changes can be merged by the document owner.

Major Changes (e.g., process overhauls, scope changes): Increment the version number by a major step (e.g., 1.1 to 2.0). These changes require formal approval as defined in section 3.4.

Revision History: All changes, regardless of size, must be documented in the document’s “Revision History” table. The entry must include the new version number, the author of the change, the date, and a brief note summarizing the nature of the update.

Compliance Verification for Operational Documents

Operational governance documents—such as impact assessments, risk assessments, system specifications, and monitoring plans—must comply with the requirements of their source procedures (e.g., AI-009, AI-008). Unlike handbook documents (policies, procedures), these operational documents have specific required fields and content mandated by their source procedures.

Verification Requirements

When creating or revising operational governance documents, the document owner must verify that all requirements of the source procedure are met:

1. For new documents: Use the approved template from /content/templates/ and complete all required fields. Do not remove or skip fields marked as required by the source procedure.

2. For major revisions (version X.0): Before submitting changes for review, verify that the revision does not remove required content. Consult the compliance checklist for the document type (when available).

3. For minor revisions (version X.Y): Verify that clarifications or corrections do not inadvertently remove required content. Consult the compliance checklist for the document type (when available).

Compliance Checklists

Procedure-specific compliance checklists define the required fields and content for each operational document type. These checklists are maintained in the governance repository and referenced during document creation and revision.

Automated Validation

Pre-commit hooks in the governance repository validate document structure and required fields before changes can be committed. These automated checks help prevent accidental removal of required content during revisions.

• Pre-commit validation runs automatically when committing changes
• Validation failures must be resolved before the commit can proceed
• Automated validation supplements but does not replace manual compliance verification

Review and Approval

All aspects of the handbook (e.g. policies and procedures) must be approved by the CTO. Review and approval of AIMS internal documentation produced during the operation of the AIMS (e.g. specifications, assessments, etc) are approved by the relevant document owners.

Periodic Reviews

Document owners are responsible for reviewing documents by their next review date. This review is managed and documented using a GitLab Merge Request (MR).

If changes are required: The owner creates an MR with the necessary updates. The approval and merge of this MR serve as the formal approval record. The changes are summarized in the Revision History table.

If no changes are required: The owner must still create an MR. The only change in this MR will be to update the next_review_date in the front matter. The MR description must state that the periodic review was completed and no substantive changes were necessary. The approval and merge of this MR serves as the auditable record of the review.

3.5 Resource Documentation

Resources used within the AIMS are documented per ISO 42001 A.4.2-A.4.6:

Generic lifecycle resources are documented in AI-013 (AI System Development Lifecycle), which defines typical resource requirements for each development phase.

System-specific resources are documented in each AI System Design Specification, which identifies the actual resources used by that particular system.

When resources change, the relevant documentation (AI-013 or system specifications) is updated following the version control and change management process defined in Section 3.3.

Distribution and Communication

All current, approved documents are available on the main branch of the GitLab repository. The AIMS Handbook is available publicly through GitLab Pages.

Major updates are announced via the #general Slack channel.

Retention

• Policies/Procedures: Retain current + previous version
• Assessments: 3 years minimum
• Audit Records: 3 years minimum
• Training Records: Duration of employment + 3 years
• Incident Records: 3 years minimum

Responsibilities

• Principal AI Engineer: Maintain the AIMS document control system and approve procedural documents.
• CTO: Approve all policies and major revisions to the AIMS Handbook.
• Document Owners: Ensure their assigned documents remain accurate and are reviewed on schedule.
• All Staff: Responsible for using the current, approved versions of documents available in the GitLab repository.

Integration with Existing Systems

This procedure supplements Rygen’s existing document control by adding AIMS-specific requirements. Where not specified here, follow standard company document management practices.

Revision History