R-TF-012-030 Software Configuration Management Plan

Purpose

This document defines the software configuration management plan for the device. It establishes the policies, procedures, and tools used to:

• Identify and uniquely label all software configuration items
• Control and track changes to source code and configuration items
• Ensure reproducibility and traceability of all software builds
• Manage releases through a structured branching, tagging, and review workflow
• Maintain configuration status accounting and audit capabilities
• Verify configuration management activities through periodic audits

This plan fulfills the configuration management requirements of IEC 62304 clause 8:

IEC 62304 Clause	Requirement	Section in This Document
8.1.1	Establish means to identify configuration items	Configuration Identification
8.1.2	Identify SOUP configuration items	SOUP Identification
8.1.3	Identify system configuration documentation	Configuration Identification
8.2.1	Approve change requests	Pull Request Workflow
8.2.2	Implement changes	Branching Strategy, Pull Request Workflow
8.2.3	Verify changes	Pull Request Workflow, Release Candidate Verification
8.2.4	Provide means for traceability	Traceability
8.3	Configuration status accounting	Configuration Status Accounting

Problem and change request tracking is managed through GitHub Issues as described in the Traceability section. The analysis and approval of change requests follows the Pull Request Workflow.

Scope

This plan applies to all software configuration items of the device. A configuration item is any artifact under configuration management control that can be uniquely identified at a given reference point. Configuration items include:

• Application source code
• Build configurations and build system files
• Third-party dependencies (SOUPs)
• Automated tests and test configurations
• Deployment scripts and infrastructure definitions
• Configuration files that affect software behavior

This plan must be reviewed, updated, and approved whenever changes occur to the design, development process, or tooling.

Terminology

Term	Definition
Baseline	A formally approved set of configuration items that serves as the basis for further development and can only be changed through formal change control procedures
Bazel	A build system that compiles, tests, and packages software with deterministic, reproducible outputs
CI (Continuous Integration)	Practice of frequently integrating code changes and automatically verifying them through builds and tests
Configuration item	Any artifact under configuration management control that can be uniquely identified at a given reference point
Git	A distributed version control system used to track changes in source code
Git branch	A lightweight, movable pointer to a commit in a repository's history
Git cherry-pick	A Git command that applies a specific commit from one branch to another without merging the entire source branch
Git commit	A snapshot of the repository at a particular point in time
Git commit SHA	A 40-character hexadecimal string that uniquely identifies a commit
Git commit short SHA	The first 7-10 characters of the full SHA, sufficient to identify a commit within a repository
Git tag	An immutable reference that points to a specific commit, used to mark releases
GitHub Actions	A CI/CD platform integrated with GitHub that automates build, test, and deployment workflows
GitHub Issue	A tracking item in GitHub for bugs, enhancements, or other work requests
GitHub Repository	A cloud-hosted Git repository providing centralized storage for source code and configuration files
Hotfix	An urgent bug fix applied to a version already deployed in production, resulting in a patch release
PR (Pull Request)	A mechanism to propose changes from one branch to another, enabling code review before integration
Release branch	A long-lived branch that isolates a version line for stabilization and maintenance
Release candidate (RC)	A pre-release version intended for final verification before the official release
Safety-critical code	Code that directly implements or affects risk control measures, medical algorithms, data integrity safeguards, or functionality whose failure could lead to patient harm or incorrect clinical decisions. Examples include diagnostic algorithms, and data validation for clinical inputs.
SOUP	Software of Unknown Provenance — third-party software not developed under the company's quality management system
Squash merge	A merge strategy that combines all commits from a branch into a single commit on the target branch

Roles and Responsibilities

Effective configuration management requires clear accountability. The following roles have specific responsibilities under this plan:

