MIL-STD-882E: a first review of software safety evidence

01 / Establish the governing basis

What does MIL-STD-882E require you to distinguish?

A hazard is a condition that could lead to harm; a mishap is the event or sequence producing the defined harm. Software may initiate a hazardous sequence, fail to interrupt it, or provide information on which another part of the system acts. Start with that system relationship, including people and operating modes. A defect description alone does not explain the possible mishap. Definitions §§3.2.15, 3.2.21 and identification §4.3.2.

Locate what your program adopted

Find the solicitation or contract clause, edition, selected tasks, applicable program safety plan and formally approved tailoring. Record unresolved interpretation with an owner. Sections 3 and 4 apply when the standard is required; each additional task must be specifically called out. Applicable DoDI 5000-series provisions take precedence over conflicting standard text, and applicable laws and regulations are not displaced without an exemption. §§1.1, 2.3, 4.1 and 5.2 through 5.3.

Core §4.3.1.d already requires a closed-loop Hazard Tracking System (HTS) connecting hazards, mishaps, risk assessments, identified and selected mitigations, status, verification of reduction and acceptance. Selected Task 106, Hazard Tracking System, adds detailed tracking requirements. The small worksheet below helps prepare one thread for that process; it does not replace it.

Keep three assessments separate

The matrices answer different questions. Use the complete adopted definitions and any formally approved alternatives when making an actual assessment.

Basis: §4.3.3, §§4.4 through 4.4.3 and Tables III through VI.

LOR describes the depth and breadth of software analysis and verification. Section 4.4 explains that software-function failure probability cannot be estimated from historical data in the same way as hardware reliability; a passing test history or assistant confidence supplies no substitute.

Read the full SCC descriptions before relying on words such as autonomous, independent or redundant. They concern system command authority, detection, intervention and available response time. An autonomous software function is not the same concept as an AI coding agent. Calling a proposed control an interlock does not establish that its detection and intervention are independent or timely. §3.2.19, §3.2.39 and Table IV.

Separate evidence from permission to proceed

Verification asks whether the selected mitigation was implemented. Validation asks whether it is effective in the system. Risk acceptance is a separate authorized decision before known hazardous exposure, supported by the configuration and evidence. The user representative must formally concur before Serious and High acceptance decisions. Identify the applicable program, Component, acquisition-pathway and delegation records; neither a software reviewer nor a passing test gains acceptance authority by default. Standard §§4.3.6 through 4.3.7; DoDI 5000.88, §3.6.e.

02 / Start with one usable record

Free human first-review starter

Copy either complete record as plain text. Both work without Proof, signup or JavaScript. Use UNKNOWN for missing information, UNASSIGNED for a person not appointed, and NOT ESTABLISHED for a claim lacking an adequate basis. The proposed next verification starts NOT EXECUTED; identify any existing results separately under supplied evidence.

If a role is unassigned, identify the program contact who can appoint it and request a named owner before scheduling verification.

This is an original engineering aid for one document review. It is not a complete Task 106 HTS, prescribed contractual deliverable, approved safety case or risk-acceptance form. The selectable records below are the complete artifact.

Blank record

Copy FIRST HAZARD / SOFTWARE-EVIDENCE REVIEW
Scope: document review; proposed next verification NOT EXECUTED.

Record or candidate/revision reference:
  [Identify the requirement, change or document under review.]

Governing basis and unknowns:
  [Contract/program reference; adopted edition; selected tasks; tailoring.]
  [Existing hazard/assessment/authority record references, or UNKNOWN.]

Possible mishap and operating mode:
  [Who or what could be harmed; how; in which mode and system boundary?]

Software contribution:
  [What software action, omission or information could enable the mishap?]

Proposed control and requirement basis:
  [Required prevention/mitigation and legitimate permitted behavior.]
  [Requirement source/revision; approval status and authorized approver.]

Supplied evidence versus missing verification:
  [Documents/results actually available, their scope and relevant revision.]
  [Unanswered behavior, abnormal conditions, timing or interface questions.]

Actual result of proposed next verification: NOT EXECUTED.
Control effectiveness:
  [Supporting validation record, or NOT ESTABLISHED.]
Applicable risk decision:
  [Authorized decision/acceptance record, or NOT ESTABLISHED.]

Responsible owner:
  [Named person/role for the gap, or UNASSIGNED.]
  [Requirement owner and program/system-safety contact.]

Smallest next check and decision:
  [Material to inspect; expected observation or unresolved criterion.]
  [Who must decide what, before which next activity?]

Filled record: illustrative maintenance-guard review

Copy FIRST HAZARD / SOFTWARE-EVIDENCE REVIEW
Status: ILLUSTRATIVE document/test-planning review.
No actual installation, incident or implemented control is established.

Record or candidate/revision reference:
  Maintenance-guard proposal in this guide; no project revision supplied.

