The Visibility Gap, Part 2

From Signal to Alert: How Product Safety Information Becomes Visible

The Visibility Gap is a four-part investigation into how product safety signals are detected, interpreted, escalated and made visible before harm occurs. New parts are published weekly throughout August.

By the time the public sees a product safety alert, the real visibility test has already happened.

A Safety Gate notification, a recall notice, a public warning or a corrective action may appear to be the beginning of the story.

In reality, it is usually the end of a much longer journey.

Long before an issue becomes externally visible, someone has recognised a signal, interpreted what it may mean, escalated it across the organisation and assessed whether legal reporting obligations have been triggered.

That journey does not happen automatically. It depends on people, processes, evidence, thresholds and judgement. As products become more connected, software-dependent and internationally distributed, the path from signal to alert becomes increasingly complex.

Stage 1: Detection

Most product safety issues do not begin as formal regulatory events.

They begin quietly through a customer complaint, warranty claim, field-service observation, retailer escalation, unusual software behaviour or an emerging pattern within post-market data.

At this stage there may be no confirmed defect, regulator involvement, recall or public warning. There is only information, and that information may be weak, intermittent or difficult to reproduce.

The first challenge is recognising that it may have safety significance.

A single complaint can appear to be customer dissatisfaction. A software anomaly may look like a technical support issue. A field-service report may remain isolated within one country or one business function.

Visibility begins when an organisation recognises that apparently unrelated observations may be connected.

The question is not simply whether information exists. It is whether the organisation can distinguish an emerging safety signal from ordinary operational noise.

Stage 2: Interpretation

Recognition alone is not enough.

The organisation must determine what the information actually means.

Interpretation requires evidence, engineering judgement and operational understanding. The assessment must consider whether the behaviour is reproducible, whether it represents a foreseeable safety risk, whether similar products may be affected and whether something has changed since the original product assessment.

For many traditional physical products, the evidence may be relatively bounded. An overheating component, broken mechanical part or hazardous chemical exposure can often be examined against a defined product configuration.

Software-defined products create a different challenge.

A connected device may operate normally until a remote software update changes its behaviour. A safety-related function may depend on a cloud service or third-party API. A pattern may only become visible across thousands of installed products after the same software revision has been deployed.

The question is therefore no longer simply whether the product is dangerous.

It is whether the organisation can establish what the emerging signal is actually telling it before uncertainty delays action.

Product safety is increasingly becoming an information challenge.

Stage 3: Escalation

Even when a signal has been recognised, visibility can still fail because the relevant information rarely exists within one function.

Customer Support may receive complaints, Engineering may identify unexpected behaviour, Quality may investigate performance, software teams may hold the system logs and Commercial teams may hear concerns from distributors.

The visibility problem is not necessarily that information is missing. It is that no individual function may hold enough of it to recognise the whole event.

The critical questions therefore become:

Who decides that these separate observations may represent one product safety issue?

Who owns the escalation decision?

Who ensures that every function is working from the same evidence?

This is where product governance becomes operational.

Escalation is not simply the movement of information upwards. It is the process of assembling fragmented evidence quickly enough for informed decisions to be made.

A formally correct procedure will not create visibility if different functions use different terminology, maintain separate systems or assume another team owns the decision.

Escalation succeeds only when organisations have clear thresholds, connected information flows and defined authority to act.

Stage 4: Classification

Once the available information has been assembled, the organisation must determine whether an external reporting obligation exists.

Classification assesses whether the product is dangerous, whether an accident has occurred, which products and markets may be affected, what corrective action is required and which authority must be informed under which legal framework.

This is where jurisdiction begins to matter.

Under Article 9(8) of the EU General Product Safety Regulation, a manufacturer that considers, or has reason to believe, that a product it has placed on the market is dangerous must immediately take appropriate corrective measures and inform consumers where appropriate. Articles 9(8) and 9(9) together establish the related notification process through the Safety Business Gateway. Article 20 separately requires manufacturers to notify product-related accidents through the Gateway without undue delay.

Great Britain operates under the General Product Safety Regulations 2005, supplemented by sector-specific legislation where applicable. Businesses must notify the appropriate enforcement authority where unsafe or non-compliant products trigger the relevant legal requirements.

Northern Ireland continues to apply the EU General Product Safety Regulation under the Windsor Framework. As a result, businesses operating across the UK may need to assess the same product under different reporting frameworks.

Consider a connected consumer product sold in France, Great Britain and Northern Ireland.

