Trust Center / Algorithms and schedule versions

Algorithms and schedule versions

updated 2026-10-06

Every figure this movement ever displays that is computed — an Impact Share, a coverage answer, a price — carries the version of the algorithm or schedule that produced it, and every version is published before it is used. A version is never mutated; a change is a new version alongside the old one.

Version	Status	What it does
PP-v0	Provisional — the founding-cohort algorithm	Attributes Purpose Points per project from GitHub’s contributor statistics for the canonical repository: half from each contributor’s share of the lines added and deleted (churn), half from their share of the commits, over the trailing 12 months. Deliberately coarse, with its weaknesses disclosed below rather than mitigated. Shows a contributor’s points to that contributor alone, and everyone it credits as `credited`, with no rank and no band; displays a currency figure only above the materiality floor. Contributors’ category choices run in shadow mode: recorded and displayed, routing no money
PP-v1	Planned	Clone-based attribution over the actual code, with the full anti-gaming guard set (commit splitting, vendored code, generated files, bot identities). Replaces PP-v0 from PP-v1’s first complete month, under the sunset commitment below

Rules that hold for every version:

Directing, never receiving. Impact Shares direct where a project’s routed funds go; no contributor receives anything of monetary value.
Materiality gate. Per-contributor currency figures display only above a published floor; below it, points only. No leaderboards, no cross-contributor money ranking, ever.
Shadow before active. Contributor choices (among the seven categories, or left to the Association) route real money only after one reviewed quarter of shadow data and a fairness-qualified allocation algorithm — the canonical routing modes are project_default, shadow, and contributor_active.
Nothing displays before it exists. No attributed figure is displayed at v0: the claim flow that lets a contributor appear is a later phase.

How PP-v0 computes shares and points

No production PP-v0 snapshot exists yet. The rule is published here before its first use, as every version is.

A PP-v0 snapshot covers one repository and one month. It is computed from GitHub’s contributor statistics for that repository (GET /repos/{owner}/{repo}/stats/contributors), which list, for each contributor, the lines added, the lines deleted and the commits of every week.

The window. For month M, the weeks whose start (in UTC) falls in the 12 calendar months ending with M. The window is set by the month, never by the day the snapshot is taken.
Bots, and people who objected, are removed first. An account GitHub marks as a Bot, or whose login ends in [bot], is left out before any arithmetic. People who have used their right to object to attribution are left out of the month’s computation in the same way, so the others’ shares are computed without them. If everyone in a repository has objected, the snapshot credits no one, and that month’s money for the repository routes by its administrators’ designation, and failing that by the board’s published allocation key.
The share. For each remaining contributor, churn is the lines added plus the lines deleted in the window, and commits is the number of commits in the window. The share is half the contributor’s share of all churn plus half their share of all commits: 0.5 × churn ÷ total churn + 0.5 × commits ÷ total commits.
When a half is empty. If nobody has any churn in the window, the commit half carries the whole weight, and if nobody has any commits, the churn half does. If the window holds neither, the repository’s whole history replaces it; if that holds nothing either, the snapshot is empty and credits no one.
Rounding. Shares are whole millionths of the repository and add up to exactly 1,000,000. Each share is rounded down, and the millionths left over go one at a time to the largest fractional remainders, ties broken by ascending GitHub node id.
Points. A contributor’s Purpose Points are their share in parts per 10,000 of the repository, that is, their millionths divided by 100 and rounded down. A share of 123,456 millionths is 1,234 points. Because each contributor’s points are rounded down, a snapshot’s points can add up to less than 10,000.

Points are an estimate produced by this method, not a measure of what anyone’s work is worth: a different method would give different figures. A contributor’s points are shown to that contributor alone, on their own page in the signed-in application. Everyone a snapshot credits is shown the same way on every surface, as credited: PP-v0 ranks no one and computes no band.

The PP-v0 specification and its worked examples are not in the specification repository yet; until they are, this page is the published statement of the rule.

Weaknesses: disclosed, not mitigated

PP-v0 has no caps, no path weights and no churn dampening. Its weaknesses are disclosed here instead of mitigated, which is acceptable only under the provisional label:

Churn can be gamed. Every line added or deleted counts in full, so a contributor can raise their churn share by adding and removing lines. Nothing in PP-v0 dampens it.
Only the top 100 are seen. GitHub’s statistics name at most 100 of a repository’s contributors: the top 100 by commits over its whole history. When the list holds exactly 100 entries, the snapshot is marked truncated and shares are computed over the listed contributors only; the rest are not estimated. Contributors outside the top 100 hold no PP-v0 share, and appear in the repository’s unclaimed share only once PP-v1 replaces PP-v0. Any surface that renders a truncated snapshot carries the provisional label and this fixed sentence, word for word:

