Working was not the same as healthy

The incident involved an ROV armored cable that combined high-voltage power, optical-fiber communication and a mechanical load-bearing structure formed by opposing layers of high-strength wire.

During recovery of the vehicle, I noticed that the outer armor layer had loosened and that some strands had begun to overlap.

I reported the condition to the supervisor and began correcting it with another technician. The required intervention was known: realign the strands and tension the cable before using it again. The work was estimated to delay the operation by approximately one hour.

The intervention was stopped. The decision was to launch the vehicle again based on the expectation that the armor would settle during deployment.

The condition remained unresolved, and a knot subsequently formed in the cable on the drum. The vehicle could no longer be recovered normally.

1. ObserveLoose outer armor and overlapping strands during recovery.
2. PrepareRealignment and tensioning began; the intervention was estimated at approximately one hour.
3. DeferThe correction was stopped and the vehicle was launched again.
4. FailA knot formed on the drum and normal recovery became impossible.

The team managed to recover the ROV, but doing so damaged a section of the cable. Returning the system to service required removing the damaged section, rebuilding the armored-cable termination at the vehicle and completing the necessary tests.

More than 16 hours elapsed between the knot forming and the ROV returning to operational condition.

As a trainee, I assisted the technicians and supervisor throughout the recovery and retermination while observing the procedure as part of my development. I did not lead the repair or own the operational decision.

Preventive intervention also has a cost, and unnecessary maintenance can create waste or new risk. The stronger lesson was that the current state of a system is not enough to decide its future.

The system had not yet failed, but direct observation showed a condition that required correction. After the intervention was deferred, the observed condition developed into a knot, followed by cable damage, retermination and more than 16 hours of downtime.

Good preventive judgment combines evidence, technical limits, criticality, operational context, intervention cost and the consequence of deferring action.

A condition deferred today can return with greater consequences.

This experience helped shift my attention from responding only after failure toward acting before a known condition became a larger problem.

The case is not evidence of software architecture, SRE or software reliability expertise. Its relevance is narrower: it shows the origin of a consequence-oriented and preventive way of making engineering decisions.

In software, a system can still deliver features while accumulating coupling, fragility, obsolete dependencies or implicit knowledge. That does not justify automatic refactoring. It means the decision should include another question: what could happen if we leave the system in this condition?

This case study passed desktop, mobile, accessibility and confidentiality validation before publication.

Explore other evidence