Contribution Ledger¶

Record artifact — instantiates Reputational Signal Governance

Keeps an append-only, per-subject record of contributions, no-shows, and repairs across repeated rounds, so standing rests on a whole conduct history rather than the last impression.

A Contribution Ledger is the raw memory a reputation system is built on: a running, per-subject log of what an actor did, failed to do, and later put right, entry by entry, round after round. Its defining move is that it records omission and repair, not just wins — a missed commitment or a no-show is an entry, and so is the make-good that follows. It is deliberately not a score: it neither aggregates nor judges, it just captures attributable conduct with enough context that any later scoring, decay, or appeal has something faithful to work from. Think of it as the ledger of first-hand facts that everything downstream must reconcile with.

Example¶

An open-source project keeps a contribution ledger for its maintainers and regular contributors. It doesn't just tally merged pull requests; it records the shape of participation across each release cycle — reviews given, a security patch shipped on time, a release a maintainer signed up to cut and then quietly dropped, and the follow-up where they came back, apologized, and covered the next two. Each entry carries who, what, which cycle, and a link to the actual artifact (the PR, the thread, the missed milestone).

When the project later decides who to hand commit rights or a funded maintainer slot, the ledger is what the conversation rests on. Instead of "they seem reliable" or the memory of one dramatic incident, there is a legible record: consistent for eleven cycles, one dropped release two years ago, repaired within a month. The ledger doesn't make the decision — but it means the decision is made against conduct that was actually observed and attributed, not vibes.

How it works¶

Capture each act as an attributable entry. Every tracked event — contribution, non-contribution, or repair — becomes a line tied to a subject, a time/round, and a pointer to the underlying evidence.
Log the negative space. Absences and unmet commitments are first-class entries, because a reputation built only on visible wins hides exactly the conduct others most need to know.
Preserve context, not just outcome. Each entry keeps enough surrounding detail (what was expected, what happened) that a later reader can interpret it fairly rather than re-litigate it.
Stay append-only. The ledger grows; it does not silently rewrite. Corrections are added as new entries (and routed through appeal), so the history of the history is itself intact.

Tuning parameters¶

Tracked-act scope — how wide a net of conduct becomes an entry. Broad scope captures more signal but drifts toward surveillance and chills participation.
No-show / omission logging — whether and how absences are recorded. Logging them is the ledger's whole point, but over-recording petty misses buries the meaningful ones.
Round granularity — per-interaction entries versus per-cycle summaries. Finer granularity is more faithful and more costly, and invites over-reading noise.
Append-only strictness — how immutable entries are, and whether corrections overwrite or accrete. Strict append protects integrity; too strict makes genuine errors sticky.
Retention horizon — how far back the ledger keeps entries before they are archived out of active view (the input the decay rule then acts on).

When it helps, and when it misleads¶

Its strength is memory of consistency and repair: it resists the last-impression bias that lets one great demo or one bad week dominate, and it makes a pattern of quiet reliability visible. Durable cooperative systems tend to monitor member conduct and remember it precisely so that response can be graduated to history rather than to mood.^[1]

It misleads when the act of recording becomes the harm: comprehensive logging can tip into surveillance that chills the very participation it means to reward, and a ledger optimized for countable acts quietly over-values easily-gamed volume (many trivial contributions) over hard-to-count value. Its classic misuse is selective mining — pulling an old omission out of the ledger to justify a decision already made about someone. The discipline that guards against it is to treat the ledger as an input that must be aged by a decay rule and correctable through appeal, never as a standing verdict.

How it implements the components¶

behavior_trace_capture — its core function: turning each contribution, non-contribution, and repair into a recorded, timestamped trace.
attribution_and_context_record — every entry is bound to a subject and its surrounding context, so the trace can be read fairly later rather than as a bare data point.

It deliberately does not verify, score, or age what it records — attestation is Attested Credential Registry's job, aging is Decay-Weighted Score Update's, and turning the record into a number belongs to the score index (Reputation Score or Standing Index).

Instantiates: Reputational Signal Governance — the Contribution Ledger is the faithful behavioral record the rest of the pipeline compresses, ages, and governs.
Sibling mechanisms: Decay-Weighted Score Update · Attested Credential Registry · Appeal and Correction Workflow · Complaint and Resolution Record · Moderation Record with Reentry · Peer Reference or Vouching · Verified Transaction History · Reputation Score or Standing Index · Rating and Review System · Sybil, Collusion, and Brigading Detection · Trust-Tier Badging · Reputation Portability Protocol

Notes¶

The Contribution Ledger and Verified Transaction History are close cousins and easy to conflate: both are faithful behavioral records. The distinction is domain — the ledger records cooperative conduct (contribution, omission, repair) in a repeated-participation setting, where absence itself is meaningful; a transaction history records verified economic exchanges. A system with real commitments and no-shows to remember wants the ledger; one settling completed deals wants the transaction record.

References¶

[1] In Elinor Ostrom's design principles for durable common-pool institutions, effective commons monitor members' conduct and remember it, so that responses can be graduated to a subject's history rather than applied blindly — the governance rationale for keeping a faithful ledger before any scoring. ↩