NYCN/Summit Organizer Meeting Prep — 2026-05-21

A reading-frame for one conversation with someone who knows the work.

This packet adapts the Thursday meeting brief for the 2026-05-21 conversation with a NYCN/Summit organizer (two-plus years inside the work). If the two disagree, the Thursday brief controls ICN repo-state facts for this meeting; this packet controls the conversational shape. Project-level truth still lives in the source-of-truth docs.

Treat Summit-organizing reality as shared ground. No 101 on committees, sponsor outreach, accessibility planning, registration, or handoff pain. The organizer knows.

0. Why this organizer is the right person for this conversation

The organizer has worked the Summit for two-plus years and sits squarely at the content / logistics seam — speakers, sessions, the final schedule, room layout, interpretation, presenter support, translated descriptions, the public program, run-of-show, and post-event handoff. That seam is where ICN's spine gets stress-tested most honestly. It is not abstract governance; it is "we said this would happen, did it, how do we prove it, and how does next year's chair learn from it?"

The other reason: this organizer carries institutional memory across Summit cycles. Most of what ICN is trying to make durable — what a body decided, what it promised, what it actually delivered, what survived the chair rotation — is exactly the load they have been carrying in spreadsheets, threads, and head-state. If the spine looks real from inside that vantage, the project has a foothold. If it looks wrong, that is the single most useful signal we will get this month.

The point is not to persuade the organizer that the spine is right. The point is to find where it breaks when it touches real Summit work.

1. The cooperative-movement problem

Cooperatives have democratic values, but most of the digital infrastructure available to them was not built to hold democratic institutions together. Governance lives in Loomio, Google Forms, and Slack threads. Fiscal records live in tools built for conventional businesses. Membership lives in mailing lists, spreadsheets, or CRMs. Inter-organizational coordination lives in email. Each piece can be useful, but the institutional spine is fragmented, vendor-owned, and hard to verify across years. When a vendor changes terms, prices, or politics, institutional memory walks with them — and there is no way to prove to a funder, accountant, partner co-op, or future organizer that a decision actually happened, by whom, under what authority, without asking them to trust the organization's word for it.

The values are there. The owned digital rails for governance, coordination, evidence, membership, obligations, and federation are not.

2. What ICN is trying to become

Not "an app." Not a database. Not crypto. Not SaaS. Not a federation server.

ICN is social software running on social infrastructure: a substrate for standing, authority, decisions, obligations, receipts, evidence, member participation, stewardship, and inter-cooperative coordination — designed so a cooperative or federation can run its own institution without trusting a vendor with its memory.

The substrate enforces constraints. The cooperative carries meaning. The kernel does not understand "vote," "credit limit," or "trust score" — it sees signed records, capabilities, and constraint sets, and produces receipts a third party can verify later.

A real substrate exists: daemon, identity, ledger, governance primitives, gateway, and proof-bearing receipt paths. Most of the human-facing surface — the app a member would actually use, the dashboard an organizer would actually open — is still design and fixture rehearsal, not production. NYCN is an active partnership track, not a formally committed pilot.

3. Why this matters for NYCN / Summit

Summit already contains the real workflow: committees, chairs, sponsor outreach, speakers, venues, accessibility planning, registration, logistics, follow-up, document sprawl, organizer memory, post-Summit handoff. The ICN spine maps onto that world. Each layer below is a thing Summit already does — the column on the right is what ICN is trying to let Summit eventually own without trusting a vendor with it.

