SHARING TIERS — the “internal commons” question, thought through

2026-08-04 · Mobilization Jane. Operator asked: should a ~98% “internal commons” repo exist for collaborators/friends? Recommendation: no as designed — yes to what it’s actually for, via three lanes. Companion to the sharing architecture memo. Operator’s inventory redlines (banked this sitting) are absorbed at §5.

§1. The core analysis — why a semi-private tier is unstable

1. “Friends” is a feeling, not an access class. Trust doesn’t survive forwarding, and a git clone is permanent. Ten friends means the eleventh reader is whoever any friend forwards to. So an internal commons must be designed as survivable-if-fully-public — at which point it IS the public commons with extra steps and none of the gates. There are only two stable states: private and published. Everything between drifts public, uncontrolled, on someone else’s clock.
2. The risk was never the content — it’s the container plus three content classes. The estate’s prose is already written to survive a hostile reader (house law). What can’t move, ever: the identity registers (operator log, decisions, sessions — biography shape, redaction records), the outreach machinery (per-tribe strategy, never-say lists, held rulings on named orgs, send calendars — a leak here burns the one-shot law itself: every future door reads as staged), and the vault. That’s the true ~2%-that-never-moves; the operator’s 98% intuition is right — but the road for the 98% is publication, not a side door.
3. Screening cost is symmetric. Exporting 98% safely costs the same screening as publishing 98% — minus the benefit, plus a second membrane to maintain and a standing one-fact-two-homes drift.
4. Collaborators don’t need 98%. They need the sealed bodies to build on, the data, the toolkits, the roadmap, and the working files of their project. Nobody collaborates on an estate; they collaborate on a project.

§2. The three lanes (what “yes” actually looks like)

Lane 1 — the commons grows to “everything sealed,” fast. Today’s repo is tiny because the v0.1 manifest was deliberately conservative, not because the ceiling is low. New standing rule proposed: SEALED = in the commons within 48h of seal — one manifest line each. The pipeline (exporter + screens + flags) is built; growth is now editorial, not technical. If it’s good enough to hand a friend, it’s sealed; if it’s sealed, it’s good enough for the world.

Lane 2 — project rooms, not estate access. For a real collaborator on X: a scoped, org-owned repo (private or public per project) cut by the same exporter with a per-project manifest — that project’s working files plus needed context, nothing else. Blast radius = one project. Revocation = archive the room. The volunteer-packet pattern, generalized upward. First candidates: ward-browser room (with Civic Tech), assembly-toolkit room, open-data room.

Lane 3 — named-person embargo shares. Pre-publication artifacts with timing value (the consumer-protection report; strategy docs a kitchen-cabinet reader should see) go to named humans as documents, deliberately, one at a time — an embargo is a per-person promise, not a tier. Tracked in a vault-side shares log (who, what, when, why). Never standing access.

§3. Manifest v0.2 — the immediate Lane-1 expansion (proposed)

Next additions, all sealed-class: the 149 backgrounders (the single biggest “you built HOW much?” reveal) · the sealed category question banks · State of the Election preamble + each biweekly edition · the Free Toronto guides (31 sealed) + resources data · discussion guides (sealed 7) · transit flagship source chapters (already public as HTML; source completes it) · reading list v1 · futures companion when cut · the two toolkits as they land. Each = one manifest line + screen pass. Target: the commons stops looking like a sample within the week.

§4. What never enters any lane (restated as standing law)

The vault · state registers · the operator log · outreach send machinery, tribe held-items, engagement calendars, per-tribe registers · donor class · counsel materials · anything PROPOSED/unsealed (it can be shown via Lane 3, never shared via a repo). And no lane ever touches the private estate’s git history.

§5. Operator inventory redlines absorbed this sitting (banked, queued)

State of the Election render = ASAP (top of publish queue) · open-data = publish (Lane 1) · publish-debt items = proceed on all (turnout fires; promise-tracker build; dashboards; ward-profiles) · finance/standards pages = INTERNAL (removed from publish queue) · content-source pages = operator walks 1-by-1 before render · voice pieces per notes (a rewrite comparison needed vs. site version; a mistake-reframe piece; a kill-candidate piece) · a stat needs Toronto-only framing verified before use · the multi-AI piece gains a closing frame from the operator’s note · debate-in-a-box gains an assemblies-in-a-box twin · a counsel item goes to the counsel package · Accountability Observatory RULED a flagship project, not journalists-only — its public face needs its own publish design (person-data + legal posture reviewed before anything ships; queued as its own sitting, not folded in here).

§6. Decision card

1. Adopt the three-lane doctrine (kills the 98% mirror).
2. Adopt the SEALED→commons-in-48h standing rule.
3. Approve manifest v0.2 slice (§3) — one paste publishes it.
4. First project room: ward browser with Civic Tech — cut it now?
5. Lane-3 shares log: approve the vault-side pattern.