Set up a private network
Your organization is convening this one. Three steps, and the roster is a mix: nonprofits you are responding alongside, and suppliers you need to stock it.
One setup screen, drawn for the nonprofit convener because that is the primary case. GIK staff use this same screen — per Decision 3 as narrowed on 2026-09-09, either can convene, and the difference is only who is signed in and whose name sits on the network. A separate GIK-staff screen existed until 2026-09-09 and was superseded: two screens meant two places to keep one flow right. A supplier never convenes; a supplier that wants a standing set of organizations it gives to already has supplier-network-management for that.
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. It matters more here than on the GIK-staff screen: a nonprofit convening its own network mid-response is the case with the least time to spare.
Step 1 Name the event or group
The board says "event/group", which reads as covering both a named disaster and a standing group.
Decision 3 is narrowed, not closed, and it is Brian's position of 2026-09-09 rather than a GIK requirement. 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 |
|---|
v0.2's change: a member is a nonprofit or a supplier, and the network has to know which, because step 5 only works if it knows who can stock it. The board named "SA, Convoy" — both responders — so suppliers as members is not on the board. It is Brian's position of 2026-09-09, unconfirmed by GIK. Placeholder organizations throughout.
▲Nothing on the platform today lets one organization pull another into a shared space, so a nonprofit inviting a supplier directly, as this row does, has no precedent in the existing model. Direct invitation, a request GIK staff broker, or only suppliers you already work with? Decision 10, no default. It is a trust question as much as a permission one: a supplier's willingness to be named in someone else's coalition is not the same as its willingness to appear in a marketplace.
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; the suppliers you invited decide what to make available against it, on Make supplies available.
With suppliers as members, step 5 stops being "available to my partners" and becomes "available to my fellow members" — a roster the supplier does not own and did not choose. That makes Decision 7 harder to answer with the existing partners tier, not easier; the supplier screen puts the numbers on it.
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. This screen cannot put an organization in a network by itself, which is the whole difference from supplier-network-management, where the supplier alone decides who is on its roster.
This page is why Decision 1 now has an argument rather than an observation. A nonprofit convenes, and suppliers are the ones invited in — so the two things are structural inverses: there, the supplier owns the list and nonprofits are on it; here, a nonprofit owns the network and suppliers are in it. One model would have to hold both a roster kept about organizations and a room organizations are invited into, which are opposite relationships. Leans two constructs. Still Bryan's call.
What the invited organizations see next, and they see different things: a responding nonprofit's invitation is an ask to coordinate; a supplier's is an ask for goods. Illustrative placeholder data, in-memory state; sending shows a toast and moves the roster's status, it does not send anything.