Standing — who sits on which committee with which authority class. Today: a holder-label in a roster doc. ICN direction: queryable standing the next chair can verify.
Authority — which clause or mandate lets a chair commit a venue or sign a sponsor letter. Today: implicit, sometimes "I'll ask the chair." ICN direction: the authority basis is on the action before it's signed.
Decisions — a committee deciding "we book Venue X / accept Sponsor Y / publish Speaker Z." Today: a Google Doc minute. ICN direction: a governance decision with cited mandate.
Obligations — sponsor commitments, speaker honoraria, venue contracts, accessibility accommodations promised, day-of logistics. Today: forwarded threads + organizer memory. ICN direction: tracked from creation through fulfillment.
Effects — the bookings, the agreements, the published program, the accommodations actually arranged. Today: a calendar + an email. ICN direction: an effect dispatched against the cited mandate.
Receipts — the durable, plain-language record that an effect happened, who confirmed it, when. Today: screenshots. ICN direction: receipts the next organizer can read without backchanneling six people.
Evidence — what survives chair rotation and post-Summit handoff without leaking private fields. Today: organizer memory + zip files. ICN direction: repo-safe evidence per NYCN's existing `PILOT-REHEARSAL-EVIDENCE.md` shape.
Review / federation — outside verification: a funder, a partner co-op, a future organizer, an accountant. Today: trust the organizer's word. ICN direction: receipts and provenance the outside party can verify without trusting us.

These are not claims that the whole system exists today. They are the layers ICN is trying to build, and the question for Thursday is whether those layers look real from inside Summit organizing.

3a. What the Summit materials show

Looking at NYCN's existing record, the Summit is already shaped like a recurring democratic institution rather than an event:

A yearly cycle that touches recruitment, charter, committee formation, fundraising, content, accessibility, marketing, logistics, run-of-show, post-event feedback, and the carryover into the next year.
A content / logistics seam that runs from a session idea, through speaker outreach and confirmation, through bio / headshot / description collection, through support and interpretation needs, through room and material needs, through schedule placement and public program publication, through run-of-show, to post-event material collection. This is the part the public sees; it is also the part where memory gets lost most often.
A feedback loop: raw attendee feedback (much of it private) → anonymized themes → organizer review → decision to act, defer, or reject → next-year planning obligations → evidence the decision was honored.
Accessibility and care obligations held by a small group, often without durable records that survive a chair rotation. The institution learns slowly across years because the evidence does not travel safely.
Sponsor, funder, and accountability trails with real obligations on both sides, often tracked in forwarded threads.
Multilingual materials and translated descriptions whose status (drafted / reviewed / published / outdated) sits in someone's head.
A persistent organizer-load and handoff problem: exhausted people become the database; when they rotate out, the institutional memory walks with them.
Movement follow-through: attendees who said they wanted to help, who never got contacted because the list of "people who said yes" did not survive the week after Summit.

The Summit is therefore the first realistic institutional laboratory for ICN — not a generic event use case. The point is not to "demo ICN at Summit." The point is that Summit already does the work ICN is trying to make legible, and the question is which slice of that work would benefit from receipts, evidence, and durable obligation memory without making organizers carry yet another tool.

4. The roles ICN intends to fill

Member interface — plain-language participation, action cards, standing, obligations, current status. Mobile-first, offline-tolerant, accessibility-first. Spec at `docs/spec/member-shell-v0.md`. No live app.
Steward / operator interface — coordination, divergence detection, follow-up, evidence trails, degraded states surfaced honestly. Spec at `docs/spec/steward-cockpit-v0.md`. No live cockpit.
Institution package layer — NYCN-specific charter, committee structure, Summit-specific fixtures and templates live in NYCN's own repo, not in ICN core. The NYCN repo already does this; the boundary is intentional.
Federation layer — cooperatives coordinating across organizations with verifiable records. Not a blockchain. Not a global ledger. Receipts that can travel between cooperatives without a shared landlord.
Developer / cooperative-builder layer — reusable substrate that other cooperative institutions can adopt. The point is not that NYCN is special; the point is that NYCN is the first instance and other cooperatives could be next.

5. The conversation — shape, not script

A back-and-forth structure, not a monologue. Each beat is show → ask → listen, in that order. Each beat should be one or two minutes of Matt talking, then five-plus minutes of the organizer talking. If Matt is talking more than half the meeting, the structure is failing.

