Organisation and operations
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 Aarau, Switzerland · commercial-register entry pending publication
- Founded
- October 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 code it registers for others, and never a recipient of routed funds — see what we can never do.
- Other activities
- The Association also develops and sells Rendlio Sheets, a software product, as another activity, booked separately. Purpose Fee money never funds it, and its money never enters the Purpose Fee account. Any project the Association owns that is registered here is marked Association-owned and receives no treatment unavailable to any other project.
- 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, and the published text is in the public licence repository. Versions
The statutes
Adopted at founding, published in full with the protected provisions marked. Statutes v1
The money rules
The fee stack with its caps, the direct-cost classes — people among them — who pays the running costs, the Recipient List and the Recipient Standard, the lock-before-sweep rule, the operations reserve, the append-only ledger methodology — published before the first franc. Where the money goes
The exit
A stop only by two thirds of all members, for a serious published reason and with at least three months' notice, and a wind-down protocol that preserves what the licence gives payers and adopters by construction. If the activity stops
The keys
Non-exportable signing keys, how the current one was created, an append-only transparency log, and one fixed verification address. Keys and log
What a certificate may claim
The two classes issuable at this phase, the permitted and prohibited wording for each, and the classes that do not exist yet with what has to happen first — published before the first certificate is issued. Certificate policy
The site itself
No cookies, no analytics, no consent banner, no database on any anonymous path, two third-party scripts. Security
Documents
Where the money goes
The pledge, the fee stack with its caps, the direct-cost classes, who pays the running costs, the Recipient List and the Recipient Standard, the lock-before-sweep rule, the operations reserve, and the ledger methodology.
updated 2026-10-06
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-26
Certificate policy: coverage and status
What each certificate records, how to verify it, and the permission to use official logos and badges.
updated 2026-10-02
What we can never do
The standing prohibitions, each cross-linked to the article of the statutes, the section of the licence, or the published rule that binds it.
updated 2026-10-05
If the activity stops
When the Purpose Source activity can stop — only by a vote of two thirds of all members, for a serious reason published with the decision, announced at least three months ahead — and what happens then to payers, adopters, the money, the registry, the domain and the marks.
updated 2026-10-05
Statutes, register, tax letter, review, 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-10-05
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-10-06
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-10-06
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-10-02
Statutes v1
The constitution: purpose, organs, the direct-cost cap and the cost-support rules, and every protected provision. 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.
Legal documents
Imprint · privacy notice · terms of use · entitlement terms · refund policy — each address shows the current version, and each version keeps its own permanent address.
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. Two third-party scripts exist — the bot-protection widget on the contact forms and Paddle.js on the pricing page, loaded only at payment — and the Content-Security-Policy names their hosts as the only permitted external script sources.
- 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 Azure Key Vault in Switzerland: the private key never leaves Key Vault in readable form, and the vault signs a digest our services send it; until our signing service takes over, the operator's own account holds a 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, and every one lined up to — named before it starts rather than after, with what starts it. What each does, what it sees, and where. This list is the "recipients" section of the privacy notice: until that notice is first published at its permanent URL, a change here amends it in place and carries a dated counsel marker; from that first publication, a change here publishes as a new version of it at a new URL.
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 | Key vault (Standard tier, software-protected keys) | 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 Key Vault in readable form; an encrypted backup restores only into Key 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; Paddle.com Inc. (buyers in the United States); Paddle.com (Canada) Ltd. (buyers in Canada) | 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. Postmark operates no EU region and relies on the standard contractual clauses for transfers — its own EU data-protection page, checked 2026-09-08. |
| The steward mailbox — Google LLC (Google Workspace) | The mailbox behind every published address | Receives what the forms forward and what is sent to the published addresses, and is where a person on the Association’s side reads and answers it. | The text of what you send: your reply address, a subject, a message. This is the longest-lived store of the free text people send us — 24 months, and a data request plus a year; see the retention table in the privacy notice. | Google’s global data centres; the region is not pinned — no data-region policy for the tenancy is on our record, and the setting that would pin it has not been read. Transfers rest on Google’s data processing addendum with the standard contractual clauses and the EU–US Data Privacy Framework. The published addresses forward today to the steward’s own mailbox on that host. A Swiss-hosted mailbox on the Association’s own tenancy is decided and pending before launch, and this row is updated on the day it exists — see the residency statement below. |
| Better Stack, Inc. | Uptime monitoring · status page (not set up yet) | Probes the site from outside its own failure domain. One monitor runs today, on the preview host; the probes of the edge API, the badge and verification endpoints and checkout, and the published incident history, arrive with the status page when it is set up. | No visitor data from this site — probe traffic only. | Provider-hosted; the region is not yet published — the public status page is not set up yet. No personal data of this site’s visitors reaches it. |
| Sentry (Functional Software, Inc.) | Error telemetry for the edge Worker — wired, not yet receiving | Will report exceptions thrown by our own edge code so a failing route is noticed before a reader reports it. The reporting is written and specified; no project exists yet, so the Worker holds no endpoint and nothing has been sent. | Once switched on, technical error events only: stack trace, the operation that failed, its trace id, the edge version and environment, and non-personal detail such as an artifact path or an upstream status. The path is configured not to read request bodies; a scrubbing pass drops bodies, cookies and credential headers, cuts addresses to their network (/24, /48) and redacts email-shaped strings before an event leaves the edge. | Sentry’s EU data region, once the Association’s own project is created. |
Data residency statement
The rule: the Association's own stores go to Switzerland North — the signing-key vault today, and the account and entitlement database when there is one. An EU region is the documented fallback where a service is offered in no Swiss region. A global edge is accepted for public artifacts and bot-protection challenge tokens — and unavoidably for the request metadata any edge writes to its own short-retention logs, and the inbound mail it routes in transit, neither of which the Association exports or retains. It is never accepted for a store of personal data the Association keeps.
Everything else is an exception, and every exception is listed here with what it touches and why. Two rows are still pending, in two different ways: one says “not yet published” — its region is not on our record at all — and one says its region is not pinned: its host is named, but the setting that would pin the region has not been read. Each names the act that settles it. They are listed pending rather than left out — a residency statement that quietly omitted them would be worse than one that admits the gap.
Data residency at v0 — every service, where it runs, what it touches there, and why it is not Switzerland North
| Service | Where it runs | What it touches here | Why not Switzerland North |
|---|---|---|---|
| Hosting, the edge API, the key-value cache, the bot-protection challenge, inbound mail routing | Global anycast edge — any edge location. No regional-services restriction is configured. | Published artifacts, which are public by design (class P0) and hold nothing personal beyond what an organisation consented to publish or a contributor elected to display; request metadata (IP address, path, user agent) in short-retention edge logs, which the Association neither exports nor retains; the challenge token; inbound mail in transit. | A delivery edge is global by construction — that is the property being bought, and what it caches is public. Authenticated and personal responses are marked private and no-store and are never edge-cached. |
| Key custody (the signing keys) | Switzerland North (Zürich). | No visitor data. Key material, which never leaves Key Vault in readable form. | Not an exception — this is the rule the rest of this table is a list of exceptions to. The keys are born in the vault and are non-exportable. |
| Transactional email (one message per form submission; receipts and certificate notices) | United States. | Message content, reply address, delivery metadata — in transit. Nothing is stored on this site’s side. | The service is offered in no Swiss or EU region. A form submission is one email and nothing is stored on the way, so what crosses the border is a message already addressed to us. |
| The steward mailbox behind every published address | Google LLC (Google Workspace). The region is not pinned — no data-region policy for the tenancy is on our record, and the setting that would pin it has not been read. Until it is, what we can state is Google’s global data centres under its data processing addendum, with transfers on the standard contractual clauses and the EU–US Data Privacy Framework. | The text of what you send us, for 24 months — data-request correspondence for the request plus one year. | Not a choice: the published addresses forward today to the steward’s own mailbox, which predates the Association’s own infrastructure. This is the longest-lived store of the free text people send us, which is why it was listed here while its host was still unnamed. What settles it is a mailbox on the Association’s own tenancy, hosted in Switzerland — decided, an operator act, and pending before launch; this row is updated on the day it exists. |
| Entitlement checkout (the merchant of record) | United Kingdom / European Union / United States, per its own infrastructure. | Payer billing identity and payment data, held by it as an independent controller under its own notice. | It is the seller to you rather than a processor of ours, so its regions are not ours to choose — and it is the reason card and bank details never reach the Association at all. |
| Uptime monitoring and the status page | Provider-hosted; the region is not yet published. | No visitor data — probe traffic only. | A status page inside the failure domain it reports on is worthless, so it sits outside our own infrastructure. Its region is recorded here when the public status page is set up. |
| Error telemetry for the edge API | An EU region, chosen when the account is created. Nothing is sent today — no such account exists and the edge API runs without one. | Technical error events: stack trace, trace id, edge version. No request bodies; addresses are truncated to their network and email-shaped strings redacted before anything is sent. | Switzerland is not offered as a data region for this service; the EU is, and an EU region is the documented fallback. |
| Source hosting and the transparency-log mirror | United States (global service). | Public repository content. From the claim flow: a contributor’s platform login and opaque account identifier, minimal scope, no email address. | The public artifacts are hosted where the contributors already are. Moving them would not make them less public — only harder to find and to verify. |
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.