Document Lifecycle Overview
Risk specification documents follow a four-state lifecycle with electronic signature support for approval tracking and baseline management:
Document States and Transitions
| State | Purpose | Entry Point | Actions Available | Next States |
|---|---|---|---|---|
| Draft | Initial document creation and editing | Document creation | Edit content, add work items, submit for review | In Review |
| In Review | Submitted for stakeholder review and feedback | Send for Review action | View reviewer comments, request changes, approve/reject | Approved, Rework |
| Approved | Signed off by required approvers | Approve action (requires signatures) | Publish document as baseline | Published, Rework |
| Published | Formal baseline version locked for traceability | Publish action | Reference as baseline for downstream analysis | Rework |
From any non-draft state, a Rework action returns the document to Draft state. This action marks all electronic signatures as obsolete and resets approval verdicts, enabling re-submission after modifications.
Electronic Signature and Approval Requirements
The risk specification workflow implements electronic signature tracking for safety-critical approval chains, per DO-178C and ARP 4754A requirements.Signature Policy: At Least One Signature
The Approve action requires:- At least one project approver signature on the document
- No disapprovals from any approver
- Auto-signature support for the
project_approverrole
Approver role. Approvers may then electronically sign the document before it advances to Approved state.
| Signer Role | Auto-Added | Required | Can Override |
|---|---|---|---|
project_approver | Yes (Send for Review) | At least one | Yes (via signature) |
project_assignee | No | Conditional | Yes |
Signature Lifecycle
| Event | Effect |
|---|---|
| Document created | No signatures |
| Send for Review | Auto-add project_approver signers |
| Approve (Mark Approved) | Signatures must satisfy AtLeastOneApprovedAndNooneDisapproved condition |
| Rework | All signatures marked obsolete, verdicts reset |
| Reopen from Approved | Signatures marked obsolete, verdicts reset |
| Publish | Signatures locked as part of baseline |
Risk Specification Document Types
All risk specification documents in the Aerospace Safety Solution use the same workflow, but may have different content structures and risksheet configurations:| Document Type | Template | Scope | Risksheet Type | Work Item Focus |
|---|---|---|---|---|
| FHA (Functional Hazard Assessment) | FHATemplate | System-level | Failure Condition | Functional hazards and failure conditions |
| SFMEA (System FMEA) | System-FMEATemplate or SubSystem-FMEATemplate | System or subsystem | Failure Mode | System failure modes and effects |
| DFMEA (Design FMEA) | DFMEATemplate | Component-level | Failure Mode | Component failure modes, characteristics, causes |
| PSSA (Preliminary System Safety Assessment) | PSSATemplate | System-level | Safety Requirement | Safety requirements allocated from failure conditions |
| SSA (System Safety Assessment) | SSATemplate | System-level | Failure Condition | Final verification of failure condition evidence |
| FTA (Fault Tree Analysis) | FTATemplate | System-level | Fault (logic gates) | Top-level failures and contributing factors |
| CCA (Common Cause Analysis) | CCATemplate | System-level | Common Cause Event | Shared failure mechanisms across components |
| Hazard Tracking | HazardTrackingTemplate | System-level | Hazard | MIL-STD-882E hazard inventory and closure status |
| Security Threat Assessment | SecurityThreatTemplate | System-level | Security Threat | DO-326A STRIDE threat inventory |
| Compliance Matrix | ComplianceTemplate | Project-wide | Compliance Objective | Standards compliance objectives and evidence |
| PFMEA (Process FMEA) | PFMEATemplate | Process-level | Failure Mode (Process) | Process step failure modes with Action Priority |
| Risk Control Plan | RiskControlPlanTemplate | System-level | Risk Control | Risk mitigation actions and implementation status |
Exact template naming and availability may vary by Aerospace Safety Solution version. Refer to the RiskTemplates folder in your project to confirm available templates.
Document Status Enumeration
Risk specification documents use a four-value status enumeration that mirrors the workflow states:| Status | Color | Meaning | Workflow State |
|---|---|---|---|
| Draft | Blue | Document under creation or revision | Draft |
| In Review | Light Yellow | Awaiting approver review and feedback | In Review |
| Approved | Green | Signed off by required approvers | Approved |
| Published | Bold Green | Formal baseline version locked | Published |
Risksheet Integration Pattern
Each risk specification document contains a Risksheet link panel that connects the document to its associated analysis data:
System Element Binding (Scope)
Most risk specification documents are scoped to a specific system element in the project hierarchy:| Document Type | System Element Binding | Scope |
|---|---|---|
| FHA | System | Entire system |
| SFMEA (system-level) | System | Entire system |
| SFMEA (subsystem-level) | Subsystem | Single subsystem only |
| DFMEA (component-level) | Component | Single component only |
| PSSA | System | Entire system |
| SSA | System | Entire system |
| FTA | System | Entire system |
| CCA | System | Entire system |
| Hazard Tracking | None (project-wide) | All system elements |
| Security Threat Assessment | None (project-wide) | All system elements |
| Compliance Matrix | None (project-wide) | All system elements |
systemElementId field in the document XML binds the document to its scope. Project-wide documents (Hazard Tracking, Security Threat Assessment, Compliance Matrix) have no systemElementId, meaning they apply across the entire project.
In hierarchical systems, a separate SFMEA document is created for each subsystem level, each bound to its respective subsystem via
systemElementId. This allows detailed analysis at each decomposition level while maintaining traceability from system to subsystem to component.Workflow Example: DFMEA Approval Chain
A typical Design FMEA approval workflow follows these steps:- Create — Design engineer creates DFMEA document (Draft state)
- Analyze — Team identifies failure modes, effects, causes, and initial risk rankings in the risksheet
- Define Mitigations — Risk control tasks are created and linked to failure modes
- Send for Review — Design engineer clicks “Send for Review”
- Document state → In Review
- Project approvers automatically added as signers
- Review comments solicited from safety team
- Incorporate Feedback — If changes needed, click “Rework”
- Document state → Draft
- Signatures marked obsolete
- Team incorporates feedback into risksheet
- Steps 3–4 repeated
- Approve — Once review complete and feedback incorporated, click “Mark Approved”
- All project approvers sign electronically
- Document state → Approved
- Signatures locked
- Publish — Click “Publish”
- Document state → Published
- Document becomes formal baseline
- DFMEA results feed into PSSA and downstream safety assessment
Workflow State Machine (XML Configuration)
The risk specification workflow is defined in.polarion/documents/workflow/riskSpecification-workflow.xml. Key workflow transitions include:
| Transition | From | To | Condition | Action |
|---|---|---|---|---|
| Send for Review | Draft | In Review | None | AddDefaultSigners (project_approver role) |
| Approve | In Review | Approved | AtLeastOneApprovedAndNooneDisapproved | Lock signatures |
| Publish | Approved | Published | None | Create baseline snapshot |
| Rework | In Review, Approved, Published | Draft | None | MarkSignaturesObsolete, reset verdicts |
| Reject | In Review | Draft | None | Add rejection comment |
Exact workflow transitions and conditions are configured in the Polarion project XML. For detailed transition rules, review the riskSpecification-workflow.xml file in your project’s
.polarion/documents/workflow/ folder.Related Documentation
- Risk Control (riskControl) — Reference for risk mitigation tasks linked in this workflow
- Failure Mode (failureMode) — Reference for failure mode work items in risk documents
- Failure Condition (failureCondition) — Reference for functional hazards in FHA documents
- RTM Domain Model — Complete data model including document types and relationships
- SFMEA Risksheet Configuration Reference — Detailed column structure for system FMEA analysis
- DFMEA Risksheet Configuration Reference — Detailed column structure for design FMEA analysis
This reference covers the standard risk specification document workflow as implemented in the Aerospace Safety Solution. Actual workflow behavior, available actions, and signature policies may vary based on your project’s Polarion configuration and user roles. Always verify specific workflow rules in your live project.
Source References (dev)
Source References (dev)
Code:
.polarion/documents/workflow/riskSpecification-workflow.xml (0.73) · .polarion/tracker/fields/severity-enum.xml, status-enum.xml, priority-enum.xml, implementationStatus-enum.xml, riskSpecification-document-status-enum.xml (0.62) · .polarion/tracker/workflow/workflow.xml (0.55) · 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.49) · modules/RiskTemplates/PSSATemplate/attachments/risksheet.json (0.48) · modules/RiskTemplates/SSATemplate/attachments/risksheet.json (0.48) · modules/RiskTemplates/ComplianceTemplate/attachments/risksheet.json (0.47) · modules/RiskTemplates/DFMEATemplate/attachments/risksheet.json (0.46) · modules/RiskTemplates/PFMEATemplate/attachments/risksheet.json (0.46) · .polarion/polarion-project.xml, .polarion/context.properties, .polarion/security/user-roles.xml, .claude/PROJECT.md, TODO.md (0.46)