IGB-DOC-002¶
Documentation Style Guide¶
Document ID : IGB-DOC-002
Title : Documentation Style Guide
Version : v1.0
Status : Approved
Owner : IGB Engineering
Last Update : 2026-08
Revision History¶
| Version | Date | Description |
|---|---|---|
| v1.0 | 2026-08 | Initial Approved Release |
1. Purpose¶
This document defines the official documentation style requirements for the IGB Engineering Platform.
Its purpose is to ensure that engineering documentation is consistent, readable, searchable, maintainable, and suitable for long-term engineering use.
This document defines document presentation and writing conventions.
It does not define the overall documentation architecture, document hierarchy, or repository structure.
2. Scope¶
This standard applies to engineering documentation maintained within the IGB Engineering Platform.
Including but not limited to:
- Architecture
- Engineering
- Requirements
- Communication
- Security
- Validation
- Manufacturing
- Software
- Bill of Materials
- Releases
- Intellectual Property
- Products
- Specifications
- Standards
- Templates
3. Authority¶
This document is a subordinate documentation standard under:
IGB-DOC-001 — Documentation Architecture
IGB-DOC-001 defines the overall documentation architecture and authority.
This document defines documentation style requirements within that architecture.
Where a conflict exists between this document and IGB-DOC-001, IGB-DOC-001 shall take precedence.
4. Documentation Principles¶
Engineering documents shall be:
- Clear
- Precise
- Consistent
- Traceable
- Machine Searchable
- Human Readable
- Version Controlled
- Long-term Maintainable
Documentation shall describe engineering facts, decisions, requirements, implementation, verification, or controlled engineering information.
Ambiguous or undocumented assumptions shall be avoided.
5. Document Header¶
Official engineering documents shall provide document control information.
The recommended document header shall include:
- Document ID
- Title
- Version
- Status
- Owner
- Last Update
6. Document Title¶
The document title shall clearly identify the subject of the document.
Titles shall:
- Be concise
- Be technically meaningful
- Avoid unnecessary abbreviations
- Remain stable across revisions unless the document scope changes
The title shall correspond to the controlled Document ID.
7. Heading Hierarchy¶
Markdown headings shall use a consistent hierarchy.
Recommended structure:
# Document Title
# 1. Major Section
## 1.1 Subsection
## 1.2 Subsection
# 2. Major Section
Heading levels shall not be skipped without justification.
8. Paragraph Style¶
Technical statements shall be written as direct engineering statements.
Requirements, decisions, specifications, and observations shall use language appropriate to their engineering meaning.
9. Lists¶
Lists shall be used where multiple related items must be presented.
Ordered lists shall be used for procedures or explicitly sequenced activities.
10. Tables¶
Tables shall be used for structured information such as requirements, interfaces, parameters, revision history, status, ownership, traceability, and configuration data.
Tables shall use descriptive column names.
11. Code and Command Blocks¶
Shell commands, source code, configuration examples, and machine-readable data shall be presented using fenced code blocks.
Code blocks shall identify the appropriate language where practical.
12. Engineering Data¶
Engineering values shall include units where applicable.
Examples:
Voltage : 12 V
Current : 5 A
Temperature : 85 °C
Length : 120 mm
13. Figures and Drawings¶
Figures, diagrams, and engineering drawings shall have meaningful descriptions.
Where applicable, documentation shall identify figure number, figure title, revision, source, and related document.
Engineering drawing requirements are governed by IGB-DOC-004 — Engineering Drawing Standard.
14. Cross-References¶
Documents shall reference controlled documents using their Document ID and title where practical.
Preferred:
IGB-DOC-001 — Documentation Architecture
Cross-references shall point to the current authoritative document whenever possible.
15. Requirements Language¶
Requirements shall use precise language.
Where a requirement is mandatory, use:
shall
Where a capability is optional or permitted, use:
may
Where a recommendation is being provided, use:
should
16. Status Terminology¶
Document status shall use controlled terminology.
Recommended lifecycle states include:
Draft
Review
Approved
Active
Engineering Freeze
Released
Archived
The authoritative lifecycle is defined by IGB-DOC-001 — Documentation Architecture.
17. Revision History¶
Official documents shall maintain revision history.
Each revision entry should identify:
- Version
- Date
- Description
Revision history shall describe substantive changes.
18. Version Number Placement¶
Official document versions shall be maintained inside the document.
Version numbers shall not be embedded in the canonical filename.
Correct:
IGB-DOC-002_Documentation_Style_Guide.md
Incorrect:
IGB-DOC-002_Documentation_Style_Guide_v1.0.md
This requirement is inherited from IGB-DOC-001 — Documentation Architecture.
19. File Naming¶
Filename requirements are governed by:
IGB-DOC-003 — File Naming Convention
This document defines presentation style only and shall not supersede the file naming standard.
20. Git and Version Control¶
Documentation shall be maintained under Git version control.
Git history is the authoritative historical record for document changes.
Version-control requirements are governed by IGB-DOC-005 — Version Control Policy.
Git workflow requirements are governed by IGB-DOC-006 — Git Workflow Standard.
21. Review Requirements¶
Documents shall be reviewed according to their document class and lifecycle state.
A review should verify, as applicable:
- Technical correctness
- Scope
- Consistency
- Traceability
- Cross-references
- Status
- Revision history
- Formatting
- Compliance with applicable standards
A document shall not claim an approval state that has not been established by the applicable governance process.
22. Machine Readability¶
Documentation shall remain suitable for automated processing.
Documents should:
- Use predictable headings
- Use stable Document IDs
- Use structured tables where appropriate
- Avoid unnecessary formatting complexity
- Avoid embedding critical information only in images
- Maintain searchable text
23. Human Readability¶
Documentation shall remain understandable to qualified engineers without requiring interpretation of undocumented conventions.
Technical abbreviations shall be defined when first introduced unless they are already controlled terminology.
Critical assumptions shall be explicitly documented.
24. Compliance¶
All official engineering documentation shall comply with this standard where this standard applies.
Non-compliant documents shall be identified and corrected through the applicable documentation or engineering governance process.
This document does not supersede domain-specific engineering standards.
25. Related Documents¶
| Document ID | Title | Relationship |
|---|---|---|
| IGB-DOC-001 | Documentation Architecture | Parent / Authority |
| IGB-DOC-003 | File Naming Convention | Related Standard |
| IGB-DOC-004 | Engineering Drawing Standard | Related Standard |
| IGB-DOC-005 | Version Control Policy | Related Standard |
| IGB-DOC-006 | Git Workflow Standard | Related Standard |
Appendix A¶
Documentation Style Baseline¶
Controlled Document ID
Controlled Title
Version
Status
Owner
Revision History
Structured Headings
Structured Technical Content
Traceable Cross-References
Git Version Control
Appendix B¶
Authority Relationship¶
IGB-DOC-001
Documentation Architecture
|
+-- IGB-DOC-002
Documentation Style Guide
IGB-DOC-002 shall remain subordinate to IGB-DOC-001.
Appendix C¶
Document Status¶
Document Status : Approved
Authority : IGB-DOC-001
Owner : IGB Engineering