Docs · Governance

How the standard evolves.

A protocol is a promise about stability. This is how GOVP-1 is versioned, how changes are proposed and gated, what compatibility you can rely on, and how it is licensed and stewarded in the open.

Current wire format · GOVP-1

1 · Versioning

One version in the bytes, not in a promise

The wire format carries its own version in the Version field (GOVP-1). Two things version independently so implementations know exactly what they are dealing with:

Wire format	The record grammar, canonicalization and signing input. A new incompatible grammar means a new format tag (e.g. GOVP-2) — never a silent change to GOVP-1.
Profiles	Named add-ons like GOVP-RFC3161 or GOVP-QTSP. New capabilities arrive as new profiles, so a record always declares what it relies on.
Conformance suite	Versioned goldens (GOVP-CORE-CONFORMANCE-1). The suite is the executable definition of a format version.

2 · Change process

How a change is proposed

Changes are made in the open, against the specification and the conformance vectors — not by fiat in a product.

Propose
Open a proposal describing the change, its motivation, and its impact on the wire format, profiles or trust model.
Specify
Write the exact behavior, including new or amended canonical bytes, so it is unambiguous.
Add vectors
Contribute golden vectors that pin the new behavior byte-for-byte.
Prove across implementations
Demonstrate at least two independent implementations agreeing on the new vectors.
Adopt
A backward-compatible addition ships as a profile or minor suite bump; an incompatible change mints a new format tag.

3 · Compatibility

What you can rely on

Records don't rot	A record valid under a published format stays verifiable under that format forever. Verification is a pure function of the record.
Additive by default	New profiles and optional fields never invalidate existing records or existing verifiers.
Breaking = new tag	Any change that would alter the canonical bytes of an existing record is a new format version, never an edit to a shipped one.
Unknown-but-safe	Verifiers ignore optional fields they don't understand rather than failing, as long as the signed core verifies.

4 · Conformance gate

The suite is the source of truth

An implementation is "GOVP-conformant" only if it reproduces the golden vectors exactly — the same canonical bytes, the same GOVP-ID, the same pass/fail verdict. The spec prose explains; the vectors decide.

Available implementations exist in Python, JavaScript and PHP today. The WordPress plugin ships a self-test and a reproducible PHP↔Python harness so an operator can verify conformance inside the installation and in CI. See the conformance suite →

5 · License & FSF

Open claims must be independently checkable

The GOVP-1 specification, schemas, conformance vectors and reference CLI are released under the MIT License. The WordPress reference implementation is also MIT-licensed. Each additional component states its licence in its own distribution. No planned submission, affiliation or directory listing is presented as if it had already happened.

The intent is explicit: an evidence protocol should belong to the commons — openly specified, freely implementable, and governed in the open rather than owned as a product. That is what makes "the proof outlives the vendor" more than a slogan.

The open-source commitment Reference libraries

6 · Security disclosure

Report issues responsibly

Cryptographic evidence deserves cryptographic seriousness. If you find a weakness in the specification, the canonicalization, a reference implementation or the conformance vectors, disclose it privately first so a fix and updated vectors can ship before details are public.

In scope	Signature or canonicalization flaws, ID collisions, verifier bypasses, SVL authorization gaps, trust-model manipulation.
Contact	Reach the maintainers at contact@gemacode.org with "GOVP security" in the subject.
Handling	Coordinated disclosure: private report → fix + new vectors → public advisory.

7 · Stewardship

Who maintains it, and how it opens up

GOVP is currently developed and maintained by Gemacode Research, which stewards the specification and the conformance suite. The direction of travel is toward independent, multi-party governance as adoption grows — the same principle the protocol itself embodies: no single party should be the sole source of trust.

Read the specification Back to docs

8 · Name & mark

Using the GOVP name

The protocol is free to implement; the name carries meaning worth protecting. The rules are the simple ones an open standard needs:

You may	Say your implementation "conforms to GOVP-1 (GOVP-CORE-CONFORMANCE-1: pass)" when it does; call your product "GOVP-compatible"; use the name to refer to the protocol in docs, talks and articles.
You may not	Call a non-conformant implementation "GOVP"; imply endorsement by the maintainers without it; use the name for a modified format that fails the vectors — fork freely, but under your own name.
Badges	A GOVP badge may say "verifiable" and link to verification; it must never say "approved", "certified true" or "safe". See the badge honesty rules.