The Steward Guide

Stewards hold editorial authority over the catalog on behalf of the community. A Steward's Confirm carries a vote weight of 5.0 — enough to verify a record alone — which is precisely why the role demands restraint. Stewards verify what they can check against a reference, and abstain from what they cannot.

A Steward's power is the community's trust on loan. Every use of it is logged, attributed, and permanent.

Confirm a record only when you can verify its identifying facts — country, year, denomination, and the distinguishing details — against a reference you trust. Dispute with a written explanation when you find a factual error; the explanation is for the contributor, so write it the way you would want to receive it. Abstain freely: an honest abstention is worth more than a careless confirmation.

Newcomers' first submissions set the tone of their whole relationship with the commons. Prefer a correcting edit or a kind dispute over a silent rejection.

Deprecation is the only Steward-exclusive lifecycle action. It marks a record as superseded — it never deletes. Before deprecating: the successor record must already exist, the reason must be recorded, and the deprecated OSID must resolve to its canonical successor for decades. If you cannot name the successor, the record is not ready to deprecate.

Country codes, currency codes, revenue subclasses, and TYPE codes live in registry tables that Stewards maintain through the admin interface. Registry changes affect every future OSID in their bucket, so they are append-mostly: codes are added, annotated, or closed to new use — never reused for a different meaning.

Every privileged action — verification overrides, deprecations, registry changes, trust adjustments — is written to a permanent, append-only audit log. The log is part of the catalog's provenance, held to the same standard as the records themselves.