Governing basis and unknowns:
  Orientation source: MIL-STD-882E with Change 1, 27 September 2023.
  Actual contract, adopted basis, selected tasks and tailoring: UNKNOWN.
  Program risk assessment, SCC, SwCI and LOR: NOT ESTABLISHED.
  Actual accepting authority and acceptance record: NOT ESTABLISHED.

Possible mishap and operating mode:
  A person servicing machinery through an open maintenance-access guard
  could be injured by powered motion. Maintenance is the exposure mode.

Software contribution:
  Software could enable a motion request despite the open guard.

Proposed control and requirement basis:
  Refuse the request while the guard is open and issue no command
  enabling that requested motion. Preserve ordinary permitted operation
  with the guard closed and all other required operating conditions met.
  Source: illustrative proposal above; project approval NOT ESTABLISHED.

Supplied evidence versus missing verification:
  Supplied: proposed rule and a plan containing closed-guard behavior only.
  Missing: open-guard verification and all execution results.
  Stale/missing guard information, changing guard state, stop/restart,
  timing and actuator-interface criteria/evidence: NOT ESTABLISHED.

Actual result of proposed next verification: NOT EXECUTED.
Control effectiveness: NOT ESTABLISHED.
Applicable risk decision: NOT ESTABLISHED.

Responsible owner:
  Proposed coordination role: system-safety lead.
  Proposed planning role: verification lead, with the requirement owner.
  Actual individuals/assignments: UNASSIGNED.

Smallest next check and decision:
  Requirement owner, with system-safety input: resolve the rule,
  guard-signal meaning and permitted-operation prerequisites;
  identify the required approval under the program process.
  Verification lead: propose a controlled check of open-guard refusal
  alongside legitimate closed-guard operation, with observable criteria.
  Next decision: whether the rule and revised plan are ready for
  authorized verification. Actual approver: NOT ESTABLISHED.
  Keep unresolved system conditions assigned and open.

03 / Find the missing verification

Worked example: correct the plan before claiming a control works

The proposed rule concerns a person exposed to powered motion while servicing machinery. At the software decision boundary, the intended behavior is to refuse a motion request when the maintenance-access guard is open and issue no command enabling that request. A closed guard permits the normal-operation case only when the operating mode and all other required conditions also permit it.

The initial proposed plan examines only that ordinary closed-guard case. It contains no case challenging the condition the control is intended to address. Even a future successful closed-guard result would leave open-guard refusal unverified. Here, neither case has run.

Proposed correction to the verification plan

Retain the legitimate-operation case and add the open-guard challenge. Preserve unresolved abnormal and system conditions as explicit planning work.

ILLUSTRATIVE plan entries, not executed tests. “Guard reported open” below means an input to the proposed software check. It is not evidence that a sensor correctly detects the physical guard.

The permitted-operation check matters because a controller that refuses every request could satisfy a refusal-only check while violating required operation. This is a reason for the proposed comparison, not an executed faulty variant.

The smallest useful next verification is the open/closed comparison at an agreed software boundary, after the requirement, prerequisites, procedure and controlled setup are approved. Plan to inspect both the request outcome and the command that would enable motion. A rejection message alone would not establish that the enabling command was withheld. No implementation or setup is supplied here.

System evidence must separately address guard sensing, actuator behavior, relevant stopping and restart conditions, physical timing, human action and possible common causes. The program also needs to decide whether this control is an appropriate mitigation within the design alternatives. Neither this proposed pair nor the interlock label establishes those claims. §§4.3.2, 4.3.4 and 4.3.6; Table IV.

Review result: the initial plan leaves the proposed protective behavior unsupported. The proposed handoff identifies the requirement and system-safety roles for rule resolution and the verification role for plan revision; actual people must still be appointed. Verification is NOT EXECUTED; implementation, mitigation effectiveness and risk acceptance are NOT ESTABLISHED.

Use the starter on one real control requirement: identify its missing verification and the person responsible for the next decision.

04 / Apply the review to your project

How to review one hazard-to-software-evidence thread

1. Locate the adopted basis. Identify the contract or program requirement, edition, selected tasks, approved tailoring and responsible interpretation. Link existing assessments rather than guessing missing values.
2. Describe the possible mishap in one mode. Name the affected person or asset, hazardous condition, software contribution and system interfaces. Distinguish anticipated harm from an observed event.
3. Challenge the proposed control against the design alternatives. Section 4.3.4 orders mitigation approaches by decreasing effectiveness: eliminate the hazard through design selection; reduce risk through design alteration; use engineered features or devices; provide warning devices; then use signage, procedures, training and personal protective equipment. Record the selection rationale. For Catastrophic or Critical consequences, the standard says reliance solely on the last group should be avoided. §4.3.4.
4. Locate the software assessment and required work. Ask the responsible safety assessor for the function's SCC, SwCI and LOR basis. If absent, assign that assessment. Do not manufacture a classification to finish the form.
5. Compare the requirement with the supplied evidence. Inspect what each document, analysis or result actually addresses, including prohibited behavior, required permitted behavior and relevant failures or transitions. Confirm that expected results come from approved intent.
6. Choose the smallest check that resolves the gap. Specify the question, method, observation and remaining limits. An unresolved requirement may need a decision before an executable check can be credible.
7. Assign the decision and retain the open work. Name the person, required material and next activity. Carry results into the program's controlled records, preserving separate implementation, effectiveness and acceptance decisions. Revisit affected evidence when requirements, interfaces, software or operating conditions change. §§4.3.6 through 4.3.8.