A remote software update changes its behaviour and several safety-related incidents are reported.

The technical signal may be identical across all three markets, but the reporting analysis is not.

France and Northern Ireland fall within the EU GPSR framework and the Safety Business Gateway route. Great Britain requires assessment under the General Product Safety Regulations 2005 and any relevant sector-specific legislation.

One technical event has now become several jurisdictional decisions.

Classification is therefore not simply a legal exercise. It requires technical evidence, market knowledge, operational coordination and governance clarity.

If the analysis takes too long, visibility lags.

If the wrong framework is assumed, visibility fragments.

Stage 5: Reporting and External Visibility

Once classification has been completed, the issue enters a formal reporting process.

Within the European Union, businesses use the Safety Business Gateway to notify national authorities about dangerous products and qualifying accidents. Authorities assess the information, oversee corrective action where necessary and, when the legal criteria are met, circulate information through the Safety Gate Rapid Alert System.

In Great Britain, businesses notify the relevant enforcement authority. The UK Product Safety Database is used by Trading Standards, national regulators and OPSS enforcement teams to record and share information relating to unsafe and non-compliant products. It is not the direct notification route for businesses.

External reporting does not necessarily make the issue immediately visible to the public.

Authorities may need to validate the information, assess the risk, coordinate corrective action or request additional evidence.

Reporting is therefore not the end of the visibility journey.

It is the point at which the organisation's internal assessment becomes subject to external scrutiny.

A public alert, recall or corrective-action notice confirms that the signal reached the formal reporting system.

It does not necessarily reveal how long the signal existed, how fragmented the evidence was or how difficult the internal decision became.

The journey is rarely linear, especially for software-defined products

The five stages provide a useful model, but real product safety investigations rarely follow a perfectly linear sequence.

New evidence may change the interpretation. Software updates may remove one symptom while exposing another. Different markets may require separate assessments, and investigations often move repeatedly between interpretation, escalation and classification before a final reporting decision is reached.

Software places additional pressure on every stage because signals may originate from remote updates, cloud infrastructure, cybersecurity events, external APIs or changing operating conditions. The relevant evidence may be distributed across systems and organisations that were never designed to support one coherent product safety assessment.

The revised Product Liability Directive explicitly brings software within the product liability framework. The AI Act introduces lifecycle expectations around monitoring, governance, documentation and human oversight.

Together, these developments reinforce the same conclusion.

Product safety increasingly depends not only on understanding physical products, but on understanding how information moves throughout the product lifecycle.

Visibility must therefore be designed into the organisation.

It cannot be assumed to emerge naturally from disconnected engineering, quality, legal and regulatory processes.

Final Thought

Product safety reporting systems are often described as alert systems.

In reality, they are information and decision systems.

Their effectiveness depends on how evidence moves through an organisation, who interprets it, how thresholds are applied and whether fragmented signals can be connected before valuable time is lost.

Modern product safety is becoming less about reacting to visible failures and more about recognising emerging patterns before they become visible to everyone else.

That is the real visibility gap.

Next in the Series

Part 3 explores what happens once product safety information reaches the public domain and asks a difficult question.

Do public alerts show the complete picture of product safety, or only the incidents that successfully made it through the visibility journey?

Sources and References

Regulation (EU) 2023/988 – General Product Safety Regulation
https://eur-lex.europa.eu/eli/reg/2023/988/oj/eng

European Commission – Safety Gate Rapid Alert System
https://ec.europa.eu/safety-gate/

European Commission – Safety Business Gateway
https://webgate.ec.europa.eu/safety-business-gateway/

UK Government – General Product Safety Regulations 2005
https://www.gov.uk/government/publications/general-product-safety-regulations-2005

UK Government – Business Notifications of Unsafe and Non-compliant Products
https://www.gov.uk/government/publications/business-notifications-of-unsafe-and-noncompliant-products

UK Government – Product Safety and Non-compliance Notification Guidance
https://www.gov.uk/government/publications/notifications-of-unsafe-and-noncompliant-products/product-safety-and-noncompliance-notification-guidance

UK Government – General Product Safety Regulations (Northern Ireland)
https://www.gov.uk/government/publications/general-product-safety-regulations-northern-ireland

Directive (EU) 2024/2853 – Revised Product Liability Directive
https://eur-lex.europa.eu/eli/dir/2024/2853/oj/eng

Regulation (EU) 2024/1689 – Artificial Intelligence Act
https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng