Trust Center
An accurate map of what this Association can prove today, what it has filed and is waiting on, and what a phase has not yet produced. Pending items are listed, not omitted.
The organisation
- Name
- Purpose Source Association
- Legal form and seat
- Verein under Art. 60 ff. ZGB · seat Aargau, Switzerland · commercial-register entry pending publication
- Founded
- September 2026 — the founding assembly adopted Statutes v1
- Commercial register
- Entry applied for; publication pending. The Art. 61 Abs. 2 Ziff. 3 ZGB registration duty (an association collecting or distributing funds abroad for charitable purposes) is acknowledged; a member register under Art. 61a ZGB is kept.
- Representative under Art. 69 Abs. 2 ZGB
- appointed; named in the imprint on publication of the register entry — Swiss-domiciled
- Role
- Registrar and witness for the Purpose Source category. Never a licensor of any project's code and never a recipient of routed funds — see what we can never do.
- Contacts
- hello@purposesource.org · legal@purposesource.org · security@purposesource.org — all routes on the contact page
What we can prove today
The licence text
Byte-exact, hash-pinned, served at a permanent URL, with the development record public. Versions
The statutes
Adopted at founding, published in full with the never-reopen articles marked. Statutes v1
The money rules
The fee stack with its cap, the cost-line categories, the one-month hold, the append-only ledger methodology — published before the first franc. Where the money goes
The exit
Pre-registered kill criteria and a wind-down protocol that leaves every payer whole by construction. Kill protocol
The keys
Non-exportable signing keys, a two-person ceremony, an append-only transparency log, and one fixed verification address. Keys and log
The site itself
No cookies, no analytics, no consent banner, no database on any anonymous path, one third-party script. Security
Documents
Where the money goes
The fee stack with its cap, the cost-line categories, the one-month hold, the routing-tier report, and the ledger methodology.
updated 2026-09-02
Keys and the transparency log
The signing key set, the key ceremony and rotation policy, the certificate transparency log, offline verification, and the one place certificates are verified.
updated 2026-09-02
What we can never do
The never-reopen clauses, each cross-linked to the article of the statutes or the section of the licence that binds it.
updated 2026-09-02
Kill criteria and the wind-down protocol
The pre-registered conditions under which the Association stops rather than continues, and what happens to payers, funds, the registry, and the marks when it does.
updated 2026-09-02
Statutes, register, rulings, audit, board
The Association’s own documents — what is published, what is filed, and what is pending on a third party or a phase.
updated 2026-09-02
Annual transparency report
The report index — the first report covers financial year 2026 and is published in Q2 2027 — and the template every report follows, with every figure deep-linked to its source.
updated 2026-09-02
Algorithms and schedule versions
The Impact Share algorithm versions, the coverage function and where its source is published, and every fee schedule version.
updated 2026-09-02
Security
How to report a vulnerability, what is in scope, the response targets and safe-harbour wording, and a summary of how this site and the edge API are built.
updated 2026-09-02
Statutes v1
The constitution: purpose, organs, the operating-cost cap, and every never-reopen article. English working text; the German original prevails once published.
Public API and rate limits
The published read APIs, their cache behaviour, the error envelope, the rate limits, and the propagation bound — documented with the developer docs rather than duplicated here.
Status and incident history
Uptime monitors for the site, the badge endpoint, the verification endpoint, and checkout, on the Association's own monitoring account, with public incident history.
Legal documents
Imprint · privacy notice · terms of use · entitlement terms — versioned, immutable permalinks.
Pending
Each entry names the document and the event that produces it. Some wait on a third party; some wait on a phase. None is "coming soon".
Security summary
- Static site, no cookies, no analytics, no consent banner. Aggregate traffic comes from server-side edge metrics. One third-party script exists — the bot-protection widget on the contact forms — and the Content-Security-Policy names it as the only permitted external script source.
- No database on any anonymous path. The edge API serves published artifacts from an object store and a key-value cache. Forms are verified and forwarded, never stored, and fail closed.
- Key custody. ES256 signing keys, born non-exportable in an HSM-backed vault in Switzerland; no human holds standing sign permission; every certificate is logged before delivery.
- Reporting. security@purposesource.org, security.txt, coordinated disclosure with published response targets and safe-harbour wording — on the security page.
Subprocessors
Every third party that processes data on the Association's behalf, what it does, what it sees, and where. This list is the "recipients" section of the privacy notice; a change here is a change to that notice and publishes as a new version of it.
Subprocessors at v0 — provider, purpose, data category, residency
| Provider | Services | Purpose | Data it sees | Residency |
|---|---|---|---|---|
| Cloudflare, Inc. | DNS · Pages (static hosting) · Workers (edge API) · Turnstile (bot protection on forms) · Email Routing | Serves this site and the public read APIs; challenges form submissions; routes mail sent to the published addresses to the steward inbox. | Request metadata (IP address, user agent, path) in short-retention edge logs; the challenge token; the envelope and body of inbound email in transit. Cached content is public (P0) artifacts only. | Global edge network. Anonymous request metadata may be processed at any edge location; no regional-services restriction is configured at v0. This is the documented residency exception for the public read plane. |
| Microsoft — Azure Key Vault | HSM-backed key vault | Custody of the ES256 signing keys, which are born in the vault and non-exportable; signing is an operation the vault performs. | No visitor data. Key material (never leaves the vault) and the vault’s own audit log. | Switzerland North (Zürich). |
| GitHub, Inc. | Source hosting · registry data (v0 YAML) · transparency-log mirror · OAuth sign-in (from P-M3) | Hosts the public repositories this movement is built in, including the committed transparency log; at P-M3, verifies repository administrative control in the claim flow. | Public repository content. At P-M3: GitHub login and opaque account identifier for people who sign in to claim a repository (minimal OAuth scope, no email). | United States (global service). |
| Paddle.com Market Ltd | Merchant of record for Entitlements | Sells the Entitlement to the payer as seller of record: checkout, invoice, card processing, indirect tax. The Association receives settlement records, never card data. | Payer billing identity and payment data, held by Paddle under its own notice; the Association receives the purchasing organisation, its contact, the band self-certification, and the settlement record. | United Kingdom / European Union / United States, per Paddle’s own infrastructure. Payment data never reaches the Association. |
| Postmark (ActiveCampaign, LLC) | Transactional email | Delivers form submissions to the steward inbox, and purchase receipts and certificate notices to their recipients. | Message content, reply address, delivery metadata. Nothing is stored on this site’s side; Postmark retains delivery logs under its own terms. | United States. |
| Better Stack, Inc. | Status page · uptime monitoring | Probes the site, the badge endpoint, the verification endpoint, and checkout; publishes the incident history. | No visitor data from this site — probe traffic only. Visitors to the status page itself are subject to Better Stack’s notice. | Provider-hosted status page (linked from the footer). |
| Sentry (Functional Software, Inc.) | Error telemetry for the edge Worker | Reports exceptions thrown by our own edge code so a failing route is noticed before a reader reports it. | Technical error events: stack trace, trace id, edge version. No request bodies, no personal data by configuration (IP addresses are not stored). | Sentry’s EU data region. |
Data residency statement
The Association's own stores — the signing-key vault and, from P-M3, the account and entitlement database — are in Switzerland North. The exceptions, stated rather than glossed over:
- The public read plane is a global edge. Published artifacts — the registry, the ledger, certificate records, the key set, the transparency log — are public by design (class P0) and are cached at edge locations worldwide. Nothing personal is in them beyond what an organisation consented to publish or a contributor elected to display.
- Edge request logs (IP address, path, user agent) are processed by the content-delivery provider at the edge location that served the request and retained briefly under its terms. The Association does not export or retain them.
- Email transits US providers: routing at the edge and delivery through the transactional-email provider. A form submission is one email; nothing is stored on the way.
- Payments are processed by the merchant of record outside Switzerland, under its own notice. Card data never reaches the Association.
- Error telemetry is held in the error tracker's EU region and contains no request bodies or personal data.
Transfers to the United States rest on standard contractual clauses and, where a provider is certified, the Swiss–US Data Privacy Framework. Switzerland is recognised as adequate by the European Union, so a transfer from the EU to the Association needs no further safeguard.
How to check us
- The licence text. Fetch
/license/{versionId}.txt, hash it, compare with the hash on the version page and in the licence repository's tag. - A certificate. Verify the signature yourself in your browser at /verify, or entirely offline with the offline procedure — the page fetches the key set and checks the signature locally rather than asking us whether the certificate is good.
- A coverage claim. Fetch the organisation's signed entitlement record and verify it against the published key set. At this phase that record is the proof; the computed endpoint comes later.
- The statutes. Read them at /constitution and, once the register entry is public, compare them with the filed German original.
- The ledger, once it exists. Keep a copy of any monthly export. The hash chain makes a later rewrite detectable by anyone who did.