05 / Check the handoff

First-review checklist

• The governing basis is identified, or its absence has a named owner.
• The possible mishap, operating mode and software contribution are understandable.
• The control's source and approval status are visible.
• Relevant system-risk and software-assessment records are linked or explicitly missing.
• Supplied documents, proposed checks and actual observations have distinct statuses.
• The plan challenges prohibited behavior and preserves legitimate required operation.
• Unresolved abnormal, timing and interface conditions remain open.
• The next check, responsible person and decision are explicit.
• No technical result is being used as an unauthorized risk-acceptance decision.

These gates assess whether the first review is usable. They do not establish completion of the program safety effort.

06 / Avoid misleading shortcuts

Mistakes that make a record look stronger than its evidence

The independence and change questions follow the standard's system-context approach, including Table IV and §§4.3.8, 4.4.3. The table gives practical review remedies, not additional prescribed tasks.

07 / Maintain the evidence relationships

Where Proof can help

Proof can maintain agreed intent and supported relationships between requirements and evidence, help inspect gaps and suspect links after changes, and preserve separate review decisions. For this first review, connect the control requirement, candidate revision, supplied evidence and assigned unresolved work. Keep the original results and their scope available to the reviewer. See the public project and agent workflow.

A declared link is not execution. A review stamp does not establish competent safety analysis, effective control, official classification or authorized risk acceptance. No complete shipped MIL-STD-882E conformance matrix, risk-scoring or approval engine, qualified safety tool or approved safety case is established here.

08 / Choose the method for the question

Which review or verification approach fits?

Choose the method that can answer the claim before choosing where to store its result. Section 4.3.6 permits appropriate analysis, testing, demonstration or inspection. When selected, Task 401, Safety Verification, requires tests where analysis or inspection cannot establish mitigation adequacy and provides for recommended alternatives where safety tests are infeasible. §401.2 through §401.2.4.

Method choices for different unanswered questions

Choose the combination required by the actual LOR obligations. Passing a model or finite set of tests does not establish production correctness or certification. Selected Task 208, Functional Hazard Analysis, specifically considers loss, degradation, malfunction and behavior out of time or sequence, alongside functional allocation and software criticality. §208.2.1.

If a coding assistant helped with the change

Review the actual changed software contribution and control against authorized intent. Challenge expected results derived from the same generated proposal as the implementation. These are applications of the evidence-review method, not a special coding-assistant mandate in MIL-STD-882E. No assistant or tool brand establishes independence or qualification.

Delivered machine learning raises a separate scope question. The official January 2026 Machine Learning System Safety Engineering Guide supplies informational, recommended approaches specifically for supervised ML, including embedded models and standalone ML tools that create system inputs. It places generative AI beyond its stated topic. Its proposed tasks are not a universal assistant-generated-code checklist or an amendment to the standard. Preface vii through viii, §1.1.1 through §1.1.2 and §2.

10 / Apply the distinction elsewhere

Two additional first-review examples

These are illustrative document-review situations. No execution, classification or risk acceptance is established for either.

An advisory display acquires a time-critical role

A display previously used for planning is proposed as the warning on which an operator must act to prevent a mishap. Existing display tests may still check the same values, while the software's system role has changed. Ask the safety assessor to revisit control-category assumptions, available intervention time and the evidence needed for the operator response. The word “advisory” cannot settle that assessment. Table IV.

Two protective paths begin sharing an input

A proposed interface change feeds both a controller and a claimed independent protective monitor from the same processed sensor value. Each component's previous tests may remain relevant to its local behavior, but they cannot establish that the new shared dependency preserves independent protection. The next review needs the changed architecture, common-cause analysis and a decision about which evidence must be renewed. §4.3.8 and, when selected, Task 205 System Hazard Analysis, §205.2.1.c.

12 / Continue with the next task

Related guides

• Hazard analysis to code: inspect a separate bounded implementation example once you have a hazard and control requirement to trace. Its local queue evidence does not establish MIL-STD-882E conformance.
• Software verification plan: expand an agreed control into methods, criteria, owners and evidence obligations.
• Requirements-based testing: derive assertions from required behavior.
• MC/DC coverage: understand structural evidence and what it leaves unresolved.
• Software PoC review: review the bounded claim and next check for an existing proof of concept.