Verification Policy

General Principle: OpenGPSR does not "create truth". OpenGPSR stores versioned information along with source and verification history. Verification status serves to assess record usage risk, not to certify the entity.

1. Verification Statuses (Taxonomy)

Verification status describes the current assessment of data credibility for a given record version. The system uses taxonomy consistent with VerificationStatusType.

Status	Trust Level	Meaning
PRIMARY_CONFIRMED	High	Data confirmed by a primary source (e.g., official entity website, official document published by the entity). Source is indicated and verifiable.
COMMUNITY_CONFIRMED	Medium	Data confirmed by community (e.g., independent confirmations + verifiable source trace), but without strong primary confirmation.
UNVERIFIED	Low	Default status for new submissions or versions that have not passed review yet. Data may contain errors or be incomplete.
OUTDATED	None	Data marked as outdated (e.g., 404 page, expired domain, email bounce). Record may remain visible as a historical trace but should not be used for compliance.
HISTORICAL	Low	Historical data or requiring re-verification (e.g., no current source, old document, temporal discrepancies). May be "true", but risk is higher.
DISPUTED	Low	Data disputed or conflicting (different sources provide different information). Record requires resolution or additional evidence.

Note: Status is assigned to a specific version of data. Changing data creates a new version, and verifications constitute a separate event history.

2. Verification Process

Verification is a controlled process. Submissions are accepted mainly via form or GitHub Issue, and then evaluated based on the Source Policy. The API is designed primarily for data reading.

Requirements for PRIMARY_CONFIRMED

Indication of a direct source (URL or document), preferably on a domain owned by the entity.
Unambiguity: source must explicitly state the data we publish (no guesswork).
Manual verification by maintainers / trusted verifiers or clearly documented automated method (if applied).

Transition to COMMUNITY_CONFIRMED

Can occur when there is a credible trace but primary confirmation is lacking, and data has been confirmed repeatably (e.g., by independent reports and consistent secondary sources). In practice, treat this as "useful, but with caution" level.

Status Degradation

Status can be lowered or set to OUTDATED / HISTORICAL / DISPUTED, if evidence of obsolescence, contradiction, or error appears (e.g., new source, report with proof). We do not promise automatic thresholds — decision depends on evidence quality and context.

3. Verification Metadata (Audit Trail)

Review status label alone is not enough. To ensure transparency, every verification is logged as a separate entry linked to a specific data version (e.g., VerificationRecord):

status: value from VerificationStatusType.
verifiedAt: verification date (ISO 8601).
verifiedBy: verifier identifier (user/system) – if available.
verificationMethod: method (e.g., manual_check, automated_check, user_report).
evidenceUrl: link to proof (evidence), if applicable.
notes: explanatory note (optional).
expiresAt: if verification has an "expiration date" (optional).

Important: Verification concerns a moment in time. The fact that a source was correct on verification day does not mean it will be correct in the future. That's why dates, evidence, and re-evaluation capability are essential.

4. Disclaimer

Status PRIMARY_CONFIRMED only means that at the time of verification, the indicated source contained data consistent with the record. It does not mean that the entity fulfills legal obligations, nor that the contact is actively serviced. The database user has an obligation of due diligence in their use case.