this provisional snapshot covers the repository's top 100 contributors only.
No path weighting. PP-v0 gives every file the same weight: documentation, lockfiles and vendored or generated files count as code does.
Contributors GitHub cannot match to an account are absent. Commits whose author email GitHub cannot resolve to an account (an anonymous commit email) are missing from its statistics, so PP-v0 has no unmapped bucket: that work is neither credited nor counted. PP-v1, which reads the repository itself, will count it in an unmapped bucket within the repository’s unclaimed share.
GitHub’s statistics have limits of their own. For a repository with 10,000 or more commits, GitHub reports zero lines added and deleted for everyone, so there the churn half is empty and PP-v0 weighs commits alone (step 4 above). Merge commits and empty commits never count. The statistics describe the default branch only, so commits that exist only on other branches are not counted.
A late snapshot sees later pushes. A snapshot records the moment it was taken. Its window is set by the month, but GitHub’s statistics are read as they stand at that moment, not as they stood when the month ended: a snapshot taken after its month has ended also counts, for example, commits pushed after the month ended whose author dates fall inside the window.
No answer in time means no snapshot. GitHub computes these statistics on request and answers that they are not ready until it has. The run that locks a month asks again after growing pauses, within a fixed time budget, and there is no later attempt. If the statistics are still not ready by then, or GitHub gives no usable answer, the repository gets no snapshot for that month. Nobody is credited for the repository that month, and the money attributed to it routes as it would if no contributor had made a designation: by its administrators’ designation, and failing that by the board’s published allocation key. A month with no snapshot means that no measurement was available, not that nobody contributed.

The sunset commitment

PP-v0 carries a published sunset commitment:

PP-v1 ships within one quarter of P-M4 entry; the provisional label persists on every PP-v0 surface until PP-v1 replaces it.

P-M4 is the platform milestone that follows P-M3.

The coverage function

“Is this organisation covered for this repository?” is answered by a pure, versioned function over published artifacts only — the organisation’s signed entitlement record, the repository record, and the public waiver list. It reads no database, holds no state, and takes the current time as a parameter, so its answers are reproducible by anyone with the same inputs.

Version in force: cov-v2. It is cov-v1 with three changes: an organisation holding a Pass inside its term is answered yes-via-pass about a repository with no published record, with the reason pass-any-work; a registered repository is answered the same whether or not its admins claimed it; and an answer reports registered for a record that says registered or the older verified. cov-v1 stays published beside it, unchanged, so every answer it gave can still be reproduced.
Answer set, closed at eight values: yes-via-pass, yes-via-project, yes-via-portfolio, yes-via-waiver, yes-via-donation, no, lapsed-in-grace, no-entitlement-required-under-threshold. yes-via-donation is retired and never returned: the direct-donation route it answered for was dropped before it opened (D91). It stays in the set because the set is frozen. Semantics and precedence are on the coverage page.
Source: the module and its frozen test vectors are mirrored verbatim to https://github.com/purposesource/spec (spec/coverage/), and continuous integration fails if the deployed bundle’s module hash differs from the mirrored file. /v1/meta reports the deployed hash.
A new version ships alongside the ones before it (cov-v3 beside cov-v2 and cov-v1); a published version is never edited.

At v0 there is no live coverage endpoint. The proof of coverage is the published, signed entitlement record plus the verification page. The function is published now so that a client built against the eight answers needs no change when the endpoint activates.

Schedule versions

Version	Status	Effective from	Notes
Schedule v1	Current — the launch price list	2026-10-02	Eight bands by consolidated-group revenue; a Project (one Standard or Utility repository) or the Pass, both offered in one checkout; annual prices in US dollars before tax, by card up to USD 10,000 a purchase and by Paddle invoice above that. The pre-launch illustrative tables (Portfolio, a Donation Entitlement, multipliers) were withdrawn before any sale; until launch v1 is edited in place (D102) — see v1

From launch, every schedule version stays published at a permanent URL with its effective-date range and an unambiguous marker for the current one; until launch, version 1 is edited in place. Prices are set by the Association alone, in one published schedule; repository administrators never set prices, and bespoke pricing requests are answered by pointing at the governance process — propose a schedule change for everyone — never by a private deal (Statutes Art. 11).