Algorithms and schedule versions

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.

Impact Share algorithm

Version	Status	What it does
PP-v0	Provisional — the founding-cohort algorithm	Attributes Purpose Points per project from the public contribution record (merged pull requests and commits on the canonical repository, weighted by a published, deliberately coarse scheme). Displays points and percentile bands always; displays a currency figure only above the materiality floor. Category votes 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). Activates only after PP-v0 has run for at least one reviewed quarter and the fairness review is published

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 and percentile only. No leaderboards, no cross-contributor money ranking, ever.
• Shadow before active. Contributor category votes 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.

The PP-v0 specification and its worked examples publish in the specification repository alongside the coverage function.

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-v1.
• 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. 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 as cov-v2 alongside 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 — illustrative	On the first Entitlement sale	Bands by consolidated-group revenue; lanes Project (purchasable), the Pass and Portfolio (launch-ordered), Donation Entitlement (compliance lane); multipliers 2× / 5× / 10×. Every figure is labelled illustrative until the first transaction settles — see the schedule

Every schedule version stays published at a permanent URL with its effective-date range and an unambiguous marker for the current one. 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. 9).