Skip to content
Menu

Trust Center / Certificate policy: coverage and status

Certificate policy: coverage and status

updated 2026-10-02

This proposed policy describes what our certificates record and how to check them. Purchasers may describe their participation in their own words, in any language, without prior approval. The publicity and brand-use policy grants permission to use our name, links and official artwork. Its rules apply to our marks, not to purchasers’ independent wording.

No production certificate has been issued yet. None is issued before launch. The transparency log is empty.

The two classes

The machine tokens are frozen and are not renamed to match prose. A consumer switches on the token; a reader reads the name.

  • Payment certificate — typ: supporter. Attests a settled payment, and nothing beyond it.
  • Status certificate — typ: license-status. Attests a status already recorded, and nothing beyond it.

Payment certificate — typ: supporter

What it attests. Which Entitlement the organisation bought, the period and the scope it covers, and the revenue band the payer self-certified. It is issued after the payment settles against a recorded transaction, never in anticipation of one. It prints the self-certified band, which is the whole deterrent: understating a band is self-embarrassing in a procurement review, and there is no audit right anywhere in the terms.

Variants, of which exactly one is issuable at this phase:

  • entitlement — the holder may state that it holds a paid Entitlement of the Purpose Source Network. Issuable, on a settled Purpose Fee payment; none has settled yet.
  • gift-funder — funded an Entitlement for another organisation. Not issuable: it needs the gift flow.
  • waived-funder — holds a waiver and funded the movement separately. Not issuable: it needs a settled top-up or a documented donation, and neither exists at this phase.
  • donation — funded the movement through the donate-direct lane. Not issuable: that route was dropped on 2026-10-01, before it opened.
  • sponsor — sponsors the Purpose Source Association. Not issuable: it waits for the tax adviser’s answer on how sponsorship is treated for VAT (LEG-094). Its terms will be published alongside it. A sponsorship is invoiced and paid by bank transfer, buys no coverage, and is never a Purpose Fee.

Sharing the record. The certificate supplies facts you can reference: the coverage, period, scope and fee. You may use your own wording and link to the record. The payment on this lane is a Purpose Fee, never a donation.

Status certificate — typ: license-status

What it attests. A status this movement has already recorded, and only that. It attests no payment, because none was made under it, and it carries no amount field at all — an unfunded class has nothing to quote.

Variants. These labels identify the recorded status:

  • waiver — the holder may state that it is a Purpose Source Licensed Organization — waiver. Issuable, on a granted waiver; none has been granted yet.
  • under-threshold — Purpose Source Licensed Organization — under threshold. Issuable, on a recorded threshold registration; none is recorded yet.
  • gifted-pass — covered via gifted Pass. Not issuable: it needs the gift flow.

Two of those three are issuable by policy and unreachable in practice today, and the difference is worth stating rather than blurring. A waiver is granted by a repository administrator who has proved administrative control, and that flow does not exist yet: the waiver registry is published and correctly empty, so no waiver certificate exists either. A threshold registration is the organisation’s own self-certification, on one binding tick with no audit right anywhere in the terms, and the surface that records it is not built either. Both are honest empty states, not outages — and the waivers guide carries the rules that will govern the first one.

Sharing the record. This class establishes the status and period shown. It records no payment. You may describe your participation in your own words and link to the verification record.

Publicity and official marks

You are welcome to reference Purpose Source, link to our website and official social profiles, and use the official logos and coverage badges. No approval of your wording is required. The brand-use policy asks that official artwork retain its identity, badge status remain accurate and marks not be used to imply a false affiliation or in deceptive or abusive material. Purchasers are responsible for their own statements and third-party permissions.

Verification

Our canonical human verification page is purposesource.org/verify. Official coverage badges link to the relevant verification record. Other publicity may link to our website or official social profiles. Machine endpoints are documented in the public API.

Expiry, revocation and supersession

A certificate’s status is one of four values, and the differences between them matter:

  • valid — in force for the period it states.
  • expired — its period has ended. Expiry is derived from the date, needs no write, and is not revocation: an expired certificate verifies as “was valid for period P”, because the coverage it attested was permanently vested when it was paid for.
  • revoked — an event, appended to the log, never an edit. The reason is published as one of six classes — issuance error, subject request, fraud or misrepresentation, project delisting, waiver revocation, key-compromise reissue — and the verification page renders the class label only. There is no free-text shaming. A waiver revocation is prospective: the record keeps both the original coverage window and the revocation date.
  • superseded — a renewal issued a new certificate with a new id, linked by supersedes / supersededBy. An issued payload is never mutated, for any reason; that immutability is what the log attests.

A correction is always a new forward-only entry. Nothing in the log is ever edited or deleted, and how to check that yourself needs none of our code.

What does not exist yet

The type system names five classes. Three of them cannot be issued at this phase, and the fourth thing on this list does not exist at all:

  • Contributor participation certificate — contributor. Not before the claim flow: it needs a claimed account, the subject’s own opt-in, and an attribution record to attest. A certificate about a person is never issued without that person’s opt-in.
  • Steward certificate — steward. Not before the claim flow, which is what establishes a proven project steward; the impact variant additionally not before the project’s own first ledger row.
  • Top-up multiplier certificate — topup. Reserved and never issued: the voluntary multipliers were withdrawn before any sale (D44), so there is no way to buy a multiplier and no settled payment for one to attest. The token stays only because the type system is frozen.
  • Any certificate, figure or claim about impact — no token exists for it. Not before the first disbursed ledger row exists. Nothing has been disbursed, so there is nothing to attest and no figure to print.

The last item is the load-bearing one. There is no token for it in the frozen type system, and the operator signing tool has no code path that could write such a field: the absence is structural rather than remembered. The ledger is where the first disbursed row will appear, and the day it does is the day the question of a further class can be asked — not before.

Machine-readable records

Sample artifacts on the non-production hosts use the earlier certificate schema; production holds none. They are retained for technical verification and do not define the current purchase. No new certificate is issued here. The API reference documents that historical format. A production rollout of this proposal will require a new policy and issuance format; existing signed records remain unchanged.