Risk Specification Workflow

​

Workflow Overview

Risk Specification documents follow a four-state approval workflow with controlled transitions and signature requirements:

​

Workflow States

​

Workflow Actions

​

sendForReview — Draft → In Review

Initiates the formal review process and creates approval requirements. What happens:

• Document transitions from editable Draft to In Review state
• All users with the project_approver role are automatically added as required signers
• Users with project_approver role can auto-sign using their role credentials
• Review cycle begins; reviewers should validate completeness and accuracy of risk analysis

When to use:

• Risk identification is complete (all hazards/failure modes identified)
• Mitigation measures and risk controls are proposed
• Risksheet data is complete and consistent

​

approve — In Review → Approved

Records formal approval via signature and advances document to Approved state. What happens:

• Document transitions to Approved state only after signature requirement is satisfied
• At least one project approver must sign (signature policy: atLeastOne)
• Users with project_approver role can auto-approve without manual action
• Document remains editable but approval is documented

When to use:

• Reviewers have validated risk analysis
• All action items from review are resolved
• Risk specification is ready for publication

​

publish — Approved → Published

Releases the risk specification as a finalized baseline. What happens:

• Document transitions to Published state, indicating final release
• Signatures from Approved state are maintained and visible
• Risk specification becomes the stable reference for downstream activities
• Published documents are typically used for compliance audits, V&V evidence, and traceability

When to use:

• Risk analysis is complete and approved
• Signatures are obtained and verified
• Content is stable and will not change (except via rework cycle)
• Project milestone or compliance gate is reached

​

rework — Any State → Draft

Allows return to Draft for corrections or major revisions; invalidates all existing signatures. What happens:

• Document transitions back to Draft state regardless of current state
• All existing signatures are marked as obsolete using MarkWorkflowSignaturesAsObsolete() function
• Signature verdict is reset via ResetSignaturesVerdict() function
• Document becomes fully editable; review/approval cycle must be repeated

When to use:

• Reviewers identify significant issues requiring rework
• Risk analysis needs major corrections or additions
• Substantial changes to hazard identification or mitigation measures
• ASIL classifications need to be revised

​

Signature Management

​

Automatic Signer Addition

When sendForReview is executed, the workflow automatically:

1. Queries all users with the project_approver role in the project
2. Adds each approver as a required signer
3. Assigns the signer role label: Approver
4. Sets signature policy: atLeastOne (at least one signature required)

​

Signature Policy: atLeastOne

The atLeastOne signature policy means:

• At least one project approver must sign the document
• Multiple approvers can sign; only one signature is required for approval
• Users with project_approver role can auto-sign (self-approval)
• Document cannot transition to Approved until signature requirement is satisfied

​

Signature Reset on Rework

When rework is executed:

• All existing signatures are marked as obsolete (no longer valid)
• Signature verdict is reset to “pending”
• Document state returns to Draft
• All signatures are cleared; no signers carry forward
• Next sendForReview cycle creates fresh signature requirements

​

Document Workflow Integration

Risk Specification documents participate in the TestAuto2 approval workflow alongside other document types. The workflow ensures:

• Controlled approval gates — Risk specifications cannot be published without formal review and signature
• Audit trail — All approvals, signatures, and state transitions are recorded
• Iterative development — Rework action enables refinement cycles without workflow restart
• Compliance evidence — Published documents with signatures serve as evidence of formal risk assessment completion

​

Typical Risk Specification Workflow Sequence

​

Phase 1: Development (Draft)

1. Create new risk specification module (FMEA, HARA, HAZID, or Control Plan)
2. Configure Risksheet columns and hierarchies per module type
3. Populate risk data iteratively:
   • Identify hazards/failure modes
   • Assess severity/occurrence/detection ratings
   • Define risk controls and mitigations
   • Calculate risk priority (RPN, ASIL, etc.)
4. Validate completeness using coverage reports and dashboard metrics

​

Phase 2: Review (In Review)

1. Execute sendForReview action
   • Approvers are automatically added as required signers
   • Document state changes to In Review
2. Project approvers review risk analysis:
   • Validate hazard identification completeness
   • Check rating consistency and justification
   • Verify risk controls are adequate
   • Identify any gaps or inconsistencies
3. If issues found, return to Draft via rework action and repeat Phase 1
4. If satisfied, approvers sign the document

​

Phase 3: Approval (Approved)

1. Execute approve action once at least one approver has signed
2. Document transitions to Approved state
3. Signatures are finalized and documented
4. Document is now authorized for publication

​

Phase 4: Publication (Published)

1. Execute publish action to release risk specification
2. Document transitions to Published state
3. Risk specification becomes the official baseline
4. Used as reference for:
   • Traceability to downstream safety activities
   • Compliance audit evidence
   • V&V test case derivation
   • Risk control implementation tracking

​

Common Workflow Patterns

​

Single Rework Cycle (Minor Issues)

After rework, return to Draft and repeat the development and review cycle.

​

Multiple Rework Cycles (Major Revisions)

Multiple iterations may be needed for complex risk analyses with ASIL changes or major control plan revisions.

​

Fast-Track Approval (Straightforward Analysis)

For well-defined, straightforward risk analyses that require minimal rework.

​

Role-Based Responsibilities

​

Workflow State Transitions Reference

​

Integration with TestAuto2 Standards

The Risk Specification Workflow supports compliance with:

• ISO 26262 — Formal approval of Hazard Analysis and Risk Assessment (HARA) and failure mode analysis documents
• AIAG-VDA FMEA — Controlled release of System FMEA, Design FMEA, and Process FMEA analyses
• ISO 14971 — Formal risk management documentation and sign-off
• IATF 16949 — Control Plan release and process risk assessment approval

See Workflow Lifecycle for broader workflow concepts and Document Workflow States for general document approval patterns.