Key takeaway

The archive must show what was tested, against which procedure, with what result and reinstatement evidence.

Review the function rather than the ticket count

A completed maintenance ticket can describe a sensor check without demonstrating the documented scope of a safety-instrumented function. Before counting proof-test records, identify the function, applicable procedure and evidence expected under the responsible engineering program. A data reviewer can expose missing documentation; the reviewer cannot determine safety integrity from ticket fields or choose a safe testing method.

HSE's current functional-safety page describes SIS sensing, logic and final elements and places periodic proof-testing within a managed lifecycle. Its control-systems guidance discusses defined criteria, end-to-end scope, process connections and reinstatement, and distinguishes actuator exercising or partial-stroke diagnostics from proof testing. These UK guidance passages were read 10 October 2026. This article is a retrospective evidence review, not instructions for testing, bypassing, modifying or operating a real safety system.

Work one incomplete function record

In this hypothetical function F7, an approved documentary checklist expects five evidence relationships. Ticket T17 is marked complete, but its packet contains only the sensor observation and logic-check reference. It links a separate actuator exercise, lacks the required process-connection evidence and has no reinstatement verification. The packet can establish that those two documented activities occurred; it cannot demonstrate the full approved scope.

Counting two populated rows out of five would produce 40% documentary completeness under this invented checklist. It would not produce 40% dangerous-failure coverage, proof-test effectiveness or any safety-integrity level. Different failure modes, test methods and dependencies cannot be represented by equally weighted rows. The completed records-review result is scope evidence incomplete, with missing items assigned to the competent function owner for review.

Expected relationshipIllustrative T17 evidenceRecords-review result
Sensor to applicable procedureObservation with procedure revisionEvidence present; technical adequacy not assessed
Logic function checkLinked result referenceEvidence present; technical adequacy not assessed
Final element scopeActuator-exercise note onlyNo full proof-test scope demonstrated
Process-connection evidenceNo linked resultUnresolved
Reinstatement verificationNo retained confirmationUnresolved; no operating clearance

Preserve scope, as-found and as-left information

Build an internal map from function identity to the authorized procedure version, covered components, recorded results and exclusions. Preserve who performed and reviewed the activity, its actual date, conditions and stated acceptance criteria. Keep as-found observations distinct from repairs and as-left results so a later successful status does not erase a failure discovered during the work.

Retain references to applicable exceptions, deferred activities and follow-up actions. If several tickets jointly provide evidence for one function, show the relationship instead of counting them as several independently tested functions. If one ticket covers several functions, do not assume every result applies to all of them. The responsible engineering owner must determine whether the recorded scope and relationships are appropriate for the actual system.

Treat reinstatement and changes as separate evidence

HSE's sensing and maintenance passages identify reinstatement and verification after testing or maintenance. In an archive, link that evidence to the activity it closes. A ticket's administrative closure may occur before a verification document is attached; preserve both timestamps and do not infer the missing verification from the closure flag.

For F7, the first retrieval tasks are the actual final-element/procedure relationship, process-connection result and reinstatement evidence. If those records cannot be found, describe the gap rather than reconstructing a favorable result from memory. Keep a component replacement or configuration change linked to its own authorized review. A prior test record may describe an earlier configuration, so its applicability to a modified function needs explicit expert assessment rather than automatic carry-forward.

Use metadata that does not expose the plant

The deliverable is a function-to-evidence map with missing scope and configuration relationships. It helps an owner determine whether historical test descriptions are interpretable before a separate technical review. It does not certify a plant, recommend an interval or substantiate a recipient's proposed safety model. Detailed logic, vulnerabilities, locations and incident information can be highly sensitive.

Use Inventory and Due diligence to explain categories through fictional rows first. VOID has no upfront seller referral fee and may receive conditional receiving-program compensation. A named-recipient metadata introduction requires permission; actual records, evaluation and licensing each require separate authorization and appropriate specialist review. No documentary-completeness percentage establishes market value, safety performance or buyer demand.

Tools for this decision

Data inventory builder →Diligence question builder →