Superseded 2026-09-09. This screen drew setup as something only GIK staff do. Nonprofits convene their own networks too, so the nonprofit-convened screen replaced it and now serves both conveners — the difference between them was the actor, not the flow, so two screens was two places to keep one thing right. Kept as the record of the earlier reading, and the suite lists it under its own superseded heading rather than beside the live screens.

Set up a private network

One screen for the whiteboard's first three steps: name the event, pick the disaster template, adjust what it pre-fills, and send the invitations.

What the replacement adds beyond a different actor: the roster carries a role, so it can mix receivers with suppliers, and a network with no supplier in it gets a warning rather than a block. Both came out of Decision 3 narrowing on 2026-09-09.

Elapsed on this screen 0:00 · the board's target is under five minutes

The < 5 mins on Mark's board is read here as a design target, not a meeting timebox — that reading is the spec's Decision 5 and is unconfirmed. The clock is the prototype arguing its own case: if setup cannot finish on one screen, the target does not hold. It is a demonstration device, not a product feature.

Step 1 Name the event or group

The board says "event/group", which reads as covering both a named disaster and a standing group.

Network name Linked disaster record

Whether a network attaches to the disaster record disaster-need-tagging already owns, or stands alone, is Decision 2. Drawn here as a link that can be left empty, which is the reading that covers both words on the board. If a network must always have a disaster, this field stops being optional and the second option disappears.

Step 2 Pick a disaster template

A template pre-fills the roster and the supply lists. Everything it adds stays editable, and is marked so you can see what came from where.

The brace on the board spans steps 2 to 5, so a template is drawn here filling both the roster and the supply lists — Decision 4, and the brace's exact span is ambiguous in the photo. This is the load-bearing assumption of the whole screen: without it there is nothing to pre-fill and the five-minute target has no mechanism behind it.

Step 2b Members

Pre-filled from the template. Add or remove before anything is sent.

Organization	Role in this network	Added by

Add an organization

The board names "SA, Convoy" as examples — read as Salvation Army and Convoy of Hope, both NVOAD members and both receiving. Placeholder organizations throughout; nothing here is real client data.

v0.2: a member can be a supplier as well as a nonprofit, so the roster carries a role. Suppliers as members is Brian's position of 2026-09-09, unconfirmed by GIK.

Step 2c Supply lists the template suggests

What this disaster type usually needs. Suppliers fill these in their own portal; this only says what the network is asking for.

This is the other half of the brace. The network states what it needs; a supplier decides what to make available against it, on Make supplies available. Whether that supplier action needs a fourth visibility tier is Decision 7.

Step 3 Notify members

Sending puts every member at "invite sent". Nobody is in the network until they accept.

Steps 3 and 4 are the two states the board draws separately — invite sent, then invite accepted — and they are the part of this feature with no equivalent anywhere in the existing model. supplier-network-management models a roster a supplier keeps about organizations, who need not know they are on it. This screen cannot put an organization in a network by itself, which is the whole difference. Whether these are one construct with two modes or two separate ones is Decision 1, and it gates the model.

What the invited organization sees next: the invitation. Illustrative placeholder data, in-memory state; sending shows a toast and moves the roster's status, it does not send anything.