Reference framework principles

\"Examine the method.\" — why the RestorSignal reference framework is designed to be audited.

The RS-RVP reference framework rests on a principle stated directly in its normative text: "You do not have to take our word for it. The method is built to be audited." This page explains what that means in practice, and the principles that follow from it.

The client stays in control of the artifact

RestorSignal does not connect to the client's backup console, does not select a backup itself, does not automatically search for an artifact, and never decides which backup should be checked. It also does not require administrative credentials to Proxmox, PBS, Hyper-V, a NAS, or any backup software. The client explicitly selects the artifact and triggers the verification; automation can be set up on the client side, but it remains an instruction the client defined — never an initiative RestorSignal takes on its own.

Verifying observable facts, not producing an impression

The reference framework explicitly rules out vague qualifications such as "this backup is good." A RestorSignal result must describe the facts observed, the components used, the criteria applied, and the limits of what was actually verified. That requirement for precision is what separates an evidence package from a mere opinion.

The backup software's status is not RestorSignal's proof

A "backup successful" indicator shown by backup software does not, on its own, constitute proof of restorability under the reference framework. RestorSignal produces its own proof, independent of that status.

A method built to be audited, not a certification

RestorSignal is not a certification body. It does not issue ISO certification or "official certification," and the reference framework explicitly rules out phrasing such as "certified backup" or "restore guarantee" unless an applicable external certification scheme permits it. What RestorSignal produces is reproducible, traceable technical evidence, with documented rules, versioned scenarios, and explicitly stated limitations — available for a competent third party, an external auditor, or a certification body to rely on, should they choose to.

Three distinct objects that must never be conflated

The reference framework rests on a strict conceptual separation between three objects:

• the reference framework defines what must be demonstrated — the levels, the statuses, the roll-up rules;
• the runner defines how observations are produced — the technical implementation that actually executes the restore and the controls;
• the evidence package is the documented result of a run — what was observed, with which tool, on which date, with which limitations.

A change to a runner's implementation must never silently change what a level means. If a runner's behavior changes in a way that affects the scope of a level, that must translate into a new qualification of the protocol concerned, not a silent drift in its definition.