Ask less, listen more — and do not defend in the first round. When a critique lands, do not argue. Capture the objection, translate it into a design question, and ask what would make the thing safer or more useful. The meeting's value is calibration, not persuasion. If something sounds wrong to the organizer, that signal is more valuable than any in-the-room explanation Matt could give.

Beat 1 — Open with the problem, not the product

Two sentences:

Cooperatives rent their digital rails. When the landlord changes terms, the cooperative's memory walks.

Then ask:

Where in Summit work have you seen institutional memory actually get lost — chair rotation, platform migration, fiscal sponsor change, end-of-year handoff?

Listen. The answer becomes the anchor for the next two beats.

Beat 2 — Mirror it back

Take whatever the organizer names and reflect it in ICN-spine terms:

What you're describing is a standing problem (or an authority problem, or an evidence problem, or a handoff problem).

This is the moment of legibility, not the moment of pitch. Do not introduce vocabulary she hasn't already implicitly used.

Beat 3 — Introduce the spine in one breath

Standing → authority → decisions → obligations → effects → receipts → evidence → review / federation.

Eight words. Then ask:

Does that order match the order of how Summit work actually moves through your committees?

The answer reshapes the rest of the conversation. If she pushes back on the order, follow her order.

Beat 4 — Walk through one Summit workflow

See §6 below. Walk one candidate end-to-end through the spine. Stop after each beat and ask:

Does this look like how it actually works for you, or am I missing something?

This is the heart of the meeting.

Beat 5 — State what is not real yet, plainly

No live member app.
No live steward cockpit.
Not a formally committed pilot. NYCN is the intended first cooperative partner; the next concrete human gate is exactly this kind of conversation, not a deployment.
The Debian appliance boots in a dev image; it is not signed, not immutable, not partner-ready.
Receipts alone do not prove legitimacy.

Then ask:

What of this would you trust? What would you not? What would you look at first?

Beat 6 — Surface the anti-features

Where should ICN stay out? What stays human and process-first and should not be automated? Ask:

What is the right anti-software boundary?

Anti-features are as load-bearing as features in this kind of project. The most useful thing the organizer can do is name one.

Beat 7 — Close on the smallest honest rehearsal

Not a launch. Not a pilot announcement. A tabletop walkthrough against fictional or sanitized data of one Summit workflow. Ask together:

What is the smallest thing that would be useful to rehearse? Who else should be in that room?

6. The walkthrough — one Summit workflow, through the spine

Three candidates. Candidate A is the primary — it lives at the content / logistics seam where the organizer's experience is deepest. Candidate B (sponsor commitment) and Candidate C (accessibility accommodation) are secondary; reach for them only if the organizer's earlier answers point that way. Walk whichever candidate is used through the spine, beat by beat; after each beat ask:

How does this happen for you today? What would change if there were a receipt at this step?

Candidate A — Content / session → public program (PRIMARY)

Good for: the organizer's actual workflow seam — speakers, sessions, run-of-show, multilingual material, post-event collection.

Standing — the content / program committee, with the session-curation mandate delegated by the steering body, alongside an interpretation / translation steward role.
Authority — charter section authorizing the committee to issue invitations, confirm slots, request bios / headshots / descriptions, and bind the organization to specific support, interpretation, room, and material commitments within the approved program-track scope.
Decision — committee accepts a session idea and decides to invite Speaker Y.
Obligation — Speaker Y owes a bio, a headshot, and a session description (with translation if needed) by date D; the committee owes Speaker Y a slot, a room, listed materials, interpretation if requested, and any agreed support arrangement (compensation, travel logistics, accessibility provisions).
Effect — bio / headshot / description collected; translation reviewed; schedule slot assigned; public program updated; room and material requests routed to logistics; interpretation booked; run-of-show role assigned; day-of confirmations sent.
Receipt — each step is acknowledged: speaker confirms, materials received, translation reviewed, schedule entry published, day-of role confirmed, post-event material collected. Each acknowledgement is a small receipt the next chair can audit.
Evidence — post-Summit, a future program chair can ask "for last year's Summit, which sessions ran, with which speakers, in which slots, with what support arrangements honored, and what was missed?" — and get a readable answer without backchanneling.

