Curation policy

This is the policy page of assumptions-registry, an IFP-22 Assumptions Registry published under the Collective Sense Commons banner and operated by Peter Kaminski. IFP-22 leaves curation to the operator and asks only that the posture be published. This is ours.

What this registry shelves

This registry is deliberately ecumenical: a broad shelf of widely-held codes of conduct, professional ethics, political and social philosophies, religious rules of life, jurisdiction facts, and shared vocabularies — across traditions, in a range of scopes, chosen to be citable by many kinds of principals. We shelve texts that significant communities actually operate under, not texts we are campaigning for.

Other registries may be as opinionated as their operators wish — a registry curated to one community's convictions is exactly as conformant as this one. Anyone can host a registry; a community that wants a different shelf should stand one up, and citations will always name the registry they resolve through.

Hosting is not endorsement

Shelving a text here means we judged it citable, not that we agree with it — the SPDX License List holds licenses its maintainers would never choose. Likewise, per IFP-21, a principal citing an entry at acknowledges is saying "we know this text," not "we agree with it." Both of these will otherwise be assumed wrongly, so we state them here plainly.

The write path

Withdrawal

Write-once protects the verifiability of outstanding citations, not our obligation to keep serving every text we've ever shelved (IFP-22 §4.1). We handle content that shouldn't have been merged by grade:

A tombstone is itself write-once — reinstating a text, including one tombstoned in error, is publishing a new version, never un-withdrawing the old one.

The mechanism, concretely. CI's write-once check (scripts/check-immutability.sh) gets exactly one carve-out, and it is deliberately hard to trigger by accident: a PR may replace a published entry file only if (1) the path is listed in the git-tracked tombstone-allowlist.txt — an explicit, reviewable edit the operator makes in the same PR, separate from the content change — and (2) scripts/check-tombstone.py confirms the replacement is a well-formed tombstone whose withdrawn_cid matches the withdrawn text's actual pre-image bytes and whose identity fields are unchanged. Failing either leaves the ordinary write-once rejection in place. Deletions and renames under entries/ are never permitted, allowlisted or not.

Two limits, stated honestly. Withdrawal removes our copy and our imprimatur — not the text from the world: mirrors, clones, and pins made before withdrawal are beyond our reach, as they are for all publishing. And CI cannot smell odium — prevention is this page, the review standard we hold ourselves to; the tombstone is the remedy when that standard failed, not a substitute for it.

Static hosting and the 410. IFP-22 §4.1 says a policy-withdrawn entry's URL should answer 410 Gone. This registry deploys as a static site, so the guaranteed part is the tombstone content itself, served at the withdrawn text's normal URL in place of what used to be there — that works on any static host. The 410 status code is best-effort: make build emits a dist/_redirects line per withdrawn entry, but Cloudflare Pages does not document guaranteed support for a bare non-3xx/404 status there, so it may not take effect after deploy. If it doesn't, the tombstone content is still served (with a 200), which is the artifact that actually carries the identity, CID, reason, and pointer a receiver needs — see README.md if a guaranteed 410 ever matters enough to warrant a small Cloudflare Pages Function instead.

Entry standards

Version ordering

Each entry's versions are totally ordered. This registry uses, per entry, whichever scheme the instrument itself suggests: upstream version strings where the instrument has them (2.1), the instrument's year where that is how the world names it (2018), and plain integers (1, 2, …) where the entry is ours or effectively unversioned. Within one entry, all versions use one scheme, and supersedes links each version to its predecessor.

Categories and kinds

Categories: the starter set of IFP-22, Section 3, plus one extension this registry has made under §3's "extensible by registry policy": governance, for charters, constitutions, and enforcement procedures — instruments about how authority is structured and what happens when commitments are violated, which are neither conduct norms nor ethics codes. Further extension is a policy change made by PR to this page.

Kinds: entries additionally carry an optional kind field naming the document's form — creed, principles, oath, code-of-ethics, code-of-conduct, charter, enforcement-policy, teaching — with tokens defined in the document-kinds vocabulary entry. Kind is orthogonal to category (an oath may be professional or religious) and is a registry extension offered as feedback toward IFP-22.

License classes

Every entry's license field draws from a small allowlist (enforced by the validator): SPDX identifiers for free licenses (CC-BY-4.0, CC-BY-SA-3.0, CC-BY-SA-4.0, CC0-1.0, MIT), the public-domain token for texts with no surviving copyright, and the verbatim-only token for instruments whose steward permits full-document verbatim reproduction but not modification — RFCs under the IETF Trust Legal Provisions, the Agile Manifesto under its own notice. Verbatim-only is not libre, but it satisfies exactly what the CID story requires: lawful mirroring and pinning of exact bytes. Evidence per instrument lives in the licensing worksheet.

De novo entries

Most entries shelve instruments that live elsewhere. A de novo entry is first published in this registry — the registry as a text's original home, not a mirror of it. No entry currently on the shelf uses this route; the rules below govern the first one that does. De novo entries follow every rule above — write-once, licensed (free license required; CC0 preferred), CID-pinned — and their notes field says plainly that the registry is the original place of publication.

Contact and disputes

Open an issue or pull request on the repository. Disputes about a restatement's fidelity get priority; disputes about whether a text belongs on an ecumenical shelf are decided by the operator.

And the remedy for that second kind of disagreement is another registry — by design. This is one shelf built to IFP-22, not the shelf; being first does not make it authoritative. If you think we have shelved the wrong things, missed the ones that matter, or drawn the line where your field would not, fork the repository and run your own: the tooling is MIT, there is no server or database, and a static host and a domain are the whole of the infrastructure. Entries in your registry are cited exactly like entries in ours — an IFP-21 declaration names a URL and a content identifier, and nothing in the protocol points structurally at us. Many honest registries is the intended outcome; one registry everybody has to accept is the failure mode. If you stand one up, tell us and we will link to it.