ICISELFLAB / RELIABILITY

Reliability testing built around failure mechanisms

ICI Reliability asks whether a correction survives when the conditions change, instead of treating one successful rerun as proof that the underlying failure has been removed.

01

The problem

A system can appear fixed because the original symptom disappears while the causal mechanism remains active. Regression returns when context, load, tool sequence, data quality or operator behaviour changes. Conventional pass/fail testing can miss this because it records the outcome without retaining why the failure happened.

02

How ICI approaches it

ICI records the failure mechanism, supporting and opposing evidence, corrective action and the conditions under which the result was obtained. It then generates counter-tests that vary causal factors deliberately, looking for hidden recurrence, interacting controls and boundaries where the mitigation stops working.

03

Operational example

A workflow stops failing after one parameter is adjusted. Reliability testing restores the original load while independently changing telemetry quality or a dependent control. If the fault returns, the correction is classified as context-bound rather than treated as a durable fix.

04

Evidence discipline

Results distinguish verified mitigation, regression, hidden recurrence, unresolved interaction and insufficient evidence. Confidence follows the available test evidence rather than the apparent neatness of the result.

WHY THIS MATTERS

When agreement is not independent evidence

A short principle page connects a maritime integrated-system failure with a modern AI case.

This is not a 1995 principle. It is a structural principle.

The same information can pass through several displays, people, agents or workflow stages and look confirmed simply because it appears more than once. Progress increases speed and the number of steps; it does not remove causal dependence on the original source.

Repetition can increase perceived confidence without increasing independent information.
1995ROYAL MAJESTY

Royal Majesty: many systems, one fragile position source

On 10 June 1995, Royal Majesty grounded near Nantucket. The NTSB found that after a GPS antenna connection problem, the receiver shifted to dead-reckoning mode while the integrated navigation system and autopilot continued to operate without the mode change being adequately recognised and managed.

The NTSB stated that comparing inputs from multiple independent position receivers and alarming on discrepancies could have prevented the grounding.

ICI: Different displays do not necessarily mean different sources. If the upstream dependency is shared, downstream coherence can be only apparent.

Primary source: NTSB Marine Accident Report MAR-97/01 ↗
2023MATA v. AVIANCA

Mata v. Avianca: asking the same source to confirm itself

In Mata v. Avianca, a lawyer used ChatGPT for legal research. The system produced citations and judicial opinions that did not exist. When those authorities were questioned, further prompts to the same system produced additional assurances and details instead of an independent verification.

The court documented that the cited authorities were fictitious and imposed sanctions. The same informational origin had effectively been reused as if it could validate its own result.

ICI: A second answer is not a second piece of evidence when it comes from the same epistemic dependency. Real verification requires an independent path.

Source: U.S. District Court, S.D.N.Y., sanctions opinion ↗

The right question is not “How many agents agree?” but “How many genuinely independent evidence lines support that conclusion?”

The principle is public. The implementation is not.

This page explains the epistemic rationale and public cases. It does not disclose Sentinel’s proprietary architecture, scoring logic, thresholds, internal evaluators or intervention-selection mechanisms.