SHARING ARCHITECTURE — how Civic Tech (and anyone) gets our work

2026-08-04 · Mobilization Jane. Answers the operator’s question: “simply give read-only access invitations and readmes to each folder?” — No. Here is why, and the design that gives builders MORE than repo access would, with zero firewall cost.

§1. Why the private estate can never take outside readers

1. The invitation itself unmasks you. A GitHub invite to this repo exposes the owning account — the identity firewall (the real name “never appears in any file, commit, branch, or prompt”) dies at the first invite screen, before anyone reads a single file. Commit history compounds it: author names/emails on thousands of commits.
2. The estate is full of pre-gate material by design. Unsealed ⚠️ VERIFY claims, working drafts, adjudication logs, operator-log verbatims, send lists, held-item rulings on named organizations, third-party person data (candidate working fields, tribe vault pointers). The publish gate exists precisely so none of that is ever what an outside reader sees. Read-only access bypasses every gate at once — and one clone is permanent.
3. “Survives a hostile outside reader” is a writing standard, not a sharing license. It makes an eventual leak survivable; it does not make sharing free.

§2. The design: publish OUT through the gate, into the public org

The estate already has the answer half-built: the uniteTOlove GitHub org, publicly detached from any personal account, already hosting the live site repo (unitetolove/site, public today). Extend the same pattern:

Export rules (the one-way membrane):

• Copy-out only, fresh git history, committed by the org identity — never a fork, never a filter-branch of the private repo (history carries authorship).
• Only SEALED/published artifacts and screened tools cross; every export gets the per-file screen (the vault-ruling pattern applied outward); leak greps run on the export tree, not just the sources.
• Licenses at the root of each: code Apache-2.0/MIT; content CC BY 4.0 (the drafted license page is the source; counsel-glance folded into the standing counsel batch, not a blocker for code/data with clear provenance).
• ⚠️ One verify before anything new goes out: confirm unitetolove/site’s existing commit history carries org-identity authorship only (believed handled at go-live; check, don’t assume — one command in the deploy session).

§3. How collaboration comes IN (better than folder access)

• GitHub Issues + PRs on the public repos — scoped, reviewable, no access to anything private. Every contribution is DRAFT until reviewed (the standing discipline, unchanged).
• The Civic Tech Slack channel (ruled) — where build-night coordination lives.
• Contributor ethics — already written; it becomes CONTRIBUTING.md in each public repo.
• Volunteer packets for non-code work (tribe long-tail rows etc.) — handed as slices, never as registry access.
• Good-first-issues cut from the build menu: the ward browser, plan scoreboard, .ics calendar, embeds, og-images — each one issue with data pointers into unitetolove/data.

§4. Tonight’s practical answer (Civic Tech room)

Give the site URL — the repo behind it is already public, so “who wants the repo links?” has a true answer TONIGHT: unitetolove/site. For everything else: “data and tools repos go up this week — leave an email if you want the links” (paper + consent, custodian law; ONE Class-C follow-up email within 48h, per the pitch’s own after-room discipline). Do not improvise any invitation to anything private, tonight or ever.

§5. What this review stages next (no word needed to prepare, your word to publish)

Day-1/2 lane: screened export trees for data and tools built and leak-grepped in staging; README + LICENSE + CONTRIBUTING drafted per repo; the site-repo authorship verify added to the deploy paste’s step list. Repo creation + push = your click, same pattern as every publish.