All blueprints

Connect every risk control to the evidence behind it.

Keep risk scenarios, controls, verification and new operational evidence connected. Ask neil to investigate gaps and prepare controlled improvements.

Illustration of a seal beside an open evidence folio containing SOP, training and execution records.

A named control is not evidence
that it works.

Vessel overfill: follow the high-level signal to the inlet valve.

High-level stop: Inlet remained openThe sensor should command the inlet valve to close. In this alternative failed test the valve stayed open, so the claimed control is not verified.InletClose commandVesselSensor
CTRL-021 / high-level stopIntended to interrupt transfer before overflow.
Required response
Inlet closes
Observed in this example
Inlet remained open

The failure leads back to the control.

Link the failed result to an investigation and the affected control. Assess the cause and define the verification needed after the change.

Fictional engineering illustration with alternative test outcomes—not live equipment, a native Seal screen or an accepted risk assessment.

Follow the failure back to the control.

A failed verification should lead to the requirement it challenges, the configuration tested and the work needed next. In Seal, those can be linked records—not references someone has to reconcile across spreadsheets.

Keep the original observation. An investigation can change the explanation or the proposed control; it should not rewrite what happened in the test. Reviewers decide which checks must be repeated and whether the remaining risk is acceptable.

New evidence can challenge an old assumption.

A complaint, maintenance finding or production deviation may change the basis of a risk assessment. Connect the source to the affected scenario and retain why it belongs in the review.

The related complaint example below separates the original report from the technical investigation and safety assessment. A reported malfunction is evidence to assess, not a confirmed cause or a risk conclusion.

Native Seal complaint intake preserves the source wording and leaves identity and assessments unresolved.
Related complaint workflow in the actual Seal interface. Fictional records; no confirmed defect or safety decision.View full size

Keep the denominator with the estimate.

Fewer failures do not necessarily mean less risk. In this related CAPA example, failures fall from 12 to 5, but use falls from 150 to 60 runs. The observed rates are 8.0 and 8.3 per 100 runs.

Seal’s configured chart keeps the comparison visible. Assess the population, observation period, uncertainty and competing explanations before using it to revise an estimate. These observations alone do not establish a causal effect.

Native Seal CAPA chart compares 8.0 failures per 100 runs before a change with 8.3 afterward.
Related CAPA example, not the vessel control above. A saved chart of fictional source records, not a live risk estimate.View full size

Ask neil to prepare the follow-up.

Give neil the risk file, the changed requirement or the new evidence. It can investigate permitted records and author proposed assessments, verification cases and workflow changes in Seal.

The useful deliverable is inspectable work: source-linked reasoning, explicit gaps and a proposed change your team can test. People approve the technical scope, run verification and make the risk decision.

Investigate a challenged control
Find the requirements and scenarios linked to this failed verification. Compare the tested configuration with the current one.

A proposed impact assessment with source versions, competing explanations and the evidence needed to distinguish them. Missing evidence becomes linked follow-up work.

Prepare the next verification
Turn the proposed control change into requirements, capture fields and verification cases.

Inspectable configuration and proposed cases covering the intended response, failure paths and missing evidence. Include verification of the configured workflow itself before publication.

Review the operating evidence
Compare the relevant complaints and service findings with the assumptions in this risk file.

A source-linked comparison with population and exposure limits, candidate affected scenarios and proposed review tasks. No unsupported incidence estimate or automatic risk acceptance.

Start with your risk workflow

Illustrative requests and proposed outputs. The captures on this page do not demonstrate neil execution.

Capabilities

Connected records

Entity hierarchy
What it records
Kind
Hazard
Potential source of harm, with its product or process context and supporting evidence.
entity
Energy Hazard
Electrical, mechanical, thermal, radiation. Physical energy transfer that can cause harm.
template
Biological Hazard
Biocompatibility, infection, contamination. The device meets the body.
template
HAZ-2024-017
Fictional reprocessing scenario: surface geometry may retain contamination and needs assessment.
record
Use Error
Misuse, abnormal use, use environment. The surgeon's hand strength can't generate 2N.
template
Risk
Assessment of a scenario using the defined criteria, evidence and uncertainty.
entity
Risk Control
Measure intended to reduce risk, linked to its requirement and verification.
entity
Design Control
Design measure intended to reduce risk, with its rationale and verification scope.
template
CTRL-2024-001
Fictional time-based stop requirement. Implementation, operating conditions and evidence require review.
record
Protective Measure
Protective measure such as a guard, alarm or interlock, with a defined response and evidence.
template
Information Control
Information for safe use, with its intended audience, scope and assessment of limitations.
template
Residual Risk
Assessment of the risk remaining after controls, with rationale and required review.
entity
Post-Market Data
Operating evidence that may support or challenge the assumptions in the risk file.
entity
FMEA
Analysis of functions, failure modes, effects, causes and controls within a defined scope.
entity
Process FMEA
Process-step functions, failure modes, effects, causes, existing controls, estimates, actions, verification, and residual decisions.
template
Risk Management Plan
Scope, lifecycle, roles, activities, methods, criteria, verification, information sources, review, deliverables, and change triggers.
entity
ISO 14971 Risk File
Medical-device lifecycle plan, analyses, scenarios, controls, verification, residual and overall risk, report, and post-production review.
template
ICH Q9 Quality Risk Assessment
Pharmaceutical quality question, risk method, evidence, analysis, control, communication, review, and formality proportional to risk.
template
Use & Process Context
Intended use, users, patients, environments, workflows, interfaces, maintenance, reprocessing, service, disposal, and foreseeable misuse.
entity
Risk Scenario
Hazard, initiating event, sequence, exposure, hazardous situation, harm, severity, probability elements, evidence, and uncertainty.
entity

Questions and answers

No. Your team defines the criteria, context and required review. Seal holds the versioned assessments, evidence and decisions; a passing verification does not itself accept residual risk.
Use distinct templates for the methods your process needs. They can reference common functions, controls, requirements and source evidence while retaining their own terminology and assessment criteria.
Retain the failed result and tested configuration. Link the investigation and proposed correction to the affected control, then define the verification needed after the change. Review the residual risk separately.
Configure the categories, definitions and criteria for your context. Record their version and the basis for each estimate so reviewers can understand what the assigned values mean.
Link relevant complaints, deviations or service findings to the assessment. Configure ownership and review triggers, and retain why each source was included or excluded. A similarity is not a confirmed cause.
neil can analyse supplied documents and permitted records, prepare source-linked assessments and follow-up work, and author proposed requirements, capture fields and verification cases. People verify the configuration and approve the decisions.
Not automatically. Keep the applicability, configuration and supporting evidence explicit for each assessed scope. A shared reference helps identify the affected products; reviewers determine whether the evidence applies.
Action completion and risk acceptance are different decisions. Review implementation, verification, remaining uncertainty and any required effectiveness evidence before recording the authorised conclusion.

Related blueprints

See your process in Seal.

Tell us about your workflow. We’ll show you how neil and Seal can help your team.

Book a demo