IGB-DOC-005¶

Version Control Policy¶

Document ID : IGB-DOC-005

Title : Version Control Policy

Version : v1.0

Status : Approved

Owner : IGB Engineering

Last Update : 2026-08

Revision History¶

Version	Date	Description
v1.0	2026-08	Initial controlled release

1. Purpose¶

This document establishes the version-control policy for controlled engineering documentation, engineering source files, configuration artifacts, and related engineering repository content maintained by IGB Engineering.

The purpose of version control is to ensure that engineering artifacts remain:

identifiable;
traceable;
reviewable;
reproducible;
recoverable;
change-controlled; and
attributable to an authoritative repository history.

Version control shall provide the historical record necessary to determine what changed, when it changed, and under which controlled revision the change was introduced.

2. Scope¶

This policy applies to controlled engineering content maintained within the IGB Engineering Platform repository, including:

engineering documentation;
architecture artifacts;
engineering specifications;
engineering standards;
source code;
configuration files;
automation scripts;
templates;
engineering data;
verification and validation artifacts;
release artifacts;
repository governance artifacts; and
other content explicitly designated as version-controlled engineering material.

This policy establishes governance requirements.

Operational Git procedures and detailed developer workflows shall be governed by the applicable Git Workflow Standard, including IGB-DOC-006.

3. Authority¶

This document is subordinate to the IGB documentation and engineering governance hierarchy.

3.1 IGB-DOC-001 — Documentation Architecture¶

IGB-DOC-001 defines the overall documentation architecture and documentation authority.

Where a conflict exists between this document and IGB-DOC-001, IGB-DOC-001 shall take precedence.

3.2 IGB-DOC-002 — Documentation Style Guide¶

IGB-DOC-002 governs controlled-document presentation and formatting.

This document does not override the presentation requirements established by IGB-DOC-002.

3.3 IGB-DOC-003 — File Naming Convention¶

IGB-DOC-003 governs controlled file naming.

Version-controlled artifacts shall comply with the applicable naming requirements established by IGB-DOC-003.

3.4 IGB-DOC-004 — Engineering Drawing Standard¶

IGB-DOC-004 governs engineering drawing requirements.

Engineering drawing revisions maintained under version control shall preserve the drawing identity, revision traceability, and canonical repository authority defined by the applicable drawing standard.

3.5 IGB-DOC-006 — Git Workflow Standard¶

IGB-DOC-006 defines the operational Git workflow used to implement the version-control requirements established by this policy.

Where this policy establishes governance requirements and IGB-DOC-006 establishes operational procedures, the governance requirements of this document shall take precedence.

No subordinate document shall override the authority of a higher-level governing document.

4. Definitions¶

4.1 Version Control¶

A controlled mechanism for recording, identifying, and retrieving successive states of an engineering artifact.

4.2 Revision¶

A distinct controlled state of an artifact resulting from an authorized change.

4.3 Commit¶

A recorded repository change set representing a controlled state transition within a version-control system.

4.4 Branch¶

A version-control development line used to isolate or organize changes before integration.

4.5 Tag¶

A persistent repository reference identifying a specific controlled revision.

4.6 Baseline¶

A formally identified and controlled set of artifacts representing an approved engineering state.

4.7 Release¶

A controlled publication of a defined artifact or artifact set for a specified purpose.

4.8 Canonical Source¶

The single active repository location recognized as the authoritative source for a controlled artifact.

4.9 Obsolete Revision¶

A superseded revision that shall no longer be treated as the active authoritative revision.

5. Version-Control Principles¶

Version control within the IGB Engineering Platform shall follow these principles:

Every controlled artifact shall have an identifiable version history.
Changes shall be attributable to a repository history.
The active revision shall remain identifiable.
Approved baselines shall be reproducible.
Historical revisions shall remain traceable.
Obsolete revisions shall not become alternative active authorities.
Controlled changes shall not silently overwrite historical information.
The canonical repository location shall remain identifiable.
Version-control history shall support engineering review and audit.
Repository state shall remain consistent with the applicable engineering baseline.

6. Repository Control¶

The IGB Engineering Platform repository shall serve as the controlled repository for engineering artifacts designated for repository-based version control.