Role	Responsibilities
Developer	Create branches following naming conventions; write code with traceability to GitHub Issues; submit PRs with complete descriptions; address review feedback; ensure CI passes before requesting merge
Code Reviewer	Verify code correctness, test coverage, and compliance with coding standards; approve or request changes on PRs; ensure traceability requirements are met
Release Manager	Create release branches and tags; coordinate release candidate verification; approve final release tags; maintain VERSION file updates
Quality Assurance	Verify release candidates meet acceptance criteria; approve releases for production deployment; conduct configuration audits
Technical Lead	Resolve merge conflicts that require architectural decisions; approve emergency changes; ensure adherence to this plan

All team members are responsible for following the configuration management procedures defined in this document.

A single individual may hold multiple roles. However, the Code Reviewer for a change must be different from the Developer who authored it to ensure independent verification. For safety-critical changes requiring two reviewers, both reviewers must be independent of the change author.

Tools and Infrastructure

Version Control

We use Git as the version control system, hosted on GitHub. GitHub provides:

• Repository hosting: centralized storage for all source code and configuration files
• Pull Request workflows: structured code review before integration
• Branch protection: enforcement of review and CI requirements before merging
• Continuous Integration: automated build and test pipelines via GitHub Actions
• Issue tracking: linking code changes to bug reports and feature requests
• Access control: role-based permissions for repository access
• Audit logging: immutable record of all repository access and modifications

Every file required to build and deploy the device software is committed to version control.

Build System

We use Bazel as the build system. Bazel manages compilation, testing, and packaging of the device software. All build configurations, dependencies, and build rules are defined in version-controlled files (BUILD.bazel, MODULE.bazel, and dependency lock files) alongside the source code.

Bazel provides:

• Deterministic builds: identical inputs always produce identical outputs
• Reproducibility: any historical build can be recreated from its commit
• Dependency management: explicit declaration and pinning of all dependencies
• CI/CD integration: automated verification of all code changes via GitHub Actions

Continuous Integration Pipeline

GitHub Actions executes the following checks on every Pull Request:

1. Build verification: Bazel builds all targets to verify compilation succeeds
2. Automated tests: Unit tests and integration tests run against the changed code
3. Static analysis: Linters and code quality tools verify coding standards compliance
4. Dependency verification: Lock files are validated to ensure reproducibility

All checks must pass before a PR can be merged. CI logs are retained as quality records.

Repository Backup and Recovery

The GitHub repository serves as the authoritative source for all configuration items. GitHub provides:

• Redundant storage: multiple geographic replicas of repository data
• Point-in-time recovery: ability to restore to any previous commit
• Immutable history: Git's content-addressable storage prevents undetected modification

In the event of GitHub service disruption, developer local clones contain the complete repository history and can serve as recovery sources. Additionally, automated backup procedures maintain off-site copies of the repository in accordance with the company's data backup policy.

Repository Protection Rules

To enforce configuration management policies technically, the following protection rules are configured in GitHub:

Branch protection for main:

• Require pull request before merging
• Require at least one approval
• Require status checks to pass (all CI checks)
• Require branches to be up to date before merging
• Do not allow bypassing the above settings

