Back to Home

Governance Model

Decision-making principles, responsibility, and dispute resolution.

"OpenGPSR is a technical project, not a legal arbiter."

1. Role Structure

👑 Lead Maintainer

Coordinates the direction of development and makes tie-breaking decisions on technical architecture, security, and stability. Responsible for server infrastructure and data publication policy.

🛡️ Maintainers

A trusted group of people with permissions to approve code changes and verify data submissions (form / GitHub Issue). Publication decisions are based on evidence (sources) and data consistency.

*Maintainer status is granted based on the quality and consistency of contributions, not professional titles.

2. Decision Making

OpenGPSR operates on an "evidence first" model: every decision to add or change data should have an indicated source (URL / registry / document / official website). In practice:

  • No source usually means no publication.
  • Conflicting sources mean marking a dispute and cautious publication (e.g., status DISPUTED).
  • API is designed primarily for data reading; changes/reports are prioritized via the form and verification process.

3. Dispute Resolution

In open projects, conflicts are inevitable. We use a simple escalation path:

A. Content Disputes (e.g., "is this the correct contact?") The strength of evidence (source) decides. If evidence is equivalent or ambiguous, data may be published as disputed (e.g., DISPUTED) or marked for re-verification (HISTORICAL/OUTDATED). The goal is pragmatism and risk minimization, not "winning the argument".
B. Technical Disputes (e.g., "how to model data / API?") We strive for consensus in technical discussion. In the absence of agreement, the Lead Maintainer chooses the solution safest for system stability, compatibility, and security.
C. Legal Disputes (e.g., "entity demands removal or correction") "Safety First" Principle: in case of a credible legal report or risk of rights infringement, data may be immediately hidden from public view pending clarification. OpenGPSR is not a party to legal disputes and does not conduct litigation. The priority is limiting project exposure and rapid response.

4. Philosophy: Right to be wrong

  • Iteration over perfection: the database will not be 100% perfect. Records may contain errors at the time of addition. The project assumes versioning and corrections, not a "one-time truth".
  • Fix, don't defend: if data is incorrect or outdated — we correct it based on sources. Change history is an element of audit (versions, sources, verification statuses), not a field for proving points.
  • Neutrality: OpenGPSR does not evaluate companies or products. We do not grant "certificates" and do not publish opinions. We provide identification and contact data needed to automate compliance processes.

5. Project Continuity and Succession

The project is designed so that it can survive a change of maintainers. The public view of data may be periodically exported to open formats (e.g., JSON), enabling independent archiving and launching a project copy (fork) if needed.

Note: export is not a "guarantee of completeness" — it is a snapshot of the public state, intended for integration and reading.