Controlled artifacts shall be maintained in their designated repository locations.

Repository organization shall remain subject to:

IGB-DOC-001;
applicable engineering architecture;
applicable repository governance;
applicable configuration-management governance; and
applicable engineering standards.

The repository shall not be treated as an uncontrolled file-storage location.

7. Controlled Artifact Identification¶

Every controlled artifact shall be identifiable through sufficient metadata and repository context.

Where applicable, identification shall include:

document or artifact identifier;
title;
version or revision;
status;
ownership;
repository location;
applicable baseline;
applicable change record; and
applicable release or approval information.

A controlled identifier shall correspond to one active canonical artifact.

8. Git Repository Requirements¶

Engineering repositories using Git shall preserve sufficient repository history to support:

change identification;
revision comparison;
authorship attribution;
branch history;
merge history;
release identification;
baseline reconstruction; and
audit traceability.

Repository history shall not be intentionally rewritten when doing so would destroy required engineering traceability.

Any exceptional repository-history operation shall be governed by the applicable engineering governance and configuration-management requirements.

9. Branch Control¶

Branches shall be used to isolate controlled development activity where required.

Branch usage shall preserve a clear relationship between:

development work;
review activity;
integration;
release preparation; and
the resulting controlled revision.

Branches shall not be used to establish competing permanent authorities for the same controlled artifact.

Detailed branch naming and operational procedures shall be defined by IGB-DOC-006.

10. Commit Control¶

Commits shall represent meaningful and traceable engineering changes.

A controlled commit should provide sufficient information to determine:

what changed;
why the change was made;
the affected engineering context; and
the resulting repository state.

Commit history shall not be intentionally used to conceal engineering changes.

Where a change is associated with a formal engineering change record, review, issue, requirement, or decision, the applicable traceability reference shall be preserved.

11. Merge and Integration Control¶

Changes shall be integrated into controlled branches through an authorized process.

Integration shall preserve:

change history;
authorship;
review traceability;
affected artifact identity;
applicable approval status; and
resulting repository state.

A merge shall not be considered an approval by itself unless the applicable governance process explicitly defines it as such.

Detailed integration procedures shall be governed by IGB-DOC-006.

12. Tag and Release Control¶

Tags may be used to identify significant controlled repository states.

Tags shall be associated with a specific repository state and shall not be used ambiguously.

A release shall identify, where applicable:

release identifier;
release version;
release date;
source revision;
applicable baseline;
approval status; and
relevant release documentation.

A released artifact shall remain traceable to the repository revision from which it was released.

13. Revision and Change History¶

Controlled artifacts shall preserve sufficient history to determine their evolution.

Revision history shall not be replaced merely because a newer revision becomes active.

Historical revisions shall remain distinguishable from the active revision.

Where a controlled document contains a revision-history section, the revision history shall be maintained consistently with the repository history.

14. Baseline Control¶

A baseline shall identify a controlled engineering state.

A baseline may include:

documents;
source files;
configuration;
architecture artifacts;
specifications;
verification artifacts;
release artifacts; and
other defined engineering content.

Baseline contents shall be identifiable and reproducible.

Changes to a controlled baseline shall occur through the applicable change-control process.

A repository revision alone shall not be interpreted as an approved engineering baseline unless the applicable governance process designates it as such.

15. Traceability¶

Version control shall support traceability between engineering changes and their applicable context.

Where applicable, traceability shall connect:

```text Requirement ↓ Engineering Change ↓ Implementation ↓ Review / Verification ↓ Repository Revision ↓ Baseline ↓ Release

The required level of traceability shall be proportional to the engineering artifact and applicable governance requirements.

Review and Approval

Version-control operations shall not replace engineering review or approval.

A repository commit, branch, merge, or tag shall only carry approval significance when explicitly defined by the applicable engineering governance process.

Controlled documents marked as Approved shall have an identifiable approval basis.

Unapproved development content shall not be represented as an approved engineering baseline.

Archive and Obsolete Revisions

Historical and obsolete revisions shall remain distinguishable from active authoritative revisions.

Archived material shall not silently compete with the active canonical source.

An obsolete artifact shall not be referenced as the active authority unless explicitly restored through the applicable change-control process.

Where archival copies are retained, their historical status shall remain clear.

Canonical Repository Location

The canonical repository location for this document is:

docs/standards/IGB-DOC-005_Version_Control_Policy.md

The canonical active repository location shall be treated as the authoritative source for the active version of IGB-DOC-005.

A controlled document identifier shall correspond to one active canonical document.

No Uncontrolled Duplicate Authority

Duplicate copies shall not be treated as independent authoritative sources.

Where multiple copies exist for operational, archival, publication, or backup purposes, only the designated canonical source shall constitute the active authority.

Derived or published copies shall remain traceable to their canonical source.

Change Control

Changes to controlled engineering artifacts shall be performed through the applicable engineering change-control mechanism.

The change process shall preserve sufficient information to determine:

affected artifact; change reason; change origin; resulting revision; applicable review; applicable approval; and resulting baseline or release impact.

Changes shall not bypass applicable higher-level governance.

Security and Integrity

Version-controlled repositories shall be protected against unauthorized modification where required by the applicable security governance.

Repository access shall be controlled according to applicable access-management requirements.

Where repository integrity is required, appropriate mechanisms may include:

access control; protected branches; signed commits or tags; review controls; backup; repository integrity monitoring; and controlled release mechanisms.

Security controls shall not be interpreted as replacing engineering traceability requirements.

Compliance

Engineering teams responsible for controlled artifacts shall comply with this policy.

Non-compliance shall be identifiable through applicable engineering review, repository review, configuration-management review, or audit.

Exceptions shall be documented and approved through the applicable governance mechanism.

No local workflow shall silently override this policy.

Authority Relationship

The documentation authority relationship is:

IGB-DOC-001 Documentation Architecture │ ├── IGB-DOC-002 │ Documentation Style Guide │ ├── IGB-DOC-003 │ File Naming Convention │ ├── IGB-DOC-004 │ Engineering Drawing Standard │ ├── IGB-DOC-005 │ Version Control Policy │ └── IGB-DOC-006 Git Workflow Standard

IGB-DOC-001 remains the parent documentation authority.

IGB-DOC-002 governs documentation presentation.

IGB-DOC-003 governs controlled file naming.

IGB-DOC-004 governs engineering drawing requirements.

IGB-DOC-005 governs version-control policy requirements.

IGB-DOC-006 governs operational Git workflow.

No subordinate document shall override the authority of a higher-level governing document.

Closure Requirements

Before IGB-DOC-005 v1.0 is considered closed, the following conditions shall be satisfied:

Canonical file exists. Git identity is confirmed. Metadata is complete. Status is explicitly controlled. Purpose and scope are defined. Authority relationship is defined. Version-control requirements are defined. Baseline and traceability requirements are defined. Archive and obsolete-revision requirements are defined. Canonical repository location is declared. No uncontrolled duplicate authority is declared. No unresolved TODO/TBD/FIXME/XXX markers remain. MkDocs navigation entry is confirmed. MkDocs strict build completes successfully. Final closure verification passes. Appendix A — Controlled Versioning Model

The controlled versioning model is:

Working Change ↓ Repository Revision ↓ Review ↓ Controlled Integration ↓ Baseline ↓ Release ↓ Archive / Historical Record

The exact operational workflow shall be governed by IGB-DOC-006 and applicable engineering governance.

Appendix B — Version Identification

Version identifiers shall remain unambiguous and traceable.

For controlled documentation, the document version shall be maintained consistently with the applicable documentation governance.

Repository history shall provide the detailed change record beneath the controlled document version.

Appendix C — Canonical Repository Structure

The controlled engineering repository may contain, as applicable:

IGB-Engineering-Platform/ ├── docs/ │ ├── standards/ │ ├── architecture/ │ ├── governance/ │ ├── templates/ │ └── archive/ ├── drawings/ ├── products/ ├── specifications/ ├── architecture/ ├── governance/ ├── templates/ └── archive/

The exact repository structure shall remain governed by IGB-DOC-001 and applicable repository governance.

Appendix D — Canonical Path docs/standards/IGB-DOC-005_Version_Control_Policy.md

This path is the canonical active repository location for IGB-DOC-005.