This is the candidate to walk first. It pulls on the seam the organizer has lived in, surfaces multilingual / accessibility / support obligations naturally, and ends on the handoff problem that recurs every year.

Candidate B — Sponsor commitment (SECONDARY)

Good for: external proof, obligations, future fundraising handoff.

Standing — the outreach committee, with the sponsorship clause delegated by the steering body.
Authority — charter section authorizing the committee to solicit and accept sponsorship within the pre-approved sponsorship policy; outside that policy, steering approval is required.
Decision — the committee decides to approach Sponsor Y at tier Z.
Obligation — Sponsor Y commits support at tier Z in exchange for visibility deliverables A, B, C.
Effect — agreement signed, logo published, table booked, accessibility provisions arranged.
Receipt — each deliverable confirmed; the sponsor's counter-deliverable acknowledged.
Evidence — post-Summit, the record survives in a form a future fundraising chair can read without backchanneling six people.

Candidate C — Accessibility accommodation request (SECONDARY)

Good for: privacy boundaries, care obligations, learning across years.

Standing — the accessibility committee, with charter authority to commit resources for accommodations within the committee's pre-approved scope.
Authority — clause in the Summit operating doc that allows the committee to bind the organization to ASL, captioning, sensory-aware spaces, dietary accommodations, and similar.
Decision — the committee approves accommodation X for Speaker / Attendee Y.
Obligation — vendor booked, arrangements confirmed, day-of confirmation required.
Effect — the accommodation is delivered.
Receipt — the requesting party confirms the accommodation met the need.
Evidence — post-Summit, the record exists in a form that lets next year's accessibility chair learn what worked and what didn't, without seeing private medical or personal details.

All three candidates are intentionally abstract enough to map to anyone's Summit experience. None uses real NYCN/Summit private records.

7. The 90-second spoken explanation

Say this out loud. Not to read — to speak in Matt's voice. Direct, serious, not melodramatic, no manifesto, no investor pitch. Target under 100 seconds.

Cooperatives have spent decades building democratic values and almost no time building the digital infrastructure those values need. We govern in Loomio, account in QuickBooks, remember in Slack threads, and federate in email. Every piece of the institutional spine — who's a member, who has authority, what was decided, what was promised, what was delivered — sits in someone else's product. When that product changes hands, when a chair rotates, when a fiscal sponsor leaves, the cooperative's memory walks. And we have no way to prove to a funder or a partner co-op that a decision actually happened, by whom, under what authority, without asking them to trust our word.

ICN is an attempt to build the infrastructure layer cooperatives actually need to own: a substrate for standing, authority, decisions, obligations, receipts, evidence, and federation. Not a vote app. Not a payment app. Not a blockchain. A constraint-enforcement engine the cooperative runs, where the rules come from a charter the members ratify, and the records are signed in a way an outside party can verify later without trusting us.

A real substrate exists: daemon, identity, ledger, governance primitives, gateway, and proof-bearing receipt paths. But most of the human-facing surface — the app a member would actually use, the dashboard an organizer would actually open — is still design and fixture rehearsal, not production. NYCN is the partnership track that's helping shape what that surface should look like. I'm not here to ship anything. I'm here to ask whether the spine looks real from inside Summit work, and what the smallest honest rehearsal would be. The cleanest test is the part of Summit work you already know: how a session becomes a public program, a set of obligations, a run-of-show, and something next year's organizers can inherit.

8. Questions to ask the organizer

Ask one at a time. Leave silence after each one. Do not stack questions.

