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 will be filed; publication follows. 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 enters the Purpose Fee account only to make up a shortfall for the listed recipients, and never flows back. 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-09

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-26

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-08

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-09

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-23

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-24

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

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 60 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: normally the first bank working day after the first calendar month with a Purpose Fee payout ends, and at the latest thirty days after it (Financial Regulation § 4 para. 5) — 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 (a private person who is neither a member nor a board member and declares no tie to any buyer, recipient or registered project may ask to stay unnamed), 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.

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 first bank working day of the month after the payout carrying that purchase is credited, within sixty days of its credit.

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

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, loaded only to open Paddle’s checkout, on the pricing page at payment and on the page Paddle’s payment links open — 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's first public use, a change here updates it in place; after that, it publishes as a new version 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, the account dashboard and the public read APIs; passes signed-in requests through to the account service; 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; signed-in requests to the account service and their answers, in transit and never cached. 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	Container Apps (the account service and its scheduled jobs) · Azure Database for PostgreSQL · Storage (files, queues and the published registry files) · Functions · Container Registry · Key Vault (Standard tier, software-protected keys) · Log Analytics	Runs the account service behind api.purposesource.org and the dashboard — sign-in, accounts, repository claims and purchase records — and the jobs that build the registry and clean up stored data; holds the ES256 signing keys, which are born in the vault and non-exportable (signing is an operation the vault performs), and the key that protects stored GitHub tokens (it encrypts each token’s own key).	Account records; sessions (a shortened IP address and the browser family); GitHub logins, account IDs and profile-picture links; the encrypted GitHub tokens; the e-mail addresses accounts hold; purchase and entitlement records; the public registry files; operational logs, kept 90 days. Key material never leaves Key Vault in readable form (an encrypted backup restores only into Key Vault), and the vault keeps its own audit log.	Switzerland North (Zürich).
GitHub, Inc.	Source hosting · transparency-log mirror · sign-in with GitHub · the public GitHub data the registry is built from	Hosts the public repositories this movement is built in, including the committed transparency log; signs people in to the account service and answers the checks that a person administers a repository they claim; its public search and repository data are where the registry finds the repositories that carry the licence.	Public repository content. At sign-in, GitHub hands us the person’s public profile, of which we keep only the public login, account ID and profile-picture link (never an e-mail address), and an access token with no scope, which we keep encrypted and use only for the reads the privacy notice lists (§3); GitHub sees those requests, and the request to revoke our access when an account is deleted. A pull request that adds the licence uses a separate, wider grant, which we never store and delete when the work ends.	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; sign-in codes and links, and notices about changes to an account’s e-mail addresses, to the account holder; and purchase receipts and certificate notices to their recipients.	Message content, the recipient or reply address, delivery metadata. Nothing is stored on this site’s side, and the account service keeps no copy of the messages it sends; 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: the platform (api, hooks, jobs) reports today; the edge Worker is wired but not yet receiving	Reports exceptions in our own code, so that a failure is noticed before a reader reports it. The platform’s api, hooks and jobs are connected to the Association’s own Sentry organisation in Sentry’s EU region and can send it an error event. The edge Worker’s reporting is written and specified, but it holds no endpoint yet, so it has sent nothing.	Technical error events: the exception and its stack trace; its message, which can name one of our own opaque identifiers (of an account, an organisation or a repository); which part of the platform raised it (the api, a hook or a named job); the version and the environment; and the runtime’s technical context (operating system, .NET version). Never a request body or a cookie. Before an event leaves our systems, addresses are cut to their network (/24, /48), email-shaped strings are redacted and credential headers are dropped. Once the edge reports, its events add the operation that failed, its trace id, non-personal detail such as an artifact path or an upstream status, and the request’s URL cut to its shape: no query, and no login, page id or other segment that names a person.	Sentry’s EU data region (the Association’s own organisation).

Data residency statement

The rule: the Association's own stores go to Switzerland North — the key vault, and the account service with its database, storage and logs. 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, a contributor elected to display, or GitHub already shows about a listed repository and its owner; 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; signed-in requests to the account service and their answers, 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.
The account service (the API behind the dashboard and its jobs, with their database, storage, queues and logs)	Switzerland North (Zürich).	Account records, sessions, GitHub logins and account IDs, the encrypted GitHub tokens, the e-mail addresses accounts hold, purchase records, and the registry before it is published.	Not an exception — the rule. The key that protects the stored GitHub tokens (it encrypts each token’s own key) is held in the same vault as the signing keys.
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	Sentry’s EU data region. The platform’s api, hooks and jobs are connected to it in production and can send it an error event; the edge API does not report yet.	Technical error events: the exception, its message (which can name one of our own opaque identifiers, of an account, an organisation or a repository) and its stack trace, the part of the platform that raised it, the version and the environment; from the edge, once it reports, also a trace id and the request’s URL cut to its shape. 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, the transparency-log mirror and sign-in with GitHub	United States (global service).	Public repository content. At sign-in: the person’s public login, account ID and profile-picture link, and the requests we make with the access token GitHub issues, which carries no scope; we keep no e-mail address from GitHub.	The public artifacts are hosted where the contributors already are, and signing in with GitHub is how a person shows that they administer a repository there. Moving the artifacts 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.