Verification
SHP verification answers a specific question:
Does the observed system state satisfy the applicable SHP controls under the defined evaluation rules?
Verification is separate from both hardening and certification.
Hardening is not verification
Applying a configuration does not prove that the required state exists.
A deployment procedure can fail, a system can drift, a dependency can change, or the observed state can differ from the intended state.
SHP therefore requires controls to define how their resulting state is evaluated.
Deterministic evaluation
Verification tooling must be designed so that the same supported inputs, evaluated under the same versioned rules, produce reproducible results.
The verification process must not depend on hidden judgement.
Verification logic must be:
- open
- deterministic
- versioned
- reproducible
- structured in machine-readable output
Evidence
Verification is based on evidence derived from observed state.
Evidence must retain enough context to support the applicable evaluation and certification decision.
Where evidence is unavailable, insufficient, unsupported, erroneous, or otherwise unable to establish the required condition, the verifier must preserve that distinction according to the applicable specification rather than silently treating uncertainty as success.
Control results
Control evaluation is not a percentage-based security score.
Individual control results feed the applicable platform and tier decision rules.
Non-Negotiable Controls receive their defined gate semantics.
A verifier must not silently convert a failed mandatory condition into a passing certification result.
Machine-readable output
Verification output is intended to be suitable for deterministic downstream processing.
The certification decision must map directly to the applicable verification output and decision rules.
This allows the reasoning from observed state to certification outcome to be examined rather than hidden behind an opaque decision.
Verification does not equal certification
Anyone may be able to execute open verification tooling and inspect its output.
That does not create SHP certification.
Certification requires a valid certification decision and issuance under SHP-controlled signing authority.
Client self-signing, locally generated badges, or independently produced statements do not constitute SHP certification.
Drift and re-verification
Certification represents an evaluated state.
When relevant system state changes, the previous verification result may no longer describe the current state.
SHP therefore treats drift according to defined rules rather than assuming that a previously certified configuration remains valid indefinitely.
Where drift invalidates certification, re-verification is required before the current state can again be represented as certified.
Independent verification
The SHP model is designed so that certification authenticity and the machine-readable artefacts supporting it can be independently examined.
Public verification supplements cryptographic verification; it does not replace it.