Skip to content
Menu

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".

Pending publication

The commercial-register extract — not yet published. Expected: on entry in the Aargau commercial register. The register number prints as “CHE-… — pending publication” until then; the imprint and the footer are updated on the day the register confirms it.

Open

The pass-through tax letter — not yet published. Expected: the Aargau tax administration's confirmation, asked on the list model, that Purpose Fees passed on within 30 days to the recipients on the published Recipient List, in the published shares, are booked as pass-through (Durchlaufposten), not as income given away, the retained shares being ordinary income. The office may refuse; then Purpose Fees are ordinary income, the tax publishes as its own line, and no page claims pass-through before the answer. No public-benefit tax-exemption application is pursued at founding; no page describes the Association as tax-exempt, and the answer publishes here whatever it says.

Pending publication

The first cost-support table — not yet published. Expected: the end of the first calendar month with a Purpose Fee payout — fees net of the rail's fee, every running-cost invoice, any personnel cost as one line per function, every supporter by name and amount, what was charged to fees against the cap, each transfer to a listed recipient with its receipt, and the reserve retention with the reserve's balance; then monthly, aggregated in the annual transparency report.

Who pays the movement's running costs — the fixed text and today's list.

Pending publication

The report on the yearly check of the fee account — not yet published. Expected: the first financial year in which routed volume exceeds the published threshold, or earlier if the board engages it: a licensed auditor independent of the board checks the fee account, the reserve account and the pass-on under agreed-upon procedures, every year; published in full when it exists. No statutory audit applies at this scale, and none is claimed — the proof of the money rules is publication to the invoice.

Requested

The SPDX licence listing — not yet published. Expected: SPDX's decision on the request for PurposeSource-1.0 filed on 2026-10-01. Until it is listed, files use LicenseRef-PurposeSource-1.0, and scanners may flag an “unknown licence”; the OSPO pack says how to handle them.

OSPO and legal pack — scanners and SPDX

Pending publication

The key ceremony record — not yet published. Expected: on completion of the two-person ceremony — key id, date, roles present, vault object version and public JWK — which is a precondition of the first certificate. psn-prod-2026-1 itself was created by the operator alone on 2026-09-02, not in a ceremony, and the record will say so. The key set is published and lists psn-prod-2026-1 as active: publishing a public JWK is a key-set act and not the ceremony record, so its presence is not evidence a ceremony was held.

Keys and the transparency log

Pending publication

The first ledger row — not yet published. Expected: with the first settled Entitlement purchase; its allocation rows at the lock, before any transfer; the first transfers — one per listed recipient, direct — normally initiated on the 25th of the month in which the payout carrying that purchase is credited, within thirty days of its credit.

The methodology that will govern every row is published already, so it can be criticised before it matters.

Pending publication

Waivers — not yet published. Expected: with the claim flow, when repository administrators can prove administrative control and grant a waiver from their dashboard.

The waiver registry exists and correctly shows an empty list; the rules are in the waivers guide.

Pending publication

The public status page and its incident history — not yet published. Expected: when the monitoring account publishes a status page and a hostname resolves to it. One monitor is live today — this site's deployed host; the monitors for the API host and for checkout have not been created, so there is no probe of them to publish and no incident history to read. Until it exists, this entry is the whole of what the Association can say about its uptime.

The footer's status entry and /status both point here rather than at a hostname that resolves to nothing; they move to the status page in the same change that publishes it. What the site itself is built from is on the security page.

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.

Drafted, adoption pending

The data-protection impact assessment (DPIA v0) — not yet published. Expected: adoption by the operator before launch. It covers the processing this site does today — the forms, the checkout, the recording of a purchase, sanctions screening, the data-request route, monitoring — and states plainly that the attribution of contributions is outside its scope and needs its own assessment before any code reads a repository's history. The assessment is an internal record; what publishes here is the fact of its adoption, and the residency table above, which is drafted with it.

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.