TRUST METHODOLOGY
How a HIP score is produced.
This page explains the methodology and review model. Each live result carries the exact rule version, evidence and score breakdown that produced it.
RULE VERSION
Per result
Every result records the immutable version that produced it instead of presenting a possibly stale site-wide number.
BASELINE
Versioned
The baseline belongs to the active rule definition. HIP does not silently treat 50 as neutral.
SCORE RANGE
0–100
Clamped at both ends. A score is only meaningful next to its scan date.
Score bands
The bands below illustrate the design vocabulary. A live result's versioned breakdown is authoritative, and no band is a promise about future behaviour.
85–100 · Trusted
Required checks pass and no significant risk signal fired at the time of the scan.
70–84 · Mostly Trusted
Nothing severe, but one or more findings are worth resolving.
45–69 · Needs Review
Meaningful weaknesses found. Visitors may be exposed to avoidable risk.
0–44 · High Risk
Severe findings, such as credentials submitted over an unencrypted connection.
Badge requirements
All of the following must hold before a trust badge is granted. Registering a domain is not sufficient.
Ownership proof
A DNS TXT record unique to the domain and account, still present at the time of review.
Required checks
Encrypted connection enforced, valid certificate from a trusted issuer, no critical page-behaviour finding.
Score threshold
At or above the current verification standard for the active rule version.
Human review
A reviewer confirms the evidence. Automated pass alone does not grant a badge.
Pause conditions
The badge is paused if a required check fails or the score falls below the current standard, not for ordinary point-to-point movement.
Expiry
Verification records expire, so a badge cannot outlive the evidence behind it.
Review and corrections
How a finding is contested
Findings marked appealable can be contested with context. A reviewer sees the same evidence you do and either upholds the finding, adjusts your result, or changes the rule for everyone.
Appeals and their outcomes are recorded against the domain's audit history.
How a rule is corrected
Rule changes are proposed and discussed in the open repository, tested against real scans, and shipped as a new rule version.
Scores are not silently rewritten: a result keeps the version that produced it, and re-scanning is what applies a newer rule set.
How provider results are handled
Attribution
Every external result is recorded with its source and the time it was retrieved.
Weighting
A provider signal is one input among several. A single provider cannot by itself set a score.
Disagreement
Where providers conflict, the result shows both rather than silently picking one.
Staleness
Provider results carry their retrieval time; an old result is shown as old, not as current.
Known limits
Stated plainly, because a trust system that hides its limits is not trustworthy.
Point-in-time only
A score reflects one scan at one moment. A site can change immediately afterwards.
No guarantee of safety
HIP does not prevent every threat. A high score means the checks HIP ran found no significant problems.
Observable signals only
HIP measures what it can inspect from outside. It cannot see server-side code or internal practice.
Wording rules are judgement calls
Urgency and impersonation detections are the most contestable, which is why they are documented and appealable.
Coverage varies
A new domain carries less evidence than an established one. HIP says so rather than guessing.
Provider dependence
Where an external service is unavailable, the affected signal is marked missing rather than assumed clean.