Who decided this rating? Recording where an FMEA's severity, occurrence and detection came from

An FMEA reviewer can only judge ratings they can tell apart. Forge FMEA now records whether each severity, occurrence and detection was entered, accepted from an AI suggestion or corrected, marks AI values nobody has touched, and names the approved revision in every report. Forge SOP does the same for accepted AI draft steps.

November 12, 20265 min read

On this page

An FMEA worksheet is a list of judgments. Severity, occurrence and detection are each a number someone chose on a scale, and the document is only as trustworthy as those choices. When an AI assistant can fill in the numbers, a new question appears: of the ratings on this page, which ones did a person decide, and which ones did a person merely leave alone?

Until version 0.21, Forge FMEA could not answer. A rating the AI suggested and a person let stand was saved exactly like one the person chose. This article describes why that matters and what the worksheet now records.

Why a suggestion that looks like a decision is a problem

Human factors research has studied this for decades under the names automation complacency and automation bias. Parasuraman and Manzey's review of the empirical work describes two related failures: people under load stop checking what an automated aid produces, and they follow its output even when it is wrong, including by omitting a check they would otherwise have made. Neither failure needs a careless person. It needs a decision aid that is usually right and an interface that makes its output look like everything else on the page.

A review step makes this sharper rather than softer. If a reviewer is shown a worksheet in which every rating looks equally authoritative, the review cannot be targeted. The reviewer either re-derives all of the ratings, which defeats the point of the assistant, or trusts all of them, which defeats the point of the review. A review can only be as good as the reviewer's ability to tell which numbers carry a person's judgment and which carry a model's guess.

Three origins for every S, O and D

Each severity, occurrence and detection now carries an origin:

entered: a person chose it;
accepted: an AI suggestion that was taken as it was;
corrected: a person changed a suggested value.

A new row's default, and any rating saved before this field existed, carries none. Nobody is on record for it, and the worksheet does not pretend otherwise. The rule is recorded at the single place every rating write passes through, so a paste, a fill-down and an undo cannot bypass it. Undoing an edit puts the previous origin back with the previous value instead of recording the undo itself as somebody's choice.

In the worksheet, an S, O or D that an AI suggestion filled in and no person has changed yet shows a small AI mark. A person's value, or a suggestion a person corrected, shows none. The Excel export gains a Rating Origin column, for example S: AI · O: person · D: AI, edited, so the information survives outside the application. Severity belongs to the failure mode's effects, so its origin is the origin of the governing effect: the highest-severity end-user effect, or the highest of all when there is no end-user effect.

Which revision was approved

Document status (draft, review, approved) existed in the file format from the start, but nothing set it, and every FMEA stayed a draft. Version 0.21 completes the step. On the last worksheet step, a document moves from draft to review to approved, and an approved one can go back to draft. Approving requires the approver's name. It writes the approved content as the next snapshot revision and records that revision, the time and the approver on the document.

Two details matter for honesty. If an approved FMEA is saved after its content changed, it is saved as a draft, and the record still names the revision that was approved. And the PDF report and the Excel export both state the status and, once approved, the revision, the approver and the date. A printout of later edits is therefore never mistaken for the approved content. The project list shows a status badge on each card, and documents created from a shipped template start as drafts, because a template's sample status is not a review anybody performed.

The same idea in Forge SOP

An SOP step can begin as an AI draft. In Forge SOP 0.16, applying a draft records the loaded model and the time on each step and section it filled. The step editor marks such a step AI draft with the model and the day, and the printed SOP carries AI draft · accepted beside the step. A step a person wrote, or one imported from another app, carries no mark.

What the mark does not say

The origin records who last decided a value, not whether the value is right. Accepted means somebody let a suggestion stand. It does not mean they verified it, and a person origin does not make a rating correct. The marks are there to point a reviewer's attention, not to replace it. Ratings from before the field existed show no origin at all, and for those only the approval record helps.

IEC 60812 describes an FMEA as an analysis that is planned, performed, documented and maintained. Keeping the origin of each judgment next to the judgment is one concrete way of documenting it. Nothing here claims that a worksheet meets a standard; that is decided by the organization's own quality system.

Try it in Forge FMEA and Forge SOP

In Forge FMEA, ask the AI to suggest ratings, accept some, change one, and watch the marks. Then move the document to review and approve it, export the PDF, and look at the first rows of the planning table. In Forge SOP, apply an AI draft to a procedure and print it.

References

R. Parasuraman and D. H. Manzey, "Complacency and bias in human use of automation: an attentional integration", Human Factors, 52(3), 2010, pp. 381–410, doi:10.1177/0018720810376055.
IEC 60812:2018, Failure modes and effects analysis (FMEA and FMECA), edition 3.0, International Electrotechnical Commission, 2018.

Three dispatching rules that come with a proof: SPT, WSPT and EDD, and where the proof stops November 11, 2026
Shortest processing time, weighted shortest processing time and earliest due date are each provably optimal for one objective on one machine. A five-job example checked against all 120 orders shows what each one wins and what it gives up, and why a sorting rule stops being a theorem the moment a second machine appears.
When a p chart flags half the days: overdispersion and Laney's p′ chart October 23, 2026
With large subgroups, a p chart's binomial limits get so narrow that ordinary day-to-day variation lands outside them. What overdispersion is, how Laney's p′ chart measures it with σz, a worked example where the p chart flags 10 of 20 days and the p′ chart flags one, and what σz below 1 means.
RULA, REBA and OWAS from a video: what the camera measures, and what you still have to tell it October 13, 2026
Forge Lens 0.21 scores RULA, REBA and OWAS from a work video on your own PC, using a 17-point body pose model. Which inputs come from the video and which you set yourself, what happens when the worker is out of frame, and what published studies say about how far 2D video scores can be trusted.