Attribution reserved
No token. Nothing to trade. This is a
database.
An entry on the record can be in one of two attribution states. This page is
what each one means, so that a permalink to either answers the question "whose
is this?" without anyone having to explain it.
Reserved
When a contribution is accepted, the entry is written immediately — in the
week the work happened, valued by the published rule, with the merge commit as
its evidence. If the contributor does not hold a key yet, the entry names
nobody. It is not anonymous and it is not unassigned: it carries a binding
fixed at that moment to the account that authored the merged pull request, and
only a signature that matches that binding can attach a name to it.
Worked example. Not a record entry: the values below are
illustrative and no ledger exists at this address.
Entry — accepted contribution
- Attribution
- Reserved — provably bound to the author of the merged pull
request this entry cites; awaiting their signature.
- Valuation
- computed by the published rule at acceptance, from the tier floor · shown
with its derivation
- Evidence
- the merge commit, by hash
- Binding
sha256(github:<the author's account>) — the
hash only; the account name itself is not on the record- Position
- fixed: this entry's place in the chain does not move when it is claimed
If this is your work: how to claim it
— three commands, and no deadline.
Three things are deliberately true of this state:
- It is designed, not a gap. "Attribution reserved" is a
state the record has; it is never rendered as "anonymous", "unknown" or an
empty cell.
- It is already correct. The valuation, the week and the
evidence are all recorded at acceptance. Claiming later changes none of them —
which is the whole reason the entry is written before the key exists.
- It waits. There is no timer anywhere on this page,
because there is no timer anywhere in the mechanism.
Claimed
A claim is a new entry appended after the reserved one. Nothing is
rewritten: the original entry still says what it always said, and the record
now also contains a signed statement, made by the key, that this entry is
theirs.
Worked example. Not a record entry: the values below are
illustrative and no ledger exists at this address.
Entry — accepted contribution
- Attribution
z6Mk… — claimed, with the signed attestation that
matched the binding- Valuation
- unchanged from acceptance
- Evidence
- the merge commit, by hash
- Position
- unchanged
Reading it back is mechanical: replay the record from the beginning, and an
entry's attribution is whatever the first valid claim against its binding says
it is, or reserved if there is none. Two people cannot both claim it — the
second claim is refused by the same rule that let the first one through — and
the order is settled by position in the chain, not by anyone's judgement.
Why the record works this way
The alternative would be to wait: write no entry until the contributor holds
a key. That sounds tidier and is worse. It would date the work to whenever the
contributor got around to running ssh-keygen, so two identical
contributions could be valued differently for no reason a reader could ever
audit — and it would make a merged, accepted contribution sit unrecorded while
somebody reads a page about key pairs. Writing the entry at acceptance and
attaching the name afterwards keeps the facts in the week they happened and
makes the invitation literally true: it is already yours, and it is waiting.
The rule that admits a claim, refuses a second one, and
refuses a maintainer claiming an entry they accepted themselves, is
in the validator as a named
predicate, not in review guidance.