On institutional memory and the content / logistics seam:

Where in the session → public program flow does institutional memory actually get lost?
What never makes it from one Summit into the next year's planning, even though it should?
Which step in speaker outreach / confirmation / support / translation / run-of-show would benefit most from a small durable receipt?

On feedback becoming next-year obligation:

How does attendee feedback turn into a next-year planning decision today — when it does turn into one at all?
What feedback never reaches the committee that could have acted on it?
What does the gap between "we heard this" and "we decided to do something about it" look like in practice?
What would change if a committee could see "here is the anonymized theme; here is the obligation we accepted last year; here is the evidence we honored it" before this year's planning starts?

On boundaries:

What must stay human and process-first? Where is the right anti-software boundary?
What information should expire, get deleted, or never be public?
What would make this trustworthy to organizers — and what would make it untrustworthy?

On the smallest honest rehearsal:

Which Summit workflow would be worth rehearsing under this spine — and which would be a waste of it?
What is the smallest sanitized / tabletop rehearsal that's worth a meeting?
Who else should be in this conversation — accountants, lawyers, mutual-aid operators, federation organizers — that we haven't invited yet?

9. Claims not to make

Matt reads this list before the call. This is muscle memory, not background.

Not production-ready. Not externally audited. Not legally or regulatorily certified.
Not a live federation. Not an end-to-end federation lifecycle.
Not a formally committed cooperative pilot. NYCN is an active partnership track.
Not a live member or mobile app. Not a live steward cockpit dashboard.
Not a signed, immutable, A-B-updated, or production-ready appliance.
Receipts alone do not prove legitimacy. Authority shortcuts must label themselves as shortcuts.
The kernel/app firewall is partially CI-enforced (Wave 1 complete); the denylist is currently advisory through Waves 2–6.
No use of payment, currency, balance, wallet, token, crypto, blockchain, timebank for ICN-native primitives. Vocabulary stays settlement, obligation, allocation, unit, position, receipt, provenance, evidence. This is a regulatory boundary, not a style preference.
No real NYCN private data has been or will be put in git for this work. The Summit-workflow walkthroughs above are abstract enough to map to anyone's experience.

10. The freeze rule (Tuesday onward)

After Tuesday's rehearsal, the human-facing story is frozen. No new claims, no updated framing, no Thursday-facing changes to this packet or the Thursday brief unless something on main materially changes a stated fact. Normal ICN development continues on branches. Repo-detail rabbit holes are out of scope for Thursday unless the organizer explicitly asks.

11. Tuesday rehearsal checklist

Matt runs this Tuesday afternoon:

Read the packet end-to-end once, top to bottom.
Say the §7 ninety-second version aloud, twice. Time it. If it runs over 100 seconds, cut.
Walk Candidate A aloud — one beat, one ask, listen-pause, next beat. Skim Candidate B and Candidate C only as alternate branches if they feel likely to come up.
Read the §8 questions aloud once. If any feels stiff or scripted, rewrite.
Read the §9 claims-not-to-make list aloud.
Pull up the three docs Matt will reference if asked: `docs/OVERVIEW.md`, `docs/PHASE_PROGRESS.md`, and `docs/architecture/ABUSE_CASE_HARDENING_STRATEGY.md`.
Confirm git status is clean on main. Confirm gh pr list -R InterCooperative-Network/icn --state open has not surfaced a surprise.
Stop. Do nothing else with the repo before Thursday.

12. Post-meeting capture

Filled in after Thursday — kept here so it isn't drafted under time pressure.

What the organizer identified as real:
What the organizer identified as wrong / overbuilt / unclear:
The smallest rehearsal chosen:
Who else she said should be in the next conversation:
What needs to change in the spine doctrine, the specs, or the NYCN docs:

Post-freeze delta log

Date	Repo	Change	Does it change Thursday claims?	Action needed
(no entries yet — fill in as deltas land on `main`)	—	—	—	—