Skip to main content

​
Why a Formal Lifecycle Exists

Aerospace certification standards (ARP 4754A, DO-178C, DO-254) require that safety evidence be formally baselined and change-controlled. A hazard assessment that was reviewed last month but never formally approved carries no certification weight. The lifecycle enforces this discipline: a document in Published state represents a frozen, signed baseline — the kind of evidence an airworthiness authority can audit. Think of it like a contract. A draft contract is a working document. A signed contract is a legal instrument. The lifecycle transforms a working risk analysis into certifiable safety evidence.

​
The Four-State Workflow

All risk specification documents share a single 4-state workflow, regardless of document type — whether DFMEA, FHA, PSSA, SSA, FTA, CCA, Hazard Tracking, Security Threat Assessment, Compliance Matrix, or Risk Control Plan. diagram Draft — The document is being actively edited. Risk records can be added, modified, or deleted freely. No signatures are attached. In Review — Triggered by “Send for Review,” this state automatically routes the document to designated approvers (the project_approver role) and opens the electronic signature process. The document content is effectively frozen for signature collection. Approved — The document has received the required signatures. The signature policy requires at least one approval from the project_approver role before this state is reached. Published — The document is formally baselined. This is the version that constitutes certification evidence. The Published state creates a versioned snapshot of the risk analysis that satisfies ARP 4754A baseline management and DO-178C configuration control requirements.

​
Rework: The Escape Hatch

The Rework action is available from any non-Draft state — In Review, Approved, or Published. When triggered, it does two important things simultaneously: it resets the document to Draft state and marks all existing signatures as obsolete.
Triggering Rework does not preserve existing approvals. The entire signature collection process must restart from scratch. This is intentional — it ensures that any substantive change to a risk analysis is reviewed and re-approved by the full approval team.
This prevents a common failure mode in safety programs: a document that was approved for version 1 content but quietly edited afterward. The Aerospace Safety Solution enforces the connection between what was reviewed and what was signed.

​
Document Identity and the systemElementId Field

Not all risk documents are scoped the same way. The optional systemElementId field on a risk specification document creates a critical link between the document and a specific node in the system element hierarchy.
  • Component-scoped documents (DFMEA instances, component-level analyses): carry a systemElementId pointing to their component system element
  • Subsystem-scoped documents (SFMEA instances): carry a systemElementId pointing to their subsystem
  • System-level or cross-cutting documents (COMPLIANCE-001, MIL-STD-882E Hazard Tracking, Security Threat Assessment): do not carry a systemElementId
This field is not cosmetic. It drives:
  • Breadcrumb navigation in the top panel of each Risksheet document
  • Document inventory grouping on space dashboards
  • FMEA hierarchy reports that roll up from component → subsystem → system
A document without a systemElementId appears as a standalone artifact rather than as part of the decomposition tree. See System Element Hierarchy for the full decomposition model.

​
Naming Conventions and Automatic Navigation

Document IDs follow strict naming patterns. These are not just organizational conventions — the Risksheet top panel navigation is pattern-matched against them. Breaking the naming pattern disables automatic cross-document links.
PatternDocument Type
DFMEA-CMP-*Component DFMEA
SFMEA-SUB-*Subsystem SFMEA
SFMEA-SYS-*System SFMEA
DRS-*Design Requirements
CHARS-*Design Characteristics
SUBRS-*Subsystem Requirements
COMPLIANCE-001Compliance Matrix
MIL-STD-882E-HTS-001Hazard Tracking
SEC-THREAT-001Security Threat Analysis
The top panel of each Risksheet document assembles contextual navigation from these patterns — showing breadcrumb trails to parent system elements, links to associated requirements and characteristics, and a live 5×5 risk matrix. All of this depends on documents being named according to the convention.

​
The Risk Matrix and Rendering Modes

Each DFMEA, SFMEA, and PFMEA document includes a JavaScript-rendered 5×5 risk matrix in its top panel. This matrix is calculated from pHazard × pHarm values using the formula ceil((pHazard × pHarm) / 5) to normalize the result to a 1–5 probability range. The resulting probability × severity grid is color-coded green, yellow, or red and is view-only — it reflects the aggregate risk profile of the document’s work items without requiring manual update.
Risk specification documents use either a section layouter (for requirements-style content, showing id at the start and status/rvb at the end) or a paragraph layouter (for failure modes and hazards, with inline severity and status in a sidebar). The rendering mode is determined by the document template, not by the document instance.

​
Relationship to DAL and Certification Evidence

The lifecycle states map directly to certification evidence requirements. A Published document with a complete signature record satisfies the baseline approval requirements under DO-178C and ARP 4754A. The electronic signature trail — including who approved, when, and from which role — is part of the document record. For a practical guide to working within this lifecycle, see the guides in How-To Guides. For the broader compliance picture, see ARP 4761 Safety Assessment Coverage and DAL Classification.
Code: .polarion/tracker/fields/severity-enum.xml, status-enum.xml, priority-enum.xml, implementationStatus-enum.xml, riskSpecification-document-status-enum.xml (0.69) · .polarion/documents/workflow/riskSpecification-workflow.xml (0.53) · modules/RiskTemplates/DFMEATemplate/module.xml, modules/Risks/DFMEA-CMP-PSU/module.xml, modules/_default/WholeRTMSheet/module.xml, modules/Requirements/CUSTOMER-REQS/module.xml (representative of ~50 module.xml files across all spaces and templates) (0.52) · modules/Risks/COMPLIANCE-001/module.xml, modules/Risks/MIL-STD-882E-HTS-001/module.xml, modules/Risks/SEC-THREAT-001/module.xml, modules/Risks/SFMEA-SUB-001/module.xml, modules/Risks/SFMEA-SUB-002/module.xml, modules/Risks/SFMEA-SUB-003/module.xml (0.48) · modules/RiskTemplates/DFMEATemplate/attachments/risksheetTopPanel.vm, SubSystem-FMEATemplate/attachments/risksheetTopPanel.vm, System-FMEATemplate/attachments/risksheetTopPanel.vm, PFMEATemplate/attachments/risksheetTopPanel.vm, HazardTrackingTemplate/attachments/risksheetTopPanel.vm, DFMEATemplate/attachments/risksheetPdfExport.vm, SubSystem-FMEATemplate/attachments/risksheetPdfExport.vm, System-FMEATemplate/attachments/risksheetPdfExport.vm, PFMEATemplate/attachments/risksheetPdfExport.vm (0.47) · .polarion/polarion-project.xml, .polarion/context.properties, .polarion/security/user-roles.xml, .claude/PROJECT.md, TODO.md (0.46) · .polarion/documents/fields/document-type-enum.xml (0.44) · .polarion/tracker/fields/riskRecord-custom-fields.xml (0.44) · .polarion/pages/scripts/velocity/nextedy_solutions.vm (0.41) · modules/RiskTemplates/RiskControlPlanTemplate/attachments/risksheet.json (0.40)