Branch protection for release/*:

• Same requirements as main
• Additionally, restrict who can push to release branches (Release Manager and Technical Lead only)

Tag protection:

• Protect tags matching v* pattern
• Only Release Manager can create version tags
• Tags cannot be deleted or modified once created

These protections are configured by repository administrators and audited during configuration audits. Any changes to protection rules require Technical Lead approval and must be documented.

Configuration Identification

Configuration Item Naming

Each configuration item type follows a specific naming scheme:

Item Type	Naming Scheme	Example
Build artifact	<name>_<W>.<X>.<Y>.<Z>[-<PreRelease>]+<Build>	md-1.2.3.4+g1511f32b
SOUP	<package-name>_<version>	numpy_1.24.3
Source file	Repository-relative path	src/core/engine.py
Configuration file	Repository-relative path	config/docker-compose.yaml

Build Artifact Naming

Each build artifact is identified using the following scheme:

<configuration-item-name>_<W>.<X>.<Y>.<Z>[-<PreReleaseTag>]+<BuildMetadata>

Component	Description
W.X.Y.Z	Four-digit version number defined in GP-012. W is reserved for exceptional changes, X is major, Y is minor, Z is patch.
PreReleaseTag	Optional. Indicates a pre-release version: dev for development builds on main, or rc1, rc2, etc. for release candidates.
BuildMetadata	The letter g (denoting Git) followed by the commit short SHA, uniquely identifying the source commit.

Examples:

Type	Identifier
Stable release	md-1.2.3.4+g1511f32b
Release candidate	md-1.2.3.4-rc2+g1511f32b
Development build	md-1.3.0.0-dev+g8a2c4f1e

This naming scheme ensures:

• Uniqueness: builds from different commits are distinguished by their build metadata, even when they share the same version number
• Reproducibility: every build can be traced back to its exact source commit

The version number starts at 1.1.0.0.

Version Storage

The canonical version number is stored in a dedicated VERSION file at the repository root. This file is the single source of truth for the current version and must be updated as part of the release process. The build system reads this file to embed version information into build artifacts.

VERSION File Management

The VERSION file reflects the version currently being prepared:

Branch State	VERSION Content	Example
main during development	Next planned version with -dev suffix	1.3.0.0-dev
main at release branch point	Target release version	1.2.0.0
Release branch during stabilization	Target release version	1.2.0.0
Release branch after final tag	Remains at released version	1.2.0.0

After creating a release branch:

1. On the release branch, VERSION remains at the target version (e.g., 1.2.0.0)
2. On main, update VERSION to the next planned version with -dev suffix (e.g., 1.3.0.0-dev)

The -dev suffix clearly distinguishes development builds from release candidates and final releases. If the next version number is uncertain, use the most likely minor increment; the version can be adjusted before the next release branch is created.

Version Increment Rules

Each digit in the version scheme has specific increment rules based on the nature and impact of changes.

W (reserved/exceptional)

Incremented only for foundational changes that substantially alter the intended purpose or platform. Reserved for rare, transformative releases.

X (major)

Incremented for significant feature additions or changes that affect the device's safety or intended use, including:

• Updating the intended use or indications for use
• Changing the significance of information provided to the user
• Changing the intended disease, condition, or expanding the patient population
• Introducing or altering risks that require new control measures
• Significant changes to the algorithm (e.g., AI/ML architecture changes)
• Adding new diagnostic or therapeutic features
• Expanding compatibility with new input sources or data types
• Major cloud infrastructure or architecture changes
• Major updates to the GUI or reporting interfaces that affect medical data presentation

Y (minor)

Incremented for non-substantial modifications that do not affect the device's safety or intended use, including:

• Adding new modules that do not affect medical decision-making
• Extending existing modules with non-critical functionalities
• Algorithm updates using the same methods for development and validation
• Retraining models with new datasets of the same type
• Non-substantial preprocessing changes
• Technology modifications without medical impact
• Minor UI/UX updates that improve clarity without changing information presentation

Z (patch)

Incremented exclusively for bug fixes within a given W.X.Y version line. Patch releases do not introduce new features.

SOUP Identification

SOUPs are identified using the scheme:

<SOUP-package-name>_<version>

Component	Description
SOUP package name	The name of the open-source project, or vendor name combined with the library/software name
Version	The version identifier as provided by the supplier (typically MAJOR.MINOR.PATCH, though format varies by supplier)

SOUPs use the version format defined by their respective suppliers, which may differ from the device's four-digit versioning scheme. This distinction is intentional: SOUP versions are controlled by external parties and must be recorded as provided.

SOUPs are documented in R-TF-012-019 SOUPs.

SOUP Change Control

Changes to SOUP dependencies require additional scrutiny due to their external origin and potential impact on device safety and performance.

Before updating a SOUP:

1. Review the SOUP's release notes and changelog for breaking changes, security fixes, and new features
2. Assess whether the update affects any risk control measures or safety-critical functionality
3. Verify the new version is compatible with other dependencies and the build system

SOUP update classification:

Update Type	When Permitted	Requirements
Security patch	Any release (including patch)	Document the vulnerability addressed; verify fix does not introduce regressions
Bug fix	Minor or patch release	Verify the fix resolves the issue without side effects
Minor version	Minor release	Full regression testing of affected functionality
Major version	Major release	Comprehensive impact assessment; may require re-verification of dependent functionality

After updating a SOUP:

1. Update the SOUP documentation in R-TF-012-019 SOUPs
2. Run the full automated test suite
3. Document the rationale for the update in the PR description

SOUP updates follow the same PR workflow as other changes, with the additional requirement that the reviewer verifies SOUP documentation has been updated.

Baseline Management

A baseline is a formally approved snapshot of configuration items at a specific point in time. Baselines provide stable reference points for development, testing, and release activities.

Types of Baselines

Baseline Type	Trigger	Identification
Development baseline	Creation of a release branch	The commit from which release/W.X.Y branches
Release candidate baseline	Tagging a release candidate	Git tag vW.X.Y.Z-rcN
Production baseline	Tagging a final release	Git tag vW.X.Y.Z

Baseline Characteristics

Each baseline includes:

• All source code files at the tagged commit
• All build configuration files (including dependency lock files)
• The VERSION file specifying the release version
• All automated tests
• All configuration files

Baselines are immutable. Once a Git tag is created, it must never be deleted or moved. Changes to a baselined configuration require creating a new baseline with a new version number.

Branching Strategy

This section defines the branching model used to manage parallel development, stabilize releases, and maintain production versions. The strategy follows a branch-based workflow with short-lived feature branches and long-lived release branches. The main branch serves as the integration branch, receiving all reviewed changes before they flow to release branches.

Overview

The main branch serves as the primary integration branch, containing the latest reviewed and merged code. Development work flows into main through Pull Requests. When a release is ready, a dedicated release branch is created to isolate stabilization from ongoing development.

Branch Types

Type	Naming Convention	Base Branch	Merge Target	Purpose
Feature	feature/<issue-number>-<slug>	main	main	New functionality for a future release
Bug fix	fix/<issue-number>-<slug> or fix/<issue-number>-release-W.X.Y	main or release/*	main or release/*	Corrections to existing functionality
Maintenance	chore/<issue-number>-<slug>	main	main	Refactoring, dependency updates, documentation, tooling
Release	release/W.X.Y	main	—	Stabilization and maintenance line for a version

Naming Conventions

• Branches: Every branch must reference a GitHub Issue number (e.g., feature/1234-user-invites).
• PR titles: Follow Conventional Commits format (e.g., feat: add user invites (#1234)).
• Release branches: Use the pattern release/W.X.Y where W.X.Y identifies the version line. The branch supports all patch versions (W.X.Y.0, W.X.Y.1, etc.) within that line.
• Tags: Use the pattern vW.X.Y.Z for stable releases and vW.X.Y.Z-rcN for release candidates. The v prefix distinguishes version tags from other tags in the repository.

Feature Branches

Feature branches isolate new functionality until it is ready for integration.

• Branch from: main
• Merge into: main using squash merge
• Naming: feature/<issue-number>-<short-description>

Workflow:

1. Create a feature branch from main.
2. Develop the feature with as many intermediate commits as needed.
3. Open a Pull Request referencing the related GitHub Issue.
4. After review and approval, squash-merge the branch into main.
5. Delete the feature branch after merging.

Squash merge rationale: Squash merging produces a clean, linear history on main where each commit represents a complete, reviewed change. While this loses granular commit history from feature branches, the trade-off is acceptable because: (1) the full history remains available in the closed PR, (2) each main commit is a coherent unit of change, and (3) linear history simplifies release management and debugging.

Maintenance Branches

Maintenance branches handle non-functional changes that do not add features or fix bugs.

• Branch from: main
• Merge into: main using squash merge
• Naming: chore/<issue-number>-<short-description>

Examples of maintenance work:

• Refactoring code without changing behavior
• Updating dependencies (SOUPs) without functional changes
• Improving build configurations or CI pipelines
• Updating internal documentation or code comments

Maintenance branches follow the same workflow as feature branches.

Bug Fix Branches

Bug fix branches correct defects in existing functionality. The workflow depends on where the bug exists and when it was discovered:

Situation	See Section
Bug in unreleased code on main	This section
Bug found during release candidate testing	Fixing Bugs in a Release Candidate
Bug in a version already deployed to production	Fixing Bugs in a Stable Release (Hotfixes)

All bug fixes follow the same PR workflow as feature branches but have specific rules for targeting release branches.

Naming Convention:

Target Branch	Naming Pattern	Example
main	fix/<issue-number>-<slug>	fix/2431-null-pointer-login
release/W.X.Y	fix/<issue-number>-release-W.X.Y	fix/2431-release-1.2.0

Requirements:

Every bug fix must:

• Reference a GitHub Issue in the PR (e.g., Closes #2431)
• Follow Conventional Commits format for the PR title (e.g., fix: guard null session (#2431))
• Include a regression test that would fail if the bug were reintroduced
• Pass all CI checks before merging

Workflow by bug location:

Bug Location	Fix On	Then...
Only on main (unreleased code)	main	Done
On main and release branch(es)	main	Cherry-pick to each affected release/W.X.Y
Only on a release branch	Release	Optionally add defensive code to main

Best practices:

• Always fix on main first when the bug exists there. This ensures the fix is not lost when future releases branch from main.
• Use cherry-pick, never merge: Merging main into a release branch would introduce unrelated changes. Always cherry-pick specific commits.
• Keep fixes minimal: Patch releases should contain only the necessary bug fix. Refactors, improvements, and new features belong in minor or major releases.
• Handle cherry-pick conflicts: If the cherry-pick does not apply cleanly due to code divergence:
  1. Create a fix branch from the release branch: fix/<issue-number>-release-W.X.Y
  2. Manually adapt the fix to work with the release branch codebase
  3. Reference the original main fix commit in the PR description to maintain traceability
  4. The adapted fix still requires PR review and must pass CI before merging
• Test the cherry-pick: Whether directly cherry-picked or manually adapted, verify the fix works correctly in the release branch context. The surrounding code may differ from main, potentially affecting behavior.

Release Branches and Tags

Release branches isolate a specific version line for stabilization and long-term maintenance. Once created, a release branch receives only bug fixes — never new features. This allows main to continue accepting new work while the release stabilizes.

• Branch from: main
• Naming: release/W.X.Y (the branch serves all patch versions in that line: W.X.Y.0, W.X.Y.1, etc.)
• Tags: vW.X.Y.Z for stable releases; vW.X.Y.Z-rcN for release candidates
• Lifetime: Release branches are retained indefinitely to support hotfixes for deployed versions

Release Readiness Criteria

Before creating a release branch, verify that main meets these criteria:

• All features targeted for this release have been merged
• No critical or major bugs remain unresolved
• Any remaining minor bugs do not affect safety, core functionality, or intended use
• All CI checks pass on the target commit

Creating a Release Branch

When main is ready for release, the Release Manager creates a release branch and tags the first release candidate:

1. Update the VERSION file on main to reflect the target version.
2. Create release/W.X.Y from the target commit on main.
3. Tag vW.X.Y.0-rc1 on the release branch.
4. Update the VERSION file on main to the next development version (e.g., W.X.(Y+1).0-dev).
5. Build and deploy the release candidate to a verification environment.

After the release branch is created, main remains open for new features targeting future releases. There is no freeze on main.

Release Candidate Verification

Each release candidate undergoes verification testing. If issues are found:

1. Fix the bug (see Fixing Bugs in a Release Candidate below).
2. Tag a new release candidate (vW.X.Y.0-rc2, -rc3, etc.).
3. Repeat verification until all issues are resolved or accepted.

When verification passes, tag the final release (vW.X.Y.0) on the release branch.

Fixing Bugs in a Release Candidate

When a bug is found during release candidate testing, the fix strategy depends on whether the bug also affects main:

Bug exists on both main and the release branch:

1. Create a fix branch from main: fix/<issue-number>-<slug>.
2. Implement the fix with regression tests.
3. Merge to main via PR (squash merge).
4. Create a fix branch from release/W.X.Y: fix/<issue-number>-release-W.X.Y.
5. Cherry-pick the fix commit(s) from main.
6. Merge to release/W.X.Y via PR.
7. Tag the next release candidate.

Bug only affects the release branch (e.g., caused by a release-specific configuration):

1. Create a fix branch from release/W.X.Y: fix/<issue-number>-release-W.X.Y.
2. Implement the fix with regression tests.
3. Merge to release/W.X.Y via PR.
4. Tag the next release candidate.
5. Optionally, add defensive code to main to prevent similar issues.

If CI fails after merging to the release branch:

When a cherry-picked or adapted fix causes CI failures on the release branch:

• Do not revert immediately — assess whether the failure is in the fix itself or reveals a pre-existing issue
• Create a new fix branch from the release branch to address the failure
• If the failure indicates the original fix is incompatible with the release branch, develop an alternative fix specific to that branch
• The release candidate tag should only be created after CI passes

Never force-push to a release branch or delete commits to "fix" CI failures. All changes must go through the normal PR workflow to maintain traceability.

Fixing Bugs in a Stable Release (Hotfixes)

When a bug is discovered in a version already deployed to production, follow this hotfix workflow:

1. Locate the release branch: The branch release/W.X.Y should already exist from the original release process.
2. Fix the bug: Apply the fix using the same rules as for release candidates — fix on main first if applicable, then cherry-pick to the release branch.
3. Increment the patch version: Tag vW.X.Y.(Z+1)-rc1 (e.g., if the current version is 1.2.0.0, the hotfix becomes 1.2.0.1-rc1).
4. Verify and release: After verification passes, tag the final version (vW.X.Y.(Z+1)).

Supporting Multiple Active Releases

When multiple versions are deployed in production (e.g., different customers on different versions), each active version line has its own release branch. A single bug fix may need to be applied to multiple branches:

1. Fix the bug on main first.
2. Cherry-pick the fix to each affected release/W.X.Y branch.
3. Tag release candidates and final versions independently for each branch.

Each release branch maintains its own patch version sequence independently.

Release Builds and Deployment

Release builds are generated using Bazel from either a release candidate tag (vW.X.Y.Z-rcN) or a final release tag (vW.X.Y.Z). The build process compiles, tests, and packages the software into deployable artifacts. All build inputs are referenced by their Git commit SHA, ensuring full traceability and reproducibility.

Deployment rules:

• Only commits tagged with a final version (vW.X.Y.Z) may be deployed to production
• Release candidates (vW.X.Y.Z-rcN) are used for verification testing only
• All release tags must be on a release branch, never directly on main
• Deployment follows the procedure defined in the Software Development Plan

Build artifact traceability:

Every build artifact includes the Git commit short SHA in its identifier (see Build Artifact Naming), allowing any deployed artifact to be traced back to its exact source commit and the release branch from which it was built.

Release notes:

Each release must include release notes documenting:

• New features (for minor and major releases)
• Bug fixes included in this release
• Known issues or limitations
• Any changes to system requirements or compatibility

Pull Request Workflow

All code changes follow a Pull Request workflow that validates changes against the base branch before integration.

1. The developer creates a PR from a feature, fix, or maintenance branch.
2. CI automatically runs all automated tests and checks. If any check fails, the developer must resolve the issue before proceeding.
3. The developer assigns reviewers according to the requirements in the Approval Requirements table below.
4. Reviewers examine the changes and may approve, request changes, or add comments.
5. The developer addresses all feedback and marks resolved items as complete.
6. If the base branch has advanced since the PR was created, the developer must rebase before merging.
7. Once approved — with all discussions resolved and CI passing — the developer squash-merges the branch.

Approval Requirements

Change Type	Minimum Reviewers	Additional Requirements
Standard feature/fix	1	CI must pass
Safety-critical code	2	One reviewer must have domain expertise
SOUP updates	1	SOUP documentation must be updated
Build/infrastructure	1	Must not break existing builds

Handling Merge Conflicts

When a PR has merge conflicts with its base branch:

1. Rebase the feature branch onto the latest base branch locally.
2. Resolve conflicts, ensuring the combined code remains correct.
3. Run the full test suite locally to verify the resolution.
4. Force-push the rebased branch (this is the only acceptable use of force-push).
5. Request re-review if the conflict resolution involved significant changes.

CI Failure After Approval

If CI fails after a PR has been approved:

1. The approval is invalidated; the PR cannot be merged.
2. The developer must fix the issue and push new commits.
3. The PR requires re-approval after the fix.

Review Criteria

Reviewers verify the following criteria before approving a Pull Request:

Functional Correctness

• Implementation matches the requirements specified in the linked GitHub Issue
• Business logic correctly handles all expected inputs and edge cases
• Error handling appropriately manages invalid inputs and exception conditions

Test Coverage

• Unit tests cover all new or modified code paths
• Integration tests verify interactions with other software items
• Tests would fail if the defect were reintroduced (regression testing)
• Test assertions are meaningful and verify expected behavior

Code Quality

• Code is readable, maintainable, and follows established coding standards
• Functions and classes have single, well-defined responsibilities
• No unnecessary complexity or obfuscated logic
• Comments explain "why" for non-obvious logic (code explains "what")

Security and Safety

• No security vulnerabilities introduced (SQL injection, XSS, insecure data handling)
• Safety-critical code paths have appropriate error handling and validation
• Changes do not introduce new risks requiring mitigation per GP-013 Risk Management

Integration and Dependencies

• No unintended side effects on other components or modules
• Changes to interfaces are backward-compatible or properly versioned
• SOUP dependencies are documented in R-TF-012-019 SOUPs if added or updated

Documentation

• Code comments and docstrings updated to reflect changes
• User-facing or technical documentation updated if applicable

Traceability

Every code change must be traceable to a GitHub Issue documenting the requirement, bug report, or feature request. This traceability is enforced through:

• Branch names that include the issue number (e.g., feature/1234-user-invites)
• Commit messages that reference the issue (e.g., fix: handle null session (#1234))
• PR titles that follow Conventional Commits and include the issue number
• PR descriptions that use Closes #1234 or Fixes #1234 to automatically close the issue on merge

GitHub automatically creates hyperlinks between issues and code changes, enabling bidirectional traceability from requirements to implementation.

Traceability Verification

Traceability is verified at multiple points:

1. PR creation: CI checks verify that branch names follow the required pattern
2. PR review: Reviewers confirm the linked issue matches the implemented changes
3. Release preparation: Release notes are generated from merged PRs to verify completeness
4. Configuration audits: Periodic audits sample changes to verify traceability chain

Configuration Status Accounting

Configuration status accounting provides visibility into the current state of all configuration items and their change history.

Status Information Maintained

For each configuration item, the following status information is maintained:

Information	Source
Current version	Git tags and VERSION file
Change history	Git commit log
Change author	Git commit metadata
Change date	Git commit timestamp
Related issues	GitHub Issue links in commits
Review status	GitHub PR approval records
Build status	GitHub Actions logs
Deployment status	Deployment records in production systems

Accessing Status Information

• Current baseline: git describe --tags shows the current version relative to the nearest tag
• Change history: git log provides complete history with author, date, and change description
• File history: git log --follow <file> traces changes to a specific configuration item
• Release contents: git log v1.2.0.0..v1.2.0.1 shows all changes between two releases
• Build artifacts: Each artifact identifier includes the commit SHA for traceability

Status Reporting

The Release Manager generates configuration status reports at the following events:

• Before each release candidate tag
• Before each production release
• Upon request for regulatory submissions or audits

Reports include: current baseline version, list of changes since last release, open issues affecting the release, and SOUP version summary.

Configuration Audits

Configuration audits verify that configuration management activities comply with this plan and that configuration items are correctly identified and controlled.

Types of Audits

Audit Type	Purpose	Frequency
Functional Configuration Audit	Verify that configuration items perform as documented	Before each major release
Physical Configuration Audit	Verify that build artifacts match their documented configuration	Before each production release
Process Audit	Verify adherence to configuration management procedures	Annually or upon significant process change

Audit Activities

Functional Configuration Audit:

• Verify that test results demonstrate required functionality
• Confirm that the VERSION file matches the tagged version
• Verify that release notes accurately describe the release contents

Physical Configuration Audit:

• Verify that the build can be reproduced from the tagged commit
• Confirm that all configuration items are present and correctly identified
• Verify that SOUP versions match the documented versions

Process Audit:

• Sample PRs to verify review and approval procedures were followed
• Verify that branch naming conventions are being followed
• Review emergency change records for proper documentation

Audit Records

Audit findings are documented in configuration audit reports and retained as quality records. Non-conformances identified during audits are addressed through the corrective and preventive action (CAPA) process.

Emergency Changes

In exceptional circumstances where a critical production issue requires immediate resolution, the following expedited process may be used:

Authorization

Emergency changes require approval from the Technical Lead or designee before implementation. The approver must verify that:

• The issue is genuinely critical (affects patient safety, data integrity, or system availability)
• Standard procedures cannot be followed due to time constraints
• The proposed fix is the minimum change necessary

Expedited Process

1. Verbal approval: Obtain verbal approval from the Technical Lead.
2. Minimal change: Implement the minimum change necessary to resolve the issue.
3. Expedited review: At least one reviewer must approve the change before merge.
4. Deploy and monitor: Deploy the fix and actively monitor for regressions.
5. Post-hoc documentation: Complete all standard documentation (GitHub Issue with full description, complete PR with traceability) within 48 hours of the emergency fix.
6. Root cause analysis: Conduct and document a root cause analysis to prevent recurrence.

Compliance

Emergency changes must still follow version control and tagging procedures. The expedited process reduces review time and defers documentation; it does not bypass configuration management controls. All emergency changes are flagged for review during the next configuration audit.

Non-conformance Handling

When configuration management procedures are not followed, the deviation must be documented and addressed:

1. Identification: Any team member who identifies a deviation reports it to the Technical Lead.
2. Assessment: Evaluate the impact of the deviation on product quality and regulatory compliance.
3. Correction: Take immediate action to correct the deviation where possible.
4. Documentation: Record the deviation, its cause, and corrective actions taken.
5. Prevention: If the deviation indicates a systemic issue, initiate a CAPA to prevent recurrence.

Non-conformances are reviewed during configuration audits.

Configuration Management Operations Summary

Lifecycle Events

Event	Operations
Start development of a new project	Create the repository with a main branch and initial directory structure.
Prepare a new exceptional (W), major (X), or minor (Y) release	Update VERSION file on main to target version; create release/W.X.Y from main; tag vW.X.Y.0-rc1 on the release branch; update VERSION on main to next development version (e.g., W.X.(Y+1).0-dev); begin verification.
Complete a release after verification	Tag vW.X.Y.0 on the release branch; build from tag; archive artifacts; deploy to production.
Release a patch (hotfix) for a deployed version	Fix on main if applicable; cherry-pick to release/W.X.Y; tag vW.X.Y.Z-rc1; verify; tag vW.X.Y.Z; deploy.

Code Modification Procedures

Modification Type	Procedure Reference
Develop a new feature	See Feature Branches.
Modify an existing feature	Same as developing a new feature.
Perform maintenance (refactoring, dependencies)	See Maintenance Branches.
Fix a bug in unreleased code	See Bug Fix Branches (fix on main only).
Fix a bug in a released version	See Fixing Bugs in a Stable Release (Hotfixes).
Fix a bug found during release candidate testing	See Fixing Bugs in a Release Candidate.
Handle an emergency production issue	See Emergency Changes.

Signature meaning

The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:

• Author: Team members involved
• Reviewer: JD-003 Design & Development Manager, JD-004 Quality Manager & PRRC
• Approver: JD-001 General Manager