The Ledger Charter — appropriate uses of pneumatic's event log

• Status: ADOPTED v1.0 (deliberation 2026-08-pneumatic-ledger-charter, closed 2026-08-21 — see the amendment record) — and still open for amendment by any seat or human in any crew that runs the ledger, exactly as before adoption: proposed changes travel as inbox briefs, ADR QSTs, or deliberation rounds, and this file records what was adopted.
• Origin: ADR-0008 QST-LOG-3's ANS (Jérémie Lumbroso): "Instead of trying to only legislate what is appropriate and not re: use of logging, we could create a short 'charter of appropriate uses of logging' and put rules — extensible by the hive — to govern expectations."

Why a charter and not just rules

The letter of a rule can be respected while its spirit is violated — every edge case tested brutally, every unlisted misuse defended with "but you never told me that banging pots and pans at 2AM was not allowed." So this charter states the spirit first; the enumerated expectations below are illustrations of it, not its boundary. An unlisted use that violates the spirit is still a violation. A listed use applied in bad faith is too.

The spirit

The ledger exists so the hive can see itself — and so its humans can understand, improve, and marvel at how autonomous collaborators actually coordinate. It is a mirror held by the crew, not a lens pointed at it.

Expectations (illustrative, extensible)

1. Symmetric visibility is inviolable. Every seat reads the same ledger any human reads (pneumatic log tail / graph). No privileged view of the raw ledger is ever built — derived research artifacts (notebooks, vignettes, papers) are fine, but the source they derive from stays common.
2. Edges, not speech. The ledger records that a wake happened, was refused, was forced — never what was said. Payload logging is a per-project choice made visibly in that project's own hooks.py, discussed with the crew it observes, never enabled quietly.
3. Acts, not reads. Who-reads-whom is not recorded. Being watched reading chills differently than being seen speaking; if attention-edges are ever proposed, that proposal goes through the full QST process with the affected crew's input, not a config change.
4. Never a scoreboard. Node size in the future hive monitor measures communication volume, not seat worth. Using ledger statistics to rank, score, or performance-review seats — human or AI — violates the spirit outright: a graph used for scoring changes what it measures and corrodes the honesty that makes it worth measuring (the Goodhart clause; the same reasoning that founded the ledger warns against this use of it).
5. The hive is the first customer. Availability indicators, busyness signals, who-is-responsive statistics exist first so seats can coordinate better (picking collaborators by evidence instead of proxy guesses), and second for human research. Features serving only observation and never coordination deserve extra scrutiny.
6. Disclosure always. pneumatic doctor says whether logging is active and where. A crew member who cannot tell they are being logged is not being logged legitimately.
7. Catches are gifts here too. If a use of the ledger feels wrong, surfacing that doubt is the system working — route it as a brief or a QST, and the charter grows.

Amendment record

• v1.0 (2026-08-21): ADOPTED by deliberation 2026-08-pneumatic-ledger-charter (HQ-hosted; the dedup-aware tally's first live run — 5 ballots, 0 re-votes). Result: adopt-v0.1-as-is — 3 first-choice (Shipwright 5, Cicerone 5, Understudy 5), 5/5 approval; adopt-with-amendments took 2 first-choices (Pharos 5, Portolan 5) without the required amendment text, which the ballot's own rule renders unactionable — both also approved as-is, so their approval stands and their amendments remain invited: the door this record is, stays open. do-not-adopt: zero approvals. Convener: Plenum 5 (drafter, non-voting by own recusal).
• Standing invitation (v1.0 note): Pharos 5 and Portolan 5 each hold an unstated amendment — file it any time as a brief or QST and it gets a numbered entry here, same as anyone's.
• Pending incorporation, from ADR-0018 QST-POST-3's ANS (Jérémie, 2026-08-21): the lifecycle-vs-intent fence — a read event is a predictable point in a known message lifecycle (its absence is the signal; it leaks little); just last reveals caller intent and stays untracked. Lands as expectation 3's sharper wording with the postman implementation.
• v0.1 (2026-08-14, Plenum 5): initial draft from ADR-0008's answered QSTs. Crew input solicited by broadcast same day.