Partner Networks

Decision 21, answered by GIK (2026-10-21 Dev Sync, spec v0.17): private networks are removed from Partner Networks. Every network is a partner network: Create network opens the Partner Network form at once, with no Partner or Private choice, and the Networks page and its map list partner networks only. An organization’s own warehouses and offices stay its locations, which it already manages in its GIK organization settings; separately registered organizations, even related ones, join an ordinary Partner Network.

Not drawn: no location-management screen and no transfers between an organization’s own warehouses. Whether freight between an organization’s own sites differs (George Samra, 2026-10-08) stays open under spec scenario S9. Round 6 keeps the private network screens for the record.

Round 7, favorite networks (Release 1, scope line 10): a star saves a network for quick access. It never moves the card: the list keeps the chosen sort (Recent activity or Name), and the star, the Favorites count and a status line change in place, so search, scroll, the map and focus stay as they were. All networks / Favorites narrows the list, the map, its network picker and Activity across your networks together; the search narrows within it; a map pick that leaves the scope is cleared. Removing a favorite while Favorites is shown fades the card out, moves focus to the next card’s star (or the filter) and offers Undo. Favorites are kept for the organization chosen in Viewing as, as round 6’s bookmarks were; ▲ whether they belong to a person or an organization is not decided.

Round 7, three different things (spec v0.17): Network favorites (the star here; round 6 called them bookmarks) save networks for quick access; they are in Release 1 (scope line 10). The current event on a network’s Overview is remembered for each organization on each network (GIK, 2026-10-21); it is not a bookmark. Event bookmarks were discussed and are not drawn or decided.

Round 6, Networks page (October 13 review, spec v0.16 Decision 25): search sits beside Sort above the partner network cards and stays local to this page, as Shabab Gruberg asked; it matches network names, the convener, member organizations, events and their disasters, response areas and member locations, and a card says what matched. The map shows the networks whose cards are listed, or the one network picked, and says which; the picker offers only listed networks, so a search never leaves the map on a hidden network. Show on the map and Open network sit at the bottom of every card (George Samra). Refined: each card keeps the name and type, the convener, one line of context (your role, members, events) and the most urgent open need’s Decision 22 bar, with the bar legend once above the cards. Activity across your networks is a collapsible panel beside the map (stacked under it on a phone), one timeline in the network page’s Recent activity format, following the map’s network or the search; the same action recorded twice at the same time shows once with a count.

History (round 6), now in Release 1 (scope line 10): Shabab Gruberg and George Samra asked for a way to keep the one or two networks someone works on close at hand. The star on a card keeps that network first, in either sort, and first in the map’s Network picker; Recent activity stays the default sort. Open: whether bookmarks belong to a person or an organization (here, the organization in Viewing as), and whether Brian Anderson’s primary focus replaces them.

R5 Networks page hierarchy (selected): chosen by April Sousa on 2026-10-12 from the two R5 layout explorations; not GIK approval. Header; Waiting on you when there are invitations; a full-width Across your networks map (same layers, network picker, city-level pins, response areas, list view and annotations); Partner networks across the full width, about three cards per row on desktop, two on tablets, one on phones; then Activity across your networks, full width, in two columns on desktop, six entries by default with Show all activity, collapsible from its header. Show on the map on a card narrows the map to that network and marks the card; choose it again to show all networks.

Same data and behaviour: creation, membership, locations, sharing, switching, map geography, permissions and (until round 7) Impact are unchanged. The earlier Networks page stays in partner-network-r5-original.html as a rollback reference.

R5 proposal (phase 1): an organization can be in several networks and opens one at a time. Each network keeps its own members, invitations, email invitations, events, shared resources, activity, removals and cancellations; every R4 screen works on the open network. Resources and needs stay their organization’s records: a network refers to the resources shared with it, so one resource shared with three networks is still one resource.

Networks page: R4’s page and network cards, extended after Brian Anderson’s R4.5 Networks page (Decision 25, his direction, not confirmed by GIK). Each card: Partner Network, convener, your role, events, members and shared resources, needs by status (R4’s status bar from dashboard option C), a status line, and Open network. “Open now” marks the network you have open.

Activity across your networks: each network’s own activity, grouped by network with the most recently active first: the six most recent entries by default, and Show all activity to see the rest inline. R4’s sample entries have relative times only (Today, Aug 2026), so the panel doesn’t claim a single timeline. Network Admin-only entries appear only where you are a Network Admin.

Prototype data: Convoy of Hope’s five earlier networks from R4’s data (Hawaii Island Relief Partners, Central Indiana, Iowa River Valley, Oklahoma, North Texas) are real networks here, with R4’s members, one event each, and the shares R4 described. Added for this phase: Kimball is also a Network Admin of Oklahoma Response Coalition, Iowa River Valley Partners has an invitation out to Lakeside Hygiene Supply, and Salvation Army is invited to Oklahoma Response Coalition.

▲ Kept from R4, differs from R4.5: Review invitation opens R4’s invitation page, with its Accept and Decline. Brian’s page accepts or declines on the row.

R5 proposal (phase 3): the Networks page map. a compact map in the side column, above Activity across your networks: every network you’re in, or one picked (R4.5’s network picker). Its details panel names each item’s network and opens it. Same illustrative, city-level rules as the Overview map.

R5 proposal (phase 3): activity. each network card on the Networks page shows its latest activity, as that network’s Overview shows it to you (Network Admin-only entries only where you are one). Waiting on you is unchanged: invitations you’ve received. Nothing else in a network you belong to waits on you with the records R4 has, so nothing new is counted; R4’s Needs your attention stays on the Overview.

Out of scope until reviewed: impact totals and stories, set-aside sharing, event lifecycle changes, draft needs from templates and order-based figures (see the integration audit).

R5 Networks page hierarchy (selected): chosen by April Sousa on 2026-10-12 from the two R5 layout explorations; not GIK approval. Header; Waiting on you when there are invitations; a full-width Across your networks map (same layers, network picker, city-level pins, response areas, list view and annotations); Partner networks across the full width, about three cards per row on desktop, two on tablets, one on phones; then Activity across your networks, full width, in two columns on desktop, six entries by default with Show all activity, collapsible from its header. Show on the map on a card narrows the map to that network and marks the card; choose it again to show all networks.

Same data and behaviour: creation, membership, locations, sharing, switching, map geography, permissions and (until round 7) Impact are unchanged. The earlier Networks page stays in partner-network-r5-original.html as a rollback reference.

No networks yet: an organization in no network sees Create network and the empty state, as in R4. Create network leads into your session, which already holds Convoy of Hope’s five earlier networks; step 2, Create, walks the whole Create experience from this empty state.

R5 Networks page hierarchy (selected): chosen by April Sousa on 2026-10-12 from the two R5 layout explorations; not GIK approval. Header; Waiting on you when there are invitations; a full-width Across your networks map (same layers, network picker, city-level pins, response areas, list view and annotations); Partner networks across the full width, about three cards per row on desktop, two on tablets, one on phones; then Activity across your networks, full width, in two columns on desktop, six entries by default with Show all activity, collapsible from its header. Show on the map on a card narrows the map to that network and marks the card; choose it again to show all networks.

Same data and behaviour: creation, membership, locations, sharing, switching, map geography, permissions and (until round 7) Impact are unchanged. The earlier Networks page stays in partner-network-r5-original.html as a rollback reference.

Waiting on you: only invitations your organization has received and not answered. Salvation Army is invited to Oklahoma Response Coalition, so Waiting on you leads and Review invitation is the primary action; Create network stays as the secondary one. Outgoing invitations awaiting a reply and high-urgency needs aren’t tasks for you: they show on a card’s status line instead.

▲ R5 proposal (phase 1): Brian’s fuller list (needs you could fill, orders to send, drafts to review, stories to approve) needs records R4 doesn’t have; nothing is invented here.

Roles are per network: Kimball Household Goods is invited to Gulf Coast Response Partners, a Member of Hawaii Island Relief Partners and a Network Admin of Oklahoma Response Coalition. Only a Network Admin sees a network’s outgoing invitations on its status line.

Sort: Recent activity (default; a network moves up when something happens in it in your session) or Name.

▲ Not drawn, R4.5’s Waiting on you sort: in this phase nothing inside a network you belong to is waiting on you, so that sort would change nothing. It returns if more Waiting on you items are approved.

Round 6, Networks page (October 13 review, spec v0.16 Decision 25): search sits beside Sort above the partner network cards and stays local to this page, as Shabab Gruberg asked; it matches network names, the convener, member organizations, events and their disasters, response areas and member locations, and a card says what matched. The map shows the networks whose cards are listed, or the one network picked, and says which; the picker offers only listed networks, so a search never leaves the map on a hidden network. Show on the map and Open network sit at the bottom of every card (George Samra). Refined: each card keeps the name and type, the convener, one line of context (your role, members, events) and the most urgent open need’s Decision 22 bar, with the bar legend once above the cards. Activity across your networks is a collapsible panel beside the map (stacked under it on a phone), one timeline in the network page’s Recent activity format, following the map’s network or the search; the same action recorded twice at the same time shows once with a count.

History (round 6), now in Release 1 (scope line 10): Shabab Gruberg and George Samra asked for a way to keep the one or two networks someone works on close at hand. The star on a card keeps that network first, in either sort, and first in the map’s Network picker; Recent activity stays the default sort. Open: whether bookmarks belong to a person or an organization (here, the organization in Viewing as), and whether Brian Anderson’s primary focus replaces them.

R5 Networks page hierarchy (selected): chosen by April Sousa on 2026-10-12 from the two R5 layout explorations; not GIK approval. Header; Waiting on you when there are invitations; a full-width Across your networks map (same layers, network picker, city-level pins, response areas, list view and annotations); Partner networks across the full width, about three cards per row on desktop, two on tablets, one on phones; then Activity across your networks, full width, in two columns on desktop, six entries by default with Show all activity, collapsible from its header. Show on the map on a card narrows the map to that network and marks the card; choose it again to show all networks.

Same data and behaviour: creation, membership, locations, sharing, switching, map geography, permissions and (until round 7) Impact are unchanged. The earlier Networks page stays in partner-network-r5-original.html as a rollback reference.

Many networks: past eight networks the page adds Search your networks, and shows eight cards with Show all. The seven extra networks are test data, named like R4’s large fixture, with Convoy of Hope as a member of another organization’s network.

Round 6, Networks page (October 13 review, spec v0.16 Decision 25): search sits beside Sort above the partner network cards and stays local to this page, as Shabab Gruberg asked; it matches network names, the convener, member organizations, events and their disasters, response areas and member locations, and a card says what matched. The map shows the networks whose cards are listed, or the one network picked, and says which; the picker offers only listed networks, so a search never leaves the map on a hidden network. Show on the map and Open network sit at the bottom of every card (George Samra). Refined: each card keeps the name and type, the convener, one line of context (your role, members, events) and the most urgent open need’s Decision 22 bar, with the bar legend once above the cards. Activity across your networks is a collapsible panel beside the map (stacked under it on a phone), one timeline in the network page’s Recent activity format, following the map’s network or the search; the same action recorded twice at the same time shows once with a count.

History (round 6), now in Release 1 (scope line 10): Shabab Gruberg and George Samra asked for a way to keep the one or two networks someone works on close at hand. The star on a card keeps that network first, in either sort, and first in the map’s Network picker; Recent activity stays the default sort. Open: whether bookmarks belong to a person or an organization (here, the organization in Viewing as), and whether Brian Anderson’s primary focus replaces them.

Search: by network name or convening organization. Show all isn’t needed while searching.

Round 6, Networks page (October 13 review, spec v0.16 Decision 25): search sits beside Sort above the partner network cards and stays local to this page, as Shabab Gruberg asked; it matches network names, the convener, member organizations, events and their disasters, response areas and member locations, and a card says what matched. The map shows the networks whose cards are listed, or the one network picked, and says which; the picker offers only listed networks, so a search never leaves the map on a hidden network. Show on the map and Open network sit at the bottom of every card (George Samra). Refined: each card keeps the name and type, the convener, one line of context (your role, members, events) and the most urgent open need’s Decision 22 bar, with the bar legend once above the cards. Activity across your networks is a collapsible panel beside the map (stacked under it on a phone), one timeline in the network page’s Recent activity format, following the map’s network or the search; the same action recorded twice at the same time shows once with a count.

History (round 6), now in Release 1 (scope line 10): Shabab Gruberg and George Samra asked for a way to keep the one or two networks someone works on close at hand. The star on a card keeps that network first, in either sort, and first in the map’s Network picker; Recent activity stays the default sort. Open: whether bookmarks belong to a person or an organization (here, the organization in Viewing as), and whether Brian Anderson’s primary focus replaces them.

Round 6, Networks page (October 13 review, spec v0.16 Decision 25): search sits beside Sort above the partner network cards and stays local to this page, as Shabab Gruberg asked; it matches network names, the convener, member organizations, events and their disasters, response areas and member locations, and a card says what matched. The map shows the networks whose cards are listed, or the one network picked, and says which; the picker offers only listed networks, so a search never leaves the map on a hidden network. Show on the map and Open network sit at the bottom of every card (George Samra). Refined: each card keeps the name and type, the convener, one line of context (your role, members, events) and the most urgent open need’s Decision 22 bar, with the bar legend once above the cards. Activity across your networks is a collapsible panel beside the map (stacked under it on a phone), one timeline in the network page’s Recent activity format, following the map’s network or the search; the same action recorded twice at the same time shows once with a count.

History (round 6), now in Release 1 (scope line 10): Shabab Gruberg and George Samra asked for a way to keep the one or two networks someone works on close at hand. The star on a card keeps that network first, in either sort, and first in the map’s Network picker; Recent activity stays the default sort. Open: whether bookmarks belong to a person or an organization (here, the organization in Viewing as), and whether Brian Anderson’s primary focus replaces them.

Round 7, favorite networks (Release 1, scope line 10): a star saves a network for quick access. It never moves the card: the list keeps the chosen sort (Recent activity or Name), and the star, the Favorites count and a status line change in place, so search, scroll, the map and focus stay as they were. All networks / Favorites narrows the list, the map, its network picker and Activity across your networks together; the search narrows within it; a map pick that leaves the scope is cleared. Removing a favorite while Favorites is shown fades the card out, moves focus to the next card’s star (or the filter) and offers Undo. Favorites are kept for the organization chosen in Viewing as, as round 6’s bookmarks were; ▲ whether they belong to a person or an organization is not decided.

Round 7, three different things (spec v0.17): Network favorites (the star here; round 6 called them bookmarks) save networks for quick access; they are in Release 1 (scope line 10). The current event on a network’s Overview is remembered for each organization on each network (GIK, 2026-10-21); it is not a bookmark. Event bookmarks were discussed and are not drawn or decided.

Round 6, Networks page (October 13 review, spec v0.16 Decision 25): search sits beside Sort above the partner network cards and stays local to this page, as Shabab Gruberg asked; it matches network names, the convener, member organizations, events and their disasters, response areas and member locations, and a card says what matched. The map shows the networks whose cards are listed, or the one network picked, and says which; the picker offers only listed networks, so a search never leaves the map on a hidden network. Show on the map and Open network sit at the bottom of every card (George Samra). Refined: each card keeps the name and type, the convener, one line of context (your role, members, events) and the most urgent open need’s Decision 22 bar, with the bar legend once above the cards. Activity across your networks is a collapsible panel beside the map (stacked under it on a phone), one timeline in the network page’s Recent activity format, following the map’s network or the search; the same action recorded twice at the same time shows once with a count.

History (round 6), now in Release 1 (scope line 10): Shabab Gruberg and George Samra asked for a way to keep the one or two networks someone works on close at hand. The star on a card keeps that network first, in either sort, and first in the map’s Network picker; Recent activity stays the default sort. Open: whether bookmarks belong to a person or an organization (here, the organization in Viewing as), and whether Brian Anderson’s primary focus replaces them.

Round 7, favorite networks (Release 1, scope line 10): a star saves a network for quick access. It never moves the card: the list keeps the chosen sort (Recent activity or Name), and the star, the Favorites count and a status line change in place, so search, scroll, the map and focus stay as they were. All networks / Favorites narrows the list, the map, its network picker and Activity across your networks together; the search narrows within it; a map pick that leaves the scope is cleared. Removing a favorite while Favorites is shown fades the card out, moves focus to the next card’s star (or the filter) and offers Undo. Favorites are kept for the organization chosen in Viewing as, as round 6’s bookmarks were; ▲ whether they belong to a person or an organization is not decided.

Needs visibility (Release 1 scope line 11, checked 2026-10-26): in the prototype only a network’s members reach its needs. Every network page, need, Respond and event screen requires membership (an invited organization sees its invitation, with no needs; a declined, removed or uninvited one is told the network isn’t available), and the Networks page, its map and search show needs only for networks you belong to. A need posted from a network appears in that network only. The earlier notes below that call network-only needs Later describe round 4’s assumption that such a need also stays visible in GIK’s Marketplace, which the prototype doesn’t draw and Release 1 rules out. ▲ For the build (Mike Perry): keeping network needs and shared inventory out of Marketplace search, matching, the API and MCP, which no screen here can show.

Another network open: Hawaii Island Relief Partners, from its card. The Overview (Option A), tabs and actions are R4’s, over this network’s own members, event and shared resources. Opening a network clears every search, filter and form from the one you left.

History (round 5): needs belong to a network. a need appears in the network it was posted from, not in every network its organization belongs to. It stays the organization’s record and keeps GIK’s existing visibility (D17 as R4 draws it): this is not network-only visibility. R4, with one network, listed every member’s needs; R4.5 gives each network its own needs (Decision 17, Brian’s direction). Pending stakeholder validation; not a confirmed backend requirement. R4’s sample needs belong to Gulf Coast Response Partners; two more are prototype data for Hawaii Island and Iowa River Valley.

Shares stay per network: Iowa River Valley Partners shows the flood cleanup buckets and hygiene kits shared with it. Bottled water is shared with Gulf Coast and Hawaii Island, not here. Sharing or stopping in one network never changes another; the organization keeps the resource.

Needs visibility (Release 1 scope line 11, checked 2026-10-26): in the prototype only a network’s members reach its needs. Every network page, need, Respond and event screen requires membership (an invited organization sees its invitation, with no needs; a declined, removed or uninvited one is told the network isn’t available), and the Networks page, its map and search show needs only for networks you belong to. A need posted from a network appears in that network only. The earlier notes below that call network-only needs Later describe round 4’s assumption that such a need also stays visible in GIK’s Marketplace, which the prototype doesn’t draw and Release 1 rules out. ▲ For the build (Mike Perry): keeping network needs and shared inventory out of Marketplace search, matching, the API and MCP, which no screen here can show.

History (round 5): needs belong to a network. a need appears in the network it was posted from, not in every network its organization belongs to. It stays the organization’s record and keeps GIK’s existing visibility (D17 as R4 draws it): this is not network-only visibility. R4, with one network, listed every member’s needs; R4.5 gives each network its own needs (Decision 17, Brian’s direction). Pending stakeholder validation; not a confirmed backend requirement. R4’s sample needs belong to Gulf Coast Response Partners; two more are prototype data for Hawaii Island and Iowa River Valley.

Example: Hawaii Island Relief Partners shows only the need posted from it (Bayou Relief Kitchen’s meals for Hilo shelters). Salvation Army and Bayou Relief Kitchen also belong to Gulf Coast Response Partners, but their Gulf Coast needs stay there. The event filter lists Hurricane Lala only.

Members and invitations per network: Iowa River Valley Partners’ members, and its own pending invitation to Lakeside Hygiene Supply. Invite, cancel, remove and re-invite act on this network only.

Creating another network: R4’s Create (name and optional description) adds a network and opens it; the others keep their records. Mobile Bay Shelter Partners is a prototype name.

A new network starts empty: no members, events, shared resources or activity of its own, and Get your network ready. Convoy of Hope’s own needs would appear here once it posts any.

Round 6, Networks page (October 13 review, spec v0.16 Decision 25): search sits beside Sort above the partner network cards and stays local to this page, as Shabab Gruberg asked; it matches network names, the convener, member organizations, events and their disasters, response areas and member locations, and a card says what matched. The map shows the networks whose cards are listed, or the one network picked, and says which; the picker offers only listed networks, so a search never leaves the map on a hidden network. Show on the map and Open network sit at the bottom of every card (George Samra). Refined: each card keeps the name and type, the convener, one line of context (your role, members, events) and the most urgent open need’s Decision 22 bar, with the bar legend once above the cards. Activity across your networks is a collapsible panel beside the map (stacked under it on a phone), one timeline in the network page’s Recent activity format, following the map’s network or the search; the same action recorded twice at the same time shows once with a count.

History (round 6), now in Release 1 (scope line 10): Shabab Gruberg and George Samra asked for a way to keep the one or two networks someone works on close at hand. The star on a card keeps that network first, in either sort, and first in the map’s Network picker; Recent activity stays the default sort. Open: whether bookmarks belong to a person or an organization (here, the organization in Viewing as), and whether Brian Anderson’s primary focus replaces them.

R5 Networks page hierarchy (selected): chosen by April Sousa on 2026-10-12 from the two R5 layout explorations; not GIK approval. Header; Waiting on you when there are invitations; a full-width Across your networks map (same layers, network picker, city-level pins, response areas, list view and annotations); Partner networks across the full width, about three cards per row on desktop, two on tablets, one on phones; then Activity across your networks, full width, in two columns on desktop, six entries by default with Show all activity, collapsible from its header. Show on the map on a card narrows the map to that network and marks the card; choose it again to show all networks.

Same data and behaviour: creation, membership, locations, sharing, switching, map geography, permissions and (until round 7) Impact are unchanged. The earlier Networks page stays in partner-network-r5-original.html as a rollback reference.

R5 proposal (phase 3): the Networks page map. a compact map in the side column, above Activity across your networks: every network you’re in, or one picked (R4.5’s network picker). Its details panel names each item’s network and opens it. Same illustrative, city-level rules as the Overview map.

Settled (Q4 roadmap): “A network admin creates an invite-only group tied to an event.”

Working decision D3: any organization admin, Non-Profit or Supplier, and GIK staff can create a network. The 2026-10-07 review framed creation as a permissions question: what counts is the acting user’s authority, not the organization’s type. Every persona here can create, so Kimball Household Goods (a Supplier) shows the same Create network as Convoy of Hope (a Non-Profit). ▲ Open: the exact permission level; no named roles are invented.

Three different things: organization type (Non-Profit, Supplier) describes an organization; the network relationship (creator, invited, member) is per network; capabilities (create networks, invite organizations, manage members, manage and share resources) decide actions. “Convener” means the organization that created this network, never a third type.

Call to action: Create network is the primary action for anyone allowed to create. While an invitation needs an answer, Review invitation leads and Create network stays as the secondary action; once answered, Create leads again and Open network is secondary. The same for every organization type.

Settled D16 (2026-10-07, spec v0.5a): the name is Partner Networks.

Platform today: the Organizations tab is the existing follow-based directory; following is not membership. Discovery and join requests are Later (model round 2).

Decision 21, answered by GIK (2026-10-21 Dev Sync, spec v0.17): private networks are removed from Partner Networks. Every network is a partner network: Create network opens the Partner Network form at once, with no Partner or Private choice, and the Networks page and its map list partner networks only. An organization’s own warehouses and offices stay its locations, which it already manages in its GIK organization settings; separately registered organizations, even related ones, join an ordinary Partner Network.

Not drawn: no location-management screen and no transfers between an organization’s own warehouses. Whether freight between an organization’s own sites differs (George Samra, 2026-10-08) stays open under spec scenario S9. Round 6 keeps the private network screens for the record.

Stakeholder review (2026-10-08): creating a Partner Network should feel as simple as creating a group: a name and an optional description, then Create network. Inviting organizations, adding an event and sharing resources come afterwards, from the network’s Overview.

Removed from Create: the initial event, the Supply plan template section and its preview cards, suggested organizations, the starter supply list and the invite-candidate summary. Nothing else about the network changes.

Stakeholder review (2026-10-08): templates move out of Create, not out of the product. Supply plan templates now start an event’s supply plan, in step 5, Events (proposed). In round 4 they carry no suggested organizations; round 3 keeps the original template behavior for comparison. No template is applied when a network is created.

Network first: the hint asks for a name that describes the group, not a specific event, so the name still fits as the network’s work continues. The description becomes About this network on the Overview (ERD round 1, networks.description).

Invite-only: stated once under the title. There is no visibility setting and no purpose or category field in this iteration.

Answered (Decisions 1 and 2): a network is created without an event and can take on several later: it is a standing group that works on many events (GIK, 2026-10-08), or none (Brian Anderson, 2026-10-10). The data model for this is ERD round 3’s draft (R2), for Mike Perry to confirm (T9).

Working decision D5: five-minute setup is a design target; nothing here measures it.

Validation: Network name is the only required field. Create network with no name keeps you on the form, marks the field and moves focus to it; the message clears as you type. The description is never required.

Description is optional: about three lines, for what brings these organizations together. It can be edited later from About this network (Edit, Network Admins only).

Round 7, creating a network (spec v0.18 in PR #198, Decision 5; GIK 2026-10-26): after naming the network, Create goes straight to Add organizations: find organizations on GIK, pick organizations from your previous networks (shown only when your organization is in another network), or invite by email address. Sending at least one invitation (spec v0.22, Decision 5) opens the network’s Overview, where Add event leads. An email invitee signs up and names its own organization (Decision 12); that sign-up and the hand-off are not drawn. ▲ Estimating default 5 (Mike Perry to confirm): the invitation is matched to the invitee’s email address when they sign up and attaches to the organization they create, with no expiry in Release 1; the prototype assumes GIK’s existing sign-up is reused.

R5 proposal (phase 2): duplicate names. now that an organization can be in several networks, a name matching one it already belongs to shows a warning under the field as you type. It never blocks Create (after R4.5’s soft hint).

R5 proposal (phase 1): Add from previous networks lists the organization’s real other networks in R5 (any it created or joined, except the one open), each with its current members. R4 drew them from fixed sample data; for Convoy of Hope the five networks are the same. Kimball Household Goods and Salvation Army now see theirs too.

Round 4, phase 2 (2026-10-09): Invite organizations is a full page, not a dialog, reached from Get your network ready and from the network’s Invite organizations action (Overview and Members). Creating a network never opens it. The page follows Create’s pattern: breadcrumb, title, a short description, sections, then the actions.

Round 4, phase 3 (2026-10-09): the two ways to find recipients share one area as tabs, Find on GIK (the default) and Invite by email, with Add from previous networks as a secondary section under the search. The Organizations to invite list stays on the right on a desktop and below on a phone, and switching tabs keeps everything selected, organizations and email addresses alike, in one list.

Layout: Send stays disabled until at least one recipient is selected; Cancel and Send sit under the Organizations to invite list.

No templates here: Supply plan templates are not offered on this page and draw no candidates. In round 4 a template only starts an event’s supply plan (step 5); organizations are found and invited here, never from a template.

Find organizations on GIK: search by name; each result shows the organization’s type and Add, or Selected once it is on the list. An organization already invited or in the network is marked and cannot be added again.

One invitation list: each organization appears once, by stable organization ID, with every source that suggested it: the template, each previous network, or “Added by you”. Every candidate not yet invited is selected unless you leave it out. A left-out organization stays out when sources change, until you add it back; the selected count is the same whatever the search or filter shows.

Round 4, phase 4 (2026-10-09): All, Non-Profits and Suppliers sit under the search. Results appear once something is typed and match the name and the chosen type together; changing the filter keeps the search text and everything already on the list. The count says how many match. No other filters (geography, resources, services) in this iteration.

R5 iteration, Government (PR 166): Government joins Non-Profit and Supplier as an organization type in the invitation search and its type filter, after the Government persona spec: the label is Government (that spec’s Decision 1 default; Government Partner is the alternative), with the same privileges as a Non-Profit. Organization type stays separate from network role and capabilities: an invited Government organization becomes a Member, and a Network Admin can make it an admin, as with any other type. Lakeview County Emergency Management is the illustrative organization from the Government persona prototype.

No matches: when nothing matches the name and type, the page says so and suggests All or Invite by email. The list on the right is unchanged.

Working internal direction (2026-10-07 internal review): select members from more than one previous network; organizations are de-duplicated by organization, so one that appears in two networks is one entry with two sources.

Previous networks add to the selection, they never invite: their organizations join the Organizations to invite list, each removable. Only member lists carry forward, never resources, needs, commitments or activity, and each organization accepts again.

Release 1 (scope line 2, GIK 2026-10-26): Add from previous networks shows only when your organization is in another network, and you pick organizations, not whole networks. ▲ Recording several source networks in the model is for Mike Perry. History (round 5): spec section 4, S7 and D19 describe starting from “a previous network’s members”, and ERD round 1 has a single created_from_network_id (D-a), recorded at creation. Choosing networks after creation, and several of them, is a proposal for Simon and Mike; the candidates it produces seed invitations only, as D-a requires.

Decision 12, answered by GIK (Release 1 scope line 2): inviting an organization that is not on GIK, by email address only. The invitee signs up, names its own organization, and the invitation attaches to it.

Same validation as round 3: an address is required and must be valid, and an email already invited to this network is refused; an email already in the selection is refused too. A valid address is added to Organizations to invite, not sent; it goes with everything else on Send.

Model R3: an email invitation has a target email and no organization; it creates no organization, membership or access. Sending is simulated.

▲ Not drawn, estimating default 5 (Mike Perry to confirm): the invitee’s sign-up and the hand-off to its new organization. The default matches the invitation to the invitee’s email address at sign-up, reusing GIK’s existing sign-up, with no expiry in Release 1. Who in the new organization accepts is still open.

Organizations to invite: every recipient once, organizations with their type and source, email invitations marked By email; a running count; remove anything before sending. An organization removed from a previous network’s list stays out, under Removed, until you add it back.

Send is the only action that invites: Send N invitations names the count. Cancel returns to the Overview, sends nothing and restores the selection to what it was when the page opened.

Working decision D11: a selection with no supplier is allowed, with a note that never asks for one.

Model R3: one invitation per organization, by stable organization ID. Gap: the page sets no role (everyone is invited as a member); expiry, resend and revoke are not drawn (T6). ▲ Open (R8): whether network invitations reuse the person-to-organization invites.

Round 4, phase 6 (2026-10-09): Send opens a confirmation instead of returning straight to the Overview, after GIK’s existing confirmation page: Invitations sent!, the number actually sent, and two next steps. View members opens Members with Pending selected; Go to Network Overview opens the Overview. Nothing redirects on its own.

Wireframe, not styling: the check is drawn in the wireframe’s greys, not GIK orange, so the page is not mistaken for the product’s visual design (wireframe standard WF1, WF28).

One submission: Send works once; a second click while sending does nothing, and an organization already invited or an email already pending is never invited twice.

Not everything sent: the page only says “Invitations sent!” when every invitation went out. Otherwise it says how many were sent, lists what wasn’t with the reason, and offers Review and retry: the invite page again with only those recipients, so nothing already sent is sent twice.

Prototype simulation: an email at a .invalid domain is the only thing that fails. How real delivery failures are detected and reported is not designed.

Round 5: this Overview is round 5’s selected dashboard, built from Option A’s cards; step 9, Overview, has its notes and examples. Notes here that describe the Overview’s layout were written for round 4’s baseline Overview; what each card does is unchanged.

Back on the Overview: no second success banner, since the confirmation already said it. The Pending invitations count is updated and Invite organizations is done in Get your network ready; Invite organizations stays in the header for more. Invitations stay Pending until each organization accepts or declines.

No templates here: Supply plan templates are not offered on this page and draw no candidates. In round 4 a template only starts an event’s supply plan (step 5); organizations are found and invited here, never from a template.

Members, Pending: View members on the confirmation opens Members with the Pending filter selected; All, Joined and Declined stay one click away. Invited organizations and the email invitation are listed as Pending, with where each came from, and are not counted as members until they accept. Accepting and declining are unchanged from round 3 (steps 4 and 6).

Working internal direction (2026-10-07 internal review): membership is managed here, not on the Overview: a member directory built for hundreds of organizations. State filters with counts (All, Joined, Pending, Declined), one search across organizations and email invitations, a compact table (organization, type, Network role, status, and for Network Admins the source and a Manage action), 25 rows at a time with Show more. Add ?fixture=large to the address for a network of about a hundred organizations.

Invitations belong here: an invitation is sent from Invite organizations and then stays Pending until the organization accepts (Joined) or declines (Declined). Pending rows show where the organization came from (template, previous network or Added by you). Invite organizations stays a separate action.

Manage → Network role: a Network Admin opens Manage on a joined organization and switches it between Member and Network Admin, with what each can do spelled out. Several organizations can be Network Admins at once. Members see the directory without these controls.

Model R3: an invitation is pending, accepted, declined or expired. Expiry is not drawn because nothing in the prototype expires (T6). Invitations carry no sent date in ERD round 1, so none is drawn.

Organizations, not people: each row is a member organization. People act on behalf of their organization; no individual is shown as a member, and no designated contacts are drawn.

First release item 8 and T6: removing a member and canceling an invitation are drawn in round 4 (from Manage on each row). Leaving a network and resending an invitation are in the spec’s scope but not drawn yet. Re-inviting a declined organization is not decided.

Pending and declined are listed for Network Admins only; a member sees joined organizations only.

Roles (Release 1, scope line 3): Network Admin and Member; a Network Admin makes or removes admins and removes members, and an organization can leave (the convener and the last admin can’t). The prototype shows several Network Admins for testing. ▲ Open: designated contacts and any finer permissions.

Two separate things: organization type (Non-Profit, Supplier) describes the organization; the Network role (Network Admin, Member) is per network and held by the organization. Either type can hold either role. “Network Admin” is used instead of “Admin” so it is not confused with an organization’s own GIK administrator.

Prototype assumption, what a Network Admin can do: invite organizations, manage membership and invitations, and manage Network roles. It is not a confirmed permission set, and resource sharing stays with each organization: a Member that manages its resources shares them; a Network Admin that doesn’t, doesn’t. A network keeps at least one Network Admin (also an assumption): demoting the last one is blocked with an explanation, and every role change asks for confirmation first.

Model R2: network_memberships carry a role of admin or member, so several organizations holding the admin role fits the model as drawn. Gap: who may change roles, and whether the convener can be demoted, are not decided; both are allowed here. “Convened by” names the creating organization, never sole owner or sole administrator.

▲ Templates (Release 1 scope, estimating default 2, pending GIK): Hurricane and Wildfire ship. General coordination loads no supply items and is proposed for removal; it stays here until GIK confirms. Templates an organization saves for itself are a separately priced option (O1) and are not shown.

Stakeholder review (2026-10-08): a Partner Network is a standing group that can coordinate around several events over time, so an event is added from the network, not chosen when it is created. Templates now set up an event, not the network.

Answered (Decision 1, GIK 2026-10-08): a network works on many events over time, so it can hold several; ERD round 3 drafts an event record per network (R2), for Mike Perry to confirm (T9).

Settled fields: Event type and Stage are two separate lists GIK staff keep in Super Admin, with no free text (Decision 29, GIK 2026-10-13); linking a GIK disaster record stays optional (Decision 2); a template is optional and belongs to the event (Decision 4).

▲ Proposed: the location or response area and the description are prototype fields; the spec’s flow does not list them.

▲ Not drawn: the spec’s flow also sets how much focus an event gets (Primary focus, Active or Watching) and lets an event be closed later (Decision 4, Brian Anderson 2026-10-11).

Round 4, phase 10 (2026-10-09): Add an event follows Create and Invite organizations: breadcrumb, title, one short line, sections, then Create event and Cancel. Only the name is required; nothing about an event is mandatory for the network.

Event name and disaster record are separate: an event is named by the network; linking a GIK disaster record is optional and suggests a template, and an event need not be a disaster (Community Support, Other).

Round 6, event type and stage (spec v0.16 Decision 29, GIK 2026-10-13): two separate fields. Type is what kind of event it is, from a fixed list: the nine major U.S. natural disaster types from Shabab Gruberg’s list, plus Community Support for work that isn’t a disaster. There is no free-text type. Stage is one of FEMA’s four phases (Mitigation, Preparedness, Response, Recovery) and is changed with Edit event as the response moves on. They replace R5’s Readiness, Response and Recovery types. Linking a GIK disaster stays optional and never sets the type. The sample events from earlier rounds take their stage from their old type and their type from what each event is.

▲ Open (Decision 29): which stage a new event starts in (the prototype presets none: Stage starts as Not set), and whether past stages are kept (no stage history is drawn).

Hurricane (Round 6 review): Tropical cyclones is shown as “Tropical cyclones (including hurricanes)” so a hurricane response finds it; the stored value stays Tropical cyclones, from Decision 29’s list. ▲ Decision for GIK: whether to add Hurricane as its own type. That changes the list GIK staff keep in Super Admin and needs GIK’s approval; it isn’t drawn.

Super Admin (separate scope, not drawn): GIK staff keep both lists in Super Admin, adding, renaming and reordering values, and the first rows ship in every environment. Templates are managed there too if template management is in the first release, which Release 1 leaves out (estimating default 10: the starting rows ship in the migration). These screens are not part of this prototype.

Round 6, event type and stage (spec v0.16 Decision 29, GIK 2026-10-13): two separate fields. Type is what kind of event it is, from a fixed list: the nine major U.S. natural disaster types from Shabab Gruberg’s list, plus Community Support for work that isn’t a disaster. There is no free-text type. Stage is one of FEMA’s four phases (Mitigation, Preparedness, Response, Recovery) and is changed with Edit event as the response moves on. They replace R5’s Readiness, Response and Recovery types. Linking a GIK disaster stays optional and never sets the type. The sample events from earlier rounds take their stage from their old type and their type from what each event is.

▲ Open (Decision 29): which stage a new event starts in (the prototype presets none: Stage starts as Not set), and whether past stages are kept (no stage history is drawn).

Hurricane (Round 6 review): Tropical cyclones is shown as “Tropical cyclones (including hurricanes)” so a hurricane response finds it; the stored value stays Tropical cyclones, from Decision 29’s list. ▲ Decision for GIK: whether to add Hurricane as its own type. That changes the list GIK staff keep in Super Admin and needs GIK’s approval; it isn’t drawn.

Super Admin (separate scope, not drawn): GIK staff keep both lists in Super Admin, adding, renaming and reordering values, and the first rows ship in every environment. Templates are managed there too if template management is in the first release, which Release 1 leaves out (estimating default 10: the starting rows ship in the migration). These screens are not part of this prototype.

No template needed: an event can be created with just its details. Create event saves it to the network, returns to the Overview with a confirmation, shows it under Event context and marks Add event done.

Round 4, phase 12 (2026-10-09): Associated disaster is a search field, not a fixed list. Focus shows recent records; typing filters by name, location and disaster type, with partial matches on every word (“flood” finds Flood records and names). Results show the name, then type · location · counties · declaration date, and scroll inside the list. Arrow keys and Enter choose; Escape or clicking away closes; the ✕ clears the link.

Prototype data: besides Hurricane Odalys, the Ohio severe storms and Tropical Storm Nolo, eight more records are illustrative, added to show search and scrolling; none is a verified GIK record.

History (round 4), superseded in round 6: No type, Disaster Response, Disaster Recovery, Emergency Preparedness, Community Support, Resource Distribution, Other, each with a short description. Optional, and choosing a disaster type never requires or picks a disaster record.

Current in round 6: Event type and Stage are two separate controlled lists (Decision 29): see Event type and Event stage in this section.

No match: “No matching disaster records found. You can create this event without linking a disaster.” Typed text is never saved as a disaster record; leaving the field restores the linked record, or none.

▲ Templates (Release 1 scope, estimating default 2, pending GIK): Hurricane and Wildfire ship. General coordination loads no supply items and is proposed for removal; it stays here until GIK confirms. Templates an organization saves for itself are a separately priced option (O1) and are not shown.

Round 4, phase 13 (2026-10-09), proposed: a Supply plan template now starts an event’s supply plan and nothing else. The preview shows the template’s purpose, its supply-type count tagged Planning only, the full starter supply list as a checklist, and a note that applying posts no needs, shares no inventory and notifies no one, and the list can be customized afterward. No suggested organizations: finding and inviting organizations stays on Invite organizations and Members.

Answered (Decision 4): a template comes after the network exists, belongs to an event and suggests no organizations (GIK, 2026-10-08; Brian Anderson, 2026-10-10). GIK found templates “very helpful” (2026-10-13).

▲ Differs from the spec’s flow: there, applying a template loads the needs common to that kind of event as drafts (D-c); here it starts a planning-only supply plan and posts no needs. Open (Decision 4): whether loaded needs are posted at once or held as drafts, which response types the first release covers (default Hurricane), and whether GIK staff manage templates in Super Admin in the first release.

Templates are back, on the event: Hurricane (10 starter supply items), Wildfire (6) and Coordination (none), with round 3’s cards, preview, Apply, Edit and Remove. Start Empty is no longer a card, since a template is optional; its data is kept. Linking Hurricane Odalys marks Hurricane as Suggested for this disaster. No supply list is added for Coordination without stakeholder confirmation.

No suggested organizations: as GIK answered for Decision 4; round 3 keeps the earlier suggested members for comparison.

▲ Templates (Release 1 scope, estimating default 2, pending GIK): Hurricane and Wildfire ship. General coordination loads no supply items and is proposed for removal; it stays here until GIK confirms. Templates an organization saves for itself are a separately priced option (O1) and are not shown.

Proposed supply plan for this event: the template’s starter items, each removable before the event is created (here, Generators and Chainsaws were removed). Remove template clears it; Edit reopens the preview; previewing another template and applying it replaces the plan.

Nothing else happens: no invitations, no notifications, no resource listings, no needs, nothing reserved, no visibility changes. The plan belongs to this event, not the whole network (T8, ERD R10 open).

Round 5: this Overview is round 5’s selected dashboard, built from Option A’s cards; step 9, Overview, has its notes and examples. Notes here that describe the Overview’s layout were written for round 4’s baseline Overview; what each card does is unchanged.

After Create event: “Event created: Hurricane Odalys.”, the event under Event context, Add event done in Get your network ready, and the other steps unchanged. Members and invitations are untouched. On the Overview, Supply plan shows the most recent event’s plan, with View event; there is no network-wide plan for a network with events.

▲ Event favorites, a UX proposal, not in spec v0.18 in PR #198 (2026-10-27): Shabab Gruberg and George Samra asked for quick access to the one or two events an organization works on when a network coordinates many. A star beside each event in Events, and on the event’s page, saves it; Events shows All events or Favorites, with counts; on the Overview, Your favorite events sits under the current event: the first two as small clickable rows (star, name, and a chevron, or a check on the current event), in the order they were starred; past two, Show N more opens a small menu of only the rest. Choosing one makes it the current event, so the map and the needs follow it. Favorites and the current event stay separate: starring never changes the current event, and the current event is kept as Decision 28 has it. In the prototype, favorites are kept per network and per organization (the organization you view as), because the prototype has no individual sign-in; a network you can’t open shows none of them. To decide: whether favorites belong to each person or to the organization (estimating default 11 makes network favorites per person). The October 26 Release 1 scope lists event bookmarks as not in Release 1.

Events tab: Overview | Events | Resources | Members. Events lists the network’s events, newest first, with type, disaster record, area, who added it and any template, and View; Network Admins can add another. No statuses, permissions or reporting in this pass.

▲ Proposed: the Overview shows the most recent event and how many there are. The spec’s flow gives each event a focus instead (Primary focus, Active or Watching, Decision 4); that is not drawn, and who sets it is not specified.

▲ Event favorites, a UX proposal, not in spec v0.18 in PR #198 (2026-10-27): Shabab Gruberg and George Samra asked for quick access to the one or two events an organization works on when a network coordinates many. A star beside each event in Events, and on the event’s page, saves it; Events shows All events or Favorites, with counts; on the Overview, Your favorite events sits under the current event: the first two as small clickable rows (star, name, and a chevron, or a check on the current event), in the order they were starred; past two, Show N more opens a small menu of only the rest. Choosing one makes it the current event, so the map and the needs follow it. Favorites and the current event stay separate: starring never changes the current event, and the current event is kept as Decision 28 has it. In the prototype, favorites are kept per network and per organization (the organization you view as), because the prototype has no individual sign-in; a network you can’t open shows none of them. To decide: whether favorites belong to each person or to the organization (estimating default 11 makes network favorites per person). The October 26 Release 1 scope lists event bookmarks as not in Release 1.

Round 7, event page (spec v0.17 Decision 28, GIK 2026-10-21): an event’s page is the network’s Overview focused on that event, inside the network: About this event (type, stage, disaster record, area, description, and who added it and when) beside its supply plan, the map of this event’s needs and the network’s shared resources, the event’s needs with progress and Respond, and activity that names the event. Post a need for this event is the header’s primary action and isn’t repeated under the needs. A need for several events shows this event’s own amount when it has one; otherwise its whole bar, said plainly, with the other events named. No per-event accounting is added. Opening an event never changes the Overview’s current event. Drawn in Option A’s visual language only.

Event detail: what was entered, which template started it, and the event’s own supply plan, marked where a Network Admin added a type. Manage edits the plan (remove, add); it never posts needs or touches inventory.

▲ Event favorites, a UX proposal, not in spec v0.18 in PR #198 (2026-10-27): Shabab Gruberg and George Samra asked for quick access to the one or two events an organization works on when a network coordinates many. A star beside each event in Events, and on the event’s page, saves it; Events shows All events or Favorites, with counts; on the Overview, Your favorite events sits under the current event: the first two as small clickable rows (star, name, and a chevron, or a check on the current event), in the order they were starred; past two, Show N more opens a small menu of only the rest. Choosing one makes it the current event, so the map and the needs follow it. Favorites and the current event stay separate: starring never changes the current event, and the current event is kept as Decision 28 has it. In the prototype, favorites are kept per network and per organization (the organization you view as), because the prototype has no individual sign-in; a network you can’t open shows none of them. To decide: whether favorites belong to each person or to the organization (estimating default 11 makes network favorites per person). The October 26 Release 1 scope lists event bookmarks as not in Release 1.

▲ Map Quick Views, refined 2026-10-27: Established (Decision 26): a need picked on the map opens in a drawer on the right over a dimmed page, with its progress, requested items, details, Respond and Open full need. UX proposals, pending review: a shared resource opens in the same drawer (availability for this network, supplier, location, category, which network it is shared with, and Open full resource, the only action: Add to cart stays on the full resource page); the selected place shows its counts and a close button, with Needs and Resources as two tabs, three compact rows each (name, organization, a small bar or the amount, a chevron; the whole row opens the Quick View) until View all; a place picked from List view replaces the list, with Back to list; and the full need or resource page offers Back to the map, which returns to the same place, zoom, filter, layers and tab. A resource opens only if it is shared with this network or is your own. Open: whether a resource Quick View should carry a direct action (Add to cart or an offer) once the cart and offer flows are confirmed for networks.

Round 7, event page (spec v0.17 Decision 28, GIK 2026-10-21): an event’s page is the network’s Overview focused on that event, inside the network: About this event (type, stage, disaster record, area, description, and who added it and when) beside its supply plan, the map of this event’s needs and the network’s shared resources, the event’s needs with progress and Respond, and activity that names the event. Post a need for this event is the header’s primary action and isn’t repeated under the needs. A need for several events shows this event’s own amount when it has one; otherwise its whole bar, said plainly, with the other events named. No per-event accounting is added. Opening an event never changes the Overview’s current event. Drawn in Option A’s visual language only.

Round 7, event page (spec v0.17 Decision 28, GIK 2026-10-21): an event’s page is the network’s Overview focused on that event, inside the network: About this event (type, stage, disaster record, area, description, and who added it and when) beside its supply plan, the map of this event’s needs and the network’s shared resources, the event’s needs with progress and Respond, and activity that names the event. Post a need for this event is the header’s primary action and isn’t repeated under the needs. A need for several events shows this event’s own amount when it has one; otherwise its whole bar, said plainly, with the other events named. No per-event accounting is added. Opening an event never changes the Overview’s current event. Drawn in Option A’s visual language only.

Round 6, event type and stage (spec v0.16 Decision 29, GIK 2026-10-13): two separate fields. Type is what kind of event it is, from a fixed list: the nine major U.S. natural disaster types from Shabab Gruberg’s list, plus Community Support for work that isn’t a disaster. There is no free-text type. Stage is one of FEMA’s four phases (Mitigation, Preparedness, Response, Recovery) and is changed with Edit event as the response moves on. They replace R5’s Readiness, Response and Recovery types. Linking a GIK disaster stays optional and never sets the type. The sample events from earlier rounds take their stage from their old type and their type from what each event is.

▲ Open (Decision 29): which stage a new event starts in (the prototype presets none: Stage starts as Not set), and whether past stages are kept (no stage history is drawn).

Hurricane (Round 6 review): Tropical cyclones is shown as “Tropical cyclones (including hurricanes)” so a hurricane response finds it; the stored value stays Tropical cyclones, from Decision 29’s list. ▲ Decision for GIK: whether to add Hurricane as its own type. That changes the list GIK staff keep in Super Admin and needs GIK’s approval; it isn’t drawn.

Super Admin (separate scope, not drawn): GIK staff keep both lists in Super Admin, adding, renaming and reordering values, and the first rows ship in every environment. Templates are managed there too if template management is in the first release, which Release 1 leaves out (estimating default 10: the starting rows ship in the migration). These screens are not part of this prototype.

Round 4, phase 24 (2026-10-12): Edit event sits at the top of the event’s page, for Network Admins. It opens the Add event fields filled in (name, type, associated disaster, area, description), with Cancel and Save changes; templates aren’t offered again and the supply plan stays under Manage on the event page. Saving returns to the event with Event updated, and the header and Overview follow when it’s the event they show. Needs related to the event keep their link.

Round 7, event page (spec v0.17 Decision 28, GIK 2026-10-21): an event’s page is the network’s Overview focused on that event, inside the network: About this event (type, stage, disaster record, area, description, and who added it and when) beside its supply plan, the map of this event’s needs and the network’s shared resources, the event’s needs with progress and Respond, and activity that names the event. Post a need for this event is the header’s primary action and isn’t repeated under the needs. A need for several events shows this event’s own amount when it has one; otherwise its whole bar, said plainly, with the other events named. No per-event accounting is added. Opening an event never changes the Overview’s current event. Drawn in Option A’s visual language only.

A member: Salvation Army sees the event’s details, Post a need for this event and View needs for this event, but no Edit event: only Network Admins edit events.

Round 7, event page (spec v0.17 Decision 28, GIK 2026-10-21): an event’s page is the network’s Overview focused on that event, inside the network: About this event (type, stage, disaster record, area, description, and who added it and when) beside its supply plan, the map of this event’s needs and the network’s shared resources, the event’s needs with progress and Respond, and activity that names the event. Post a need for this event is the header’s primary action and isn’t repeated under the needs. A need for several events shows this event’s own amount when it has one; otherwise its whole bar, said plainly, with the other events named. No per-event accounting is added. Opening an event never changes the Overview’s current event. Drawn in Option A’s visual language only.

Manage supply plan: Network Admins remove types or add their own (Box fans here, labelled Added by a Network Admin); Save changes only this event’s plan. A plan can start empty, with or without a template.

Carried over from round 3: steps 4 to 7 are unchanged from round 3. Their examples start from a network that already has an event (Hurricane Odalys) and the Hurricane template’s supply plan, as round 3 created it. In round 4 an event and its template are added from the network, in step 5, Events.

Settled (Q4 roadmap): “A network admin creates an invite-only group tied to an event.”

Working decision D3: any organization admin, Non-Profit or Supplier, and GIK staff can create a network. The 2026-10-07 review framed creation as a permissions question: what counts is the acting user’s authority, not the organization’s type. Every persona here can create, so Kimball Household Goods (a Supplier) shows the same Create network as Convoy of Hope (a Non-Profit). ▲ Open: the exact permission level; no named roles are invented.

Three different things: organization type (Non-Profit, Supplier) describes an organization; the network relationship (creator, invited, member) is per network; capabilities (create networks, invite organizations, manage members, manage and share resources) decide actions. “Convener” means the organization that created this network, never a third type.

Call to action: Create network is the primary action for anyone allowed to create. While an invitation needs an answer, Review invitation leads and Create network stays as the secondary action; once answered, Create leads again and Open network is secondary. The same for every organization type.

Settled D16 (2026-10-07, spec v0.5a): the name is Partner Networks.

Invitation needs an answer: Review invitation is the primary action and Create network the secondary one.

First release, item 9: an in-app cue for the invitation. ▲ Open (T6): notification types, expiry and email.

Working decision D9: joining commits nothing; sharing is a separate act (ontology: Network Membership “does not by itself share anything”).

Model R2, R3: accepting creates a membership with the member role. ▲ Open: who in an organization may accept on its behalf.

▲ Open: what an invitee may see before accepting. Drawn per round one’s proposal: no roster, invitees, resources or needs.

Settled (Q4 roadmap): “suppliers can make inventory available only to that network.” That happens after joining.

Round 5: this Overview is round 5’s selected dashboard, built from Option A’s cards; step 9, Overview, has its notes and examples. Notes here that describe the Overview’s layout were written for round 4’s baseline Overview; what each card does is unchanged.

Working internal direction (2026-10-07 internal review): the Overview answers what is happening in the network now, what is being coordinated, and what the viewer can do next. Member and invitation management live on Members.

Top of the Overview: the network’s status as KPI cards first (member organizations, shared resources, open needs, and pending invitations, which only a Network Admin sees; a Member gets three), then context in two groups beneath them: Event context (the event, strongest, and its area) and Network details (who convened it, your organization with its type, and your Network role, kept as separate items). Each count is a count of prototype records and matches its list; none is a metric.

No members list on the Overview: the Members tab is the directory and the place to manage it; the Overview keeps only the member count, in the tab and the snapshot. A network with no one joined yet gets a prompt under Needs your attention.

Order of the page: status and context, then About this network (the network beside the current event notes), then a main column with what the network needs (members’ open needs, up to four in a 2 × 2 grid) and what is available (shared resources), beside a supporting column with what it is planning for (the response supply plan) and a compact activity feed (five updates, then View all). Each card keeps its natural height, so a sparse section never becomes a large empty box; on a phone the order is needs, plan, resources, activity.

Post a need sits on Members’ open needs, and in its empty state, for any organization whose acting user may post needs (a capability, never organization type; every persona here may, as a prototype assumption). It hands off to GIK’s existing need form with this network named as the context; no fields are added. Model dependency: ERD round 1 gives needs no network link (only offers and orders carry network_id, R5), so a need appears here because the posting organization is a member (D17), and it stays visible to other signed-in GIK organizations as every need is. Linking a need to a network is open.

Actions sit with what they change: Add or Manage resources in the header; Edit on About; Manage on the supply plan; View and ordering on each resource; inviting and managing organizations on Members (Invite organizations also stays in a Network Admin’s header). There is no separate quick-actions panel.

Pending invitations are reviewed from their KPI card: a Network Admin sees the count with Review, which opens Members on the Pending filter. There is no separate banner repeating the count. Members never see invitation counts or actions. A one-line prompt appears only when nothing is pending and no one has joined yet, offering Invite organizations.

Invite-only network is the network’s access model, shown as plain text with a lock under the name, never as a chip, so it is not read as a role, an organization type or a membership status.

Event as text: there is no event detail screen in the prototype, so the event name is not a link. Linking it to GIK’s disaster record is for when that screen is drawn.

Recent activity: only what the workflows already do: the network created, invitations sent and declined (Network Admins only), organizations joining, resources shared, a member’s need posted, and Network roles changed. Grouped by day; times are prototype data. No posts, comments, reactions or announcements. ▲ Open: whether GIK wants an activity view and which records carry dates (ERD round 1 gives invitations and shares none); the spec lists a widget-based dashboard as Later.

First release, item 5 and working decision D17: members, what is shared, and members’ existing open needs, filtered by membership; their audience does not change. Needs show their urgency, location, disaster tag and fulfilment as GIK needs already do.

Convened by names the organization that created the network (networks.convener_organization_id), and nothing more: not owner, not sole administrator.

▲ Decision pending, current focus: the review raised a network having a changing current focus. The Overview conveys it only with what exists (the event and its notes, open needs, shared resources, activity); no Current Focus field is added.

▲ Open (R11): whether the convener counts as a member. It is included in the member count shown here; how it is counted for the exit criteria (D14) is not decided.

Resource action, the same for every organization type: an accepted member, or the network’s creator, whose acting user can manage the organization’s resources sees Add resources, then Manage resources once it shares, in the same header position (round 4; the creating organization’s part is open, R11). Organizations with nothing in their inventory are told to add it in GIK first.

Working internal direction (2026-10-07 internal review): membership is managed here, not on the Overview: a member directory built for hundreds of organizations. State filters with counts (All, Joined, Pending, Declined), one search across organizations and email invitations, a compact table (organization, type, Network role, status, and for Network Admins the source and a Manage action), 25 rows at a time with Show more. Add ?fixture=large to the address for a network of about a hundred organizations.

Invitations belong here: an invitation is sent from Invite organizations and then stays Pending until the organization accepts (Joined) or declines (Declined). Pending rows show where the organization came from (template, previous network or Added by you). Invite organizations stays a separate action.

Manage → Network role: a Network Admin opens Manage on a joined organization and switches it between Member and Network Admin, with what each can do spelled out. Several organizations can be Network Admins at once. Members see the directory without these controls.

Model R3: an invitation is pending, accepted, declined or expired. Expiry is not drawn because nothing in the prototype expires (T6). Invitations carry no sent date in ERD round 1, so none is drawn.

Organizations, not people: each row is a member organization. People act on behalf of their organization; no individual is shown as a member, and no designated contacts are drawn.

First release item 8 and T6: removing a member and canceling an invitation are drawn in round 4 (from Manage on each row). Leaving a network and resending an invitation are in the spec’s scope but not drawn yet. Re-inviting a declined organization is not decided.

Pending and declined are listed for Network Admins only; a member sees joined organizations only.

Roles (Release 1, scope line 3): Network Admin and Member; a Network Admin makes or removes admins and removes members, and an organization can leave (the convener and the last admin can’t). The prototype shows several Network Admins for testing. ▲ Open: designated contacts and any finer permissions.

Two separate things: organization type (Non-Profit, Supplier) describes the organization; the Network role (Network Admin, Member) is per network and held by the organization. Either type can hold either role. “Network Admin” is used instead of “Admin” so it is not confused with an organization’s own GIK administrator.

Prototype assumption, what a Network Admin can do: invite organizations, manage membership and invitations, and manage Network roles. It is not a confirmed permission set, and resource sharing stays with each organization: a Member that manages its resources shares them; a Network Admin that doesn’t, doesn’t. A network keeps at least one Network Admin (also an assumption): demoting the last one is blocked with an explanation, and every role change asks for confirmation first.

Model R2: network_memberships carry a role of admin or member, so several organizations holding the admin role fits the model as drawn. Gap: who may change roles, and whether the convener can be demoted, are not decided; both are allowed here. “Convened by” names the creating organization, never sole owner or sole administrator.

Member view: a member sees joined organizations only; pending and declined invitations are the admin’s.

After answering: Kimball Household Goods (a Supplier) now sees Create network as the primary action again and Open network as secondary, the same hierarchy a Non-Profit sees.

Settled (Q4 roadmap): “A network admin creates an invite-only group tied to an event.”

Working decision D3: any organization admin, Non-Profit or Supplier, and GIK staff can create a network. The 2026-10-07 review framed creation as a permissions question: what counts is the acting user’s authority, not the organization’s type. Every persona here can create, so Kimball Household Goods (a Supplier) shows the same Create network as Convoy of Hope (a Non-Profit). ▲ Open: the exact permission level; no named roles are invented.

Three different things: organization type (Non-Profit, Supplier) describes an organization; the network relationship (creator, invited, member) is per network; capabilities (create networks, invite organizations, manage members, manage and share resources) decide actions. “Convener” means the organization that created this network, never a third type.

Call to action: Create network is the primary action for anyone allowed to create. While an invitation needs an answer, Review invitation leads and Create network stays as the secondary action; once answered, Create leads again and Open network is secondary. The same for every organization type.

Settled D16 (2026-10-07, spec v0.5a): the name is Partner Networks.

Model R3: the invitation becomes declined and no membership is created. Not decided anywhere: whether the convener can invite again.

Round 5, Manage resources (PR 166): a network’s Resources tab, and every Add resources action, now open Manage resources for that network (Networks › network › Resources › Manage resources), with this network preselected and three tabs: Add from your inventory (search, category, availability and sharing filters, selection that stays across filters and pages, then Choose networks and method, then Review and share, returning to the Resources tab), Shared with this network (change a quantity, switch to shared availability, stop sharing) and Create new resource (unchanged). Notes below that describe the card picker and its review are round 4’s.

Stakeholder review (2026-10-08): each organization controls its own resources and decides which Partner Networks can access them. Sharing is always a separate, intentional step; creating or joining a network shares nothing.

Round 4, phase 15 (2026-10-09): Add resources is a page: breadcrumb, Share resources with this network, the organization sharing, and the line “Only members of [network] can see resources you choose to share here.” Each resource shows its image, quantity, location and where it is visible now; search and a category filter narrow the list; nothing is selected for you.

Three visibility levels, kept apart: Private (your organization), Partner (the Partner Networks you choose, one at a time) and Public (the GIK Marketplace). Sharing here adds this network only: it never shares with your other networks and never changes a resource’s other visibility. Model R4: a Network Resource Share, recorded apart from the resource’s own visibility. ▲ Open (T2, R7): a share record or the unfinished partners visibility value.

Prototype data: the fully populated Gulf Coast Response Partners network, the same records as Overview’s Fully populated example, seen by Kimball Household Goods as a member. Kimball shares five resources with it: its bottled water (also shared with Hawaii Island Relief Partners), its tarps, and three illustrative records (flashlights, mold remover and bottled water). Its cleaning kits and the rest of its 2,406-item inventory are not shared.

Round 5, Manage resources (PR 166): a network’s Resources tab, and every Add resources action, now open Manage resources for that network (Networks › network › Resources › Manage resources), with this network preselected and three tabs: Add from your inventory (search, category, availability and sharing filters, selection that stays across filters and pages, then Choose networks and method, then Review and share, returning to the Resources tab), Shared with this network (change a quantity, switch to shared availability, stop sharing) and Create new resource (unchanged). Notes below that describe the card picker and its review are round 4’s.

Round 4, phase 17 (2026-10-09): Convoy of Hope created this network and is its Network Admin, and shares its own resources the same way Kimball Household Goods does: select, review, Share. Nothing was shared when the network was created.

▲ Proposed round 4 permission, pending stakeholder confirmation: any organization whose acting user can manage its inventory may share its resources, whether it created the network or joined it, Supplier or Non-Profit. Creating a network shares nothing and restricts nothing. Network Admin is about the network (members, invitations, roles), not resources: it grants no control over another organization’s resources. Whether organization type should restrict sharing is for GIK; the creating organization’s part was open (R11).

Prototype data: Convoy’s emergency food boxes are public on the Marketplace, its flood cleanup buckets are shared with Iowa River Valley Partners, and its water filtration kits are private.

Round 5, Manage resources (PR 166): a network’s Resources tab, and every Add resources action, now open Manage resources for that network (Networks › network › Resources › Manage resources), with this network preselected and three tabs: Add from your inventory (search, category, availability and sharing filters, selection that stays across filters and pages, then Choose networks and method, then Review and share, returning to the Resources tab), Shared with this network (change a quantity, switch to shared availability, stop sharing) and Create new resource (unchanged). Notes below that describe the card picker and its review are round 4’s.

Same review: Convoy of Hope’s two resources, its name as the owner, this network as the only destination; Share 2 resources is the only action that shares.

Ownership on Resources: Convoy of Hope’s food boxes and cleanup buckets show Convoy of Hope as the owner, marked Your resource with Manage. Every other organization’s resource has View and Add to cart only, although Convoy is a Network Admin: network administration and resource ownership are separate.

▲ Proposed round 4 permission, pending stakeholder confirmation: any organization whose acting user can manage its inventory may share its resources, whether it created the network or joined it, Supplier or Non-Profit. Creating a network shares nothing and restricts nothing. Network Admin is about the network (members, invitations, roles), not resources: it grants no control over another organization’s resources. Whether organization type should restrict sharing is for GIK; the creating organization’s part was open (R11).

Round 5, Manage resources (PR 166): a network’s Resources tab, and every Add resources action, now open Manage resources for that network (Networks › network › Resources › Manage resources), with this network preselected and three tabs: Add from your inventory (search, category, availability and sharing filters, selection that stays across filters and pages, then Choose networks and method, then Review and share, returning to the Resources tab), Shared with this network (change a quantity, switch to shared availability, stop sharing) and Create new resource (unchanged). Notes below that describe the card picker and its review are round 4’s.

The creator stops sharing its own: Stop sharing on Convoy’s flood cleanup buckets; the confirmation notes they stay shared with Iowa River Valley Partners. Convoy has no Stop sharing on other organizations’ resources.

Round 5, Manage resources (PR 166): a network’s Resources tab, and every Add resources action, now open Manage resources for that network (Networks › network › Resources › Manage resources), with this network preselected and three tabs: Add from your inventory (search, category, availability and sharing filters, selection that stays across filters and pages, then Choose networks and method, then Review and share, returning to the Resources tab), Shared with this network (change a quantity, switch to shared availability, stop sharing) and Create new resource (unchanged). Notes below that describe the card picker and its review are round 4’s.

No resources yet: this example hides Convoy of Hope’s inventory to show the empty state: an organization that can manage resources but has none in its inventory is offered Create new resource on this page. No separate inventory is built for networks.

▲ Proposed round 4 permission, pending stakeholder confirmation: any organization whose acting user can manage its inventory may share its resources, whether it created the network or joined it, Supplier or Non-Profit. Creating a network shares nothing and restricts nothing. Network Admin is about the network (members, invitations, roles), not resources: it grants no control over another organization’s resources. Whether organization type should restrict sharing is for GIK; the creating organization’s part was open (R11).

Round 5, Manage resources (PR 166): a network’s Resources tab, and every Add resources action, now open Manage resources for that network (Networks › network › Resources › Manage resources), with this network preselected and three tabs: Add from your inventory (search, category, availability and sharing filters, selection that stays across filters and pages, then Choose networks and method, then Review and share, returning to the Resources tab), Shared with this network (change a quantity, switch to shared availability, stop sharing) and Create new resource (unchanged). Notes below that describe the card picker and its review are round 4’s.

Select: tick one or more; the bar counts the selection. Selecting doesn’t share. Review selection is disabled until something is selected; the selection carries to the review.

Round 5, Manage resources (PR 166): a network’s Resources tab, and every Add resources action, now open Manage resources for that network (Networks › network › Resources › Manage resources), with this network preselected and three tabs: Add from your inventory (search, category, availability and sharing filters, selection that stays across filters and pages, then Choose networks and method, then Review and share, returning to the Resources tab), Shared with this network (change a quantity, switch to shared availability, stop sharing) and Create new resource (unchanged). Notes below that describe the card picker and its review are round 4’s.

Review: each selected resource with its image, quantity and owning organization, the destination network, and the count. Remove anything before sharing. Share 2 resources is the only action that shares; Cancel clears the selection and returns to the Overview.

Ownership stays: the resource stays with its organization; nothing is reserved and no other visibility changes.

Round 5, Manage resources (PR 166): a network’s Resources tab, and every Add resources action, now open Manage resources for that network (Networks › network › Resources › Manage resources), with this network preselected and three tabs: Add from your inventory (search, category, availability and sharing filters, selection that stays across filters and pages, then Choose networks and method, then Review and share, returning to the Resources tab), Shared with this network (change a quantity, switch to shared availability, stop sharing) and Create new resource (unchanged). Notes below that describe the card picker and its review are round 4’s.

First release, item 6 and Before release (T5, D-c): the member view shows the Overview as members will see it, with the selected resources; shared inventory is visible only to members, enforced by the platform.

Round 5, Manage resources (PR 166): a network’s Resources tab, and every Add resources action, now open Manage resources for that network (Networks › network › Resources › Manage resources), with this network preselected and three tabs: Add from your inventory (search, category, availability and sharing filters, selection that stays across filters and pages, then Choose networks and method, then Review and share, returning to the Resources tab), Shared with this network (change a quantity, switch to shared availability, stop sharing) and Create new resource (unchanged). Notes below that describe the card picker and its review are round 4’s.

Round 4, phase 15 (2026-10-09): Share opens Resources shared!, in the Invitations sent pattern: the count and the network, then View shared resources and Go to Network Overview. The Overview’s Shared resources count and the checklist’s Add resources step update; members and invitations don’t change.

In the network: the shared resources appear on the Resources tab with their organization. Your own are marked Your resource with Manage, which opens Add resources; another organization’s can be viewed and ordered, never managed.

Ordering follows ownership, not type: any organization with access to the network, Non-Profit or Supplier, can view and order a resource another organization shared. Its own shared resources stay visible, marked Your resource, with Manage resources where it manages them, and can never be ordered: not from the Overview, not from the resource detail, and an own resource is removed from the cart if it gets there another way. The Marketplace and network-filtered results follow the same rule when that pass is drawn; checkout here is the hand-off.

Round 5, Manage resources (PR 166): a network’s Resources tab, and every Add resources action, now open Manage resources for that network (Networks › network › Resources › Manage resources), with this network preselected and three tabs: Add from your inventory (search, category, availability and sharing filters, selection that stays across filters and pages, then Choose networks and method, then Review and share, returning to the Resources tab), Shared with this network (change a quantity, switch to shared availability, stop sharing) and Create new resource (unchanged). Notes below that describe the card picker and its review are round 4’s.

Stop sharing: only the organization that owns a resource can stop sharing it. The confirmation says members of this network won’t see it, it stays in your inventory, where else it remains visible, and that orders already placed are kept. Network Admins of other organizations get no control over it.

Gap: stopping a share is not in the spec or model yet; what happens to an open cart line is the existing cart rule (it drops).

Round 5, Manage resources (PR 166): a network’s Resources tab, and every Add resources action, now open Manage resources for that network (Networks › network › Resources › Manage resources), with this network preselected and three tabs: Add from your inventory (search, category, availability and sharing filters, selection that stays across filters and pages, then Choose networks and method, then Review and share, returning to the Resources tab), Shared with this network (change a quantity, switch to shared availability, stop sharing) and Create new resource (unchanged). Notes below that describe the card picker and its review are round 4’s.

Three visibility levels, kept apart: Private (your organization), Partner (the Partner Networks you choose, one at a time) and Public (the GIK Marketplace). Sharing here adds this network only: it never shares with your other networks and never changes a resource’s other visibility. Model R4: a Network Resource Share, recorded apart from the resource’s own visibility. ▲ Open (T2, R7): a share record or the unfinished partners visibility value.

This network only: after sharing bottled water and tarps here, bottled water is still also shared with Hawaii Island Relief Partners and tarps are still public; cleaning kits stay private. Nothing was added to Hawaii Island Relief Partners or Iowa River Valley Partners.

▲ Decision pending, events: sharing is a network-level visibility choice. It is not tied to an event or its supply plan; allocating resources to a specific event is not designed.

Round 5, Manage resources (PR 166): a network’s Resources tab, and every Add resources action, now open Manage resources for that network (Networks › network › Resources › Manage resources), with this network preselected and three tabs: Add from your inventory (search, category, availability and sharing filters, selection that stays across filters and pages, then Choose networks and method, then Review and share, returning to the Resources tab), Shared with this network (change a quantity, switch to shared availability, stop sharing) and Create new resource (unchanged). Notes below that describe the card picker and its review are round 4’s.

Same flow, Non-Profit: Salvation Army shares the same way Kimball Household Goods (a Supplier) does: capability decides, not type.

▲ Proposed round 4 permission, pending stakeholder confirmation: any organization whose acting user can manage its inventory may share its resources, whether it created the network or joined it, Supplier or Non-Profit. Creating a network shares nothing and restricts nothing. Network Admin is about the network (members, invitations, roles), not resources: it grants no control over another organization’s resources. Whether organization type should restrict sharing is for GIK; the creating organization’s part was open (R11).

Round 4, phase 21 (2026-10-09): Create new resource follows GIK’s What do you have? form on the same page: Manual | Spreadsheet above the item card; What are you sharing? (required) and Category (No category); Quantity & Unit grouped, starting at 1 Pieces; a full-width dashed Add another item; Optional details collapsed; then Who can see your resources?. The page reads “Choose existing resources or create new ones to share with [network]” and Creating as [organization]. Switching tabs keeps the draft; Cancel with a draft asks before discarding.

Source: the GIK Marketplace What do you have? form (screenshot supplied 2026-10-09); categories and units reuse GIK’s lists. Spreadsheet is GIK’s existing import, explained but not drawn.

▲ Proposed visibility model, pending stakeholder and technical confirmation: Marketplace visibility (GIK’s Private | Public) and Share with Partner Networks are separate. A resource can be Private and shared with networks, Public and shared with networks, or Private with no sharing. Changing Marketplace visibility never removes a network; removing one network leaves the others. Replaces phase 19’s single Private / Partner Network / Public choice, which implied sharing with a network removed Public.

Defaults: Marketplace visibility starts Private and this network is preselected under Share with Partner Networks, as an editable draft. No other network is selected and nothing becomes Public. The visibility preview sums it up: Marketplace: Private · Shared with Gulf Coast Response Partners.

Owned by the organization: each item becomes a resource in Kimball Household Goods’ inventory; the network is a destination, never the owner.

Multiple items: each item is its own card (Item 1, Item 2) with Remove; Add another item adds a card starting at 1 Pieces. Each becomes its own resource; description, pickup location and visibility apply to all.

Optional details: collapsed by default, with a one-line summary of what’s inside (Description added · Pickup: Kimball Household Goods Warehouse). Closing it keeps the values. Description grows as you type.

Pickup location: GIK’s location pattern, as on Post a need: one field lists the organization’s saved locations on focus, or type to search addresses; a chosen location shows with Change. No new address or warehouse data is required; it stays optional.

Prototype data: Kimball Household Goods’ saved warehouse location was added to the sample.

Private, no network sharing: removing this network’s chip leaves nothing selected. The resource will be saved to the inventory only; the review says Save resource privately.

Public, no network sharing: available through the GIK Marketplace, not added to any Partner Network. The review says Publish resource.

Select Partner Networks: a compact control replaces the always-open checkbox list. Selected networks show as removable chips; the button opens a searchable list of only the networks Kimball Household Goods belongs to (this network, Hawaii Island Relief Partners and Oklahoma Response Coalition), with a selected count and Done. Closing keeps the selection. Networks Kimball has no relationship with aren’t listed.

Several networks: three selected. Each network is a separate share: sharing with one never adds another.

▲ Proposed visibility model, pending stakeholder and technical confirmation: Marketplace visibility (GIK’s Private | Public) and Share with Partner Networks are separate. A resource can be Private and shared with networks, Public and shared with networks, or Private with no sharing. Changing Marketplace visibility never removes a network; removing one network leaves the others. Replaces phase 19’s single Private / Partner Network / Public choice, which implied sharing with a network removed Public.

Private and shared with networks: not listed publicly, but members of Gulf Coast Response Partners and Hawaii Island Relief Partners can access it. Switching Marketplace visibility to Public and back keeps these networks.

Public and shared with a network: listed on the GIK Marketplace and also shared with this network, so it shows in the network’s Resources. Changing to Public doesn’t remove the network.

Validation: What are you sharing? and Quantity are required on every item card; errors show under each field and focus moves to the first. Remove an extra item rather than leave it blank.

Spreadsheet: GIK’s existing spreadsheet import, shown above the item card as on the Marketplace. It isn’t drawn in this prototype, and no new import workflow is proposed.

Review: each resource with quantity, unit and category; the owner, description and pickup location; Marketplace visibility and Partner Networks; and a Visible after you confirm list (the inventory, each selected network, and the Marketplace if Public). Edit keeps everything.

Outcome-specific button: Create and share resources when any network is selected; Save resources privately when Private with no networks; Publish resources when Public with no networks.

Public and a network: the list shows the inventory, Gulf Coast Response Partners and the GIK Marketplace; the button is Create and share resources.

Resources created and shared!: “Your resources have been added to your organization’s inventory and shared with the selected Partner Networks,” naming the networks, with View shared resources and Go to Network Overview. Counts and the checklist update. Created once only.

In the network: the new mattresses show on Resources, owned by Kimball Household Goods, marked Your resource with Manage; other members see View and Add to cart.

Round 5, Manage resources (PR 166): a network’s Resources tab, and every Add resources action, now open Manage resources for that network (Networks › network › Resources › Manage resources), with this network preselected and three tabs: Add from your inventory (search, category, availability and sharing filters, selection that stays across filters and pages, then Choose networks and method, then Review and share, returning to the Resources tab), Shared with this network (change a quantity, switch to shared availability, stop sharing) and Create new resource (unchanged). Notes below that describe the card picker and its review are round 4’s.

In the inventory: Add resources lists the new resource (marked New) under Shared with this network, with Stop sharing. Stopping keeps it in the inventory and leaves its Marketplace visibility and other networks alone; orders already placed are kept.

Save privately: Private with no networks: the list shows only the inventory and the button says Save resource privately.

Saved privately: a distinct confirmation that doesn’t claim any sharing; the resource can be shared from Add resources later.

Published: Public with no networks: Resource published, “published to the GIK Marketplace. It isn’t shared with any Partner Network,” with Back to Add resources. Nothing is added to this network.

No inventory, create one: the empty state now offers Create new resource on the same page, instead of only pointing to GIK. Convoy of Hope’s inventory is hidden here to show it.

The creator too: Convoy of Hope, the network’s creator and Network Admin, creates and shares a new resource the same way, picking from its saved locations; it’s Convoy’s, not the network’s. Convoy can choose from all five of its earlier networks.

▲ Proposed round 4 permission, pending stakeholder confirmation: any organization whose acting user can manage its inventory may share its resources, whether it created the network or joined it, Supplier or Non-Profit. Creating a network shares nothing and restricts nothing. Network Admin is about the network (members, invitations, roles), not resources: it grants no control over another organization’s resources. Whether organization type should restrict sharing is for GIK; the creating organization’s part was open (R11).

Round 5, Manage resources (PR 166): a network’s Resources tab, and every Add resources action, now open Manage resources for that network (Networks › network › Resources › Manage resources), with this network preselected and three tabs: Add from your inventory (search, category, availability and sharing filters, selection that stays across filters and pages, then Choose networks and method, then Review and share, returning to the Resources tab), Shared with this network (change a quantity, switch to shared availability, stop sharing) and Create new resource (unchanged). Notes below that describe the card picker and its review are round 4’s.

Can’t manage resources: when the acting user can’t manage the organization’s resources, Add resources explains why and how to get access, and shows no resources. Network Admin doesn’t include it.

▲ Proposed round 4 permission, pending stakeholder confirmation: any organization whose acting user can manage its inventory may share its resources, whether it created the network or joined it, Supplier or Non-Profit. Creating a network shares nothing and restricts nothing. Network Admin is about the network (members, invitations, roles), not resources: it grants no control over another organization’s resources. Whether organization type should restrict sharing is for GIK; the creating organization’s part was open (R11).

Settled (Q4 roadmap): “A network admin creates an invite-only group tied to an event.”

Working decision D3: any organization admin, Non-Profit or Supplier, and GIK staff can create a network. The 2026-10-07 review framed creation as a permissions question: what counts is the acting user’s authority, not the organization’s type. Every persona here can create, so Kimball Household Goods (a Supplier) shows the same Create network as Convoy of Hope (a Non-Profit). ▲ Open: the exact permission level; no named roles are invented.

Three different things: organization type (Non-Profit, Supplier) describes an organization; the network relationship (creator, invited, member) is per network; capabilities (create networks, invite organizations, manage members, manage and share resources) decide actions. “Convener” means the organization that created this network, never a third type.

Call to action: Create network is the primary action for anyone allowed to create. While an invitation needs an answer, Review invitation leads and Create network stays as the secondary action; once answered, Create leads again and Open network is secondary. The same for every organization type.

Settled D16 (2026-10-07, spec v0.5a): the name is Partner Networks.

Working decision D9: joining commits nothing; sharing is a separate act (ontology: Network Membership “does not by itself share anything”).

Model R2, R3: accepting creates a membership with the member role. ▲ Open: who in an organization may accept on its behalf.

▲ Open: what an invitee may see before accepting. Drawn per round one’s proposal: no roster, invitees, resources or needs.

Working decision D17: members’ existing open needs appear on the network page without changing their audience.

Capability, not type: because Salvation Army has eligible resources and its acting user can manage them, the invitation says it can choose what to share after joining, as Kimball’s does.

Model R3: declined; no membership. Re-invitation is not decided.

Before release (T5, D-c): an organization that was never invited sees no network and is told it isn’t available if it follows a link. The platform, not the screen, must enforce this.

What we heard (2026-10-27 Dev Sync and debrief): clearer next actions at the top of the Overview; less reading; more visual guidance and color; less emphasis on Network info; and a direction that still reads as GIK, consistent with the rest of the platform. This page answers that for the Overview only.

Confirmed by GIK (Decision 30, spec v0.21, 2026-10-30): the top of the Overview has two parts. Getting started walks each organization through its first actions in order (add an event, add resources, then respond to a need) and goes once they are done (Shabab Gruberg, 15:07). The standing call to action stays above the map on a populated network (14:10, 14:17): one big orange button chosen by the organization’s type, Share resource for a supplier and Post a need for a nonprofit, beside More actions. Being a Network Admin doesn’t change it. Share resource is emphasized, and a supplier never sees Post a need. Network information and any access label stay out of the top, so the header no longer says Invite-only network; who can see the network is unchanged.

▲ Setup, status in spec v0.21: Respond is back as the last step of Getting started (spec v0.21 keeps GIK’s 2026-10-27 sequence). This supersedes R7.1’s 2026-10-29 proposal to drop it, which stays open for GIK. The spec reads Respond as a supplier’s last step, while R7.1, as before, offers it to every member who can respond: unresolved. Still R7.1 proposals for GIK to confirm: Not now, Hidden steps and Hide setup. Closed by spec v0.22 (Decision 5): a partner network needs at least one other organization at creation, so the Invite organizations step for a convener who skipped inviting is gone; the initial examples all start with invitations sent (pending counts). Closed by check 6: R7.1’s third proposal, leaving the actions only in More actions once setup is done; the standing call to action replaces it. Invitations sent is still read from the network’s own invitation records, and the step completes only after a real send.

Defaults in spec v0.21, not confirmed: Getting started is tracked for each organization in each network; once it is done, Add event stays available to Network Admins in a smaller form (here, in More actions). Open: whether a nonprofit’s main action is Post a need with Share resource beside it (the spec’s default is yes); R7.1 shows Post a need alone, as asked for in this pass, and Share resource stays in More actions and Getting started. Check 1 (nothing at the top competes with the next action): while Getting started shows, its orange Up next tile and the orange standing button are both visible; flagged for review.

UX proposals (Augusto, round 7.1, after Decision 32; not yet approved): GIK’s colors and type faces on the product screen only. Get started shows the actions still to do as one row of equal tiles in Decision 30’s order, without step numbers; the first is marked Up next and is orange, and the others stay open (nothing is locked). Done steps move to a compact Done group beneath, each still opening its action. Each tile’s help shows on hover and keyboard focus, and from an info button on touch screens. Pending invitations sit beside the admin’s Invite organizations link. The four figures show icon, count and label only. Network info is a collapsed section at the end of the Overview (GIK named an info button, a settings tab or the bottom of Members; this keeps it on the Overview, quiet and one click away). Urgency and progress keep their words beside their color.

▲ Demonstration only: a step is done when the organization has the matching record in the sample data (an event, sent invitations, a shared resource, a posted need). The prototype keeps no record of a response, so Respond is done only through a demonstration fixture (r71Responded) set in the three populated examples; clicking it, sharing or opening a need never completes it. Where a network has no open need an organization can answer (the setup examples), Respond still shows as a suggestion with nothing to answer yet; whether to suggest it then is unresolved. The examples are read-only, so the invitation flow is tried in your own session. Nothing leaves the Overview in this version except the invitation flow: the tabs, the setup actions, the standing call to action, Respond and Give, need and event pages, Open full need and More actions items show a short notice that they aren’t built out yet. The map, its Quick Views, the event selector, favorites, View all activity and Edit for Network info work in place. Nothing here is backend behavior.

Needs, confirmed (Decision 22, v0.19): three stages, completed (orders delivered), being fulfilled (orders placed, not yet delivered) and still needed; carts and shared inventory never count. A need’s card has one bar that counts quantities one to one across units, for now (“just says 250 items”, George Samra, 2026-10-27). A need’s details show a bar for each requested item in its own unit, the first five then Show more. Orders in another unit show beside the bar and are never added in. Respond stays at the bottom of the card.

Needs, UX presentation (Augusto, round 7.1; not yet approved): the Overview card shows the title, the organization and urgency, one bar, one line (for example 250 of 400 cases still needed) and Respond; the fulfillment key is hidden by default everywhere in round 7.1: a small info button after each bar’s line (labelled Explain fulfillment progress) shows Completed, Being fulfilled and Still needed beside their colors, with that bar’s exact quantities, on hover, keyboard focus or tap; there are no permanent legends or breakdown lines. A need in more than one unit reads in items, never in one unit’s name, with an N units control that says what was counted. The Quick View combines the items and their progress into one Requested items section, each item named above its bar with its unit, its remaining quantity and its requested total; it starts with five items (George’s suggestion, not an approved limit) and Show all. Address, description and the fuller breakdown stay on the need’s detail page in round 7 (not reachable from this version). The secondary setup actions are neutral, and Market Blue is kept for structure.

Give (spec v0.21, section 4 item 5; Decision 31): on an open need a supplier can respond to, the card’s button says Give and is its main action, in R7.1’s orange primary style, still at the bottom of the card. The Quick View says Give too. A nonprofit keeps Respond, and an organization’s own need shows Your need. The flow is round 7’s Respond. The give builds on Offer Without a Resource (GIK-336); its first screen, photos and repeat-offer warning stay open (Decision 31 a to c), and nothing here settles them.

▲ Data limitation: the prototype records progress for each need as a whole, not by item. Where a need has several items and some orders, the Quick View shows one Overall progress block and lists the items without bars rather than splitting the total (its info popover says progress is recorded for the whole need); per-item bars appear only where they are true (a single-item need, or one with no orders yet, or one whose orders are all delivered). Whether a network need holds several items, each with its own amount and unit, is for the data model review (GIK-624).

▲ Demonstration data: one need with seven items in five units and no orders yet (Cleanup supplies for flooded homes, Salvation Army) is added to the three populated examples so Show all and a mixed-unit Quick View can be reviewed; the prototype’s own needs have at most three items. It adds one to those examples’ open needs.

Deferring setup guidance (UX proposal, 2026-10-28; not in v0.19): Not now under each suggestion moves it to a compact Hidden steps (N) button after the done checks; it opens a small menu under the button, one row per step (the name, then Show again), and choosing a row brings that step back in its usual place; Up next moves to the next suggestion. Hide setup beside the heading hides the whole guide; More actions then offers Show setup guide, which brings it back as it was. If every remaining suggestion is hidden, the guide collapses the same way. Show setup guide then reopens it with those steps still hidden: the area shows Every step is hidden and the Hidden steps menu, and a step comes back only through Show again (2026-10-30; it used to bring them all back). Hiding steps or the guide changes the guidance only: nothing is marked done, completion is still read from the records, and every action stays where it always is (More actions, the needs, the map), with the same permissions. Each change moves focus to a nearby control and is announced. Each review example opens with the guide in its default state; its choices last for that visit only. In your live session they are kept in this browser tab for the organization viewing, in that network (the prototype identifies organizations, not individual people). No backend tracking is drawn.

Event Favorites (round 7 UX proposal; not a v0.19 requirement): the populated examples show round 7’s favorites with demonstration favorites from the network’s own events (four for the nonprofit admin, two for the nonprofit member, one for the supplier). In R7.1 the Current Event card shows the selected event’s title with its own favorite star beside it, stage and location, then a compact Change event button (when the network has more than one event) that opens one picker. It opens on Favorites, every favorite with a check on the current one, then Browse all N events, which switches the same picker to every event and back; with no favorites it opens on all events. The star beside the title is its own button, so favoriting or unfavoriting the selected event never opens the picker, and a selected event that isn’t a favorite is not added to Favorites. Choosing an event updates stage and location, the open-needs count and View event, closes the picker and returns focus to Change event. The setup examples have no favorites, so their picker opens on all events; favorites are never a setup step. They are kept as round 7 keeps them, for the organization viewing in this network; whether favorites belong to a person or an organization is unresolved, and no backend storage is drawn.

Tab badges (UX proposal, not in v0.19): the network tabs no longer show standing counts. A tab shows a badge only for items someone else added that this organization hasn’t viewed yet, such as members another admin just added, and opening the tab clears it. The populated nonprofit Network Admin example shows 2 new on Members as demonstration data; nothing is counted live, and what counts as viewed (per person or per organization) is to decide.

Deferred, not in this pass: smaller round 7.1 flow corrections, template changes and the Decision 22 calculation changes. Other screens aren’t part of this version; round 7 has them.

Colors and contrast (2026-10-28): GIK’s supplied palette: Vivid Orange #ED5424, Market Blue, Dutch Blue, Light Gray and Supply White, on a #F5F5F5 page, with Nexus Black text, GIK’s badge colors for success, urgency and priority, and the map’s colors from GIK’s product map. No brand value is changed. White text on Vivid Orange is 3.56:1, so it is used only at large size, on the step in progress; smaller primary actions are outlined in Vivid Orange with Market Blue text, and small text on orange is Nexus Black. Text on Dutch Blue is Market Blue. GIK’s own Pending badge amber is darkened here for contrast.

This state (1, initial setup, the normal path; demonstration data): Convoy of Hope, a nonprofit, has just created the network and is its Network Admin, and sent invitations while creating it: five organizations and one email address, all still pending (demonstration invitations from round 7’s sample data, not real ones). Getting started shows Add event (Up next, orange), Post a need, Share resource and Respond (a nonprofit posts before it shares, 2026-11-03); below the cards, Invite organizations (an outlined button) sits beside 6 pending; sending during creation counts as done, so there is no Invitations sent badge. While Getting started shows, Up next is the only orange action, so the header has none; hide setup and Add event appears beside More actions. The figures, map and cards appear once there is something to show.

What we heard (2026-10-27 Dev Sync and debrief): clearer next actions at the top of the Overview; less reading; more visual guidance and color; less emphasis on Network info; and a direction that still reads as GIK, consistent with the rest of the platform. This page answers that for the Overview only.

Confirmed by GIK (Decision 30, spec v0.21, 2026-10-30): the top of the Overview has two parts. Getting started walks each organization through its first actions in order (add an event, add resources, then respond to a need) and goes once they are done (Shabab Gruberg, 15:07). The standing call to action stays above the map on a populated network (14:10, 14:17): one big orange button chosen by the organization’s type, Share resource for a supplier and Post a need for a nonprofit, beside More actions. Being a Network Admin doesn’t change it. Share resource is emphasized, and a supplier never sees Post a need. Network information and any access label stay out of the top, so the header no longer says Invite-only network; who can see the network is unchanged.

▲ Setup, status in spec v0.21: Respond is back as the last step of Getting started (spec v0.21 keeps GIK’s 2026-10-27 sequence). This supersedes R7.1’s 2026-10-29 proposal to drop it, which stays open for GIK. The spec reads Respond as a supplier’s last step, while R7.1, as before, offers it to every member who can respond: unresolved. Still R7.1 proposals for GIK to confirm: Not now, Hidden steps and Hide setup. Closed by spec v0.22 (Decision 5): a partner network needs at least one other organization at creation, so the Invite organizations step for a convener who skipped inviting is gone; the initial examples all start with invitations sent (pending counts). Closed by check 6: R7.1’s third proposal, leaving the actions only in More actions once setup is done; the standing call to action replaces it. Invitations sent is still read from the network’s own invitation records, and the step completes only after a real send.

Defaults in spec v0.21, not confirmed: Getting started is tracked for each organization in each network; once it is done, Add event stays available to Network Admins in a smaller form (here, in More actions). Open: whether a nonprofit’s main action is Post a need with Share resource beside it (the spec’s default is yes); R7.1 shows Post a need alone, as asked for in this pass, and Share resource stays in More actions and Getting started. Check 1 (nothing at the top competes with the next action): while Getting started shows, its orange Up next tile and the orange standing button are both visible; flagged for review.

UX proposals (Augusto, round 7.1, after Decision 32; not yet approved): GIK’s colors and type faces on the product screen only. Get started shows the actions still to do as one row of equal tiles in Decision 30’s order, without step numbers; the first is marked Up next and is orange, and the others stay open (nothing is locked). Done steps move to a compact Done group beneath, each still opening its action. Each tile’s help shows on hover and keyboard focus, and from an info button on touch screens. Pending invitations sit beside the admin’s Invite organizations link. The four figures show icon, count and label only. Network info is a collapsed section at the end of the Overview (GIK named an info button, a settings tab or the bottom of Members; this keeps it on the Overview, quiet and one click away). Urgency and progress keep their words beside their color.

▲ Demonstration only: a step is done when the organization has the matching record in the sample data (an event, sent invitations, a shared resource, a posted need). The prototype keeps no record of a response, so Respond is done only through a demonstration fixture (r71Responded) set in the three populated examples; clicking it, sharing or opening a need never completes it. Where a network has no open need an organization can answer (the setup examples), Respond still shows as a suggestion with nothing to answer yet; whether to suggest it then is unresolved. The examples are read-only, so the invitation flow is tried in your own session. Nothing leaves the Overview in this version except the invitation flow: the tabs, the setup actions, the standing call to action, Respond and Give, need and event pages, Open full need and More actions items show a short notice that they aren’t built out yet. The map, its Quick Views, the event selector, favorites, View all activity and Edit for Network info work in place. Nothing here is backend behavior.

Needs, confirmed (Decision 22, v0.19): three stages, completed (orders delivered), being fulfilled (orders placed, not yet delivered) and still needed; carts and shared inventory never count. A need’s card has one bar that counts quantities one to one across units, for now (“just says 250 items”, George Samra, 2026-10-27). A need’s details show a bar for each requested item in its own unit, the first five then Show more. Orders in another unit show beside the bar and are never added in. Respond stays at the bottom of the card.

Needs, UX presentation (Augusto, round 7.1; not yet approved): the Overview card shows the title, the organization and urgency, one bar, one line (for example 250 of 400 cases still needed) and Respond; the fulfillment key is hidden by default everywhere in round 7.1: a small info button after each bar’s line (labelled Explain fulfillment progress) shows Completed, Being fulfilled and Still needed beside their colors, with that bar’s exact quantities, on hover, keyboard focus or tap; there are no permanent legends or breakdown lines. A need in more than one unit reads in items, never in one unit’s name, with an N units control that says what was counted. The Quick View combines the items and their progress into one Requested items section, each item named above its bar with its unit, its remaining quantity and its requested total; it starts with five items (George’s suggestion, not an approved limit) and Show all. Address, description and the fuller breakdown stay on the need’s detail page in round 7 (not reachable from this version). The secondary setup actions are neutral, and Market Blue is kept for structure.

Give (spec v0.21, section 4 item 5; Decision 31): on an open need a supplier can respond to, the card’s button says Give and is its main action, in R7.1’s orange primary style, still at the bottom of the card. The Quick View says Give too. A nonprofit keeps Respond, and an organization’s own need shows Your need. The flow is round 7’s Respond. The give builds on Offer Without a Resource (GIK-336); its first screen, photos and repeat-offer warning stay open (Decision 31 a to c), and nothing here settles them.

▲ Data limitation: the prototype records progress for each need as a whole, not by item. Where a need has several items and some orders, the Quick View shows one Overall progress block and lists the items without bars rather than splitting the total (its info popover says progress is recorded for the whole need); per-item bars appear only where they are true (a single-item need, or one with no orders yet, or one whose orders are all delivered). Whether a network need holds several items, each with its own amount and unit, is for the data model review (GIK-624).

▲ Demonstration data: one need with seven items in five units and no orders yet (Cleanup supplies for flooded homes, Salvation Army) is added to the three populated examples so Show all and a mixed-unit Quick View can be reviewed; the prototype’s own needs have at most three items. It adds one to those examples’ open needs.

Deferring setup guidance (UX proposal, 2026-10-28; not in v0.19): Not now under each suggestion moves it to a compact Hidden steps (N) button after the done checks; it opens a small menu under the button, one row per step (the name, then Show again), and choosing a row brings that step back in its usual place; Up next moves to the next suggestion. Hide setup beside the heading hides the whole guide; More actions then offers Show setup guide, which brings it back as it was. If every remaining suggestion is hidden, the guide collapses the same way. Show setup guide then reopens it with those steps still hidden: the area shows Every step is hidden and the Hidden steps menu, and a step comes back only through Show again (2026-10-30; it used to bring them all back). Hiding steps or the guide changes the guidance only: nothing is marked done, completion is still read from the records, and every action stays where it always is (More actions, the needs, the map), with the same permissions. Each change moves focus to a nearby control and is announced. Each review example opens with the guide in its default state; its choices last for that visit only. In your live session they are kept in this browser tab for the organization viewing, in that network (the prototype identifies organizations, not individual people). No backend tracking is drawn.

Event Favorites (round 7 UX proposal; not a v0.19 requirement): the populated examples show round 7’s favorites with demonstration favorites from the network’s own events (four for the nonprofit admin, two for the nonprofit member, one for the supplier). In R7.1 the Current Event card shows the selected event’s title with its own favorite star beside it, stage and location, then a compact Change event button (when the network has more than one event) that opens one picker. It opens on Favorites, every favorite with a check on the current one, then Browse all N events, which switches the same picker to every event and back; with no favorites it opens on all events. The star beside the title is its own button, so favoriting or unfavoriting the selected event never opens the picker, and a selected event that isn’t a favorite is not added to Favorites. Choosing an event updates stage and location, the open-needs count and View event, closes the picker and returns focus to Change event. The setup examples have no favorites, so their picker opens on all events; favorites are never a setup step. They are kept as round 7 keeps them, for the organization viewing in this network; whether favorites belong to a person or an organization is unresolved, and no backend storage is drawn.

Tab badges (UX proposal, not in v0.19): the network tabs no longer show standing counts. A tab shows a badge only for items someone else added that this organization hasn’t viewed yet, such as members another admin just added, and opening the tab clears it. The populated nonprofit Network Admin example shows 2 new on Members as demonstration data; nothing is counted live, and what counts as viewed (per person or per organization) is to decide.

Deferred, not in this pass: smaller round 7.1 flow corrections, template changes and the Decision 22 calculation changes. Other screens aren’t part of this version; round 7 has them.

Colors and contrast (2026-10-28): GIK’s supplied palette: Vivid Orange #ED5424, Market Blue, Dutch Blue, Light Gray and Supply White, on a #F5F5F5 page, with Nexus Black text, GIK’s badge colors for success, urgency and priority, and the map’s colors from GIK’s product map. No brand value is changed. White text on Vivid Orange is 3.56:1, so it is used only at large size, on the step in progress; smaller primary actions are outlined in Vivid Orange with Market Blue text, and small text on orange is Nexus Black. Text on Dutch Blue is Market Blue. GIK’s own Pending badge amber is darkened here for contrast.

This state (1b, initial setup, supplier Network Admin; demonstration): Kimball Household Goods, a supplier, has just created the network and is its Network Admin, and sent invitations while creating it (the same demonstration invitations as example 1, with Convoy of Hope invited in Kimball’s place). Getting started shows Add event (Up next), Share resource and Respond, never Post a need (Decision 30). While setup shows, Up next is its one orange action; hidden, the header offers Add event (no event yet), and Share resource once there is one. the invitation step is done (no badge for it), with Invite organizations and the pending count below the cards.

What we heard (2026-10-27 Dev Sync and debrief): clearer next actions at the top of the Overview; less reading; more visual guidance and color; less emphasis on Network info; and a direction that still reads as GIK, consistent with the rest of the platform. This page answers that for the Overview only.

Confirmed by GIK (Decision 30, spec v0.21, 2026-10-30): the top of the Overview has two parts. Getting started walks each organization through its first actions in order (add an event, add resources, then respond to a need) and goes once they are done (Shabab Gruberg, 15:07). The standing call to action stays above the map on a populated network (14:10, 14:17): one big orange button chosen by the organization’s type, Share resource for a supplier and Post a need for a nonprofit, beside More actions. Being a Network Admin doesn’t change it. Share resource is emphasized, and a supplier never sees Post a need. Network information and any access label stay out of the top, so the header no longer says Invite-only network; who can see the network is unchanged.

▲ Setup, status in spec v0.21: Respond is back as the last step of Getting started (spec v0.21 keeps GIK’s 2026-10-27 sequence). This supersedes R7.1’s 2026-10-29 proposal to drop it, which stays open for GIK. The spec reads Respond as a supplier’s last step, while R7.1, as before, offers it to every member who can respond: unresolved. Still R7.1 proposals for GIK to confirm: Not now, Hidden steps and Hide setup. Closed by spec v0.22 (Decision 5): a partner network needs at least one other organization at creation, so the Invite organizations step for a convener who skipped inviting is gone; the initial examples all start with invitations sent (pending counts). Closed by check 6: R7.1’s third proposal, leaving the actions only in More actions once setup is done; the standing call to action replaces it. Invitations sent is still read from the network’s own invitation records, and the step completes only after a real send.

Defaults in spec v0.21, not confirmed: Getting started is tracked for each organization in each network; once it is done, Add event stays available to Network Admins in a smaller form (here, in More actions). Open: whether a nonprofit’s main action is Post a need with Share resource beside it (the spec’s default is yes); R7.1 shows Post a need alone, as asked for in this pass, and Share resource stays in More actions and Getting started. Check 1 (nothing at the top competes with the next action): while Getting started shows, its orange Up next tile and the orange standing button are both visible; flagged for review.

UX proposals (Augusto, round 7.1, after Decision 32; not yet approved): GIK’s colors and type faces on the product screen only. Get started shows the actions still to do as one row of equal tiles in Decision 30’s order, without step numbers; the first is marked Up next and is orange, and the others stay open (nothing is locked). Done steps move to a compact Done group beneath, each still opening its action. Each tile’s help shows on hover and keyboard focus, and from an info button on touch screens. Pending invitations sit beside the admin’s Invite organizations link. The four figures show icon, count and label only. Network info is a collapsed section at the end of the Overview (GIK named an info button, a settings tab or the bottom of Members; this keeps it on the Overview, quiet and one click away). Urgency and progress keep their words beside their color.

▲ Demonstration only: a step is done when the organization has the matching record in the sample data (an event, sent invitations, a shared resource, a posted need). The prototype keeps no record of a response, so Respond is done only through a demonstration fixture (r71Responded) set in the three populated examples; clicking it, sharing or opening a need never completes it. Where a network has no open need an organization can answer (the setup examples), Respond still shows as a suggestion with nothing to answer yet; whether to suggest it then is unresolved. The examples are read-only, so the invitation flow is tried in your own session. Nothing leaves the Overview in this version except the invitation flow: the tabs, the setup actions, the standing call to action, Respond and Give, need and event pages, Open full need and More actions items show a short notice that they aren’t built out yet. The map, its Quick Views, the event selector, favorites, View all activity and Edit for Network info work in place. Nothing here is backend behavior.

Needs, confirmed (Decision 22, v0.19): three stages, completed (orders delivered), being fulfilled (orders placed, not yet delivered) and still needed; carts and shared inventory never count. A need’s card has one bar that counts quantities one to one across units, for now (“just says 250 items”, George Samra, 2026-10-27). A need’s details show a bar for each requested item in its own unit, the first five then Show more. Orders in another unit show beside the bar and are never added in. Respond stays at the bottom of the card.

Needs, UX presentation (Augusto, round 7.1; not yet approved): the Overview card shows the title, the organization and urgency, one bar, one line (for example 250 of 400 cases still needed) and Respond; the fulfillment key is hidden by default everywhere in round 7.1: a small info button after each bar’s line (labelled Explain fulfillment progress) shows Completed, Being fulfilled and Still needed beside their colors, with that bar’s exact quantities, on hover, keyboard focus or tap; there are no permanent legends or breakdown lines. A need in more than one unit reads in items, never in one unit’s name, with an N units control that says what was counted. The Quick View combines the items and their progress into one Requested items section, each item named above its bar with its unit, its remaining quantity and its requested total; it starts with five items (George’s suggestion, not an approved limit) and Show all. Address, description and the fuller breakdown stay on the need’s detail page in round 7 (not reachable from this version). The secondary setup actions are neutral, and Market Blue is kept for structure.

Give (spec v0.21, section 4 item 5; Decision 31): on an open need a supplier can respond to, the card’s button says Give and is its main action, in R7.1’s orange primary style, still at the bottom of the card. The Quick View says Give too. A nonprofit keeps Respond, and an organization’s own need shows Your need. The flow is round 7’s Respond. The give builds on Offer Without a Resource (GIK-336); its first screen, photos and repeat-offer warning stay open (Decision 31 a to c), and nothing here settles them.

▲ Data limitation: the prototype records progress for each need as a whole, not by item. Where a need has several items and some orders, the Quick View shows one Overall progress block and lists the items without bars rather than splitting the total (its info popover says progress is recorded for the whole need); per-item bars appear only where they are true (a single-item need, or one with no orders yet, or one whose orders are all delivered). Whether a network need holds several items, each with its own amount and unit, is for the data model review (GIK-624).

▲ Demonstration data: one need with seven items in five units and no orders yet (Cleanup supplies for flooded homes, Salvation Army) is added to the three populated examples so Show all and a mixed-unit Quick View can be reviewed; the prototype’s own needs have at most three items. It adds one to those examples’ open needs.

Deferring setup guidance (UX proposal, 2026-10-28; not in v0.19): Not now under each suggestion moves it to a compact Hidden steps (N) button after the done checks; it opens a small menu under the button, one row per step (the name, then Show again), and choosing a row brings that step back in its usual place; Up next moves to the next suggestion. Hide setup beside the heading hides the whole guide; More actions then offers Show setup guide, which brings it back as it was. If every remaining suggestion is hidden, the guide collapses the same way. Show setup guide then reopens it with those steps still hidden: the area shows Every step is hidden and the Hidden steps menu, and a step comes back only through Show again (2026-10-30; it used to bring them all back). Hiding steps or the guide changes the guidance only: nothing is marked done, completion is still read from the records, and every action stays where it always is (More actions, the needs, the map), with the same permissions. Each change moves focus to a nearby control and is announced. Each review example opens with the guide in its default state; its choices last for that visit only. In your live session they are kept in this browser tab for the organization viewing, in that network (the prototype identifies organizations, not individual people). No backend tracking is drawn.

Event Favorites (round 7 UX proposal; not a v0.19 requirement): the populated examples show round 7’s favorites with demonstration favorites from the network’s own events (four for the nonprofit admin, two for the nonprofit member, one for the supplier). In R7.1 the Current Event card shows the selected event’s title with its own favorite star beside it, stage and location, then a compact Change event button (when the network has more than one event) that opens one picker. It opens on Favorites, every favorite with a check on the current one, then Browse all N events, which switches the same picker to every event and back; with no favorites it opens on all events. The star beside the title is its own button, so favoriting or unfavoriting the selected event never opens the picker, and a selected event that isn’t a favorite is not added to Favorites. Choosing an event updates stage and location, the open-needs count and View event, closes the picker and returns focus to Change event. The setup examples have no favorites, so their picker opens on all events; favorites are never a setup step. They are kept as round 7 keeps them, for the organization viewing in this network; whether favorites belong to a person or an organization is unresolved, and no backend storage is drawn.

Tab badges (UX proposal, not in v0.19): the network tabs no longer show standing counts. A tab shows a badge only for items someone else added that this organization hasn’t viewed yet, such as members another admin just added, and opening the tab clears it. The populated nonprofit Network Admin example shows 2 new on Members as demonstration data; nothing is counted live, and what counts as viewed (per person or per organization) is to decide.

Deferred, not in this pass: smaller round 7.1 flow corrections, template changes and the Decision 22 calculation changes. Other screens aren’t part of this version; round 7 has them.

Colors and contrast (2026-10-28): GIK’s supplied palette: Vivid Orange #ED5424, Market Blue, Dutch Blue, Light Gray and Supply White, on a #F5F5F5 page, with Nexus Black text, GIK’s badge colors for success, urgency and priority, and the map’s colors from GIK’s product map. No brand value is changed. White text on Vivid Orange is 3.56:1, so it is used only at large size, on the step in progress; smaller primary actions are outlined in Vivid Orange with Market Blue text, and small text on orange is Nexus Black. Text on Dutch Blue is Market Blue. GIK’s own Pending badge amber is darkened here for contrast.

This state: invitations are out and there is no event, so Add event still leads.

Round 7, two setup stages (spec v0.18 in PR #198, Decisions 5 and 30; GIK 2026-10-26; presentation restored at April Sousa’s request): stage 1 is Add organizations, straight after Create, with sending at least one invitation as the only way on (spec v0.22, Decision 5; no Skip). Stage 2 is Get your network ready on the Overview, in its own full-width row above the four figures, in round 7’s earlier staged design: Add event highlighted as the suggested next step (it leads whether or not invitations were sent, and replies are never waited for), Share resources and Post a need as quieter optional suggestions, each dismissible, and a line with the invitations’ status (pending, joined) with View invitations and Invite organizations. There is no step count: these are recommended next steps, not a checklist to complete. Network info sits on its own below the figures while stage 2 shows. Creating the network says only Network created successfully. The section goes as soon as the network has an event, whether or not invitations were sent. ▲ To confirm: spec section 4 item 5 still says the section goes once organizations are invited and an event is added; this prototype follows items 1 and 30 (an event ends setup).

Earlier (2026-10-21): the section shows only what is left to do, read from this network’s own records. Before any invitation is sent, Invite organizations leads, and Add event, Share resources and Post a need are quiet links beside it. Once an invitation is sent, the invite step goes at once, with no Waiting for replies step; Invite organizations stays, as a button below the setup cards. Add event then leads, with Share resources and Post a need as smaller suggestions, offered only to an organization that may do them and hasn’t yet. Each suggestion can be dismissed. With invitations sent and an event added, the whole section goes, with no completed summary, and the four figures sit directly under the header.

Dismiss: hides that suggestion for this organization on this network only. It never marks the step done: the figures, the records and the action in its usual place (the Events tab, Manage resources, Post a need) are unchanged. In a preset example it lasts until you leave the example.

No figures before the first invitation, a UX exploration, not in spec v0.18 in PR #198 (April Sousa, 2026-10-26): while a newly created network has sent no invitations and Get your network ready shows, the four figures are hidden so the guidance is the focus; nothing is set to zero (your organization still counts as the one member). Once an invitation is sent the figures show beneath the guidance, and after the first event the Overview is the established one. Closing the guidance with × also brings the figures back.

Close (×), a UX proposal, not in spec v0.18 in PR #198 (April Sousa, 2026-10-26): the × in the corner of Get your network ready closes the whole section for this organization on this network, with no confirmation, because every network works differently. Nothing is marked done and no record changes; the Overview shows Quick actions by organization type beside Network info, and Add event and Invite organizations stay in More actions. The section doesn’t come back because the network still has no event; More actions offers Show setup guidance until the network has one. Closing is kept in your session across pages, networks and refreshes, and affects only that network. In a fixed example it lasts until you leave the example; Setup guidance closed shows the result.

▲ Open: whether closing setup guidance belongs in the product (it is Augusto’s proposal), and whether a dismissed suggestion can be brought back. Once setup is done, Quick actions by organization type sit beside Network info (Decision 30, answered by GIK; Government organizations’ actions are not defined in v0.18).

History (round 6), superseded in round 7: notes on this example that describe Invite organizations as the first step, the Also open any time line or a Your network is ready summary are round 6’s. Round 7 brings back the step count, the Waiting for replies status and the Suggested next badge, in the v0.18 order (Add event next, whether or not invitations were sent).

Round 7, two setup stages (spec v0.18 in PR #198, Decisions 5 and 30; GIK 2026-10-26; presentation restored at April Sousa’s request): stage 1 is Add organizations, straight after Create, with sending at least one invitation as the only way on (spec v0.22, Decision 5; no Skip). Stage 2 is Get your network ready on the Overview, in its own full-width row above the four figures, in round 7’s earlier staged design: Add event highlighted as the suggested next step (it leads whether or not invitations were sent, and replies are never waited for), Share resources and Post a need as quieter optional suggestions, each dismissible, and a line with the invitations’ status (pending, joined) with View invitations and Invite organizations. There is no step count: these are recommended next steps, not a checklist to complete. Network info sits on its own below the figures while stage 2 shows. Creating the network says only Network created successfully. The section goes as soon as the network has an event, whether or not invitations were sent. ▲ To confirm: spec section 4 item 5 still says the section goes once organizations are invited and an event is added; this prototype follows items 1 and 30 (an event ends setup).

Earlier (2026-10-21): the section shows only what is left to do, read from this network’s own records. Before any invitation is sent, Invite organizations leads, and Add event, Share resources and Post a need are quiet links beside it. Once an invitation is sent, the invite step goes at once, with no Waiting for replies step; Invite organizations stays, as a button below the setup cards. Add event then leads, with Share resources and Post a need as smaller suggestions, offered only to an organization that may do them and hasn’t yet. Each suggestion can be dismissed. With invitations sent and an event added, the whole section goes, with no completed summary, and the four figures sit directly under the header.

Dismiss: hides that suggestion for this organization on this network only. It never marks the step done: the figures, the records and the action in its usual place (the Events tab, Manage resources, Post a need) are unchanged. In a preset example it lasts until you leave the example.

No figures before the first invitation, a UX exploration, not in spec v0.18 in PR #198 (April Sousa, 2026-10-26): while a newly created network has sent no invitations and Get your network ready shows, the four figures are hidden so the guidance is the focus; nothing is set to zero (your organization still counts as the one member). Once an invitation is sent the figures show beneath the guidance, and after the first event the Overview is the established one. Closing the guidance with × also brings the figures back.

Close (×), a UX proposal, not in spec v0.18 in PR #198 (April Sousa, 2026-10-26): the × in the corner of Get your network ready closes the whole section for this organization on this network, with no confirmation, because every network works differently. Nothing is marked done and no record changes; the Overview shows Quick actions by organization type beside Network info, and Add event and Invite organizations stay in More actions. The section doesn’t come back because the network still has no event; More actions offers Show setup guidance until the network has one. Closing is kept in your session across pages, networks and refreshes, and affects only that network. In a fixed example it lasts until you leave the example; Setup guidance closed shows the result.

▲ Open: whether closing setup guidance belongs in the product (it is Augusto’s proposal), and whether a dismissed suggestion can be brought back. Once setup is done, Quick actions by organization type sit beside Network info (Decision 30, answered by GIK; Government organizations’ actions are not defined in v0.18).

History (round 6), superseded in round 7: notes on this example that describe Invite organizations as the first step, the Also open any time line or a Your network is ready summary are round 6’s. Round 7 brings back the step count, the Waiting for replies status and the Suggested next badge, in the v0.18 order (Add event next, whether or not invitations were sent).

▲ Share resource and Decision 31, the supplier one-step give (Release 1 scope line 8, estimated as its own line; not drawn): Share resource opens the existing resource-sharing screen: choose resources you already have and share them with the network. Release 1 asks for a one-step give instead, from the Overview’s Share resource and from a button beside every open need: the supplier says what it is giving and who it is for, without loading a resource first, building on the Offer Without a Resource spec (v0.6). The button beside each need still says Respond; estimating default 6 says Give for suppliers. What the give creates is estimating default 4 (a resource record created behind the scenes at the amount given; Mike Perry, then GIK). Once those are confirmed, the design work is the give screen, its entry from Share resource and from each open need, and what the supplier sees after giving.

Round 7, two setup stages (spec v0.18 in PR #198, Decisions 5 and 30; GIK 2026-10-26; presentation restored at April Sousa’s request): stage 1 is Add organizations, straight after Create, with sending at least one invitation as the only way on (spec v0.22, Decision 5; no Skip). Stage 2 is Get your network ready on the Overview, in its own full-width row above the four figures, in round 7’s earlier staged design: Add event highlighted as the suggested next step (it leads whether or not invitations were sent, and replies are never waited for), Share resources and Post a need as quieter optional suggestions, each dismissible, and a line with the invitations’ status (pending, joined) with View invitations and Invite organizations. There is no step count: these are recommended next steps, not a checklist to complete. Network info sits on its own below the figures while stage 2 shows. Creating the network says only Network created successfully. The section goes as soon as the network has an event, whether or not invitations were sent. ▲ To confirm: spec section 4 item 5 still says the section goes once organizations are invited and an event is added; this prototype follows items 1 and 30 (an event ends setup).

Earlier (2026-10-21): the section shows only what is left to do, read from this network’s own records. Before any invitation is sent, Invite organizations leads, and Add event, Share resources and Post a need are quiet links beside it. Once an invitation is sent, the invite step goes at once, with no Waiting for replies step; Invite organizations stays, as a button below the setup cards. Add event then leads, with Share resources and Post a need as smaller suggestions, offered only to an organization that may do them and hasn’t yet. Each suggestion can be dismissed. With invitations sent and an event added, the whole section goes, with no completed summary, and the four figures sit directly under the header.

Dismiss: hides that suggestion for this organization on this network only. It never marks the step done: the figures, the records and the action in its usual place (the Events tab, Manage resources, Post a need) are unchanged. In a preset example it lasts until you leave the example.

No figures before the first invitation, a UX exploration, not in spec v0.18 in PR #198 (April Sousa, 2026-10-26): while a newly created network has sent no invitations and Get your network ready shows, the four figures are hidden so the guidance is the focus; nothing is set to zero (your organization still counts as the one member). Once an invitation is sent the figures show beneath the guidance, and after the first event the Overview is the established one. Closing the guidance with × also brings the figures back.

Close (×), a UX proposal, not in spec v0.18 in PR #198 (April Sousa, 2026-10-26): the × in the corner of Get your network ready closes the whole section for this organization on this network, with no confirmation, because every network works differently. Nothing is marked done and no record changes; the Overview shows Quick actions by organization type beside Network info, and Add event and Invite organizations stay in More actions. The section doesn’t come back because the network still has no event; More actions offers Show setup guidance until the network has one. Closing is kept in your session across pages, networks and refreshes, and affects only that network. In a fixed example it lasts until you leave the example; Setup guidance closed shows the result.

▲ Open: whether closing setup guidance belongs in the product (it is Augusto’s proposal), and whether a dismissed suggestion can be brought back. Once setup is done, Quick actions by organization type sit beside Network info (Decision 30, answered by GIK; Government organizations’ actions are not defined in v0.18).

History (round 6), superseded in round 7: notes on this example that describe Invite organizations as the first step, the Also open any time line or a Your network is ready summary are round 6’s. Round 7 brings back the step count, the Waiting for replies status and the Suggested next badge, in the v0.18 order (Add event next, whether or not invitations were sent).

What we heard (2026-10-27 Dev Sync and debrief): clearer next actions at the top of the Overview; less reading; more visual guidance and color; less emphasis on Network info; and a direction that still reads as GIK, consistent with the rest of the platform. This page answers that for the Overview only.

Confirmed by GIK (Decision 30, spec v0.21, 2026-10-30): the top of the Overview has two parts. Getting started walks each organization through its first actions in order (add an event, add resources, then respond to a need) and goes once they are done (Shabab Gruberg, 15:07). The standing call to action stays above the map on a populated network (14:10, 14:17): one big orange button chosen by the organization’s type, Share resource for a supplier and Post a need for a nonprofit, beside More actions. Being a Network Admin doesn’t change it. Share resource is emphasized, and a supplier never sees Post a need. Network information and any access label stay out of the top, so the header no longer says Invite-only network; who can see the network is unchanged.

▲ Setup, status in spec v0.21: Respond is back as the last step of Getting started (spec v0.21 keeps GIK’s 2026-10-27 sequence). This supersedes R7.1’s 2026-10-29 proposal to drop it, which stays open for GIK. The spec reads Respond as a supplier’s last step, while R7.1, as before, offers it to every member who can respond: unresolved. Still R7.1 proposals for GIK to confirm: Not now, Hidden steps and Hide setup. Closed by spec v0.22 (Decision 5): a partner network needs at least one other organization at creation, so the Invite organizations step for a convener who skipped inviting is gone; the initial examples all start with invitations sent (pending counts). Closed by check 6: R7.1’s third proposal, leaving the actions only in More actions once setup is done; the standing call to action replaces it. Invitations sent is still read from the network’s own invitation records, and the step completes only after a real send.

Defaults in spec v0.21, not confirmed: Getting started is tracked for each organization in each network; once it is done, Add event stays available to Network Admins in a smaller form (here, in More actions). Open: whether a nonprofit’s main action is Post a need with Share resource beside it (the spec’s default is yes); R7.1 shows Post a need alone, as asked for in this pass, and Share resource stays in More actions and Getting started. Check 1 (nothing at the top competes with the next action): while Getting started shows, its orange Up next tile and the orange standing button are both visible; flagged for review.

UX proposals (Augusto, round 7.1, after Decision 32; not yet approved): GIK’s colors and type faces on the product screen only. Get started shows the actions still to do as one row of equal tiles in Decision 30’s order, without step numbers; the first is marked Up next and is orange, and the others stay open (nothing is locked). Done steps move to a compact Done group beneath, each still opening its action. Each tile’s help shows on hover and keyboard focus, and from an info button on touch screens. Pending invitations sit beside the admin’s Invite organizations link. The four figures show icon, count and label only. Network info is a collapsed section at the end of the Overview (GIK named an info button, a settings tab or the bottom of Members; this keeps it on the Overview, quiet and one click away). Urgency and progress keep their words beside their color.

▲ Demonstration only: a step is done when the organization has the matching record in the sample data (an event, sent invitations, a shared resource, a posted need). The prototype keeps no record of a response, so Respond is done only through a demonstration fixture (r71Responded) set in the three populated examples; clicking it, sharing or opening a need never completes it. Where a network has no open need an organization can answer (the setup examples), Respond still shows as a suggestion with nothing to answer yet; whether to suggest it then is unresolved. The examples are read-only, so the invitation flow is tried in your own session. Nothing leaves the Overview in this version except the invitation flow: the tabs, the setup actions, the standing call to action, Respond and Give, need and event pages, Open full need and More actions items show a short notice that they aren’t built out yet. The map, its Quick Views, the event selector, favorites, View all activity and Edit for Network info work in place. Nothing here is backend behavior.

Needs, confirmed (Decision 22, v0.19): three stages, completed (orders delivered), being fulfilled (orders placed, not yet delivered) and still needed; carts and shared inventory never count. A need’s card has one bar that counts quantities one to one across units, for now (“just says 250 items”, George Samra, 2026-10-27). A need’s details show a bar for each requested item in its own unit, the first five then Show more. Orders in another unit show beside the bar and are never added in. Respond stays at the bottom of the card.

Needs, UX presentation (Augusto, round 7.1; not yet approved): the Overview card shows the title, the organization and urgency, one bar, one line (for example 250 of 400 cases still needed) and Respond; the fulfillment key is hidden by default everywhere in round 7.1: a small info button after each bar’s line (labelled Explain fulfillment progress) shows Completed, Being fulfilled and Still needed beside their colors, with that bar’s exact quantities, on hover, keyboard focus or tap; there are no permanent legends or breakdown lines. A need in more than one unit reads in items, never in one unit’s name, with an N units control that says what was counted. The Quick View combines the items and their progress into one Requested items section, each item named above its bar with its unit, its remaining quantity and its requested total; it starts with five items (George’s suggestion, not an approved limit) and Show all. Address, description and the fuller breakdown stay on the need’s detail page in round 7 (not reachable from this version). The secondary setup actions are neutral, and Market Blue is kept for structure.

Give (spec v0.21, section 4 item 5; Decision 31): on an open need a supplier can respond to, the card’s button says Give and is its main action, in R7.1’s orange primary style, still at the bottom of the card. The Quick View says Give too. A nonprofit keeps Respond, and an organization’s own need shows Your need. The flow is round 7’s Respond. The give builds on Offer Without a Resource (GIK-336); its first screen, photos and repeat-offer warning stay open (Decision 31 a to c), and nothing here settles them.

▲ Data limitation: the prototype records progress for each need as a whole, not by item. Where a need has several items and some orders, the Quick View shows one Overall progress block and lists the items without bars rather than splitting the total (its info popover says progress is recorded for the whole need); per-item bars appear only where they are true (a single-item need, or one with no orders yet, or one whose orders are all delivered). Whether a network need holds several items, each with its own amount and unit, is for the data model review (GIK-624).

▲ Demonstration data: one need with seven items in five units and no orders yet (Cleanup supplies for flooded homes, Salvation Army) is added to the three populated examples so Show all and a mixed-unit Quick View can be reviewed; the prototype’s own needs have at most three items. It adds one to those examples’ open needs.

Deferring setup guidance (UX proposal, 2026-10-28; not in v0.19): Not now under each suggestion moves it to a compact Hidden steps (N) button after the done checks; it opens a small menu under the button, one row per step (the name, then Show again), and choosing a row brings that step back in its usual place; Up next moves to the next suggestion. Hide setup beside the heading hides the whole guide; More actions then offers Show setup guide, which brings it back as it was. If every remaining suggestion is hidden, the guide collapses the same way. Show setup guide then reopens it with those steps still hidden: the area shows Every step is hidden and the Hidden steps menu, and a step comes back only through Show again (2026-10-30; it used to bring them all back). Hiding steps or the guide changes the guidance only: nothing is marked done, completion is still read from the records, and every action stays where it always is (More actions, the needs, the map), with the same permissions. Each change moves focus to a nearby control and is announced. Each review example opens with the guide in its default state; its choices last for that visit only. In your live session they are kept in this browser tab for the organization viewing, in that network (the prototype identifies organizations, not individual people). No backend tracking is drawn.

Event Favorites (round 7 UX proposal; not a v0.19 requirement): the populated examples show round 7’s favorites with demonstration favorites from the network’s own events (four for the nonprofit admin, two for the nonprofit member, one for the supplier). In R7.1 the Current Event card shows the selected event’s title with its own favorite star beside it, stage and location, then a compact Change event button (when the network has more than one event) that opens one picker. It opens on Favorites, every favorite with a check on the current one, then Browse all N events, which switches the same picker to every event and back; with no favorites it opens on all events. The star beside the title is its own button, so favoriting or unfavoriting the selected event never opens the picker, and a selected event that isn’t a favorite is not added to Favorites. Choosing an event updates stage and location, the open-needs count and View event, closes the picker and returns focus to Change event. The setup examples have no favorites, so their picker opens on all events; favorites are never a setup step. They are kept as round 7 keeps them, for the organization viewing in this network; whether favorites belong to a person or an organization is unresolved, and no backend storage is drawn.

Tab badges (UX proposal, not in v0.19): the network tabs no longer show standing counts. A tab shows a badge only for items someone else added that this organization hasn’t viewed yet, such as members another admin just added, and opening the tab clears it. The populated nonprofit Network Admin example shows 2 new on Members as demonstration data; nothing is counted live, and what counts as viewed (per person or per organization) is to decide.

Deferred, not in this pass: smaller round 7.1 flow corrections, template changes and the Decision 22 calculation changes. Other screens aren’t part of this version; round 7 has them.

Colors and contrast (2026-10-28): GIK’s supplied palette: Vivid Orange #ED5424, Market Blue, Dutch Blue, Light Gray and Supply White, on a #F5F5F5 page, with Nexus Black text, GIK’s badge colors for success, urgency and priority, and the map’s colors from GIK’s product map. No brand value is changed. White text on Vivid Orange is 3.56:1, so it is used only at large size, on the step in progress; smaller primary actions are outlined in Vivid Orange with Market Blue text, and small text on orange is Nexus Black. Text on Dutch Blue is Market Blue. GIK’s own Pending badge amber is darkened here for contrast.

This state (2, partly complete): an event exists, so Add event moves to the Done group as a green check that still opens it, and Getting started stays: Share resource is Up next in orange, with Post a need and Respond beside it. Its three pending invitations count as sent, so the invitation step is done (no badge for it), and Invite organizations sits beside 3 pending. Post a need stays beside More actions, and stays there if Getting started is hidden.

What we heard (2026-10-27 Dev Sync and debrief): clearer next actions at the top of the Overview; less reading; more visual guidance and color; less emphasis on Network info; and a direction that still reads as GIK, consistent with the rest of the platform. This page answers that for the Overview only.

Confirmed by GIK (Decision 30, spec v0.21, 2026-10-30): the top of the Overview has two parts. Getting started walks each organization through its first actions in order (add an event, add resources, then respond to a need) and goes once they are done (Shabab Gruberg, 15:07). The standing call to action stays above the map on a populated network (14:10, 14:17): one big orange button chosen by the organization’s type, Share resource for a supplier and Post a need for a nonprofit, beside More actions. Being a Network Admin doesn’t change it. Share resource is emphasized, and a supplier never sees Post a need. Network information and any access label stay out of the top, so the header no longer says Invite-only network; who can see the network is unchanged.

▲ Setup, status in spec v0.21: Respond is back as the last step of Getting started (spec v0.21 keeps GIK’s 2026-10-27 sequence). This supersedes R7.1’s 2026-10-29 proposal to drop it, which stays open for GIK. The spec reads Respond as a supplier’s last step, while R7.1, as before, offers it to every member who can respond: unresolved. Still R7.1 proposals for GIK to confirm: Not now, Hidden steps and Hide setup. Closed by spec v0.22 (Decision 5): a partner network needs at least one other organization at creation, so the Invite organizations step for a convener who skipped inviting is gone; the initial examples all start with invitations sent (pending counts). Closed by check 6: R7.1’s third proposal, leaving the actions only in More actions once setup is done; the standing call to action replaces it. Invitations sent is still read from the network’s own invitation records, and the step completes only after a real send.

Defaults in spec v0.21, not confirmed: Getting started is tracked for each organization in each network; once it is done, Add event stays available to Network Admins in a smaller form (here, in More actions). Open: whether a nonprofit’s main action is Post a need with Share resource beside it (the spec’s default is yes); R7.1 shows Post a need alone, as asked for in this pass, and Share resource stays in More actions and Getting started. Check 1 (nothing at the top competes with the next action): while Getting started shows, its orange Up next tile and the orange standing button are both visible; flagged for review.

UX proposals (Augusto, round 7.1, after Decision 32; not yet approved): GIK’s colors and type faces on the product screen only. Get started shows the actions still to do as one row of equal tiles in Decision 30’s order, without step numbers; the first is marked Up next and is orange, and the others stay open (nothing is locked). Done steps move to a compact Done group beneath, each still opening its action. Each tile’s help shows on hover and keyboard focus, and from an info button on touch screens. Pending invitations sit beside the admin’s Invite organizations link. The four figures show icon, count and label only. Network info is a collapsed section at the end of the Overview (GIK named an info button, a settings tab or the bottom of Members; this keeps it on the Overview, quiet and one click away). Urgency and progress keep their words beside their color.

▲ Demonstration only: a step is done when the organization has the matching record in the sample data (an event, sent invitations, a shared resource, a posted need). The prototype keeps no record of a response, so Respond is done only through a demonstration fixture (r71Responded) set in the three populated examples; clicking it, sharing or opening a need never completes it. Where a network has no open need an organization can answer (the setup examples), Respond still shows as a suggestion with nothing to answer yet; whether to suggest it then is unresolved. The examples are read-only, so the invitation flow is tried in your own session. Nothing leaves the Overview in this version except the invitation flow: the tabs, the setup actions, the standing call to action, Respond and Give, need and event pages, Open full need and More actions items show a short notice that they aren’t built out yet. The map, its Quick Views, the event selector, favorites, View all activity and Edit for Network info work in place. Nothing here is backend behavior.

Needs, confirmed (Decision 22, v0.19): three stages, completed (orders delivered), being fulfilled (orders placed, not yet delivered) and still needed; carts and shared inventory never count. A need’s card has one bar that counts quantities one to one across units, for now (“just says 250 items”, George Samra, 2026-10-27). A need’s details show a bar for each requested item in its own unit, the first five then Show more. Orders in another unit show beside the bar and are never added in. Respond stays at the bottom of the card.

Needs, UX presentation (Augusto, round 7.1; not yet approved): the Overview card shows the title, the organization and urgency, one bar, one line (for example 250 of 400 cases still needed) and Respond; the fulfillment key is hidden by default everywhere in round 7.1: a small info button after each bar’s line (labelled Explain fulfillment progress) shows Completed, Being fulfilled and Still needed beside their colors, with that bar’s exact quantities, on hover, keyboard focus or tap; there are no permanent legends or breakdown lines. A need in more than one unit reads in items, never in one unit’s name, with an N units control that says what was counted. The Quick View combines the items and their progress into one Requested items section, each item named above its bar with its unit, its remaining quantity and its requested total; it starts with five items (George’s suggestion, not an approved limit) and Show all. Address, description and the fuller breakdown stay on the need’s detail page in round 7 (not reachable from this version). The secondary setup actions are neutral, and Market Blue is kept for structure.

Give (spec v0.21, section 4 item 5; Decision 31): on an open need a supplier can respond to, the card’s button says Give and is its main action, in R7.1’s orange primary style, still at the bottom of the card. The Quick View says Give too. A nonprofit keeps Respond, and an organization’s own need shows Your need. The flow is round 7’s Respond. The give builds on Offer Without a Resource (GIK-336); its first screen, photos and repeat-offer warning stay open (Decision 31 a to c), and nothing here settles them.

▲ Data limitation: the prototype records progress for each need as a whole, not by item. Where a need has several items and some orders, the Quick View shows one Overall progress block and lists the items without bars rather than splitting the total (its info popover says progress is recorded for the whole need); per-item bars appear only where they are true (a single-item need, or one with no orders yet, or one whose orders are all delivered). Whether a network need holds several items, each with its own amount and unit, is for the data model review (GIK-624).

▲ Demonstration data: one need with seven items in five units and no orders yet (Cleanup supplies for flooded homes, Salvation Army) is added to the three populated examples so Show all and a mixed-unit Quick View can be reviewed; the prototype’s own needs have at most three items. It adds one to those examples’ open needs.

Deferring setup guidance (UX proposal, 2026-10-28; not in v0.19): Not now under each suggestion moves it to a compact Hidden steps (N) button after the done checks; it opens a small menu under the button, one row per step (the name, then Show again), and choosing a row brings that step back in its usual place; Up next moves to the next suggestion. Hide setup beside the heading hides the whole guide; More actions then offers Show setup guide, which brings it back as it was. If every remaining suggestion is hidden, the guide collapses the same way. Show setup guide then reopens it with those steps still hidden: the area shows Every step is hidden and the Hidden steps menu, and a step comes back only through Show again (2026-10-30; it used to bring them all back). Hiding steps or the guide changes the guidance only: nothing is marked done, completion is still read from the records, and every action stays where it always is (More actions, the needs, the map), with the same permissions. Each change moves focus to a nearby control and is announced. Each review example opens with the guide in its default state; its choices last for that visit only. In your live session they are kept in this browser tab for the organization viewing, in that network (the prototype identifies organizations, not individual people). No backend tracking is drawn.

Event Favorites (round 7 UX proposal; not a v0.19 requirement): the populated examples show round 7’s favorites with demonstration favorites from the network’s own events (four for the nonprofit admin, two for the nonprofit member, one for the supplier). In R7.1 the Current Event card shows the selected event’s title with its own favorite star beside it, stage and location, then a compact Change event button (when the network has more than one event) that opens one picker. It opens on Favorites, every favorite with a check on the current one, then Browse all N events, which switches the same picker to every event and back; with no favorites it opens on all events. The star beside the title is its own button, so favoriting or unfavoriting the selected event never opens the picker, and a selected event that isn’t a favorite is not added to Favorites. Choosing an event updates stage and location, the open-needs count and View event, closes the picker and returns focus to Change event. The setup examples have no favorites, so their picker opens on all events; favorites are never a setup step. They are kept as round 7 keeps them, for the organization viewing in this network; whether favorites belong to a person or an organization is unresolved, and no backend storage is drawn.

Tab badges (UX proposal, not in v0.19): the network tabs no longer show standing counts. A tab shows a badge only for items someone else added that this organization hasn’t viewed yet, such as members another admin just added, and opening the tab clears it. The populated nonprofit Network Admin example shows 2 new on Members as demonstration data; nothing is counted live, and what counts as viewed (per person or per organization) is to decide.

Deferred, not in this pass: smaller round 7.1 flow corrections, template changes and the Decision 22 calculation changes. Other screens aren’t part of this version; round 7 has them.

Colors and contrast (2026-10-28): GIK’s supplied palette: Vivid Orange #ED5424, Market Blue, Dutch Blue, Light Gray and Supply White, on a #F5F5F5 page, with Nexus Black text, GIK’s badge colors for success, urgency and priority, and the map’s colors from GIK’s product map. No brand value is changed. White text on Vivid Orange is 3.56:1, so it is used only at large size, on the step in progress; smaller primary actions are outlined in Vivid Orange with Market Blue text, and small text on orange is Nexus Black. Text on Dutch Blue is Market Blue. GIK’s own Pending badge amber is darkened here for contrast.

This state (2, partly complete, last two steps; demonstration): the same partly complete network, where Convoy of Hope, a nonprofit and the Network Admin, has also posted a need (bottled water for the Mobile shelters, nothing ordered yet). Event added and Need posted are in the Done group, in the setup order (the invitation step is done but has no badge), and Getting started shows the last two steps: Share resource (Up next, in orange) and Respond. The header has no orange button while setup shows; hidden or done, it is Post a need.

What we heard (2026-10-27 Dev Sync and debrief): clearer next actions at the top of the Overview; less reading; more visual guidance and color; less emphasis on Network info; and a direction that still reads as GIK, consistent with the rest of the platform. This page answers that for the Overview only.

Confirmed by GIK (Decision 30, spec v0.21, 2026-10-30): the top of the Overview has two parts. Getting started walks each organization through its first actions in order (add an event, add resources, then respond to a need) and goes once they are done (Shabab Gruberg, 15:07). The standing call to action stays above the map on a populated network (14:10, 14:17): one big orange button chosen by the organization’s type, Share resource for a supplier and Post a need for a nonprofit, beside More actions. Being a Network Admin doesn’t change it. Share resource is emphasized, and a supplier never sees Post a need. Network information and any access label stay out of the top, so the header no longer says Invite-only network; who can see the network is unchanged.

▲ Setup, status in spec v0.21: Respond is back as the last step of Getting started (spec v0.21 keeps GIK’s 2026-10-27 sequence). This supersedes R7.1’s 2026-10-29 proposal to drop it, which stays open for GIK. The spec reads Respond as a supplier’s last step, while R7.1, as before, offers it to every member who can respond: unresolved. Still R7.1 proposals for GIK to confirm: Not now, Hidden steps and Hide setup. Closed by spec v0.22 (Decision 5): a partner network needs at least one other organization at creation, so the Invite organizations step for a convener who skipped inviting is gone; the initial examples all start with invitations sent (pending counts). Closed by check 6: R7.1’s third proposal, leaving the actions only in More actions once setup is done; the standing call to action replaces it. Invitations sent is still read from the network’s own invitation records, and the step completes only after a real send.

Defaults in spec v0.21, not confirmed: Getting started is tracked for each organization in each network; once it is done, Add event stays available to Network Admins in a smaller form (here, in More actions). Open: whether a nonprofit’s main action is Post a need with Share resource beside it (the spec’s default is yes); R7.1 shows Post a need alone, as asked for in this pass, and Share resource stays in More actions and Getting started. Check 1 (nothing at the top competes with the next action): while Getting started shows, its orange Up next tile and the orange standing button are both visible; flagged for review.

UX proposals (Augusto, round 7.1, after Decision 32; not yet approved): GIK’s colors and type faces on the product screen only. Get started shows the actions still to do as one row of equal tiles in Decision 30’s order, without step numbers; the first is marked Up next and is orange, and the others stay open (nothing is locked). Done steps move to a compact Done group beneath, each still opening its action. Each tile’s help shows on hover and keyboard focus, and from an info button on touch screens. Pending invitations sit beside the admin’s Invite organizations link. The four figures show icon, count and label only. Network info is a collapsed section at the end of the Overview (GIK named an info button, a settings tab or the bottom of Members; this keeps it on the Overview, quiet and one click away). Urgency and progress keep their words beside their color.

▲ Demonstration only: a step is done when the organization has the matching record in the sample data (an event, sent invitations, a shared resource, a posted need). The prototype keeps no record of a response, so Respond is done only through a demonstration fixture (r71Responded) set in the three populated examples; clicking it, sharing or opening a need never completes it. Where a network has no open need an organization can answer (the setup examples), Respond still shows as a suggestion with nothing to answer yet; whether to suggest it then is unresolved. The examples are read-only, so the invitation flow is tried in your own session. Nothing leaves the Overview in this version except the invitation flow: the tabs, the setup actions, the standing call to action, Respond and Give, need and event pages, Open full need and More actions items show a short notice that they aren’t built out yet. The map, its Quick Views, the event selector, favorites, View all activity and Edit for Network info work in place. Nothing here is backend behavior.

Needs, confirmed (Decision 22, v0.19): three stages, completed (orders delivered), being fulfilled (orders placed, not yet delivered) and still needed; carts and shared inventory never count. A need’s card has one bar that counts quantities one to one across units, for now (“just says 250 items”, George Samra, 2026-10-27). A need’s details show a bar for each requested item in its own unit, the first five then Show more. Orders in another unit show beside the bar and are never added in. Respond stays at the bottom of the card.

Needs, UX presentation (Augusto, round 7.1; not yet approved): the Overview card shows the title, the organization and urgency, one bar, one line (for example 250 of 400 cases still needed) and Respond; the fulfillment key is hidden by default everywhere in round 7.1: a small info button after each bar’s line (labelled Explain fulfillment progress) shows Completed, Being fulfilled and Still needed beside their colors, with that bar’s exact quantities, on hover, keyboard focus or tap; there are no permanent legends or breakdown lines. A need in more than one unit reads in items, never in one unit’s name, with an N units control that says what was counted. The Quick View combines the items and their progress into one Requested items section, each item named above its bar with its unit, its remaining quantity and its requested total; it starts with five items (George’s suggestion, not an approved limit) and Show all. Address, description and the fuller breakdown stay on the need’s detail page in round 7 (not reachable from this version). The secondary setup actions are neutral, and Market Blue is kept for structure.

Give (spec v0.21, section 4 item 5; Decision 31): on an open need a supplier can respond to, the card’s button says Give and is its main action, in R7.1’s orange primary style, still at the bottom of the card. The Quick View says Give too. A nonprofit keeps Respond, and an organization’s own need shows Your need. The flow is round 7’s Respond. The give builds on Offer Without a Resource (GIK-336); its first screen, photos and repeat-offer warning stay open (Decision 31 a to c), and nothing here settles them.

▲ Data limitation: the prototype records progress for each need as a whole, not by item. Where a need has several items and some orders, the Quick View shows one Overall progress block and lists the items without bars rather than splitting the total (its info popover says progress is recorded for the whole need); per-item bars appear only where they are true (a single-item need, or one with no orders yet, or one whose orders are all delivered). Whether a network need holds several items, each with its own amount and unit, is for the data model review (GIK-624).

▲ Demonstration data: one need with seven items in five units and no orders yet (Cleanup supplies for flooded homes, Salvation Army) is added to the three populated examples so Show all and a mixed-unit Quick View can be reviewed; the prototype’s own needs have at most three items. It adds one to those examples’ open needs.

Deferring setup guidance (UX proposal, 2026-10-28; not in v0.19): Not now under each suggestion moves it to a compact Hidden steps (N) button after the done checks; it opens a small menu under the button, one row per step (the name, then Show again), and choosing a row brings that step back in its usual place; Up next moves to the next suggestion. Hide setup beside the heading hides the whole guide; More actions then offers Show setup guide, which brings it back as it was. If every remaining suggestion is hidden, the guide collapses the same way. Show setup guide then reopens it with those steps still hidden: the area shows Every step is hidden and the Hidden steps menu, and a step comes back only through Show again (2026-10-30; it used to bring them all back). Hiding steps or the guide changes the guidance only: nothing is marked done, completion is still read from the records, and every action stays where it always is (More actions, the needs, the map), with the same permissions. Each change moves focus to a nearby control and is announced. Each review example opens with the guide in its default state; its choices last for that visit only. In your live session they are kept in this browser tab for the organization viewing, in that network (the prototype identifies organizations, not individual people). No backend tracking is drawn.

Event Favorites (round 7 UX proposal; not a v0.19 requirement): the populated examples show round 7’s favorites with demonstration favorites from the network’s own events (four for the nonprofit admin, two for the nonprofit member, one for the supplier). In R7.1 the Current Event card shows the selected event’s title with its own favorite star beside it, stage and location, then a compact Change event button (when the network has more than one event) that opens one picker. It opens on Favorites, every favorite with a check on the current one, then Browse all N events, which switches the same picker to every event and back; with no favorites it opens on all events. The star beside the title is its own button, so favoriting or unfavoriting the selected event never opens the picker, and a selected event that isn’t a favorite is not added to Favorites. Choosing an event updates stage and location, the open-needs count and View event, closes the picker and returns focus to Change event. The setup examples have no favorites, so their picker opens on all events; favorites are never a setup step. They are kept as round 7 keeps them, for the organization viewing in this network; whether favorites belong to a person or an organization is unresolved, and no backend storage is drawn.

Tab badges (UX proposal, not in v0.19): the network tabs no longer show standing counts. A tab shows a badge only for items someone else added that this organization hasn’t viewed yet, such as members another admin just added, and opening the tab clears it. The populated nonprofit Network Admin example shows 2 new on Members as demonstration data; nothing is counted live, and what counts as viewed (per person or per organization) is to decide.

Deferred, not in this pass: smaller round 7.1 flow corrections, template changes and the Decision 22 calculation changes. Other screens aren’t part of this version; round 7 has them.

Colors and contrast (2026-10-28): GIK’s supplied palette: Vivid Orange #ED5424, Market Blue, Dutch Blue, Light Gray and Supply White, on a #F5F5F5 page, with Nexus Black text, GIK’s badge colors for success, urgency and priority, and the map’s colors from GIK’s product map. No brand value is changed. White text on Vivid Orange is 3.56:1, so it is used only at large size, on the step in progress; smaller primary actions are outlined in Vivid Orange with Market Blue text, and small text on orange is Nexus Black. Text on Dutch Blue is Market Blue. GIK’s own Pending badge amber is darkened here for contrast.

This state (2, partly complete, demonstration): Salvation Army, a nonprofit and a regular member, has joined but not yet shared: Share resource is Up next in orange, with Respond beside it. Its need from the existing sample data counts once it joins, so Post a need is already in the Done group, and its own need shows Your need. With setup hidden or done, its header button is Post a need. There is no Add event or Invite organizations. The two organizations shown as joined are a demonstration state built from the invitations in the previous example.

What we heard (2026-10-27 Dev Sync and debrief): clearer next actions at the top of the Overview; less reading; more visual guidance and color; less emphasis on Network info; and a direction that still reads as GIK, consistent with the rest of the platform. This page answers that for the Overview only.

Confirmed by GIK (Decision 30, spec v0.21, 2026-10-30): the top of the Overview has two parts. Getting started walks each organization through its first actions in order (add an event, add resources, then respond to a need) and goes once they are done (Shabab Gruberg, 15:07). The standing call to action stays above the map on a populated network (14:10, 14:17): one big orange button chosen by the organization’s type, Share resource for a supplier and Post a need for a nonprofit, beside More actions. Being a Network Admin doesn’t change it. Share resource is emphasized, and a supplier never sees Post a need. Network information and any access label stay out of the top, so the header no longer says Invite-only network; who can see the network is unchanged.

▲ Setup, status in spec v0.21: Respond is back as the last step of Getting started (spec v0.21 keeps GIK’s 2026-10-27 sequence). This supersedes R7.1’s 2026-10-29 proposal to drop it, which stays open for GIK. The spec reads Respond as a supplier’s last step, while R7.1, as before, offers it to every member who can respond: unresolved. Still R7.1 proposals for GIK to confirm: Not now, Hidden steps and Hide setup. Closed by spec v0.22 (Decision 5): a partner network needs at least one other organization at creation, so the Invite organizations step for a convener who skipped inviting is gone; the initial examples all start with invitations sent (pending counts). Closed by check 6: R7.1’s third proposal, leaving the actions only in More actions once setup is done; the standing call to action replaces it. Invitations sent is still read from the network’s own invitation records, and the step completes only after a real send.

Defaults in spec v0.21, not confirmed: Getting started is tracked for each organization in each network; once it is done, Add event stays available to Network Admins in a smaller form (here, in More actions). Open: whether a nonprofit’s main action is Post a need with Share resource beside it (the spec’s default is yes); R7.1 shows Post a need alone, as asked for in this pass, and Share resource stays in More actions and Getting started. Check 1 (nothing at the top competes with the next action): while Getting started shows, its orange Up next tile and the orange standing button are both visible; flagged for review.

UX proposals (Augusto, round 7.1, after Decision 32; not yet approved): GIK’s colors and type faces on the product screen only. Get started shows the actions still to do as one row of equal tiles in Decision 30’s order, without step numbers; the first is marked Up next and is orange, and the others stay open (nothing is locked). Done steps move to a compact Done group beneath, each still opening its action. Each tile’s help shows on hover and keyboard focus, and from an info button on touch screens. Pending invitations sit beside the admin’s Invite organizations link. The four figures show icon, count and label only. Network info is a collapsed section at the end of the Overview (GIK named an info button, a settings tab or the bottom of Members; this keeps it on the Overview, quiet and one click away). Urgency and progress keep their words beside their color.

▲ Demonstration only: a step is done when the organization has the matching record in the sample data (an event, sent invitations, a shared resource, a posted need). The prototype keeps no record of a response, so Respond is done only through a demonstration fixture (r71Responded) set in the three populated examples; clicking it, sharing or opening a need never completes it. Where a network has no open need an organization can answer (the setup examples), Respond still shows as a suggestion with nothing to answer yet; whether to suggest it then is unresolved. The examples are read-only, so the invitation flow is tried in your own session. Nothing leaves the Overview in this version except the invitation flow: the tabs, the setup actions, the standing call to action, Respond and Give, need and event pages, Open full need and More actions items show a short notice that they aren’t built out yet. The map, its Quick Views, the event selector, favorites, View all activity and Edit for Network info work in place. Nothing here is backend behavior.

Needs, confirmed (Decision 22, v0.19): three stages, completed (orders delivered), being fulfilled (orders placed, not yet delivered) and still needed; carts and shared inventory never count. A need’s card has one bar that counts quantities one to one across units, for now (“just says 250 items”, George Samra, 2026-10-27). A need’s details show a bar for each requested item in its own unit, the first five then Show more. Orders in another unit show beside the bar and are never added in. Respond stays at the bottom of the card.

Needs, UX presentation (Augusto, round 7.1; not yet approved): the Overview card shows the title, the organization and urgency, one bar, one line (for example 250 of 400 cases still needed) and Respond; the fulfillment key is hidden by default everywhere in round 7.1: a small info button after each bar’s line (labelled Explain fulfillment progress) shows Completed, Being fulfilled and Still needed beside their colors, with that bar’s exact quantities, on hover, keyboard focus or tap; there are no permanent legends or breakdown lines. A need in more than one unit reads in items, never in one unit’s name, with an N units control that says what was counted. The Quick View combines the items and their progress into one Requested items section, each item named above its bar with its unit, its remaining quantity and its requested total; it starts with five items (George’s suggestion, not an approved limit) and Show all. Address, description and the fuller breakdown stay on the need’s detail page in round 7 (not reachable from this version). The secondary setup actions are neutral, and Market Blue is kept for structure.

Give (spec v0.21, section 4 item 5; Decision 31): on an open need a supplier can respond to, the card’s button says Give and is its main action, in R7.1’s orange primary style, still at the bottom of the card. The Quick View says Give too. A nonprofit keeps Respond, and an organization’s own need shows Your need. The flow is round 7’s Respond. The give builds on Offer Without a Resource (GIK-336); its first screen, photos and repeat-offer warning stay open (Decision 31 a to c), and nothing here settles them.

▲ Data limitation: the prototype records progress for each need as a whole, not by item. Where a need has several items and some orders, the Quick View shows one Overall progress block and lists the items without bars rather than splitting the total (its info popover says progress is recorded for the whole need); per-item bars appear only where they are true (a single-item need, or one with no orders yet, or one whose orders are all delivered). Whether a network need holds several items, each with its own amount and unit, is for the data model review (GIK-624).

▲ Demonstration data: one need with seven items in five units and no orders yet (Cleanup supplies for flooded homes, Salvation Army) is added to the three populated examples so Show all and a mixed-unit Quick View can be reviewed; the prototype’s own needs have at most three items. It adds one to those examples’ open needs.

Deferring setup guidance (UX proposal, 2026-10-28; not in v0.19): Not now under each suggestion moves it to a compact Hidden steps (N) button after the done checks; it opens a small menu under the button, one row per step (the name, then Show again), and choosing a row brings that step back in its usual place; Up next moves to the next suggestion. Hide setup beside the heading hides the whole guide; More actions then offers Show setup guide, which brings it back as it was. If every remaining suggestion is hidden, the guide collapses the same way. Show setup guide then reopens it with those steps still hidden: the area shows Every step is hidden and the Hidden steps menu, and a step comes back only through Show again (2026-10-30; it used to bring them all back). Hiding steps or the guide changes the guidance only: nothing is marked done, completion is still read from the records, and every action stays where it always is (More actions, the needs, the map), with the same permissions. Each change moves focus to a nearby control and is announced. Each review example opens with the guide in its default state; its choices last for that visit only. In your live session they are kept in this browser tab for the organization viewing, in that network (the prototype identifies organizations, not individual people). No backend tracking is drawn.

Event Favorites (round 7 UX proposal; not a v0.19 requirement): the populated examples show round 7’s favorites with demonstration favorites from the network’s own events (four for the nonprofit admin, two for the nonprofit member, one for the supplier). In R7.1 the Current Event card shows the selected event’s title with its own favorite star beside it, stage and location, then a compact Change event button (when the network has more than one event) that opens one picker. It opens on Favorites, every favorite with a check on the current one, then Browse all N events, which switches the same picker to every event and back; with no favorites it opens on all events. The star beside the title is its own button, so favoriting or unfavoriting the selected event never opens the picker, and a selected event that isn’t a favorite is not added to Favorites. Choosing an event updates stage and location, the open-needs count and View event, closes the picker and returns focus to Change event. The setup examples have no favorites, so their picker opens on all events; favorites are never a setup step. They are kept as round 7 keeps them, for the organization viewing in this network; whether favorites belong to a person or an organization is unresolved, and no backend storage is drawn.

Tab badges (UX proposal, not in v0.19): the network tabs no longer show standing counts. A tab shows a badge only for items someone else added that this organization hasn’t viewed yet, such as members another admin just added, and opening the tab clears it. The populated nonprofit Network Admin example shows 2 new on Members as demonstration data; nothing is counted live, and what counts as viewed (per person or per organization) is to decide.

Deferred, not in this pass: smaller round 7.1 flow corrections, template changes and the Decision 22 calculation changes. Other screens aren’t part of this version; round 7 has them.

Colors and contrast (2026-10-28): GIK’s supplied palette: Vivid Orange #ED5424, Market Blue, Dutch Blue, Light Gray and Supply White, on a #F5F5F5 page, with Nexus Black text, GIK’s badge colors for success, urgency and priority, and the map’s colors from GIK’s product map. No brand value is changed. White text on Vivid Orange is 3.56:1, so it is used only at large size, on the step in progress; smaller primary actions are outlined in Vivid Orange with Market Blue text, and small text on orange is Nexus Black. Text on Dutch Blue is Market Blue. GIK’s own Pending badge amber is darkened here for contrast.

This state (2, partly complete, demonstration): Kimball Household Goods, a supplier and a regular member, has Share resource (Up next, in orange) and Respond; a supplier is never offered Post a need (Decision 30), and has no administrative actions. With setup hidden or done, its header button is Share resource, and on each open need it can answer, the card’s button says Give. Same demonstration state as the nonprofit member’s. A supplier’s own setup as a Network Admin is example 1b.

What we heard (2026-10-27 Dev Sync and debrief): clearer next actions at the top of the Overview; less reading; more visual guidance and color; less emphasis on Network info; and a direction that still reads as GIK, consistent with the rest of the platform. This page answers that for the Overview only.

Confirmed by GIK (Decision 30, spec v0.21, 2026-10-30): the top of the Overview has two parts. Getting started walks each organization through its first actions in order (add an event, add resources, then respond to a need) and goes once they are done (Shabab Gruberg, 15:07). The standing call to action stays above the map on a populated network (14:10, 14:17): one big orange button chosen by the organization’s type, Share resource for a supplier and Post a need for a nonprofit, beside More actions. Being a Network Admin doesn’t change it. Share resource is emphasized, and a supplier never sees Post a need. Network information and any access label stay out of the top, so the header no longer says Invite-only network; who can see the network is unchanged.

▲ Setup, status in spec v0.21: Respond is back as the last step of Getting started (spec v0.21 keeps GIK’s 2026-10-27 sequence). This supersedes R7.1’s 2026-10-29 proposal to drop it, which stays open for GIK. The spec reads Respond as a supplier’s last step, while R7.1, as before, offers it to every member who can respond: unresolved. Still R7.1 proposals for GIK to confirm: Not now, Hidden steps and Hide setup. Closed by spec v0.22 (Decision 5): a partner network needs at least one other organization at creation, so the Invite organizations step for a convener who skipped inviting is gone; the initial examples all start with invitations sent (pending counts). Closed by check 6: R7.1’s third proposal, leaving the actions only in More actions once setup is done; the standing call to action replaces it. Invitations sent is still read from the network’s own invitation records, and the step completes only after a real send.

Defaults in spec v0.21, not confirmed: Getting started is tracked for each organization in each network; once it is done, Add event stays available to Network Admins in a smaller form (here, in More actions). Open: whether a nonprofit’s main action is Post a need with Share resource beside it (the spec’s default is yes); R7.1 shows Post a need alone, as asked for in this pass, and Share resource stays in More actions and Getting started. Check 1 (nothing at the top competes with the next action): while Getting started shows, its orange Up next tile and the orange standing button are both visible; flagged for review.

UX proposals (Augusto, round 7.1, after Decision 32; not yet approved): GIK’s colors and type faces on the product screen only. Get started shows the actions still to do as one row of equal tiles in Decision 30’s order, without step numbers; the first is marked Up next and is orange, and the others stay open (nothing is locked). Done steps move to a compact Done group beneath, each still opening its action. Each tile’s help shows on hover and keyboard focus, and from an info button on touch screens. Pending invitations sit beside the admin’s Invite organizations link. The four figures show icon, count and label only. Network info is a collapsed section at the end of the Overview (GIK named an info button, a settings tab or the bottom of Members; this keeps it on the Overview, quiet and one click away). Urgency and progress keep their words beside their color.

▲ Demonstration only: a step is done when the organization has the matching record in the sample data (an event, sent invitations, a shared resource, a posted need). The prototype keeps no record of a response, so Respond is done only through a demonstration fixture (r71Responded) set in the three populated examples; clicking it, sharing or opening a need never completes it. Where a network has no open need an organization can answer (the setup examples), Respond still shows as a suggestion with nothing to answer yet; whether to suggest it then is unresolved. The examples are read-only, so the invitation flow is tried in your own session. Nothing leaves the Overview in this version except the invitation flow: the tabs, the setup actions, the standing call to action, Respond and Give, need and event pages, Open full need and More actions items show a short notice that they aren’t built out yet. The map, its Quick Views, the event selector, favorites, View all activity and Edit for Network info work in place. Nothing here is backend behavior.

Needs, confirmed (Decision 22, v0.19): three stages, completed (orders delivered), being fulfilled (orders placed, not yet delivered) and still needed; carts and shared inventory never count. A need’s card has one bar that counts quantities one to one across units, for now (“just says 250 items”, George Samra, 2026-10-27). A need’s details show a bar for each requested item in its own unit, the first five then Show more. Orders in another unit show beside the bar and are never added in. Respond stays at the bottom of the card.

Needs, UX presentation (Augusto, round 7.1; not yet approved): the Overview card shows the title, the organization and urgency, one bar, one line (for example 250 of 400 cases still needed) and Respond; the fulfillment key is hidden by default everywhere in round 7.1: a small info button after each bar’s line (labelled Explain fulfillment progress) shows Completed, Being fulfilled and Still needed beside their colors, with that bar’s exact quantities, on hover, keyboard focus or tap; there are no permanent legends or breakdown lines. A need in more than one unit reads in items, never in one unit’s name, with an N units control that says what was counted. The Quick View combines the items and their progress into one Requested items section, each item named above its bar with its unit, its remaining quantity and its requested total; it starts with five items (George’s suggestion, not an approved limit) and Show all. Address, description and the fuller breakdown stay on the need’s detail page in round 7 (not reachable from this version). The secondary setup actions are neutral, and Market Blue is kept for structure.

Give (spec v0.21, section 4 item 5; Decision 31): on an open need a supplier can respond to, the card’s button says Give and is its main action, in R7.1’s orange primary style, still at the bottom of the card. The Quick View says Give too. A nonprofit keeps Respond, and an organization’s own need shows Your need. The flow is round 7’s Respond. The give builds on Offer Without a Resource (GIK-336); its first screen, photos and repeat-offer warning stay open (Decision 31 a to c), and nothing here settles them.

▲ Data limitation: the prototype records progress for each need as a whole, not by item. Where a need has several items and some orders, the Quick View shows one Overall progress block and lists the items without bars rather than splitting the total (its info popover says progress is recorded for the whole need); per-item bars appear only where they are true (a single-item need, or one with no orders yet, or one whose orders are all delivered). Whether a network need holds several items, each with its own amount and unit, is for the data model review (GIK-624).

▲ Demonstration data: one need with seven items in five units and no orders yet (Cleanup supplies for flooded homes, Salvation Army) is added to the three populated examples so Show all and a mixed-unit Quick View can be reviewed; the prototype’s own needs have at most three items. It adds one to those examples’ open needs.

Deferring setup guidance (UX proposal, 2026-10-28; not in v0.19): Not now under each suggestion moves it to a compact Hidden steps (N) button after the done checks; it opens a small menu under the button, one row per step (the name, then Show again), and choosing a row brings that step back in its usual place; Up next moves to the next suggestion. Hide setup beside the heading hides the whole guide; More actions then offers Show setup guide, which brings it back as it was. If every remaining suggestion is hidden, the guide collapses the same way. Show setup guide then reopens it with those steps still hidden: the area shows Every step is hidden and the Hidden steps menu, and a step comes back only through Show again (2026-10-30; it used to bring them all back). Hiding steps or the guide changes the guidance only: nothing is marked done, completion is still read from the records, and every action stays where it always is (More actions, the needs, the map), with the same permissions. Each change moves focus to a nearby control and is announced. Each review example opens with the guide in its default state; its choices last for that visit only. In your live session they are kept in this browser tab for the organization viewing, in that network (the prototype identifies organizations, not individual people). No backend tracking is drawn.

Event Favorites (round 7 UX proposal; not a v0.19 requirement): the populated examples show round 7’s favorites with demonstration favorites from the network’s own events (four for the nonprofit admin, two for the nonprofit member, one for the supplier). In R7.1 the Current Event card shows the selected event’s title with its own favorite star beside it, stage and location, then a compact Change event button (when the network has more than one event) that opens one picker. It opens on Favorites, every favorite with a check on the current one, then Browse all N events, which switches the same picker to every event and back; with no favorites it opens on all events. The star beside the title is its own button, so favoriting or unfavoriting the selected event never opens the picker, and a selected event that isn’t a favorite is not added to Favorites. Choosing an event updates stage and location, the open-needs count and View event, closes the picker and returns focus to Change event. The setup examples have no favorites, so their picker opens on all events; favorites are never a setup step. They are kept as round 7 keeps them, for the organization viewing in this network; whether favorites belong to a person or an organization is unresolved, and no backend storage is drawn.

Tab badges (UX proposal, not in v0.19): the network tabs no longer show standing counts. A tab shows a badge only for items someone else added that this organization hasn’t viewed yet, such as members another admin just added, and opening the tab clears it. The populated nonprofit Network Admin example shows 2 new on Members as demonstration data; nothing is counted live, and what counts as viewed (per person or per organization) is to decide.

Deferred, not in this pass: smaller round 7.1 flow corrections, template changes and the Decision 22 calculation changes. Other screens aren’t part of this version; round 7 has them.

Colors and contrast (2026-10-28): GIK’s supplied palette: Vivid Orange #ED5424, Market Blue, Dutch Blue, Light Gray and Supply White, on a #F5F5F5 page, with Nexus Black text, GIK’s badge colors for success, urgency and priority, and the map’s colors from GIK’s product map. No brand value is changed. White text on Vivid Orange is 3.56:1, so it is used only at large size, on the step in progress; smaller primary actions are outlined in Vivid Orange with Market Blue text, and small text on orange is Nexus Black. Text on Dutch Blue is Market Blue. GIK’s own Pending badge amber is darkened here for contrast.

This state (3, populated; demonstration fixture for Respond): Convoy of Hope has added an event, shared resources and posted a need, other organizations have joined, and the fixture marks Respond done, so Getting started is gone and the map moves up. With setup done, the header button is Post a need (the network has an event). Its other actions are in More actions.

▲ Map Quick Views, refined 2026-10-27: Established (Decision 26): a need picked on the map opens in a drawer on the right over a dimmed page, with its progress, requested items, details, Respond and Open full need. UX proposals, pending review: a shared resource opens in the same drawer (availability for this network, supplier, location, category, which network it is shared with, and Open full resource, the only action: Add to cart stays on the full resource page); the selected place shows its counts and a close button, with Needs and Resources as two tabs, three compact rows each (name, organization, a small bar or the amount, a chevron; the whole row opens the Quick View) until View all; a place picked from List view replaces the list, with Back to list; and the full need or resource page offers Back to the map, which returns to the same place, zoom, filter, layers and tab. A resource opens only if it is shared with this network or is your own. Open: whether a resource Quick View should carry a direct action (Add to cart or an offer) once the cart and offer flows are confirmed for networks.

Round 7, shared Overview behaviour (spec v0.17, GIK 2026-10-21): every need shows one progress bar, the bar first, with completed, being fulfilled and still needed on one small line (Decision 22); each need the viewer can act on has Respond, which hands off to GIK’s existing matching and offers (not drawn, no network checkout); the need’s own organization sees Your need, and a need with nothing still needed has no Respond. The Overview shows one current event, the most recent until you pick another; the pick is kept for your organization on this network only. About this network drops the Invite-only line, because every network is invite-only. Adding an event records a Recent activity entry for the new response; entries stay unlinked.

Round 7, Respond (Decision 22; the composer is the Supplier Offers spec’s, draft): Respond opens GIK’s offer composer already scoped to the need: the need’s summary and progress, your own resources with what is available (the ones matching a requested item marked), a quantity for each and which item it is for, an optional note, then a review. The prototype stops before sending and says so: nothing is sent, reserved or ordered, and the need’s progress does not move. Back returns to where Respond was pressed (the Overview, Needs, an event’s page or the map drawer).

Round 7, layout polish (UX, for review): tabs read Overview, Members, Events, Resources, Needs; the four figures read Member organizations, Events, Shared resources, Open needs; once invitations are sent, Invite organizations leaves the header’s main button for More actions; each need in Needs and fulfillment is its own card with the bar, one short line and Respond inside it, and a secondary note only when orders exist in another unit; the drawer dims and blocks the page behind it; an empty map shows no placeholder.

Round 7, map (Decision 26): the map zooms like an online map. Nearby places are grouped into one dark bubble whose number counts their open needs and shared resources together (estimating default 7: records). Behind the markers, major highways (I-10, I-12, I-20, I-49, I-55, I-59, I-65 and a few US and state routes) are drawn as simplified lines through the towns they pass, approximate and for orientation only, and are named where they fit when zoomed in. Selecting a grouped marker zooms in on its area: the places it grouped separate into their own markers, and the list under the map shows the places in view. Selecting a place zooms in on its surroundings (about a city’s area, with the coast, response areas and the names of nearby places still visible; nearby places outside the view are named at the edge with their direction and straight-line distance, and a scale bar shows how far the view reaches). GIK records places at city level, so a place stays one marker however close the view; its needs and shared resources are listed under the map, never placed at invented positions. There are three views at most: all locations, an area (Mobile area) and a place (Jackson, MS), so a place is never more than two steps away. + moves one view closer (from an area, to the place nearest the centre, which is then selected) and is off at a place; − moves one view out; Reset view returns to all locations. At a place, selecting markers never zooms further: the list under the map holds the detail, with needs (progress, owner, urgency; each opens the drawer) and shared resources (quantity available, owner, View resource) in separate groups. A need, from the map or the list, opens on the right in a drawer beside the page, not a dialog, with its progress, what was requested and Respond; another need replaces it; Close or Escape closes it. Zoom in (+), Zoom out (−) and Reset view sit in the map’s corner; a line above the map says what it shows, for example Viewing Jackson, MS · Reset view. Layers is a dropdown (UX proposal): the button names what is on, and the list has Response areas and Member locations as checkboxes, either or both on. Zooming never changes All, Needs or Resources, the layers, the event or the network picker. The Networks page and an event’s page use the same map, each with its own zoom. ▲ Open: whether the number on a marker counts needs or quantity. The prototype counts open needs and the Map key says so (provisional).

Round 7, one Overview layout (GIK 2026-10-26, Release 1 scope line 4; Decision 30 answered by GIK): Option B, after Shabab Gruberg’s 2026-10-21 whiteboard, is the only Overview, in the examples and in your session; the Option A comparison and the Overview layout control are gone. The same composition in every state, setup included: the four figures (at zero for a new network); the top row, which is the guided Get your network ready checklist while the network has no event (in the wider column; it is taller than Quick actions because it carries the guidance) and Quick actions once it has one, always beside Network info (description, Created by, your role); then the map, the current event beside needs, and Recent activity, each only once the network has something to show in it. A new network shows the figures at zero, Add event and Network info, with no empty map, event, needs or activity cards and nothing invented; once invitations go out, Recent activity shows them. A member’s top row is Quick actions, with one line saying events, needs and shared resources appear as members add them. Quick actions follow the organization’s type and its permissions (Simon Vance, 2026-10-26): a Nonprofit sees Post a need (primary) and Share resource; a Supplier sees Share resource (primary). Share resource keeps its name after an organization has shared; managing what it already shares stays on the Resources tab. The header has no primary button and doesn’t repeat these: its More actions holds network administration by permission (Invite organizations, Add event and Manage members for a Network Admin; Leave network where allowed). The convener starts as a Network Admin; there is no separate owner role. ▲ Government organizations keep the earlier set of actions: v0.18 doesn’t define theirs, and no Government organization is in Viewing as. ▲ Order differs from the scope document: line 4 puts the main action above the four figures. During setup the prototype does that (Get your network ready sits above them); once setup is done it keeps the figures first, with Quick actions beside Network info beneath them, provisionally. Line 4 calls the card About this network; the prototype calls it Network info. Impact and Delivery routes are Later (not in Release 1) and not shown.

▲ Map Quick Views, refined 2026-10-27: Established (Decision 26): a need picked on the map opens in a drawer on the right over a dimmed page, with its progress, requested items, details, Respond and Open full need. UX proposals, pending review: a shared resource opens in the same drawer (availability for this network, supplier, location, category, which network it is shared with, and Open full resource, the only action: Add to cart stays on the full resource page); the selected place shows its counts and a close button, with Needs and Resources as two tabs, three compact rows each (name, organization, a small bar or the amount, a chevron; the whole row opens the Quick View) until View all; a place picked from List view replaces the list, with Back to list; and the full need or resource page offers Back to the map, which returns to the same place, zoom, filter, layers and tab. A resource opens only if it is shared with this network or is your own. Open: whether a resource Quick View should carry a direct action (Add to cart or an offer) once the cart and offer flows are confirmed for networks.

Round 7, shared Overview behaviour (spec v0.17, GIK 2026-10-21): every need shows one progress bar, the bar first, with completed, being fulfilled and still needed on one small line (Decision 22); each need the viewer can act on has Respond, which hands off to GIK’s existing matching and offers (not drawn, no network checkout); the need’s own organization sees Your need, and a need with nothing still needed has no Respond. The Overview shows one current event, the most recent until you pick another; the pick is kept for your organization on this network only. About this network drops the Invite-only line, because every network is invite-only. Adding an event records a Recent activity entry for the new response; entries stay unlinked.

Round 7, Respond (Decision 22; the composer is the Supplier Offers spec’s, draft): Respond opens GIK’s offer composer already scoped to the need: the need’s summary and progress, your own resources with what is available (the ones matching a requested item marked), a quantity for each and which item it is for, an optional note, then a review. The prototype stops before sending and says so: nothing is sent, reserved or ordered, and the need’s progress does not move. Back returns to where Respond was pressed (the Overview, Needs, an event’s page or the map drawer).

Round 7, layout polish (UX, for review): tabs read Overview, Members, Events, Resources, Needs; the four figures read Member organizations, Events, Shared resources, Open needs; once invitations are sent, Invite organizations leaves the header’s main button for More actions; each need in Needs and fulfillment is its own card with the bar, one short line and Respond inside it, and a secondary note only when orders exist in another unit; the drawer dims and blocks the page behind it; an empty map shows no placeholder.

Round 7, map (Decision 26): the map zooms like an online map. Nearby places are grouped into one dark bubble whose number counts their open needs and shared resources together (estimating default 7: records). Behind the markers, major highways (I-10, I-12, I-20, I-49, I-55, I-59, I-65 and a few US and state routes) are drawn as simplified lines through the towns they pass, approximate and for orientation only, and are named where they fit when zoomed in. Selecting a grouped marker zooms in on its area: the places it grouped separate into their own markers, and the list under the map shows the places in view. Selecting a place zooms in on its surroundings (about a city’s area, with the coast, response areas and the names of nearby places still visible; nearby places outside the view are named at the edge with their direction and straight-line distance, and a scale bar shows how far the view reaches). GIK records places at city level, so a place stays one marker however close the view; its needs and shared resources are listed under the map, never placed at invented positions. There are three views at most: all locations, an area (Mobile area) and a place (Jackson, MS), so a place is never more than two steps away. + moves one view closer (from an area, to the place nearest the centre, which is then selected) and is off at a place; − moves one view out; Reset view returns to all locations. At a place, selecting markers never zooms further: the list under the map holds the detail, with needs (progress, owner, urgency; each opens the drawer) and shared resources (quantity available, owner, View resource) in separate groups. A need, from the map or the list, opens on the right in a drawer beside the page, not a dialog, with its progress, what was requested and Respond; another need replaces it; Close or Escape closes it. Zoom in (+), Zoom out (−) and Reset view sit in the map’s corner; a line above the map says what it shows, for example Viewing Jackson, MS · Reset view. Layers is a dropdown (UX proposal): the button names what is on, and the list has Response areas and Member locations as checkboxes, either or both on. Zooming never changes All, Needs or Resources, the layers, the event or the network picker. The Networks page and an event’s page use the same map, each with its own zoom. ▲ Open: whether the number on a marker counts needs or quantity. The prototype counts open needs and the Map key says so (provisional).

Round 7, one Overview layout (GIK 2026-10-26, Release 1 scope line 4; Decision 30 answered by GIK): Option B, after Shabab Gruberg’s 2026-10-21 whiteboard, is the only Overview, in the examples and in your session; the Option A comparison and the Overview layout control are gone. The same composition in every state, setup included: the four figures (at zero for a new network); the top row, which is the guided Get your network ready checklist while the network has no event (in the wider column; it is taller than Quick actions because it carries the guidance) and Quick actions once it has one, always beside Network info (description, Created by, your role); then the map, the current event beside needs, and Recent activity, each only once the network has something to show in it. A new network shows the figures at zero, Add event and Network info, with no empty map, event, needs or activity cards and nothing invented; once invitations go out, Recent activity shows them. A member’s top row is Quick actions, with one line saying events, needs and shared resources appear as members add them. Quick actions follow the organization’s type and its permissions (Simon Vance, 2026-10-26): a Nonprofit sees Post a need (primary) and Share resource; a Supplier sees Share resource (primary). Share resource keeps its name after an organization has shared; managing what it already shares stays on the Resources tab. The header has no primary button and doesn’t repeat these: its More actions holds network administration by permission (Invite organizations, Add event and Manage members for a Network Admin; Leave network where allowed). The convener starts as a Network Admin; there is no separate owner role. ▲ Government organizations keep the earlier set of actions: v0.18 doesn’t define theirs, and no Government organization is in Viewing as. ▲ Order differs from the scope document: line 4 puts the main action above the four figures. During setup the prototype does that (Get your network ready sits above them); once setup is done it keeps the figures first, with Quick actions beside Network info beneath them, provisionally. Line 4 calls the card About this network; the prototype calls it Network info. Impact and Delivery routes are Later (not in Release 1) and not shown.

▲ Map Quick Views, refined 2026-10-27: Established (Decision 26): a need picked on the map opens in a drawer on the right over a dimmed page, with its progress, requested items, details, Respond and Open full need. UX proposals, pending review: a shared resource opens in the same drawer (availability for this network, supplier, location, category, which network it is shared with, and Open full resource, the only action: Add to cart stays on the full resource page); the selected place shows its counts and a close button, with Needs and Resources as two tabs, three compact rows each (name, organization, a small bar or the amount, a chevron; the whole row opens the Quick View) until View all; a place picked from List view replaces the list, with Back to list; and the full need or resource page offers Back to the map, which returns to the same place, zoom, filter, layers and tab. A resource opens only if it is shared with this network or is your own. Open: whether a resource Quick View should carry a direct action (Add to cart or an offer) once the cart and offer flows are confirmed for networks.

Round 7, shared Overview behaviour (spec v0.17, GIK 2026-10-21): every need shows one progress bar, the bar first, with completed, being fulfilled and still needed on one small line (Decision 22); each need the viewer can act on has Respond, which hands off to GIK’s existing matching and offers (not drawn, no network checkout); the need’s own organization sees Your need, and a need with nothing still needed has no Respond. The Overview shows one current event, the most recent until you pick another; the pick is kept for your organization on this network only. About this network drops the Invite-only line, because every network is invite-only. Adding an event records a Recent activity entry for the new response; entries stay unlinked.

Round 7, Respond (Decision 22; the composer is the Supplier Offers spec’s, draft): Respond opens GIK’s offer composer already scoped to the need: the need’s summary and progress, your own resources with what is available (the ones matching a requested item marked), a quantity for each and which item it is for, an optional note, then a review. The prototype stops before sending and says so: nothing is sent, reserved or ordered, and the need’s progress does not move. Back returns to where Respond was pressed (the Overview, Needs, an event’s page or the map drawer).

Round 7, layout polish (UX, for review): tabs read Overview, Members, Events, Resources, Needs; the four figures read Member organizations, Events, Shared resources, Open needs; once invitations are sent, Invite organizations leaves the header’s main button for More actions; each need in Needs and fulfillment is its own card with the bar, one short line and Respond inside it, and a secondary note only when orders exist in another unit; the drawer dims and blocks the page behind it; an empty map shows no placeholder.

Round 7, map (Decision 26): the map zooms like an online map. Nearby places are grouped into one dark bubble whose number counts their open needs and shared resources together (estimating default 7: records). Behind the markers, major highways (I-10, I-12, I-20, I-49, I-55, I-59, I-65 and a few US and state routes) are drawn as simplified lines through the towns they pass, approximate and for orientation only, and are named where they fit when zoomed in. Selecting a grouped marker zooms in on its area: the places it grouped separate into their own markers, and the list under the map shows the places in view. Selecting a place zooms in on its surroundings (about a city’s area, with the coast, response areas and the names of nearby places still visible; nearby places outside the view are named at the edge with their direction and straight-line distance, and a scale bar shows how far the view reaches). GIK records places at city level, so a place stays one marker however close the view; its needs and shared resources are listed under the map, never placed at invented positions. There are three views at most: all locations, an area (Mobile area) and a place (Jackson, MS), so a place is never more than two steps away. + moves one view closer (from an area, to the place nearest the centre, which is then selected) and is off at a place; − moves one view out; Reset view returns to all locations. At a place, selecting markers never zooms further: the list under the map holds the detail, with needs (progress, owner, urgency; each opens the drawer) and shared resources (quantity available, owner, View resource) in separate groups. A need, from the map or the list, opens on the right in a drawer beside the page, not a dialog, with its progress, what was requested and Respond; another need replaces it; Close or Escape closes it. Zoom in (+), Zoom out (−) and Reset view sit in the map’s corner; a line above the map says what it shows, for example Viewing Jackson, MS · Reset view. Layers is a dropdown (UX proposal): the button names what is on, and the list has Response areas and Member locations as checkboxes, either or both on. Zooming never changes All, Needs or Resources, the layers, the event or the network picker. The Networks page and an event’s page use the same map, each with its own zoom. ▲ Open: whether the number on a marker counts needs or quantity. The prototype counts open needs and the Map key says so (provisional).

Round 7, one Overview layout (GIK 2026-10-26, Release 1 scope line 4; Decision 30 answered by GIK): Option B, after Shabab Gruberg’s 2026-10-21 whiteboard, is the only Overview, in the examples and in your session; the Option A comparison and the Overview layout control are gone. The same composition in every state, setup included: the four figures (at zero for a new network); the top row, which is the guided Get your network ready checklist while the network has no event (in the wider column; it is taller than Quick actions because it carries the guidance) and Quick actions once it has one, always beside Network info (description, Created by, your role); then the map, the current event beside needs, and Recent activity, each only once the network has something to show in it. A new network shows the figures at zero, Add event and Network info, with no empty map, event, needs or activity cards and nothing invented; once invitations go out, Recent activity shows them. A member’s top row is Quick actions, with one line saying events, needs and shared resources appear as members add them. Quick actions follow the organization’s type and its permissions (Simon Vance, 2026-10-26): a Nonprofit sees Post a need (primary) and Share resource; a Supplier sees Share resource (primary). Share resource keeps its name after an organization has shared; managing what it already shares stays on the Resources tab. The header has no primary button and doesn’t repeat these: its More actions holds network administration by permission (Invite organizations, Add event and Manage members for a Network Admin; Leave network where allowed). The convener starts as a Network Admin; there is no separate owner role. ▲ Government organizations keep the earlier set of actions: v0.18 doesn’t define theirs, and no Government organization is in Viewing as. ▲ Order differs from the scope document: line 4 puts the main action above the four figures. During setup the prototype does that (Get your network ready sits above them); once setup is done it keeps the figures first, with Quick actions beside Network info beneath them, provisionally. Line 4 calls the card About this network; the prototype calls it Network info. Impact and Delivery routes are Later (not in Release 1) and not shown.

▲ Event favorites, a UX proposal, not in spec v0.18 in PR #198 (2026-10-27): Shabab Gruberg and George Samra asked for quick access to the one or two events an organization works on when a network coordinates many. A star beside each event in Events, and on the event’s page, saves it; Events shows All events or Favorites, with counts; on the Overview, Your favorite events sits under the current event: the first two as small clickable rows (star, name, and a chevron, or a check on the current event), in the order they were starred; past two, Show N more opens a small menu of only the rest. Choosing one makes it the current event, so the map and the needs follow it. Favorites and the current event stay separate: starring never changes the current event, and the current event is kept as Decision 28 has it. In the prototype, favorites are kept per network and per organization (the organization you view as), because the prototype has no individual sign-in; a network you can’t open shows none of them. To decide: whether favorites belong to each person or to the organization (estimating default 11 makes network favorites per person). The October 26 Release 1 scope lists event bookmarks as not in Release 1.

Round 7, two setup stages (spec v0.18 in PR #198, Decisions 5 and 30; GIK 2026-10-26; presentation restored at April Sousa’s request): stage 1 is Add organizations, straight after Create, with sending at least one invitation as the only way on (spec v0.22, Decision 5; no Skip). Stage 2 is Get your network ready on the Overview, in its own full-width row above the four figures, in round 7’s earlier staged design: Add event highlighted as the suggested next step (it leads whether or not invitations were sent, and replies are never waited for), Share resources and Post a need as quieter optional suggestions, each dismissible, and a line with the invitations’ status (pending, joined) with View invitations and Invite organizations. There is no step count: these are recommended next steps, not a checklist to complete. Network info sits on its own below the figures while stage 2 shows. Creating the network says only Network created successfully. The section goes as soon as the network has an event, whether or not invitations were sent. ▲ To confirm: spec section 4 item 5 still says the section goes once organizations are invited and an event is added; this prototype follows items 1 and 30 (an event ends setup).

Earlier (2026-10-21): the section shows only what is left to do, read from this network’s own records. Before any invitation is sent, Invite organizations leads, and Add event, Share resources and Post a need are quiet links beside it. Once an invitation is sent, the invite step goes at once, with no Waiting for replies step; Invite organizations stays, as a button below the setup cards. Add event then leads, with Share resources and Post a need as smaller suggestions, offered only to an organization that may do them and hasn’t yet. Each suggestion can be dismissed. With invitations sent and an event added, the whole section goes, with no completed summary, and the four figures sit directly under the header.

Dismiss: hides that suggestion for this organization on this network only. It never marks the step done: the figures, the records and the action in its usual place (the Events tab, Manage resources, Post a need) are unchanged. In a preset example it lasts until you leave the example.

No figures before the first invitation, a UX exploration, not in spec v0.18 in PR #198 (April Sousa, 2026-10-26): while a newly created network has sent no invitations and Get your network ready shows, the four figures are hidden so the guidance is the focus; nothing is set to zero (your organization still counts as the one member). Once an invitation is sent the figures show beneath the guidance, and after the first event the Overview is the established one. Closing the guidance with × also brings the figures back.

Close (×), a UX proposal, not in spec v0.18 in PR #198 (April Sousa, 2026-10-26): the × in the corner of Get your network ready closes the whole section for this organization on this network, with no confirmation, because every network works differently. Nothing is marked done and no record changes; the Overview shows Quick actions by organization type beside Network info, and Add event and Invite organizations stay in More actions. The section doesn’t come back because the network still has no event; More actions offers Show setup guidance until the network has one. Closing is kept in your session across pages, networks and refreshes, and affects only that network. In a fixed example it lasts until you leave the example; Setup guidance closed shows the result.

▲ Open: whether closing setup guidance belongs in the product (it is Augusto’s proposal), and whether a dismissed suggestion can be brought back. Once setup is done, Quick actions by organization type sit beside Network info (Decision 30, answered by GIK; Government organizations’ actions are not defined in v0.18).

History (round 6), superseded in round 7: notes on this example that describe Invite organizations as the first step, the Also open any time line or a Your network is ready summary are round 6’s. Round 7 brings back the step count, the Waiting for replies status and the Suggested next badge, in the v0.18 order (Add event next, whether or not invitations were sent).

Round 6, first steps (spec v0.16 Decision 5, GIK 2026-10-13): Invite organizations leads, and Add event is the suggested next step; together they are the checklist. George Samra asked that needs and resources stay out of the first steps, so Share resources and Post a need sit on one quieter line under it and in their usual places, never counted and never disabled. No order is forced; anything can be done first.

New network, setup complete: the newly created network with invitations out (Salvation Army and Coastal Water Co., pending), two events, Convoy of Hope’s own need posted and one of its own resources shared. It has an event, so Get your network ready no longer shows and Quick actions lead.

Round 7, shared Overview behaviour (spec v0.17, GIK 2026-10-21): every need shows one progress bar, the bar first, with completed, being fulfilled and still needed on one small line (Decision 22); each need the viewer can act on has Respond, which hands off to GIK’s existing matching and offers (not drawn, no network checkout); the need’s own organization sees Your need, and a need with nothing still needed has no Respond. The Overview shows one current event, the most recent until you pick another; the pick is kept for your organization on this network only. About this network drops the Invite-only line, because every network is invite-only. Adding an event records a Recent activity entry for the new response; entries stay unlinked.

Round 7, Respond (Decision 22; the composer is the Supplier Offers spec’s, draft): Respond opens GIK’s offer composer already scoped to the need: the need’s summary and progress, your own resources with what is available (the ones matching a requested item marked), a quantity for each and which item it is for, an optional note, then a review. The prototype stops before sending and says so: nothing is sent, reserved or ordered, and the need’s progress does not move. Back returns to where Respond was pressed (the Overview, Needs, an event’s page or the map drawer).

Round 7, layout polish (UX, for review): tabs read Overview, Members, Events, Resources, Needs; the four figures read Member organizations, Events, Shared resources, Open needs; once invitations are sent, Invite organizations leaves the header’s main button for More actions; each need in Needs and fulfillment is its own card with the bar, one short line and Respond inside it, and a secondary note only when orders exist in another unit; the drawer dims and blocks the page behind it; an empty map shows no placeholder.

Round 7, map (Decision 26): the map zooms like an online map. Nearby places are grouped into one dark bubble whose number counts their open needs and shared resources together (estimating default 7: records). Behind the markers, major highways (I-10, I-12, I-20, I-49, I-55, I-59, I-65 and a few US and state routes) are drawn as simplified lines through the towns they pass, approximate and for orientation only, and are named where they fit when zoomed in. Selecting a grouped marker zooms in on its area: the places it grouped separate into their own markers, and the list under the map shows the places in view. Selecting a place zooms in on its surroundings (about a city’s area, with the coast, response areas and the names of nearby places still visible; nearby places outside the view are named at the edge with their direction and straight-line distance, and a scale bar shows how far the view reaches). GIK records places at city level, so a place stays one marker however close the view; its needs and shared resources are listed under the map, never placed at invented positions. There are three views at most: all locations, an area (Mobile area) and a place (Jackson, MS), so a place is never more than two steps away. + moves one view closer (from an area, to the place nearest the centre, which is then selected) and is off at a place; − moves one view out; Reset view returns to all locations. At a place, selecting markers never zooms further: the list under the map holds the detail, with needs (progress, owner, urgency; each opens the drawer) and shared resources (quantity available, owner, View resource) in separate groups. A need, from the map or the list, opens on the right in a drawer beside the page, not a dialog, with its progress, what was requested and Respond; another need replaces it; Close or Escape closes it. Zoom in (+), Zoom out (−) and Reset view sit in the map’s corner; a line above the map says what it shows, for example Viewing Jackson, MS · Reset view. Layers is a dropdown (UX proposal): the button names what is on, and the list has Response areas and Member locations as checkboxes, either or both on. Zooming never changes All, Needs or Resources, the layers, the event or the network picker. The Networks page and an event’s page use the same map, each with its own zoom. ▲ Open: whether the number on a marker counts needs or quantity. The prototype counts open needs and the Map key says so (provisional).

Round 7, one Overview layout (GIK 2026-10-26, Release 1 scope line 4; Decision 30 answered by GIK): Option B, after Shabab Gruberg’s 2026-10-21 whiteboard, is the only Overview, in the examples and in your session; the Option A comparison and the Overview layout control are gone. The same composition in every state, setup included: the four figures (at zero for a new network); the top row, which is the guided Get your network ready checklist while the network has no event (in the wider column; it is taller than Quick actions because it carries the guidance) and Quick actions once it has one, always beside Network info (description, Created by, your role); then the map, the current event beside needs, and Recent activity, each only once the network has something to show in it. A new network shows the figures at zero, Add event and Network info, with no empty map, event, needs or activity cards and nothing invented; once invitations go out, Recent activity shows them. A member’s top row is Quick actions, with one line saying events, needs and shared resources appear as members add them. Quick actions follow the organization’s type and its permissions (Simon Vance, 2026-10-26): a Nonprofit sees Post a need (primary) and Share resource; a Supplier sees Share resource (primary). Share resource keeps its name after an organization has shared; managing what it already shares stays on the Resources tab. The header has no primary button and doesn’t repeat these: its More actions holds network administration by permission (Invite organizations, Add event and Manage members for a Network Admin; Leave network where allowed). The convener starts as a Network Admin; there is no separate owner role. ▲ Government organizations keep the earlier set of actions: v0.18 doesn’t define theirs, and no Government organization is in Viewing as. ▲ Order differs from the scope document: line 4 puts the main action above the four figures. During setup the prototype does that (Get your network ready sits above them); once setup is done it keeps the figures first, with Quick actions beside Network info beneath them, provisionally. Line 4 calls the card About this network; the prototype calls it Network info. Impact and Delivery routes are Later (not in Release 1) and not shown.

Established network, fully populated: Gulf Coast Response Partners a few weeks into the Hurricane Odalys response, from R4’s own sample records; nothing was added to fill the screen. 15 member organizations have joined (the convener and 14 accepted members, as on the Members tab) and 8 invitations are still pending, shown beside the count for a Network Admin. Two events, with the event selector shared with the map. Seven needs: one open, five partly fulfilled and one fulfilled, two of them high urgency; the two most urgent are shown, the rest are on the Needs tab. Eleven resources shared by member organizations, placed at Mobile, AL as R4’s resource records say. Recent activity shows the four latest entries.

No setup checklist: an established network has no Get your network ready section: it is already running. The checklist belongs to newly created networks only.

A progression, not a sequence: Newly created, Partially configured and Setup complete follow a new network; Established shows a network that is already running. Get your network ready stays optional: its steps can happen in any order, and the Overview follows what the network actually holds.

History (round 5). R5 Overview hierarchy (selected): chosen by April Sousa on 2026-10-12 from the two R5 layout explorations; not GIK approval. Built from Option A’s cards, the layout follows the network’s actual records, never a count of setup steps. Nothing yet: Get your network ready as a grid of its R4 steps (optional, any order) and About this network; no empty map, zero metrics or empty activity. Members or invitations only: the setup grid stays first, with only the metrics that have something to show and Recent activity. Any event, need or shared resource: four snapshot metrics that open their tabs, a full-width map, a response snapshot (the current event, and needs at a glance with status counts and the three most urgent needs), then Recent activity. Setup shrinks to one collapsible line once members, needs or resources exist.

Moved to the tabs: need cards (Needs), shared-resource thumbnails (Resources), the supply plan (the event page), member management (Members), location management (Locations) and impact reporting (Impact, which round 7 leaves out: Decisions 24 and 27). Every link goes to the tab that has the full workflow. Same data, permissions and actions as before; the earlier Overview stays in partner-network-r5-original.html as a rollback reference.

Round 5, phase 0: a copy of round 4 with dashboard Option A, Refined Existing, as the Network Overview. Every round 4 flow is unchanged. Option A was chosen by April Sousa (2026-10-12) as round 5’s starting point; that is not GIK approval. The baseline Overview and options B and C stay in round 4 for reference.

History (round 4). Round 4, phase 25 (2026-10-12), exploration: Option A, refined existing. Changed: one primary action (Invite organizations for a Network Admin) with a More actions menu instead of a row of equal buttons; the metrics as cards near the top; a prominent current-event card holding its supply plan (planning only) and its open-need count; Members’ open needs and shared resources as compact visual cards with View all links; a compact map and Recent activity in the side column; shorter help text; network details as a small secondary card. Kept: the header, tabs and two-column structure, Get your network ready and every card’s behaviour.

Advantages and limits: lowest change and risk, familiar to anyone who reviewed R4; still reads as a tidy admin page rather than a community or a response view, and the map is small.

Map, illustrative: a schematic Gulf Coast with city-level pins: open needs from each need’s own city, shared resources at the city their cards show (Mobile, AL, prototype data). No delivery or street addresses, approximate positions, not live GIK data; List view gives the same information as text. Needs / Resources / All filter it.

History (round 4). Not approved: one of three dashboard options for review. Implementing it here implies no stakeholder approval of any option; R4’s own Overview stays as the baseline (partner-network-r4.html, step 7).

History (round 4). Same data, same functionality: the three options draw the established example (Gulf Coast Response Partners, convened by Convoy of Hope, 15 member organizations, 11 shared resources, 6 open needs, 8 pending invitations) with its two events, Hurricane Odalys (current) and Coastal Louisiana flooding, both existing R4 records. Tabs, screens, actions and permissions are R4’s; only the Overview layout differs.

History (round 4). R4 UX proposals, pending: the current-event selector (which event is “active” is a product decision; choosing one changes only what the event card shows), the quick-actions menu, and the map. Confirmed (R4): tabs, need and resource cards, Get your network ready, permissions. Later: live maps, matching or allocation of inventory to needs.

Colour: kept to the wireframe greys. The Explorer’s wireframe check rejects colours outside its grey ramp, so GIK orange for primary actions is left to visual design.

R5 proposal (phase 3): the map. R4’s illustrative Option A map, extended after R4.5’s network page (Decision 26, Brian’s direction): still city level, with R4’s All / Needs / Resources filter and List view. Layers: Response areas (on by default) and Member locations (off by default). An Event filter appears when the network has two or more events and narrows the map’s needs only. Any city opens a details panel, from its pin or List view, with up to four needs and four resources and View links.

R5 proposal (phase 3): each network’s own area. the map frames the network it belongs to: its needs, with its response area when there is little else. Gulf Coast Response Partners keeps R4’s Gulf Coast view; Hawaii Island Relief Partners shows Hawaii Island; Iowa River Valley Partners shows the Cedar and Iowa rivers. Hawaii and the mainland are never drawn in one frame. Nothing is moved to fit: a resource stays where it is (R4’s sample resources are in Mobile, as their cards say), so Bottled water shared with Hawaii Island is listed under Not shown on this map.

▲ Illustrative, not data: response areas are outlines placed from each event’s area text, labelled as outlines, never a stored geometry (R26); places are approximate city centres for the sample cities; the coastlines are schematic. Member locations come from R4’s saved locations, so only some organizations have one. No street addresses. Pins count needs and resources per city, as in R4; R4.5 sizes needs by what is still needed, which would add amounts across units, so R5 keeps R4’s counts.

R5 proposal (phase 3): need progress. R4’s fulfilled bar gains a hatched “being fulfilled” segment and a line “N being fulfilled (illustrative) · N still needed”, after R4.5 (Decision 22, Brian’s direction). Fulfilled, being fulfilled and still needed always add up to the requested total, in the need’s own unit. R4 records no orders in progress, so only four of R4’s sample needs carry an illustrative amount, and only where every item is in the need’s unit and the items add up to its total (Cots and blankets, counted as Items, keeps R4’s bar). Every other need keeps R4’s fulfilled display. Nothing is calculated from available inventory.

History (round 5). R5 Overview hierarchy (selected): chosen by April Sousa on 2026-10-12 from the two R5 layout explorations; not GIK approval. Built from Option A’s cards, the layout follows the network’s actual records, never a count of setup steps. Nothing yet: Get your network ready as a grid of its R4 steps (optional, any order) and About this network; no empty map, zero metrics or empty activity. Members or invitations only: the setup grid stays first, with only the metrics that have something to show and Recent activity. Any event, need or shared resource: four snapshot metrics that open their tabs, a full-width map, a response snapshot (the current event, and needs at a glance with status counts and the three most urgent needs), then Recent activity. Setup shrinks to one collapsible line once members, needs or resources exist.

Moved to the tabs: need cards (Needs), shared-resource thumbnails (Resources), the supply plan (the event page), member management (Members), location management (Locations) and impact reporting (Impact, which round 7 leaves out: Decisions 24 and 27). Every link goes to the tab that has the full workflow. Same data, permissions and actions as before; the earlier Overview stays in partner-network-r5-original.html as a rollback reference.

Newly created network: Get your network ready comes first (Invite organizations, Add event, Add resources, Post a need; optional, any order, completion unchanged). Empty maps, charts and zero metrics are left out; an Add event prompt stands in for the event card.

History (round 5). R5 Overview hierarchy (selected): chosen by April Sousa on 2026-10-12 from the two R5 layout explorations; not GIK approval. Built from Option A’s cards, the layout follows the network’s actual records, never a count of setup steps. Nothing yet: Get your network ready as a grid of its R4 steps (optional, any order) and About this network; no empty map, zero metrics or empty activity. Members or invitations only: the setup grid stays first, with only the metrics that have something to show and Recent activity. Any event, need or shared resource: four snapshot metrics that open their tabs, a full-width map, a response snapshot (the current event, and needs at a glance with status counts and the three most urgent needs), then Recent activity. Setup shrinks to one collapsible line once members, needs or resources exist.

Moved to the tabs: need cards (Needs), shared-resource thumbnails (Resources), the supply plan (the event page), member management (Members), location management (Locations) and impact reporting (Impact, which round 7 leaves out: Decisions 24 and 27). Every link goes to the tab that has the full workflow. Same data, permissions and actions as before; the earlier Overview stays in partner-network-r5-original.html as a rollback reference.

Filling in: after Convoy of Hope adds Hurricane Odalys the event card appears, still above an otherwise quiet page; metrics, map and charts arrive once members join or share.

Round 7, shared Overview behaviour (spec v0.17, GIK 2026-10-21): every need shows one progress bar, the bar first, with completed, being fulfilled and still needed on one small line (Decision 22); each need the viewer can act on has Respond, which hands off to GIK’s existing matching and offers (not drawn, no network checkout); the need’s own organization sees Your need, and a need with nothing still needed has no Respond. The Overview shows one current event, the most recent until you pick another; the pick is kept for your organization on this network only. About this network drops the Invite-only line, because every network is invite-only. Adding an event records a Recent activity entry for the new response; entries stay unlinked.

Round 7, Respond (Decision 22; the composer is the Supplier Offers spec’s, draft): Respond opens GIK’s offer composer already scoped to the need: the need’s summary and progress, your own resources with what is available (the ones matching a requested item marked), a quantity for each and which item it is for, an optional note, then a review. The prototype stops before sending and says so: nothing is sent, reserved or ordered, and the need’s progress does not move. Back returns to where Respond was pressed (the Overview, Needs, an event’s page or the map drawer).

Round 7, layout polish (UX, for review): tabs read Overview, Members, Events, Resources, Needs; the four figures read Member organizations, Events, Shared resources, Open needs; once invitations are sent, Invite organizations leaves the header’s main button for More actions; each need in Needs and fulfillment is its own card with the bar, one short line and Respond inside it, and a secondary note only when orders exist in another unit; the drawer dims and blocks the page behind it; an empty map shows no placeholder.

Round 7, map (Decision 26): the map zooms like an online map. Nearby places are grouped into one dark bubble whose number counts their open needs and shared resources together (estimating default 7: records). Behind the markers, major highways (I-10, I-12, I-20, I-49, I-55, I-59, I-65 and a few US and state routes) are drawn as simplified lines through the towns they pass, approximate and for orientation only, and are named where they fit when zoomed in. Selecting a grouped marker zooms in on its area: the places it grouped separate into their own markers, and the list under the map shows the places in view. Selecting a place zooms in on its surroundings (about a city’s area, with the coast, response areas and the names of nearby places still visible; nearby places outside the view are named at the edge with their direction and straight-line distance, and a scale bar shows how far the view reaches). GIK records places at city level, so a place stays one marker however close the view; its needs and shared resources are listed under the map, never placed at invented positions. There are three views at most: all locations, an area (Mobile area) and a place (Jackson, MS), so a place is never more than two steps away. + moves one view closer (from an area, to the place nearest the centre, which is then selected) and is off at a place; − moves one view out; Reset view returns to all locations. At a place, selecting markers never zooms further: the list under the map holds the detail, with needs (progress, owner, urgency; each opens the drawer) and shared resources (quantity available, owner, View resource) in separate groups. A need, from the map or the list, opens on the right in a drawer beside the page, not a dialog, with its progress, what was requested and Respond; another need replaces it; Close or Escape closes it. Zoom in (+), Zoom out (−) and Reset view sit in the map’s corner; a line above the map says what it shows, for example Viewing Jackson, MS · Reset view. Layers is a dropdown (UX proposal): the button names what is on, and the list has Response areas and Member locations as checkboxes, either or both on. Zooming never changes All, Needs or Resources, the layers, the event or the network picker. The Networks page and an event’s page use the same map, each with its own zoom. ▲ Open: whether the number on a marker counts needs or quantity. The prototype counts open needs and the Map key says so (provisional).

Round 7, one Overview layout (GIK 2026-10-26, Release 1 scope line 4; Decision 30 answered by GIK): Option B, after Shabab Gruberg’s 2026-10-21 whiteboard, is the only Overview, in the examples and in your session; the Option A comparison and the Overview layout control are gone. The same composition in every state, setup included: the four figures (at zero for a new network); the top row, which is the guided Get your network ready checklist while the network has no event (in the wider column; it is taller than Quick actions because it carries the guidance) and Quick actions once it has one, always beside Network info (description, Created by, your role); then the map, the current event beside needs, and Recent activity, each only once the network has something to show in it. A new network shows the figures at zero, Add event and Network info, with no empty map, event, needs or activity cards and nothing invented; once invitations go out, Recent activity shows them. A member’s top row is Quick actions, with one line saying events, needs and shared resources appear as members add them. Quick actions follow the organization’s type and its permissions (Simon Vance, 2026-10-26): a Nonprofit sees Post a need (primary) and Share resource; a Supplier sees Share resource (primary). Share resource keeps its name after an organization has shared; managing what it already shares stays on the Resources tab. The header has no primary button and doesn’t repeat these: its More actions holds network administration by permission (Invite organizations, Add event and Manage members for a Network Admin; Leave network where allowed). The convener starts as a Network Admin; there is no separate owner role. ▲ Government organizations keep the earlier set of actions: v0.18 doesn’t define theirs, and no Government organization is in Viewing as. ▲ Order differs from the scope document: line 4 puts the main action above the four figures. During setup the prototype does that (Get your network ready sits above them); once setup is done it keeps the figures first, with Quick actions beside Network info beneath them, provisionally. Line 4 calls the card About this network; the prototype calls it Network info. Impact and Delivery routes are Later (not in Release 1) and not shown.

History (round 5). R5 Overview hierarchy (selected): chosen by April Sousa on 2026-10-12 from the two R5 layout explorations; not GIK approval. Built from Option A’s cards, the layout follows the network’s actual records, never a count of setup steps. Nothing yet: Get your network ready as a grid of its R4 steps (optional, any order) and About this network; no empty map, zero metrics or empty activity. Members or invitations only: the setup grid stays first, with only the metrics that have something to show and Recent activity. Any event, need or shared resource: four snapshot metrics that open their tabs, a full-width map, a response snapshot (the current event, and needs at a glance with status counts and the three most urgent needs), then Recent activity. Setup shrinks to one collapsible line once members, needs or resources exist.

Moved to the tabs: need cards (Needs), shared-resource thumbnails (Resources), the supply plan (the event page), member management (Members), location management (Locations) and impact reporting (Impact, which round 7 leaves out: Decisions 24 and 27). Every link goes to the tab that has the full workflow. Same data, permissions and actions as before; the earlier Overview stays in partner-network-r5-original.html as a rollback reference.

Current event (Release 1, scope line 4): with two events, the event card can show either; here Coastal Louisiana flooding. It changes only the card (its needs count and supply plan), never event associations or other data, and the network’s needs and resources stay network-wide.

History (round 5). R5 Overview hierarchy (selected): chosen by April Sousa on 2026-10-12 from the two R5 layout explorations; not GIK approval. Built from Option A’s cards, the layout follows the network’s actual records, never a count of setup steps. Nothing yet: Get your network ready as a grid of its R4 steps (optional, any order) and About this network; no empty map, zero metrics or empty activity. Members or invitations only: the setup grid stays first, with only the metrics that have something to show and Recent activity. Any event, need or shared resource: four snapshot metrics that open their tabs, a full-width map, a response snapshot (the current event, and needs at a glance with status counts and the three most urgent needs), then Recent activity. Setup shrinks to one collapsible line once members, needs or resources exist.

Moved to the tabs: need cards (Needs), shared-resource thumbnails (Resources), the supply plan (the event page), member management (Members), location management (Locations) and impact reporting (Impact, which round 7 leaves out: Decisions 24 and 27). Every link goes to the tab that has the full workflow. Same data, permissions and actions as before; the earlier Overview stays in partner-network-r5-original.html as a rollback reference.

R5 proposal (phase 3): the map. R4’s illustrative Option A map, extended after R4.5’s network page (Decision 26, Brian’s direction): still city level, with R4’s All / Needs / Resources filter and List view. Layers: Response areas (on by default) and Member locations (off by default). An Event filter appears when the network has two or more events and narrows the map’s needs only. Any city opens a details panel, from its pin or List view, with up to four needs and four resources and View links.

R5 proposal (phase 3): each network’s own area. the map frames the network it belongs to: its needs, with its response area when there is little else. Gulf Coast Response Partners keeps R4’s Gulf Coast view; Hawaii Island Relief Partners shows Hawaii Island; Iowa River Valley Partners shows the Cedar and Iowa rivers. Hawaii and the mainland are never drawn in one frame. Nothing is moved to fit: a resource stays where it is (R4’s sample resources are in Mobile, as their cards say), so Bottled water shared with Hawaii Island is listed under Not shown on this map.

▲ Illustrative, not data: response areas are outlines placed from each event’s area text, labelled as outlines, never a stored geometry (R26); places are approximate city centres for the sample cities; the coastlines are schematic. Member locations come from R4’s saved locations, so only some organizations have one. No street addresses. Pins count needs and resources per city, as in R4; R4.5 sizes needs by what is still needed, which would add amounts across units, so R5 keeps R4’s counts.

Map, illustrative: a schematic Gulf Coast with city-level pins: open needs from each need’s own city, shared resources at the city their cards show (Mobile, AL, prototype data). No delivery or street addresses, approximate positions, not live GIK data; List view gives the same information as text. Needs / Resources / All filter it.

Interactive cards: need cards open the need, View all needs opens the Needs tab, resource thumbnails open the resource, View all resources opens Resources. Actions follow each organization’s permissions; a Network Admin gets no control over other organizations’ needs or resources.

History (round 5). R5 Overview hierarchy (selected): chosen by April Sousa on 2026-10-12 from the two R5 layout explorations; not GIK approval. Built from Option A’s cards, the layout follows the network’s actual records, never a count of setup steps. Nothing yet: Get your network ready as a grid of its R4 steps (optional, any order) and About this network; no empty map, zero metrics or empty activity. Members or invitations only: the setup grid stays first, with only the metrics that have something to show and Recent activity. Any event, need or shared resource: four snapshot metrics that open their tabs, a full-width map, a response snapshot (the current event, and needs at a glance with status counts and the three most urgent needs), then Recent activity. Setup shrinks to one collapsible line once members, needs or resources exist.

Moved to the tabs: need cards (Needs), shared-resource thumbnails (Resources), the supply plan (the event page), member management (Members), location management (Locations) and impact reporting (Impact, which round 7 leaves out: Decisions 24 and 27). Every link goes to the tab that has the full workflow. Same data, permissions and actions as before; the earlier Overview stays in partner-network-r5-original.html as a rollback reference.

Network Admin: Convoy of Hope, a Non-Profit, sees Quick actions, Post a need (primary) and Share resource, beside Network info with Edit; More actions holds Invite organizations, Add event and Manage members; pending invitations show under the Member organizations figure.

What we heard (2026-10-27 Dev Sync and debrief): clearer next actions at the top of the Overview; less reading; more visual guidance and color; less emphasis on Network info; and a direction that still reads as GIK, consistent with the rest of the platform. This page answers that for the Overview only.

Confirmed by GIK (Decision 30, spec v0.21, 2026-10-30): the top of the Overview has two parts. Getting started walks each organization through its first actions in order (add an event, add resources, then respond to a need) and goes once they are done (Shabab Gruberg, 15:07). The standing call to action stays above the map on a populated network (14:10, 14:17): one big orange button chosen by the organization’s type, Share resource for a supplier and Post a need for a nonprofit, beside More actions. Being a Network Admin doesn’t change it. Share resource is emphasized, and a supplier never sees Post a need. Network information and any access label stay out of the top, so the header no longer says Invite-only network; who can see the network is unchanged.

▲ Setup, status in spec v0.21: Respond is back as the last step of Getting started (spec v0.21 keeps GIK’s 2026-10-27 sequence). This supersedes R7.1’s 2026-10-29 proposal to drop it, which stays open for GIK. The spec reads Respond as a supplier’s last step, while R7.1, as before, offers it to every member who can respond: unresolved. Still R7.1 proposals for GIK to confirm: Not now, Hidden steps and Hide setup. Closed by spec v0.22 (Decision 5): a partner network needs at least one other organization at creation, so the Invite organizations step for a convener who skipped inviting is gone; the initial examples all start with invitations sent (pending counts). Closed by check 6: R7.1’s third proposal, leaving the actions only in More actions once setup is done; the standing call to action replaces it. Invitations sent is still read from the network’s own invitation records, and the step completes only after a real send.

Defaults in spec v0.21, not confirmed: Getting started is tracked for each organization in each network; once it is done, Add event stays available to Network Admins in a smaller form (here, in More actions). Open: whether a nonprofit’s main action is Post a need with Share resource beside it (the spec’s default is yes); R7.1 shows Post a need alone, as asked for in this pass, and Share resource stays in More actions and Getting started. Check 1 (nothing at the top competes with the next action): while Getting started shows, its orange Up next tile and the orange standing button are both visible; flagged for review.

UX proposals (Augusto, round 7.1, after Decision 32; not yet approved): GIK’s colors and type faces on the product screen only. Get started shows the actions still to do as one row of equal tiles in Decision 30’s order, without step numbers; the first is marked Up next and is orange, and the others stay open (nothing is locked). Done steps move to a compact Done group beneath, each still opening its action. Each tile’s help shows on hover and keyboard focus, and from an info button on touch screens. Pending invitations sit beside the admin’s Invite organizations link. The four figures show icon, count and label only. Network info is a collapsed section at the end of the Overview (GIK named an info button, a settings tab or the bottom of Members; this keeps it on the Overview, quiet and one click away). Urgency and progress keep their words beside their color.

▲ Demonstration only: a step is done when the organization has the matching record in the sample data (an event, sent invitations, a shared resource, a posted need). The prototype keeps no record of a response, so Respond is done only through a demonstration fixture (r71Responded) set in the three populated examples; clicking it, sharing or opening a need never completes it. Where a network has no open need an organization can answer (the setup examples), Respond still shows as a suggestion with nothing to answer yet; whether to suggest it then is unresolved. The examples are read-only, so the invitation flow is tried in your own session. Nothing leaves the Overview in this version except the invitation flow: the tabs, the setup actions, the standing call to action, Respond and Give, need and event pages, Open full need and More actions items show a short notice that they aren’t built out yet. The map, its Quick Views, the event selector, favorites, View all activity and Edit for Network info work in place. Nothing here is backend behavior.

Needs, confirmed (Decision 22, v0.19): three stages, completed (orders delivered), being fulfilled (orders placed, not yet delivered) and still needed; carts and shared inventory never count. A need’s card has one bar that counts quantities one to one across units, for now (“just says 250 items”, George Samra, 2026-10-27). A need’s details show a bar for each requested item in its own unit, the first five then Show more. Orders in another unit show beside the bar and are never added in. Respond stays at the bottom of the card.

Needs, UX presentation (Augusto, round 7.1; not yet approved): the Overview card shows the title, the organization and urgency, one bar, one line (for example 250 of 400 cases still needed) and Respond; the fulfillment key is hidden by default everywhere in round 7.1: a small info button after each bar’s line (labelled Explain fulfillment progress) shows Completed, Being fulfilled and Still needed beside their colors, with that bar’s exact quantities, on hover, keyboard focus or tap; there are no permanent legends or breakdown lines. A need in more than one unit reads in items, never in one unit’s name, with an N units control that says what was counted. The Quick View combines the items and their progress into one Requested items section, each item named above its bar with its unit, its remaining quantity and its requested total; it starts with five items (George’s suggestion, not an approved limit) and Show all. Address, description and the fuller breakdown stay on the need’s detail page in round 7 (not reachable from this version). The secondary setup actions are neutral, and Market Blue is kept for structure.

Give (spec v0.21, section 4 item 5; Decision 31): on an open need a supplier can respond to, the card’s button says Give and is its main action, in R7.1’s orange primary style, still at the bottom of the card. The Quick View says Give too. A nonprofit keeps Respond, and an organization’s own need shows Your need. The flow is round 7’s Respond. The give builds on Offer Without a Resource (GIK-336); its first screen, photos and repeat-offer warning stay open (Decision 31 a to c), and nothing here settles them.

▲ Data limitation: the prototype records progress for each need as a whole, not by item. Where a need has several items and some orders, the Quick View shows one Overall progress block and lists the items without bars rather than splitting the total (its info popover says progress is recorded for the whole need); per-item bars appear only where they are true (a single-item need, or one with no orders yet, or one whose orders are all delivered). Whether a network need holds several items, each with its own amount and unit, is for the data model review (GIK-624).

▲ Demonstration data: one need with seven items in five units and no orders yet (Cleanup supplies for flooded homes, Salvation Army) is added to the three populated examples so Show all and a mixed-unit Quick View can be reviewed; the prototype’s own needs have at most three items. It adds one to those examples’ open needs.

Deferring setup guidance (UX proposal, 2026-10-28; not in v0.19): Not now under each suggestion moves it to a compact Hidden steps (N) button after the done checks; it opens a small menu under the button, one row per step (the name, then Show again), and choosing a row brings that step back in its usual place; Up next moves to the next suggestion. Hide setup beside the heading hides the whole guide; More actions then offers Show setup guide, which brings it back as it was. If every remaining suggestion is hidden, the guide collapses the same way. Show setup guide then reopens it with those steps still hidden: the area shows Every step is hidden and the Hidden steps menu, and a step comes back only through Show again (2026-10-30; it used to bring them all back). Hiding steps or the guide changes the guidance only: nothing is marked done, completion is still read from the records, and every action stays where it always is (More actions, the needs, the map), with the same permissions. Each change moves focus to a nearby control and is announced. Each review example opens with the guide in its default state; its choices last for that visit only. In your live session they are kept in this browser tab for the organization viewing, in that network (the prototype identifies organizations, not individual people). No backend tracking is drawn.

Event Favorites (round 7 UX proposal; not a v0.19 requirement): the populated examples show round 7’s favorites with demonstration favorites from the network’s own events (four for the nonprofit admin, two for the nonprofit member, one for the supplier). In R7.1 the Current Event card shows the selected event’s title with its own favorite star beside it, stage and location, then a compact Change event button (when the network has more than one event) that opens one picker. It opens on Favorites, every favorite with a check on the current one, then Browse all N events, which switches the same picker to every event and back; with no favorites it opens on all events. The star beside the title is its own button, so favoriting or unfavoriting the selected event never opens the picker, and a selected event that isn’t a favorite is not added to Favorites. Choosing an event updates stage and location, the open-needs count and View event, closes the picker and returns focus to Change event. The setup examples have no favorites, so their picker opens on all events; favorites are never a setup step. They are kept as round 7 keeps them, for the organization viewing in this network; whether favorites belong to a person or an organization is unresolved, and no backend storage is drawn.

Tab badges (UX proposal, not in v0.19): the network tabs no longer show standing counts. A tab shows a badge only for items someone else added that this organization hasn’t viewed yet, such as members another admin just added, and opening the tab clears it. The populated nonprofit Network Admin example shows 2 new on Members as demonstration data; nothing is counted live, and what counts as viewed (per person or per organization) is to decide.

Deferred, not in this pass: smaller round 7.1 flow corrections, template changes and the Decision 22 calculation changes. Other screens aren’t part of this version; round 7 has them.

Colors and contrast (2026-10-28): GIK’s supplied palette: Vivid Orange #ED5424, Market Blue, Dutch Blue, Light Gray and Supply White, on a #F5F5F5 page, with Nexus Black text, GIK’s badge colors for success, urgency and priority, and the map’s colors from GIK’s product map. No brand value is changed. White text on Vivid Orange is 3.56:1, so it is used only at large size, on the step in progress; smaller primary actions are outlined in Vivid Orange with Market Blue text, and small text on orange is Nexus Black. Text on Dutch Blue is Market Blue. GIK’s own Pending badge amber is darkened here for contrast.

This state (3, populated; demonstration fixture for Respond): Salvation Army, a nonprofit member, has already shared and posted, and the fixture marks Respond done, so it has no steps left. Post a need stays beside More actions; on the needs, Respond for others’ needs and Your need for its own. It is offered neither Add event nor Invite organizations.

What we heard (2026-10-27 Dev Sync and debrief): clearer next actions at the top of the Overview; less reading; more visual guidance and color; less emphasis on Network info; and a direction that still reads as GIK, consistent with the rest of the platform. This page answers that for the Overview only.

Confirmed by GIK (Decision 30, spec v0.21, 2026-10-30): the top of the Overview has two parts. Getting started walks each organization through its first actions in order (add an event, add resources, then respond to a need) and goes once they are done (Shabab Gruberg, 15:07). The standing call to action stays above the map on a populated network (14:10, 14:17): one big orange button chosen by the organization’s type, Share resource for a supplier and Post a need for a nonprofit, beside More actions. Being a Network Admin doesn’t change it. Share resource is emphasized, and a supplier never sees Post a need. Network information and any access label stay out of the top, so the header no longer says Invite-only network; who can see the network is unchanged.

▲ Setup, status in spec v0.21: Respond is back as the last step of Getting started (spec v0.21 keeps GIK’s 2026-10-27 sequence). This supersedes R7.1’s 2026-10-29 proposal to drop it, which stays open for GIK. The spec reads Respond as a supplier’s last step, while R7.1, as before, offers it to every member who can respond: unresolved. Still R7.1 proposals for GIK to confirm: Not now, Hidden steps and Hide setup. Closed by spec v0.22 (Decision 5): a partner network needs at least one other organization at creation, so the Invite organizations step for a convener who skipped inviting is gone; the initial examples all start with invitations sent (pending counts). Closed by check 6: R7.1’s third proposal, leaving the actions only in More actions once setup is done; the standing call to action replaces it. Invitations sent is still read from the network’s own invitation records, and the step completes only after a real send.

Defaults in spec v0.21, not confirmed: Getting started is tracked for each organization in each network; once it is done, Add event stays available to Network Admins in a smaller form (here, in More actions). Open: whether a nonprofit’s main action is Post a need with Share resource beside it (the spec’s default is yes); R7.1 shows Post a need alone, as asked for in this pass, and Share resource stays in More actions and Getting started. Check 1 (nothing at the top competes with the next action): while Getting started shows, its orange Up next tile and the orange standing button are both visible; flagged for review.

UX proposals (Augusto, round 7.1, after Decision 32; not yet approved): GIK’s colors and type faces on the product screen only. Get started shows the actions still to do as one row of equal tiles in Decision 30’s order, without step numbers; the first is marked Up next and is orange, and the others stay open (nothing is locked). Done steps move to a compact Done group beneath, each still opening its action. Each tile’s help shows on hover and keyboard focus, and from an info button on touch screens. Pending invitations sit beside the admin’s Invite organizations link. The four figures show icon, count and label only. Network info is a collapsed section at the end of the Overview (GIK named an info button, a settings tab or the bottom of Members; this keeps it on the Overview, quiet and one click away). Urgency and progress keep their words beside their color.

▲ Demonstration only: a step is done when the organization has the matching record in the sample data (an event, sent invitations, a shared resource, a posted need). The prototype keeps no record of a response, so Respond is done only through a demonstration fixture (r71Responded) set in the three populated examples; clicking it, sharing or opening a need never completes it. Where a network has no open need an organization can answer (the setup examples), Respond still shows as a suggestion with nothing to answer yet; whether to suggest it then is unresolved. The examples are read-only, so the invitation flow is tried in your own session. Nothing leaves the Overview in this version except the invitation flow: the tabs, the setup actions, the standing call to action, Respond and Give, need and event pages, Open full need and More actions items show a short notice that they aren’t built out yet. The map, its Quick Views, the event selector, favorites, View all activity and Edit for Network info work in place. Nothing here is backend behavior.

Needs, confirmed (Decision 22, v0.19): three stages, completed (orders delivered), being fulfilled (orders placed, not yet delivered) and still needed; carts and shared inventory never count. A need’s card has one bar that counts quantities one to one across units, for now (“just says 250 items”, George Samra, 2026-10-27). A need’s details show a bar for each requested item in its own unit, the first five then Show more. Orders in another unit show beside the bar and are never added in. Respond stays at the bottom of the card.

Needs, UX presentation (Augusto, round 7.1; not yet approved): the Overview card shows the title, the organization and urgency, one bar, one line (for example 250 of 400 cases still needed) and Respond; the fulfillment key is hidden by default everywhere in round 7.1: a small info button after each bar’s line (labelled Explain fulfillment progress) shows Completed, Being fulfilled and Still needed beside their colors, with that bar’s exact quantities, on hover, keyboard focus or tap; there are no permanent legends or breakdown lines. A need in more than one unit reads in items, never in one unit’s name, with an N units control that says what was counted. The Quick View combines the items and their progress into one Requested items section, each item named above its bar with its unit, its remaining quantity and its requested total; it starts with five items (George’s suggestion, not an approved limit) and Show all. Address, description and the fuller breakdown stay on the need’s detail page in round 7 (not reachable from this version). The secondary setup actions are neutral, and Market Blue is kept for structure.

Give (spec v0.21, section 4 item 5; Decision 31): on an open need a supplier can respond to, the card’s button says Give and is its main action, in R7.1’s orange primary style, still at the bottom of the card. The Quick View says Give too. A nonprofit keeps Respond, and an organization’s own need shows Your need. The flow is round 7’s Respond. The give builds on Offer Without a Resource (GIK-336); its first screen, photos and repeat-offer warning stay open (Decision 31 a to c), and nothing here settles them.

▲ Data limitation: the prototype records progress for each need as a whole, not by item. Where a need has several items and some orders, the Quick View shows one Overall progress block and lists the items without bars rather than splitting the total (its info popover says progress is recorded for the whole need); per-item bars appear only where they are true (a single-item need, or one with no orders yet, or one whose orders are all delivered). Whether a network need holds several items, each with its own amount and unit, is for the data model review (GIK-624).

▲ Demonstration data: one need with seven items in five units and no orders yet (Cleanup supplies for flooded homes, Salvation Army) is added to the three populated examples so Show all and a mixed-unit Quick View can be reviewed; the prototype’s own needs have at most three items. It adds one to those examples’ open needs.

Deferring setup guidance (UX proposal, 2026-10-28; not in v0.19): Not now under each suggestion moves it to a compact Hidden steps (N) button after the done checks; it opens a small menu under the button, one row per step (the name, then Show again), and choosing a row brings that step back in its usual place; Up next moves to the next suggestion. Hide setup beside the heading hides the whole guide; More actions then offers Show setup guide, which brings it back as it was. If every remaining suggestion is hidden, the guide collapses the same way. Show setup guide then reopens it with those steps still hidden: the area shows Every step is hidden and the Hidden steps menu, and a step comes back only through Show again (2026-10-30; it used to bring them all back). Hiding steps or the guide changes the guidance only: nothing is marked done, completion is still read from the records, and every action stays where it always is (More actions, the needs, the map), with the same permissions. Each change moves focus to a nearby control and is announced. Each review example opens with the guide in its default state; its choices last for that visit only. In your live session they are kept in this browser tab for the organization viewing, in that network (the prototype identifies organizations, not individual people). No backend tracking is drawn.

Event Favorites (round 7 UX proposal; not a v0.19 requirement): the populated examples show round 7’s favorites with demonstration favorites from the network’s own events (four for the nonprofit admin, two for the nonprofit member, one for the supplier). In R7.1 the Current Event card shows the selected event’s title with its own favorite star beside it, stage and location, then a compact Change event button (when the network has more than one event) that opens one picker. It opens on Favorites, every favorite with a check on the current one, then Browse all N events, which switches the same picker to every event and back; with no favorites it opens on all events. The star beside the title is its own button, so favoriting or unfavoriting the selected event never opens the picker, and a selected event that isn’t a favorite is not added to Favorites. Choosing an event updates stage and location, the open-needs count and View event, closes the picker and returns focus to Change event. The setup examples have no favorites, so their picker opens on all events; favorites are never a setup step. They are kept as round 7 keeps them, for the organization viewing in this network; whether favorites belong to a person or an organization is unresolved, and no backend storage is drawn.

Tab badges (UX proposal, not in v0.19): the network tabs no longer show standing counts. A tab shows a badge only for items someone else added that this organization hasn’t viewed yet, such as members another admin just added, and opening the tab clears it. The populated nonprofit Network Admin example shows 2 new on Members as demonstration data; nothing is counted live, and what counts as viewed (per person or per organization) is to decide.

Deferred, not in this pass: smaller round 7.1 flow corrections, template changes and the Decision 22 calculation changes. Other screens aren’t part of this version; round 7 has them.

Colors and contrast (2026-10-28): GIK’s supplied palette: Vivid Orange #ED5424, Market Blue, Dutch Blue, Light Gray and Supply White, on a #F5F5F5 page, with Nexus Black text, GIK’s badge colors for success, urgency and priority, and the map’s colors from GIK’s product map. No brand value is changed. White text on Vivid Orange is 3.56:1, so it is used only at large size, on the step in progress; smaller primary actions are outlined in Vivid Orange with Market Blue text, and small text on orange is Nexus Black. Text on Dutch Blue is Market Blue. GIK’s own Pending badge amber is darkened here for contrast.

This state (3, populated; demonstration fixture for Respond): Kimball Household Goods, a supplier and a Network Admin of this network, has already shared and the fixture marks Respond done, so it has no steps left. With setup done, its header button is Share resource, and every open need it can answer shows Give as the card’s main action, in the Quick View too. Never Post a need.

History (round 5). R5 Overview hierarchy (selected): chosen by April Sousa on 2026-10-12 from the two R5 layout explorations; not GIK approval. Built from Option A’s cards, the layout follows the network’s actual records, never a count of setup steps. Nothing yet: Get your network ready as a grid of its R4 steps (optional, any order) and About this network; no empty map, zero metrics or empty activity. Members or invitations only: the setup grid stays first, with only the metrics that have something to show and Recent activity. Any event, need or shared resource: four snapshot metrics that open their tabs, a full-width map, a response snapshot (the current event, and needs at a glance with status counts and the three most urgent needs), then Recent activity. Setup shrinks to one collapsible line once members, needs or resources exist.

Moved to the tabs: need cards (Needs), shared-resource thumbnails (Resources), the supply plan (the event page), member management (Members), location management (Locations) and impact reporting (Impact, which round 7 leaves out: Decisions 24 and 27). Every link goes to the tab that has the full workflow. Same data, permissions and actions as before; the earlier Overview stays in partner-network-r5-original.html as a rollback reference.

R5 proposal (phase 3): the map. R4’s illustrative Option A map, extended after R4.5’s network page (Decision 26, Brian’s direction): still city level, with R4’s All / Needs / Resources filter and List view. Layers: Response areas (on by default) and Member locations (off by default). An Event filter appears when the network has two or more events and narrows the map’s needs only. Any city opens a details panel, from its pin or List view, with up to four needs and four resources and View links.

R5 proposal (phase 3): each network’s own area. the map frames the network it belongs to: its needs, with its response area when there is little else. Gulf Coast Response Partners keeps R4’s Gulf Coast view; Hawaii Island Relief Partners shows Hawaii Island; Iowa River Valley Partners shows the Cedar and Iowa rivers. Hawaii and the mainland are never drawn in one frame. Nothing is moved to fit: a resource stays where it is (R4’s sample resources are in Mobile, as their cards say), so Bottled water shared with Hawaii Island is listed under Not shown on this map.

▲ Illustrative, not data: response areas are outlines placed from each event’s area text, labelled as outlines, never a stored geometry (R26); places are approximate city centres for the sample cities; the coastlines are schematic. Member locations come from R4’s saved locations, so only some organizations have one. No street addresses. Pins count needs and resources per city, as in R4; R4.5 sizes needs by what is still needed, which would add amounts across units, so R5 keeps R4’s counts.

History (round 5). R5 Overview hierarchy (selected): chosen by April Sousa on 2026-10-12 from the two R5 layout explorations; not GIK approval. Built from Option A’s cards, the layout follows the network’s actual records, never a count of setup steps. Nothing yet: Get your network ready as a grid of its R4 steps (optional, any order) and About this network; no empty map, zero metrics or empty activity. Members or invitations only: the setup grid stays first, with only the metrics that have something to show and Recent activity. Any event, need or shared resource: four snapshot metrics that open their tabs, a full-width map, a response snapshot (the current event, and needs at a glance with status counts and the three most urgent needs), then Recent activity. Setup shrinks to one collapsible line once members, needs or resources exist.

Moved to the tabs: need cards (Needs), shared-resource thumbnails (Resources), the supply plan (the event page), member management (Members), location management (Locations) and impact reporting (Impact, which round 7 leaves out: Decisions 24 and 27). Every link goes to the tab that has the full workflow. Same data, permissions and actions as before; the earlier Overview stays in partner-network-r5-original.html as a rollback reference.

R5 proposal (phase 3): the map. R4’s illustrative Option A map, extended after R4.5’s network page (Decision 26, Brian’s direction): still city level, with R4’s All / Needs / Resources filter and List view. Layers: Response areas (on by default) and Member locations (off by default). An Event filter appears when the network has two or more events and narrows the map’s needs only. Any city opens a details panel, from its pin or List view, with up to four needs and four resources and View links.

R5 proposal (phase 3): each network’s own area. the map frames the network it belongs to: its needs, with its response area when there is little else. Gulf Coast Response Partners keeps R4’s Gulf Coast view; Hawaii Island Relief Partners shows Hawaii Island; Iowa River Valley Partners shows the Cedar and Iowa rivers. Hawaii and the mainland are never drawn in one frame. Nothing is moved to fit: a resource stays where it is (R4’s sample resources are in Mobile, as their cards say), so Bottled water shared with Hawaii Island is listed under Not shown on this map.

▲ Illustrative, not data: response areas are outlines placed from each event’s area text, labelled as outlines, never a stored geometry (R26); places are approximate city centres for the sample cities; the coastlines are schematic. Member locations come from R4’s saved locations, so only some organizations have one. No street addresses. Pins count needs and resources per city, as in R4; R4.5 sizes needs by what is still needed, which would add amounts across units, so R5 keeps R4’s counts.

History (round 5). R5 Overview hierarchy (selected): chosen by April Sousa on 2026-10-12 from the two R5 layout explorations; not GIK approval. Built from Option A’s cards, the layout follows the network’s actual records, never a count of setup steps. Nothing yet: Get your network ready as a grid of its R4 steps (optional, any order) and About this network; no empty map, zero metrics or empty activity. Members or invitations only: the setup grid stays first, with only the metrics that have something to show and Recent activity. Any event, need or shared resource: four snapshot metrics that open their tabs, a full-width map, a response snapshot (the current event, and needs at a glance with status counts and the three most urgent needs), then Recent activity. Setup shrinks to one collapsible line once members, needs or resources exist.

Moved to the tabs: need cards (Needs), shared-resource thumbnails (Resources), the supply plan (the event page), member management (Members), location management (Locations) and impact reporting (Impact, which round 7 leaves out: Decisions 24 and 27). Every link goes to the tab that has the full workflow. Same data, permissions and actions as before; the earlier Overview stays in partner-network-r5-original.html as a rollback reference.

R5 proposal (phase 3): the map. R4’s illustrative Option A map, extended after R4.5’s network page (Decision 26, Brian’s direction): still city level, with R4’s All / Needs / Resources filter and List view. Layers: Response areas (on by default) and Member locations (off by default). An Event filter appears when the network has two or more events and narrows the map’s needs only. Any city opens a details panel, from its pin or List view, with up to four needs and four resources and View links.

R5 proposal (phase 3): each network’s own area. the map frames the network it belongs to: its needs, with its response area when there is little else. Gulf Coast Response Partners keeps R4’s Gulf Coast view; Hawaii Island Relief Partners shows Hawaii Island; Iowa River Valley Partners shows the Cedar and Iowa rivers. Hawaii and the mainland are never drawn in one frame. Nothing is moved to fit: a resource stays where it is (R4’s sample resources are in Mobile, as their cards say), so Bottled water shared with Hawaii Island is listed under Not shown on this map.

▲ Illustrative, not data: response areas are outlines placed from each event’s area text, labelled as outlines, never a stored geometry (R26); places are approximate city centres for the sample cities; the coastlines are schematic. Member locations come from R4’s saved locations, so only some organizations have one. No street addresses. Pins count needs and resources per city, as in R4; R4.5 sizes needs by what is still needed, which would add amounts across units, so R5 keeps R4’s counts.

R5 proposal (phase 3): need progress. R4’s fulfilled bar gains a hatched “being fulfilled” segment and a line “N being fulfilled (illustrative) · N still needed”, after R4.5 (Decision 22, Brian’s direction). Fulfilled, being fulfilled and still needed always add up to the requested total, in the need’s own unit. R4 records no orders in progress, so only four of R4’s sample needs carry an illustrative amount, and only where every item is in the need’s unit and the items add up to its total (Cots and blankets, counted as Items, keeps R4’s bar). Every other need keeps R4’s fulfilled display. Nothing is calculated from available inventory.

Round 7, shared Overview behaviour (spec v0.17, GIK 2026-10-21): every need shows one progress bar, the bar first, with completed, being fulfilled and still needed on one small line (Decision 22); each need the viewer can act on has Respond, which hands off to GIK’s existing matching and offers (not drawn, no network checkout); the need’s own organization sees Your need, and a need with nothing still needed has no Respond. The Overview shows one current event, the most recent until you pick another; the pick is kept for your organization on this network only. About this network drops the Invite-only line, because every network is invite-only. Adding an event records a Recent activity entry for the new response; entries stay unlinked.

Round 7, Respond (Decision 22; the composer is the Supplier Offers spec’s, draft): Respond opens GIK’s offer composer already scoped to the need: the need’s summary and progress, your own resources with what is available (the ones matching a requested item marked), a quantity for each and which item it is for, an optional note, then a review. The prototype stops before sending and says so: nothing is sent, reserved or ordered, and the need’s progress does not move. Back returns to where Respond was pressed (the Overview, Needs, an event’s page or the map drawer).

Round 7, layout polish (UX, for review): tabs read Overview, Members, Events, Resources, Needs; the four figures read Member organizations, Events, Shared resources, Open needs; once invitations are sent, Invite organizations leaves the header’s main button for More actions; each need in Needs and fulfillment is its own card with the bar, one short line and Respond inside it, and a secondary note only when orders exist in another unit; the drawer dims and blocks the page behind it; an empty map shows no placeholder.

Round 7, map (Decision 26): the map zooms like an online map. Nearby places are grouped into one dark bubble whose number counts their open needs and shared resources together (estimating default 7: records). Behind the markers, major highways (I-10, I-12, I-20, I-49, I-55, I-59, I-65 and a few US and state routes) are drawn as simplified lines through the towns they pass, approximate and for orientation only, and are named where they fit when zoomed in. Selecting a grouped marker zooms in on its area: the places it grouped separate into their own markers, and the list under the map shows the places in view. Selecting a place zooms in on its surroundings (about a city’s area, with the coast, response areas and the names of nearby places still visible; nearby places outside the view are named at the edge with their direction and straight-line distance, and a scale bar shows how far the view reaches). GIK records places at city level, so a place stays one marker however close the view; its needs and shared resources are listed under the map, never placed at invented positions. There are three views at most: all locations, an area (Mobile area) and a place (Jackson, MS), so a place is never more than two steps away. + moves one view closer (from an area, to the place nearest the centre, which is then selected) and is off at a place; − moves one view out; Reset view returns to all locations. At a place, selecting markers never zooms further: the list under the map holds the detail, with needs (progress, owner, urgency; each opens the drawer) and shared resources (quantity available, owner, View resource) in separate groups. A need, from the map or the list, opens on the right in a drawer beside the page, not a dialog, with its progress, what was requested and Respond; another need replaces it; Close or Escape closes it. Zoom in (+), Zoom out (−) and Reset view sit in the map’s corner; a line above the map says what it shows, for example Viewing Jackson, MS · Reset view. Layers is a dropdown (UX proposal): the button names what is on, and the list has Response areas and Member locations as checkboxes, either or both on. Zooming never changes All, Needs or Resources, the layers, the event or the network picker. The Networks page and an event’s page use the same map, each with its own zoom. ▲ Open: whether the number on a marker counts needs or quantity. The prototype counts open needs and the Map key says so (provisional).

Round 7, one Overview layout (GIK 2026-10-26, Release 1 scope line 4; Decision 30 answered by GIK): Option B, after Shabab Gruberg’s 2026-10-21 whiteboard, is the only Overview, in the examples and in your session; the Option A comparison and the Overview layout control are gone. The same composition in every state, setup included: the four figures (at zero for a new network); the top row, which is the guided Get your network ready checklist while the network has no event (in the wider column; it is taller than Quick actions because it carries the guidance) and Quick actions once it has one, always beside Network info (description, Created by, your role); then the map, the current event beside needs, and Recent activity, each only once the network has something to show in it. A new network shows the figures at zero, Add event and Network info, with no empty map, event, needs or activity cards and nothing invented; once invitations go out, Recent activity shows them. A member’s top row is Quick actions, with one line saying events, needs and shared resources appear as members add them. Quick actions follow the organization’s type and its permissions (Simon Vance, 2026-10-26): a Nonprofit sees Post a need (primary) and Share resource; a Supplier sees Share resource (primary). Share resource keeps its name after an organization has shared; managing what it already shares stays on the Resources tab. The header has no primary button and doesn’t repeat these: its More actions holds network administration by permission (Invite organizations, Add event and Manage members for a Network Admin; Leave network where allowed). The convener starts as a Network Admin; there is no separate owner role. ▲ Government organizations keep the earlier set of actions: v0.18 doesn’t define theirs, and no Government organization is in Viewing as. ▲ Order differs from the scope document: line 4 puts the main action above the four figures. During setup the prototype does that (Get your network ready sits above them); once setup is done it keeps the figures first, with Quick actions beside Network info beneath them, provisionally. Line 4 calls the card About this network; the prototype calls it Network info. Impact and Delivery routes are Later (not in Release 1) and not shown.

Round 5 navigation: partner networks: Overview, Needs, Resources, Events, Members, and in rounds 5 and 6 Impact (Exploration); round 7 has no Impact tab (Decisions 24 and 27). Every member sees the Members tab; Network Admins also get Invite organizations there, as the Overview’s main action, under More actions as Manage members, and in Get your network ready. The tab bar now wraps on narrow screens: in R4 it scrolled in one row, which hid Resources and Members off-screen at phone and narrow-window widths.

Round 5: this Overview is round 5’s selected dashboard, built from Option A’s cards; step 9, Overview, has its notes and examples. Notes here that describe the Overview’s layout were written for round 4’s baseline Overview; what each card does is unchanged.

Populated on purpose: an established network after setup, in prototype data: fifteen member organizations (Non-Profit and Supplier), two of them Network Admins (Convoy of Hope, a Non-Profit, and Kimball Household Goods, a Supplier), seven pending invitations and one by email, two declined, eleven resources shared by nine organizations of both types, six open needs, and a week of activity. Add ?fixture=large to the address for about a hundred organizations.

Readable, not one long list: each module shows a few items with View all: six resources, four needs, eight activity updates. Nothing is added just to fill space.

▲ Open, exposed by this state: how a busy network’s resources are browsed beyond the Overview (the Marketplace with a Partner network filter is the next pass); whether GIK wants an activity view.

Working internal direction (2026-10-07 internal review): the Overview answers what is happening in the network now, what is being coordinated, and what the viewer can do next. Member and invitation management live on Members.

Top of the Overview: the network’s status as KPI cards first (member organizations, shared resources, open needs, and pending invitations, which only a Network Admin sees; a Member gets three), then context in two groups beneath them: Event context (the event, strongest, and its area) and Network details (who convened it, your organization with its type, and your Network role, kept as separate items). Each count is a count of prototype records and matches its list; none is a metric.

No members list on the Overview: the Members tab is the directory and the place to manage it; the Overview keeps only the member count, in the tab and the snapshot. A network with no one joined yet gets a prompt under Needs your attention.

Order of the page: status and context, then About this network (the network beside the current event notes), then a main column with what the network needs (members’ open needs, up to four in a 2 × 2 grid) and what is available (shared resources), beside a supporting column with what it is planning for (the response supply plan) and a compact activity feed (five updates, then View all). Each card keeps its natural height, so a sparse section never becomes a large empty box; on a phone the order is needs, plan, resources, activity.

Post a need sits on Members’ open needs, and in its empty state, for any organization whose acting user may post needs (a capability, never organization type; every persona here may, as a prototype assumption). It hands off to GIK’s existing need form with this network named as the context; no fields are added. Model dependency: ERD round 1 gives needs no network link (only offers and orders carry network_id, R5), so a need appears here because the posting organization is a member (D17), and it stays visible to other signed-in GIK organizations as every need is. Linking a need to a network is open.

Actions sit with what they change: Add or Manage resources in the header; Edit on About; Manage on the supply plan; View and ordering on each resource; inviting and managing organizations on Members (Invite organizations also stays in a Network Admin’s header). There is no separate quick-actions panel.

Pending invitations are reviewed from their KPI card: a Network Admin sees the count with Review, which opens Members on the Pending filter. There is no separate banner repeating the count. Members never see invitation counts or actions. A one-line prompt appears only when nothing is pending and no one has joined yet, offering Invite organizations.

Invite-only network is the network’s access model, shown as plain text with a lock under the name, never as a chip, so it is not read as a role, an organization type or a membership status.

Event as text: there is no event detail screen in the prototype, so the event name is not a link. Linking it to GIK’s disaster record is for when that screen is drawn.

Recent activity: only what the workflows already do: the network created, invitations sent and declined (Network Admins only), organizations joining, resources shared, a member’s need posted, and Network roles changed. Grouped by day; times are prototype data. No posts, comments, reactions or announcements. ▲ Open: whether GIK wants an activity view and which records carry dates (ERD round 1 gives invitations and shares none); the spec lists a widget-based dashboard as Later.

First release, item 5 and working decision D17: members, what is shared, and members’ existing open needs, filtered by membership; their audience does not change. Needs show their urgency, location, disaster tag and fulfilment as GIK needs already do.

Convened by names the organization that created the network (networks.convener_organization_id), and nothing more: not owner, not sole administrator.

▲ Decision pending, current focus: the review raised a network having a changing current focus. The Overview conveys it only with what exists (the event and its notes, open needs, shared resources, activity); no Current Focus field is added.

▲ Open (R11): whether the convener counts as a member. It is included in the member count shown here; how it is counted for the exit criteria (D14) is not decided.

About this network: two separate texts. The network’s own description stays with the network (ERD round 1 has networks.description). The current event notes describe the response now. A Network Admin edits both with Edit; members read them. The event itself and its area come from GIK’s disaster record and are not edited here.

Prototype assumption: ERD round 1 has no field for event notes; where they would live depends on R9 (an events table, or disaster_id and event_label on the network). Drawn as a separate text so the network and the event are never one thing.

Response supply plan: the starter supply list from the template, carried into the established network as the supply types this response expects to need. Every member can see it; a Network Admin manages it (add, remove), with each item labelled by where it came from: the template, or added by a Network Admin. Removing or replacing the template later does not remove these items; the template rules only act at creation.

Planning guidance only: it is no one’s inventory, not a posted need, reserves and commits nothing, and implies no fulfilment. Needs and orders stay the existing workflows. Gap: where the plan is stored is open (T8, ERD R10); showing it to members is working internal direction, not a spec requirement.

Network first, events beneath: the header names the network; its events are on the Events tab and in the Overview’s Current event card, whose selector also focuses the map. A network can hold several events (Decision 1); closing an event and an event’s focus (Decision 4) are not drawn.

Answered (Decision 1, GIK 2026-10-08): a Partner Network is a standing group that works on many events over time; Decision 2 (Brian Anderson, 2026-10-10) adds that it can have none. ERD round 3 drafts an event record per network (R2) in place of round 1’s one event per network (R1), for Mike Perry to confirm (T9).

▲ Still open: how several networks working on the same event relate, and how an event’s focus (Primary focus, Active or Watching, in the spec’s Add an event flow, Decision 4) is set and shown; the prototype draws no focus.

Three things, kept apart: the Partner Network is the group of organizations and is what you create and name; an Event is something it coordinates around, shown beneath the network as context; a Disaster is one kind of event, a GIK disaster record, used in this Gray Sky scenario. “Other event” is the free-form alternative (D2). No wider event taxonomy is proposed.

History (round 4), superseded in round 6: ERD round 1 R1 scopes a network to one event, and D-b and the ontology say a network with no disaster is “still event-scoped, never standing” (networks.disaster_id and event_label, both optional). R9, whether events become their own table, is open. The prototype keeps one event per network and says so; it does not draw event history, adding or switching events, or a standing-network mode. A model implementing a proposal is not approval.

Current in round 6: a network is a standing group of organizations that can work on several events, or none (Decisions 1 and 2). Events are added and edited from its Events tab, each with its own type and stage (Decision 29). Closing an event (Decision 4) is not drawn yet.

Round 5 navigation: partner networks: Overview, Needs, Resources, Events, Members, and in rounds 5 and 6 Impact (Exploration); round 7 has no Impact tab (Decisions 24 and 27). Every member sees the Members tab; Network Admins also get Invite organizations there, as the Overview’s main action, under More actions as Manage members, and in Get your network ready. The tab bar now wraps on narrow screens: in R4 it scrolled in one row, which hid Resources and Members off-screen at phone and narrow-window widths.

Working internal direction (2026-10-07 internal review): membership is managed here, not on the Overview: a member directory built for hundreds of organizations. State filters with counts (All, Joined, Pending, Declined), one search across organizations and email invitations, a compact table (organization, type, Network role, status, and for Network Admins the source and a Manage action), 25 rows at a time with Show more. Add ?fixture=large to the address for a network of about a hundred organizations.

Invitations belong here: an invitation is sent from Invite organizations and then stays Pending until the organization accepts (Joined) or declines (Declined). Pending rows show where the organization came from (template, previous network or Added by you). Invite organizations stays a separate action.

Manage → Network role: a Network Admin opens Manage on a joined organization and switches it between Member and Network Admin, with what each can do spelled out. Several organizations can be Network Admins at once. Members see the directory without these controls.

Model R3: an invitation is pending, accepted, declined or expired. Expiry is not drawn because nothing in the prototype expires (T6). Invitations carry no sent date in ERD round 1, so none is drawn.

Organizations, not people: each row is a member organization. People act on behalf of their organization; no individual is shown as a member, and no designated contacts are drawn.

First release item 8 and T6: removing a member and canceling an invitation are drawn in round 4 (from Manage on each row). Leaving a network and resending an invitation are in the spec’s scope but not drawn yet. Re-inviting a declined organization is not decided.

Pending and declined are listed for Network Admins only; a member sees joined organizations only.

Roles (Release 1, scope line 3): Network Admin and Member; a Network Admin makes or removes admins and removes members, and an organization can leave (the convener and the last admin can’t). The prototype shows several Network Admins for testing. ▲ Open: designated contacts and any finer permissions.

Two separate things: organization type (Non-Profit, Supplier) describes the organization; the Network role (Network Admin, Member) is per network and held by the organization. Either type can hold either role. “Network Admin” is used instead of “Admin” so it is not confused with an organization’s own GIK administrator.

Prototype assumption, what a Network Admin can do: invite organizations, manage membership and invitations, and manage Network roles. It is not a confirmed permission set, and resource sharing stays with each organization: a Member that manages its resources shares them; a Network Admin that doesn’t, doesn’t. A network keeps at least one Network Admin (also an assumption): demoting the last one is blocked with an explanation, and every role change asks for confirmation first.

Model R2: network_memberships carry a role of admin or member, so several organizations holding the admin role fits the model as drawn. Gap: who may change roles, and whether the convener can be demoted, are not decided; both are allowed here. “Convened by” names the creating organization, never sole owner or sole administrator.

Established network: fifteen joined (two Network Admins), seven pending plus one email invitation, and two declined. Use the state filters, search and Manage.

Pending, filtered: the Pending filter lists only invitations still awaiting an answer, with where each organization came from. Search narrows within it, and the counts stay visible on every filter.

Working internal direction (2026-10-07 internal review): membership is managed here, not on the Overview: a member directory built for hundreds of organizations. State filters with counts (All, Joined, Pending, Declined), one search across organizations and email invitations, a compact table (organization, type, Network role, status, and for Network Admins the source and a Manage action), 25 rows at a time with Show more. Add ?fixture=large to the address for a network of about a hundred organizations.

Invitations belong here: an invitation is sent from Invite organizations and then stays Pending until the organization accepts (Joined) or declines (Declined). Pending rows show where the organization came from (template, previous network or Added by you). Invite organizations stays a separate action.

Manage → Network role: a Network Admin opens Manage on a joined organization and switches it between Member and Network Admin, with what each can do spelled out. Several organizations can be Network Admins at once. Members see the directory without these controls.

Model R3: an invitation is pending, accepted, declined or expired. Expiry is not drawn because nothing in the prototype expires (T6). Invitations carry no sent date in ERD round 1, so none is drawn.

Organizations, not people: each row is a member organization. People act on behalf of their organization; no individual is shown as a member, and no designated contacts are drawn.

First release item 8 and T6: removing a member and canceling an invitation are drawn in round 4 (from Manage on each row). Leaving a network and resending an invitation are in the spec’s scope but not drawn yet. Re-inviting a declined organization is not decided.

Pending and declined are listed for Network Admins only; a member sees joined organizations only.

Roles (Release 1, scope line 3): Network Admin and Member; a Network Admin makes or removes admins and removes members, and an organization can leave (the convener and the last admin can’t). The prototype shows several Network Admins for testing. ▲ Open: designated contacts and any finer permissions.

Two separate things: organization type (Non-Profit, Supplier) describes the organization; the Network role (Network Admin, Member) is per network and held by the organization. Either type can hold either role. “Network Admin” is used instead of “Admin” so it is not confused with an organization’s own GIK administrator.

Prototype assumption, what a Network Admin can do: invite organizations, manage membership and invitations, and manage Network roles. It is not a confirmed permission set, and resource sharing stays with each organization: a Member that manages its resources shares them; a Network Admin that doesn’t, doesn’t. A network keeps at least one Network Admin (also an assumption): demoting the last one is blocked with an explanation, and every role change asks for confirmation first.

Model R2: network_memberships carry a role of admin or member, so several organizations holding the admin role fits the model as drawn. Gap: who may change roles, and whether the convener can be demoted, are not decided; both are allowed here. “Convened by” names the creating organization, never sole owner or sole administrator.

Member → Network Admin: Salvation Army, a Non-Profit Member, is being made a Network Admin. Save role asks for confirmation; Make Network Admin applies it to this example (in your session it persists), and the network then has three Network Admins.

Roles (Release 1, scope line 3): Network Admin and Member; a Network Admin makes or removes admins and removes members, and an organization can leave (the convener and the last admin can’t). The prototype shows several Network Admins for testing. ▲ Open: designated contacts and any finer permissions.

Two separate things: organization type (Non-Profit, Supplier) describes the organization; the Network role (Network Admin, Member) is per network and held by the organization. Either type can hold either role. “Network Admin” is used instead of “Admin” so it is not confused with an organization’s own GIK administrator.

Prototype assumption, what a Network Admin can do: invite organizations, manage membership and invitations, and manage Network roles. It is not a confirmed permission set, and resource sharing stays with each organization: a Member that manages its resources shares them; a Network Admin that doesn’t, doesn’t. A network keeps at least one Network Admin (also an assumption): demoting the last one is blocked with an explanation, and every role change asks for confirmation first.

Model R2: network_memberships carry a role of admin or member, so several organizations holding the admin role fits the model as drawn. Gap: who may change roles, and whether the convener can be demoted, are not decided; both are allowed here. “Convened by” names the creating organization, never sole owner or sole administrator.

Network Admin → Member: Kimball Household Goods, a Supplier Network Admin, is being made a Member. It keeps Manage resources, because sharing its own resources does not depend on the Network role. The last remaining Network Admin can’t be made a Member; the dialog explains why.

Roles (Release 1, scope line 3): Network Admin and Member; a Network Admin makes or removes admins and removes members, and an organization can leave (the convener and the last admin can’t). The prototype shows several Network Admins for testing. ▲ Open: designated contacts and any finer permissions.

Two separate things: organization type (Non-Profit, Supplier) describes the organization; the Network role (Network Admin, Member) is per network and held by the organization. Either type can hold either role. “Network Admin” is used instead of “Admin” so it is not confused with an organization’s own GIK administrator.

Prototype assumption, what a Network Admin can do: invite organizations, manage membership and invitations, and manage Network roles. It is not a confirmed permission set, and resource sharing stays with each organization: a Member that manages its resources shares them; a Network Admin that doesn’t, doesn’t. A network keeps at least one Network Admin (also an assumption): demoting the last one is blocked with an explanation, and every role change asks for confirmation first.

Model R2: network_memberships carry a role of admin or member, so several organizations holding the admin role fits the model as drawn. Gap: who may change roles, and whether the convener can be demoted, are not decided; both are allowed here. “Convened by” names the creating organization, never sole owner or sole administrator.

Round 4, phase 8 (2026-10-09): Manage on each row stays the one place to manage an organization, for Network Admins only. On a Joined row it opens role management with Remove organization set apart below it; on a Pending row (organizations and email invitations) it opens the invitation with Cancel invitation. Declined rows have no Manage. Destructive actions are never the primary button in Manage, and each asks for confirmation.

Guards: no Remove for your own organization (leaving a network is a separate interaction, not drawn), the organization that convened the network, or the only Network Admin.

Round 4, phase 8 (2026-10-09): Manage on each row stays the one place to manage an organization, for Network Admins only. On a Joined row it opens role management with Remove organization set apart below it; on a Pending row (organizations and email invitations) it opens the invitation with Cancel invitation. Declined rows have no Manage. Destructive actions are never the primary button in Manage, and each asks for confirmation.

Guards: no Remove for your own organization (leaving a network is a separate interaction, not drawn), the organization that convened the network, or the only Network Admin.

Cancel invitation? Keep invitation returns to Manage; Cancel invitation completes it. A canceled invitation can no longer be accepted; the organization leaves Pending, every count updates, and it can be invited again later (it is not re-selected automatically on Invite organizations). Model R3: invitations are pending, accepted, declined or expired; canceled (revoked) is in T6’s scope and not in ERD round 1 yet.

After canceling: “Invitation canceled.”, one fewer Pending here and on the Overview, and the activity log records it for Network Admins. Get your network ready keeps Invite organizations done once any invitation was sent.

Round 4, phase 8 (2026-10-09): Manage on each row stays the one place to manage an organization, for Network Admins only. On a Joined row it opens role management with Remove organization set apart below it; on a Pending row (organizations and email invitations) it opens the invitation with Cancel invitation. Declined rows have no Manage. Destructive actions are never the primary button in Manage, and each asks for confirmation.

Guards: no Remove for your own organization (leaving a network is a separate interaction, not drawn), the organization that convened the network, or the only Network Admin.

Round 4, phase 8 (2026-10-09): Manage on each row stays the one place to manage an organization, for Network Admins only. On a Joined row it opens role management with Remove organization set apart below it; on a Pending row (organizations and email invitations) it opens the invitation with Cancel invitation. Declined rows have no Manage. Destructive actions are never the primary button in Manage, and each asks for confirmation.

Guards: no Remove for your own organization (leaving a network is a separate interaction, not drawn), the organization that convened the network, or the only Network Admin.

Remove organization? Keep organization returns to Manage; Remove organization completes it. An optional Reason for removal is a note for other Network Admins, shown only to them in the removed organization’s Manage; it is never required. The organization loses access to the network, its members’ open needs and network-only resources; previous orders and transaction history are preserved. Resources it shared with this network stop being shared here; their ownership and its other visibility settings don’t change, nor do other organizations’.

▲ Decision pending (S5, first release item 8): removal rules are not decided: notice to the organization, open orders, what happens to what it shared with the network, and whether it can be invited back. The prototype withdraws its network shares and allows re-inviting.

After removing: “Bayou Relief Kitchen removed from the network.” and Bayou listed under Removed with the date and who removed it; one fewer Joined and one fewer member organization on the Overview, its shared meals gone from this network’s Resources, and a notification to the organization. Activity it already took part in stays in the log.

Round 4, phase 9 (2026-10-09): Network Admins get a Removed filter on Members (All | Joined | Pending | Declined | Removed): organizations that were members and were removed, with type, previous role, date removed and who removed them, and Manage. Members never see it. Removed organizations have no access, count toward nothing, and are left out of All, which counts current members and live invitations only.

Manage on a removed organization: name and type, previous membership and role, removal date, removed by, and the reason if one was given (Network Admins only), with Re-invite organization.

Prototype data: Riverbend Church Outreach was removed on Oct 6 by Kimball Household Goods, a Network Admin, with a reason. Dates are prototype data.

Re-invite organization? Cancel or Send invitation. Sending creates a new Pending invitation: the organization leaves Removed for Pending, the pending count updates, and it must accept like any invitation. Membership, its previous role and access are not restored until it accepts. The removal stays in its history.

After re-inviting: “Invitation sent to Riverbend Church Outreach.”, Riverbend in Pending, one more pending invitation on the Overview, and nothing restored yet. Its Manage now shows the invitation, with Cancel invitation.

Round 5: this Overview is round 5’s selected dashboard, built from Option A’s cards; step 9, Overview, has its notes and examples. Notes here that describe the Overview’s layout were written for round 4’s baseline Overview; what each card does is unchanged.

Ordering follows ownership, not type: any organization with access to the network, Non-Profit or Supplier, can view and order a resource another organization shared. Its own shared resources stay visible, marked Your resource, with Manage resources where it manages them, and can never be ordered: not from the Overview, not from the resource detail, and an own resource is removed from the cart if it gets there another way. The Marketplace and network-filtered results follow the same rule when that pass is drawn; checkout here is the hand-off.

Supplier Network Admin: Kimball Household Goods, a Supplier, is also a Network Admin here: Quick actions has Share resource only, and More actions holds Invite organizations, Add event, Manage members and Leave network. It can’t post needs.

Resource action, the same for every organization type: an accepted member, or the network’s creator, whose acting user can manage the organization’s resources sees Add resources, then Manage resources once it shares, in the same header position (round 4; the creating organization’s part is open, R11). Organizations with nothing in their inventory are told to add it in GIK first.

Roles (Release 1, scope line 3): Network Admin and Member; a Network Admin makes or removes admins and removes members, and an organization can leave (the convener and the last admin can’t). The prototype shows several Network Admins for testing. ▲ Open: designated contacts and any finer permissions.

Two separate things: organization type (Non-Profit, Supplier) describes the organization; the Network role (Network Admin, Member) is per network and held by the organization. Either type can hold either role. “Network Admin” is used instead of “Admin” so it is not confused with an organization’s own GIK administrator.

Prototype assumption, what a Network Admin can do: invite organizations, manage membership and invitations, and manage Network roles. It is not a confirmed permission set, and resource sharing stays with each organization: a Member that manages its resources shares them; a Network Admin that doesn’t, doesn’t. A network keeps at least one Network Admin (also an assumption): demoting the last one is blocked with an explanation, and every role change asks for confirmation first.

Model R2: network_memberships carry a role of admin or member, so several organizations holding the admin role fits the model as drawn. Gap: who may change roles, and whether the convener can be demoted, are not decided; both are allowed here. “Convened by” names the creating organization, never sole owner or sole administrator.

Round 5 navigation: partner networks: Overview, Needs, Resources, Events, Members, and in rounds 5 and 6 Impact (Exploration); round 7 has no Impact tab (Decisions 24 and 27). Every member sees the Members tab; Network Admins also get Invite organizations there, as the Overview’s main action, under More actions as Manage members, and in Get your network ready. The tab bar now wraps on narrow screens: in R4 it scrolled in one row, which hid Resources and Members off-screen at phone and narrow-window widths.

Round 5: this Overview is round 5’s selected dashboard, built from Option A’s cards; step 9, Overview, has its notes and examples. Notes here that describe the Overview’s layout were written for round 4’s baseline Overview; what each card does is unchanged.

Non-Profit Member: Salvation Army (a Non-Profit) is a Member that has shared its hygiene kits, so it sees Manage resources but no Invite or Manage members, and reads About and the supply plan without Edit or Manage.

Resource action, the same for every organization type: an accepted member, or the network’s creator, whose acting user can manage the organization’s resources sees Add resources, then Manage resources once it shares, in the same header position (round 4; the creating organization’s part is open, R11). Organizations with nothing in their inventory are told to add it in GIK first.

Network, not event: a member sees these resources because its organization belongs to this network, not because it is linked to the same event. The network is its own context and filter; the event is separate (model: offers and orders carry network_id, R5, while the event sits on the network, R1 and R9). Members’ needs keep their own disaster tag, which is the need’s, not the network’s.

Before release (T5, D-c): shared resources are shown only to members, enforced by the platform.

Round 5 navigation: partner networks: Overview, Needs, Resources, Events, Members, and in rounds 5 and 6 Impact (Exploration); round 7 has no Impact tab (Decisions 24 and 27). Every member sees the Members tab; Network Admins also get Invite organizations there, as the Overview’s main action, under More actions as Manage members, and in Get your network ready. The tab bar now wraps on narrow screens: in R4 it scrolled in one row, which hid Resources and Members off-screen at phone and narrow-window widths.

Working internal direction (2026-10-07 internal review): membership is managed here, not on the Overview: a member directory built for hundreds of organizations. State filters with counts (All, Joined, Pending, Declined), one search across organizations and email invitations, a compact table (organization, type, Network role, status, and for Network Admins the source and a Manage action), 25 rows at a time with Show more. Add ?fixture=large to the address for a network of about a hundred organizations.

Invitations belong here: an invitation is sent from Invite organizations and then stays Pending until the organization accepts (Joined) or declines (Declined). Pending rows show where the organization came from (template, previous network or Added by you). Invite organizations stays a separate action.

Manage → Network role: a Network Admin opens Manage on a joined organization and switches it between Member and Network Admin, with what each can do spelled out. Several organizations can be Network Admins at once. Members see the directory without these controls.

Model R3: an invitation is pending, accepted, declined or expired. Expiry is not drawn because nothing in the prototype expires (T6). Invitations carry no sent date in ERD round 1, so none is drawn.

Organizations, not people: each row is a member organization. People act on behalf of their organization; no individual is shown as a member, and no designated contacts are drawn.

First release item 8 and T6: removing a member and canceling an invitation are drawn in round 4 (from Manage on each row). Leaving a network and resending an invitation are in the spec’s scope but not drawn yet. Re-inviting a declined organization is not decided.

Pending and declined are listed for Network Admins only; a member sees joined organizations only.

Roles (Release 1, scope line 3): Network Admin and Member; a Network Admin makes or removes admins and removes members, and an organization can leave (the convener and the last admin can’t). The prototype shows several Network Admins for testing. ▲ Open: designated contacts and any finer permissions.

Two separate things: organization type (Non-Profit, Supplier) describes the organization; the Network role (Network Admin, Member) is per network and held by the organization. Either type can hold either role. “Network Admin” is used instead of “Admin” so it is not confused with an organization’s own GIK administrator.

Prototype assumption, what a Network Admin can do: invite organizations, manage membership and invitations, and manage Network roles. It is not a confirmed permission set, and resource sharing stays with each organization: a Member that manages its resources shares them; a Network Admin that doesn’t, doesn’t. A network keeps at least one Network Admin (also an assumption): demoting the last one is blocked with an explanation, and every role change asks for confirmation first.

Model R2: network_memberships carry a role of admin or member, so several organizations holding the admin role fits the model as drawn. Gap: who may change roles, and whether the convener can be demoted, are not decided; both are allowed here. “Convened by” names the creating organization, never sole owner or sole administrator.

Member view: a Member sees joined organizations with their type and Network role, and no Manage, pending or declined.

Round 5: this Overview is round 5’s selected dashboard, built from Option A’s cards; step 9, Overview, has its notes and examples. Notes here that describe the Overview’s layout were written for round 4’s baseline Overview; what each card does is unchanged.

Supplier Member: the same Kimball Household Goods, in a variant of this example where only Convoy of Hope is a Network Admin. It keeps Manage resources and loses the admin actions; its type did not change.

Roles (Release 1, scope line 3): Network Admin and Member; a Network Admin makes or removes admins and removes members, and an organization can leave (the convener and the last admin can’t). The prototype shows several Network Admins for testing. ▲ Open: designated contacts and any finer permissions.

Two separate things: organization type (Non-Profit, Supplier) describes the organization; the Network role (Network Admin, Member) is per network and held by the organization. Either type can hold either role. “Network Admin” is used instead of “Admin” so it is not confused with an organization’s own GIK administrator.

Prototype assumption, what a Network Admin can do: invite organizations, manage membership and invitations, and manage Network roles. It is not a confirmed permission set, and resource sharing stays with each organization: a Member that manages its resources shares them; a Network Admin that doesn’t, doesn’t. A network keeps at least one Network Admin (also an assumption): demoting the last one is blocked with an explanation, and every role change asks for confirmation first.

Model R2: network_memberships carry a role of admin or member, so several organizations holding the admin role fits the model as drawn. Gap: who may change roles, and whether the convener can be demoted, are not decided; both are allowed here. “Convened by” names the creating organization, never sole owner or sole administrator.

Round 5: this Overview is round 5’s selected dashboard, built from Option A’s cards; step 9, Overview, has its notes and examples. Notes here that describe the Overview’s layout were written for round 4’s baseline Overview; what each card does is unchanged.

About this network: two separate texts. The network’s own description stays with the network (ERD round 1 has networks.description). The current event notes describe the response now. A Network Admin edits both with Edit; members read them. The event itself and its area come from GIK’s disaster record and are not edited here.

Prototype assumption: ERD round 1 has no field for event notes; where they would live depends on R9 (an events table, or disaster_id and event_label on the network). Drawn as a separate text so the network and the event are never one thing.

Network Admin only: Edit appears for Network Admins; Members read the same text. Saving changes this example only; in your session it persists.

Round 5: this Overview is round 5’s selected dashboard, built from Option A’s cards; step 9, Overview, has its notes and examples. Notes here that describe the Overview’s layout were written for round 4’s baseline Overview; what each card does is unchanged.

Response supply plan: the starter supply list from the template, carried into the established network as the supply types this response expects to need. Every member can see it; a Network Admin manages it (add, remove), with each item labelled by where it came from: the template, or added by a Network Admin. Removing or replacing the template later does not remove these items; the template rules only act at creation.

Planning guidance only: it is no one’s inventory, not a posted need, reserves and commits nothing, and implies no fulfilment. Needs and orders stay the existing workflows. Gap: where the plan is stored is open (T8, ERD R10); showing it to members is working internal direction, not a spec requirement.

Try it: add a supply type (it is labelled “Added by a Network Admin”), remove one, then Save. Nothing is posted, reserved or committed.

Round 5: this Overview is round 5’s selected dashboard, built from Option A’s cards; step 9, Overview, has its notes and examples. Notes here that describe the Overview’s layout were written for round 4’s baseline Overview; what each card does is unchanged.

A stress test, not a typical network: a deliberately full example to check the Overview at high density: 22 member organizations of both types, 3 Network Admins (Convoy of Hope and Magnolia Community Food Pantry, both Non-Profits, and Kimball Household Goods, a Supplier), 10 pending invitations (6 organizations, 4 by email), 2 declined, 16 shared resources, 10 open needs, a 15-type supply plan and 16 activity updates, with deliberately mixed name and title lengths. Prototype data. Most networks will look like the established example or sparser.

How it scales: counts in the KPI cards; six featured needs once a network has eight or more (four otherwise, three on a phone), most urgent first, four shared resources (all of them on the Resources tab), twelve supply types and six activity updates, each with View all. Cards keep their natural height in a main column (needs, then shared resources) and a supporting column (plan, then activity), so no card stretches into empty space and no gap opens between modules. Matching the needs and plan heights was tried: at this density the plan and activity run about 270 px taller than six featured needs, so matching would leave a large blank inside one card.

▲ Open, exposed by this state: how members browse a long list of shared resources and needs beyond View all (the Marketplace pass); whether resource updates and need fulfilment belong in an activity view at all.

Working internal direction (2026-10-07 internal review): the Overview answers what is happening in the network now, what is being coordinated, and what the viewer can do next. Member and invitation management live on Members.

Top of the Overview: the network’s status as KPI cards first (member organizations, shared resources, open needs, and pending invitations, which only a Network Admin sees; a Member gets three), then context in two groups beneath them: Event context (the event, strongest, and its area) and Network details (who convened it, your organization with its type, and your Network role, kept as separate items). Each count is a count of prototype records and matches its list; none is a metric.

No members list on the Overview: the Members tab is the directory and the place to manage it; the Overview keeps only the member count, in the tab and the snapshot. A network with no one joined yet gets a prompt under Needs your attention.

Order of the page: status and context, then About this network (the network beside the current event notes), then a main column with what the network needs (members’ open needs, up to four in a 2 × 2 grid) and what is available (shared resources), beside a supporting column with what it is planning for (the response supply plan) and a compact activity feed (five updates, then View all). Each card keeps its natural height, so a sparse section never becomes a large empty box; on a phone the order is needs, plan, resources, activity.

Post a need sits on Members’ open needs, and in its empty state, for any organization whose acting user may post needs (a capability, never organization type; every persona here may, as a prototype assumption). It hands off to GIK’s existing need form with this network named as the context; no fields are added. Model dependency: ERD round 1 gives needs no network link (only offers and orders carry network_id, R5), so a need appears here because the posting organization is a member (D17), and it stays visible to other signed-in GIK organizations as every need is. Linking a need to a network is open.

Actions sit with what they change: Add or Manage resources in the header; Edit on About; Manage on the supply plan; View and ordering on each resource; inviting and managing organizations on Members (Invite organizations also stays in a Network Admin’s header). There is no separate quick-actions panel.

Pending invitations are reviewed from their KPI card: a Network Admin sees the count with Review, which opens Members on the Pending filter. There is no separate banner repeating the count. Members never see invitation counts or actions. A one-line prompt appears only when nothing is pending and no one has joined yet, offering Invite organizations.

Invite-only network is the network’s access model, shown as plain text with a lock under the name, never as a chip, so it is not read as a role, an organization type or a membership status.

Event as text: there is no event detail screen in the prototype, so the event name is not a link. Linking it to GIK’s disaster record is for when that screen is drawn.

Recent activity: only what the workflows already do: the network created, invitations sent and declined (Network Admins only), organizations joining, resources shared, a member’s need posted, and Network roles changed. Grouped by day; times are prototype data. No posts, comments, reactions or announcements. ▲ Open: whether GIK wants an activity view and which records carry dates (ERD round 1 gives invitations and shares none); the spec lists a widget-based dashboard as Later.

First release, item 5 and working decision D17: members, what is shared, and members’ existing open needs, filtered by membership; their audience does not change. Needs show their urgency, location, disaster tag and fulfilment as GIK needs already do.

Convened by names the organization that created the network (networks.convener_organization_id), and nothing more: not owner, not sole administrator.

▲ Decision pending, current focus: the review raised a network having a changing current focus. The Overview conveys it only with what exists (the event and its notes, open needs, shared resources, activity); no Current Focus field is added.

▲ Open (R11): whether the convener counts as a member. It is included in the member count shown here; how it is counted for the exit criteria (D14) is not decided.

About this network: two separate texts. The network’s own description stays with the network (ERD round 1 has networks.description). The current event notes describe the response now. A Network Admin edits both with Edit; members read them. The event itself and its area come from GIK’s disaster record and are not edited here.

Prototype assumption: ERD round 1 has no field for event notes; where they would live depends on R9 (an events table, or disaster_id and event_label on the network). Drawn as a separate text so the network and the event are never one thing.

Response supply plan: the starter supply list from the template, carried into the established network as the supply types this response expects to need. Every member can see it; a Network Admin manages it (add, remove), with each item labelled by where it came from: the template, or added by a Network Admin. Removing or replacing the template later does not remove these items; the template rules only act at creation.

Planning guidance only: it is no one’s inventory, not a posted need, reserves and commits nothing, and implies no fulfilment. Needs and orders stay the existing workflows. Gap: where the plan is stored is open (T8, ERD R10); showing it to members is working internal direction, not a spec requirement.

Round 5: this Overview is round 5’s selected dashboard, built from Option A’s cards; step 9, Overview, has its notes and examples. Notes here that describe the Overview’s layout were written for round 4’s baseline Overview; what each card does is unchanged.

A stress test, not a typical network: a deliberately full example to check the Overview at high density: 22 member organizations of both types, 3 Network Admins (Convoy of Hope and Magnolia Community Food Pantry, both Non-Profits, and Kimball Household Goods, a Supplier), 10 pending invitations (6 organizations, 4 by email), 2 declined, 16 shared resources, 10 open needs, a 15-type supply plan and 16 activity updates, with deliberately mixed name and title lengths. Prototype data. Most networks will look like the established example or sparser.

How it scales: counts in the KPI cards; six featured needs once a network has eight or more (four otherwise, three on a phone), most urgent first, four shared resources (all of them on the Resources tab), twelve supply types and six activity updates, each with View all. Cards keep their natural height in a main column (needs, then shared resources) and a supporting column (plan, then activity), so no card stretches into empty space and no gap opens between modules. Matching the needs and plan heights was tried: at this density the plan and activity run about 270 px taller than six featured needs, so matching would leave a large blank inside one card.

▲ Open, exposed by this state: how members browse a long list of shared resources and needs beyond View all (the Marketplace pass); whether resource updates and need fulfilment belong in an activity view at all.

Member view: Salvation Army, a Non-Profit Member, sees the same content without Edit, Manage or the invitation alert; it can still post a need and order other members’ resources.

Ordering follows ownership, not type: any organization with access to the network, Non-Profit or Supplier, can view and order a resource another organization shared. Its own shared resources stay visible, marked Your resource, with Manage resources where it manages them, and can never be ordered: not from the Overview, not from the resource detail, and an own resource is removed from the cart if it gets there another way. The Marketplace and network-filtered results follow the same rule when that pass is drawn; checkout here is the hand-off.

A stress test, not a typical network: a deliberately full example to check the Overview at high density: 22 member organizations of both types, 3 Network Admins (Convoy of Hope and Magnolia Community Food Pantry, both Non-Profits, and Kimball Household Goods, a Supplier), 10 pending invitations (6 organizations, 4 by email), 2 declined, 16 shared resources, 10 open needs, a 15-type supply plan and 16 activity updates, with deliberately mixed name and title lengths. Prototype data. Most networks will look like the established example or sparser.

How it scales: counts in the KPI cards; six featured needs once a network has eight or more (four otherwise, three on a phone), most urgent first, four shared resources (all of them on the Resources tab), twelve supply types and six activity updates, each with View all. Cards keep their natural height in a main column (needs, then shared resources) and a supporting column (plan, then activity), so no card stretches into empty space and no gap opens between modules. Matching the needs and plan heights was tried: at this density the plan and activity run about 270 px taller than six featured needs, so matching would leave a large blank inside one card.

▲ Open, exposed by this state: how members browse a long list of shared resources and needs beyond View all (the Marketplace pass); whether resource updates and need fulfilment belong in an activity view at all.

Working internal direction (2026-10-07 internal review): membership is managed here, not on the Overview: a member directory built for hundreds of organizations. State filters with counts (All, Joined, Pending, Declined), one search across organizations and email invitations, a compact table (organization, type, Network role, status, and for Network Admins the source and a Manage action), 25 rows at a time with Show more. Add ?fixture=large to the address for a network of about a hundred organizations.

Invitations belong here: an invitation is sent from Invite organizations and then stays Pending until the organization accepts (Joined) or declines (Declined). Pending rows show where the organization came from (template, previous network or Added by you). Invite organizations stays a separate action.

Manage → Network role: a Network Admin opens Manage on a joined organization and switches it between Member and Network Admin, with what each can do spelled out. Several organizations can be Network Admins at once. Members see the directory without these controls.

Model R3: an invitation is pending, accepted, declined or expired. Expiry is not drawn because nothing in the prototype expires (T6). Invitations carry no sent date in ERD round 1, so none is drawn.

Organizations, not people: each row is a member organization. People act on behalf of their organization; no individual is shown as a member, and no designated contacts are drawn.

First release item 8 and T6: removing a member and canceling an invitation are drawn in round 4 (from Manage on each row). Leaving a network and resending an invitation are in the spec’s scope but not drawn yet. Re-inviting a declined organization is not decided.

Pending and declined are listed for Network Admins only; a member sees joined organizations only.

Roles (Release 1, scope line 3): Network Admin and Member; a Network Admin makes or removes admins and removes members, and an organization can leave (the convener and the last admin can’t). The prototype shows several Network Admins for testing. ▲ Open: designated contacts and any finer permissions.

Two separate things: organization type (Non-Profit, Supplier) describes the organization; the Network role (Network Admin, Member) is per network and held by the organization. Either type can hold either role. “Network Admin” is used instead of “Admin” so it is not confused with an organization’s own GIK administrator.

Prototype assumption, what a Network Admin can do: invite organizations, manage membership and invitations, and manage Network roles. It is not a confirmed permission set, and resource sharing stays with each organization: a Member that manages its resources shares them; a Network Admin that doesn’t, doesn’t. A network keeps at least one Network Admin (also an assumption): demoting the last one is blocked with an explanation, and every role change asks for confirmation first.

Model R2: network_memberships carry a role of admin or member, so several organizations holding the admin role fits the model as drawn. Gap: who may change roles, and whether the convener can be demoted, are not decided; both are allowed here. “Convened by” names the creating organization, never sole owner or sole administrator.

▲ Needs and Resources figures, a UX proposal (2026-10-27): three cards in the Overview’s style above each tab’s filters, for information only. Needs count needs, never amounts: Open needs (not fulfilled) of all needs; High urgency (open needs marked High); Being fulfilled (open needs with orders placed and not yet delivered, the bar’s middle part, using the event’s own amount when a need has one). The Event filter narrows all three to that event’s needs, and the first card names it; search, Status and Urgency don’t change them. A need for two events counts once for each event. Resources are the network’s, never an event’s: Shared resources and how many organizations share them; Available resources, those with supply left for this network (a set-aside amount less what the network has ordered, or else what is left in shared availability); In fulfillment, those with open orders recorded for this network. To decide (Decision 23): what counts as available and as in fulfillment. The sample data links no orders to resources in most examples (the orders behind a need’s bar aren’t tied to a resource), so In fulfillment shows 0 with Not linked to orders yet beneath it, saying why; the Hawaii Island sharing example, which records an order, shows 1.

Working internal direction (2026-10-07 internal review): a Resources tab beside Overview and Members holds every resource shared with this network: search by name, organization or category, filter by category and by organization (including Your resources), and each card shows the owner, category, quantity and location. The Overview keeps four with View all, which opens this tab.

Ordering follows ownership, not type: your organization’s own resources are marked Your resource with Manage; other organizations’ have View and Add to cart (one unit from the list, any quantity from the detail). Add or Manage resources for your organization sits in the header and at the top of the tab.

Network-scoped, not a second Marketplace: this tab lists what is shared with this network, for its members. The main Marketplace can still show the same resources alongside other eligible inventory, with a Partner network filter (the Marketplace pass). Prototype data: categories are illustrative; the build would use GIK’s existing resource categories.

Ordering follows ownership, not type: any organization with access to the network, Non-Profit or Supplier, can view and order a resource another organization shared. Its own shared resources stay visible, marked Your resource, with Manage resources where it manages them, and can never be ordered: not from the Overview, not from the resource detail, and an own resource is removed from the cart if it gets there another way. The Marketplace and network-filtered results follow the same rule when that pass is drawn; checkout here is the hand-off.

Your own, marked: Kimball Household Goods sees its bottled water and tarps marked Your resource, with Manage instead of Add to cart; Organization: Your resources filters to them.

Working internal direction (2026-10-07 internal review): a Resources tab beside Overview and Members holds every resource shared with this network: search by name, organization or category, filter by category and by organization (including Your resources), and each card shows the owner, category, quantity and location. The Overview keeps four with View all, which opens this tab.

Ordering follows ownership, not type: your organization’s own resources are marked Your resource with Manage; other organizations’ have View and Add to cart (one unit from the list, any quantity from the detail). Add or Manage resources for your organization sits in the header and at the top of the tab.

Network-scoped, not a second Marketplace: this tab lists what is shared with this network, for its members. The main Marketplace can still show the same resources alongside other eligible inventory, with a Partner network filter (the Marketplace pass). Prototype data: categories are illustrative; the build would use GIK’s existing resource categories.

A stress test, not a typical network: a deliberately full example to check the Overview at high density: 22 member organizations of both types, 3 Network Admins (Convoy of Hope and Magnolia Community Food Pantry, both Non-Profits, and Kimball Household Goods, a Supplier), 10 pending invitations (6 organizations, 4 by email), 2 declined, 16 shared resources, 10 open needs, a 15-type supply plan and 16 activity updates, with deliberately mixed name and title lengths. Prototype data. Most networks will look like the established example or sparser.

How it scales: counts in the KPI cards; six featured needs once a network has eight or more (four otherwise, three on a phone), most urgent first, four shared resources (all of them on the Resources tab), twelve supply types and six activity updates, each with View all. Cards keep their natural height in a main column (needs, then shared resources) and a supporting column (plan, then activity), so no card stretches into empty space and no gap opens between modules. Matching the needs and plan heights was tried: at this density the plan and activity run about 270 px taller than six featured needs, so matching would leave a large blank inside one card.

▲ Open, exposed by this state: how members browse a long list of shared resources and needs beyond View all (the Marketplace pass); whether resource updates and need fulfilment belong in an activity view at all.

Working internal direction (2026-10-07 internal review): a Resources tab beside Overview and Members holds every resource shared with this network: search by name, organization or category, filter by category and by organization (including Your resources), and each card shows the owner, category, quantity and location. The Overview keeps four with View all, which opens this tab.

Ordering follows ownership, not type: your organization’s own resources are marked Your resource with Manage; other organizations’ have View and Add to cart (one unit from the list, any quantity from the detail). Add or Manage resources for your organization sits in the header and at the top of the tab.

Network-scoped, not a second Marketplace: this tab lists what is shared with this network, for its members. The main Marketplace can still show the same resources alongside other eligible inventory, with a Partner network filter (the Marketplace pass). Prototype data: categories are illustrative; the build would use GIK’s existing resource categories.

Working decision D18 and first release, item 7: members order through the existing offer and cart flow. Drawn schematically; current GIK screens are not filed in the repo.

Shared by a Supplier, seen by a Non-Profit: Coastal Water Co. shared its water pallets with the network; Salvation Army sees them as a member and can order them.

Ordering follows ownership, not type: any organization with access to the network, Non-Profit or Supplier, can view and order a resource another organization shared. Its own shared resources stay visible, marked Your resource, with Manage resources where it manages them, and can never be ordered: not from the Overview, not from the resource detail, and an own resource is removed from the cart if it gets there another way. The Marketplace and network-filtered results follow the same rule when that pass is drawn; checkout here is the hand-off.

Round 4, phase 24 (2026-10-12): Edit resource sits at the top of a resource’s detail page, only for the organization that owns it and may manage its resources. Salvation Army viewing Coastal Water Co.Salvation Army viewing Coastal Supply’s water pallets#x2019;s water pallets sees no Edit, and neither does a Network Admin from another organization.

Edit resource: the owner edits what it entered on What do you have?: name, category, quantity available and unit, and description. Who can see it is shown but changed only on Add resources. Changes apply wherever the resource is listed; orders already placed keep their details. Save changes returns to the resource with Resource updated.

A Supplier orders too: Kimball Household Goods, a Supplier, views Coastal Water Co.’s water pallets and can add them to its cart. Who may order depends on network access and ownership, never on organization type.

Ordering follows ownership, not type: any organization with access to the network, Non-Profit or Supplier, can view and order a resource another organization shared. Its own shared resources stay visible, marked Your resource, with Manage resources where it manages them, and can never be ordered: not from the Overview, not from the resource detail, and an own resource is removed from the cart if it gets there another way. The Marketplace and network-filtered results follow the same rule when that pass is drawn; checkout here is the hand-off.

Your own resource: Kimball Household Goods views the bottled water it shared. It is marked Your resource, with Manage resources and no Add to cart.

Ordering follows ownership, not type: any organization with access to the network, Non-Profit or Supplier, can view and order a resource another organization shared. Its own shared resources stay visible, marked Your resource, with Manage resources where it manages them, and can never be ordered: not from the Overview, not from the resource detail, and an own resource is removed from the cart if it gets there another way. The Marketplace and network-filtered results follow the same rule when that pass is drawn; checkout here is the hand-off.

Ordering follows ownership, not type: any organization with access to the network, Non-Profit or Supplier, can view and order a resource another organization shared. Its own shared resources stay visible, marked Your resource, with Manage resources where it manages them, and can never be ordered: not from the Overview, not from the resource detail, and an own resource is removed from the cart if it gets there another way. The Marketplace and network-filtered results follow the same rule when that pass is drawn; checkout here is the hand-off.

Network, not event: the cart line shows the network the resource came through. It records no event, and the network is never inferred from an event.

What this shows: the network attribution on the cart line only (Release 1 scope line 9: the order records the network). Model R5: offers and orders carry a nullable network_id; cart lines have none, so how the network reaches the order is open (T7). Persistence is not validated here.

▲ Decision pending: mixed network and public carts, approval steps, and what happens if membership, sharing or availability changes before checkout completes.

Next pass (checkout): checkout, confirmation and order detail follow once current GIK screens are filed. ▲ Conflict, D14: how cross-partner orders are counted.

Round 5: this Overview is round 5’s selected dashboard, built from Option A’s cards; step 9, Overview, has its notes and examples. Notes here that describe the Overview’s layout were written for round 4’s baseline Overview; what each card does is unchanged.

Round 4, phase 16 (2026-10-09): Post a need is in Get your network ready and on Members’ open needs, for any organization that may post needs. It is optional; nothing else depends on it.

Needs visibility (Release 1 scope line 11, checked 2026-10-26): in the prototype only a network’s members reach its needs. Every network page, need, Respond and event screen requires membership (an invited organization sees its invitation, with no needs; a declined, removed or uninvited one is told the network isn’t available), and the Networks page, its map and search show needs only for networks you belong to. A need posted from a network appears in that network only. The earlier notes below that call network-only needs Later describe round 4’s assumption that such a need also stays visible in GIK’s Marketplace, which the prototype doesn’t draw and Release 1 rules out. ▲ For the build (Mike Perry): keeping network needs and shared inventory out of Marketplace search, matching, the API and MCP, which no screen here can show.

Option 1, full form (comparison): every field shown at once, as phase 18 drew it. Same fields, rules, review and confirmation as Option 2, including Associated events; kept so the two can be compared.

Needs visibility (Release 1 scope line 11, checked 2026-10-26): in the prototype only a network’s members reach its needs. Every network page, need, Respond and event screen requires membership (an invited organization sees its invitation, with no needs; a declined, removed or uninvited one is told the network isn’t available), and the Networks page, its map and search show needs only for networks you belong to. A need posted from a network appears in that network only. The earlier notes below that call network-only needs Later describe round 4’s assumption that such a need also stays visible in GIK’s Marketplace, which the prototype doesn’t draw and Release 1 rules out. ▲ For the build (Mike Perry): keeping network needs and shared inventory out of Marketplace search, matching, the API and MCP, which no screen here can show.

Round 4, phase 20 (2026-10-09), Option 2: progressive disclosure, the recommended default. Same fields and validation as Option 1, with the optional ones behind expanders: About this need shows title, description (grows as you type) and urgency; What do you need? shows item name, quantity and unit; Delivery shows one location field. Nothing is removed.

Source: fields follow GIK’s Post a Need as the product-matching prototypes capture it; required here: title, at least one item with a quantity, and a delivery location (an assumption).

History (round 4), superseded by Release 1 scope line 11: network-only needs. Posting from a network uses GIK’s existing need visibility: other signed-in GIK organizations can see it, and it appears in this network because the posting organization is a member (working decision D17, spec decision 17). No Private / Partner / Public choice is added for needs; selective sharing was confirmed for resources, not needs.

Needs visibility (Release 1 scope line 11, checked 2026-10-26): in the prototype only a network’s members reach its needs. Every network page, need, Respond and event screen requires membership (an invited organization sees its invitation, with no needs; a declined, removed or uninvited one is told the network isn’t available), and the Networks page, its map and search show needs only for networks you belong to. A need posted from a network appears in that network only. The earlier notes below that call network-only needs Later describe round 4’s assumption that such a need also stays visible in GIK’s Marketplace, which the prototype doesn’t draw and Release 1 rules out. ▲ For the build (Mike Perry): keeping network needs and shared inventory out of Marketplace search, matching, the API and MCP, which no screen here can show.

Associated events (Release 1, scope line 6; Decision 17): Event and deadline opens on its own when you arrive from an event (Post a need for this event, on the event’s page), with that event ticked. Associated events can be one, several or none. The first event listed sets the need’s one disaster when it is linked to one, marked with that event’s name, instead of asking again; if it isn’t, no disaster is set and a note names the disaster another ticked event is linked to. With several events a note says the need records one disaster, and warns when they link to different disasters. Choose a different disaster switches to the search; once you’ve picked one yourself, changing the events never overwrites it (Use the event’s disaster puts it back). With no event, the disaster is searched directly. ERD round 3 drafts the link between a need and its events (T10).

Round 6, associated events (spec v0.16 Decision 17): Post a need, in both form layouts, offers Associated events, a checkbox per network event, optional; a need’s own organization can change them from the need’s details. A need stays one record: it counts once in the network’s totals, keeps one requested amount, its orders and its progress, and appears under each of its events in the Needs and map filters and in each event’s open-need count. Changing its events never changes its amounts or progress.

▲ Estimating default 8, one requested amount per event (Decision 17; Mike Perry, then GIK): drawn: one sample need, Shelf-stable food for pantry restock, has its own amount and progress for each event (250 Cases for Hurricane Odalys, 150 for Coastal Louisiana flooding), and an event’s page shows that event’s amount; the need’s first event sets its one disaster, as the default says. Not drawn: Post a need asks for one amount however many events are ticked; changing a need’s events never splits its amount (the sample need’s events can’t be changed); and Respond, the offer and the order never ask which event they count toward, so the default’s “an order counts toward the event chosen when ordering” is not shown. For the estimate: an amount for each ticked event when posting, with its total; choosing the event when responding or ordering (only for a need with several events); what happens to amounts and orders when events are added or removed; and whether cards show the whole need or one event’s bar.

Category and requirements: GIK’s item categories, no network-specific ones; Tell us more about what you need takes size, material, wattage, fuel type or anything a supplier should match.

Example product, optional and secondary: Search for an example finds illustrative products by name or kind; Use adds one to the item (and fills its category if empty). It gives context only: suppliers match on the requirements, and it never asks for that exact product.

Paste a product link: a full link (https://) adds the product as the example; reading the product’s details from the link is simulated here.

Item cards: each item has its own name, category, requirements, optional example product, quantity and unit. Add another item collapses finished items to a one-line summary (name, quantity, unit, category); open or remove any of them before posting.

Finished items collapse: Add another item collapses finished items to a summary (name, quantity and unit, and Details added when there are any); the item being edited never collapses on its own. Open or remove any item before posting.

Quantity and unit: kept together in the item card, with GIK’s units (Pieces, Cases, Pallets, Boxes, Gallons, Pounds, Kits, Bags, Rolls). Quantity is how many the organization needs, separate from how an example is packaged.

Delivery location: one field: focus it to see the organization’s saved locations, or type to search any address. The choice shows as Delivering to, with Change.

Search any address: results match name, street or city and aren’t limited to saved warehouses (prototype addresses). Address validation is the live form’s.

Unloading capabilities: GIK’s five options as checkbox cards with their descriptions; pick any, or none if unsure.

Privacy, corrected: one small row: the need follows GIK’s usual visibility and also appears in the network because the organization is a member; delivery details are private by default, for matched suppliers only. Nothing says the need is network-only.

Collapsed, nothing lost: Event and deadline, the item’s details and Unloading capabilities are closed but keep their values, shown as a one-line summary on each expander (the event, disaster and deadline; category, specifications, example product; capabilities selected). The preview shows everything.

Errors are never hidden: an invalid product link opens the item’s details so the error shows; a missing delivery location shows under the field. A collapsed item with an error reopens on Preview.

Preview, before posting: the card and every detail: title, description, organization, network, associated events and disaster, urgency, deadline, each item with its quantity, category, requirements and example, delivery, unloading and the actual visibility. Edit keeps everything; only Post need posts.

Round 4, phase 16 (2026-10-09): Your need has been posted!, in the GIK confirmation pattern, with View need details and Go to Network Overview. Nothing redirects on its own; no commitment, order or match is created.

Round 5: this Overview is round 5’s selected dashboard, built from Option A’s cards; step 9, Overview, has its notes and examples. Notes here that describe the Overview’s layout were written for round 4’s baseline Overview; what each card does is unchanged.

Back on the Overview: Open needs and Members’ open needs include the new need, with its organization and event; Post a need is done in Get your network ready and stays available.

▲ Need Detail, a UX presentation (2026-10-27): the page now has the network pages’ width and cards, like the event page: the header with one action (Respond for an organization that can respond; Edit or close in GIK for the need’s own organization), Requested items beside the wider Need details (About this need, Request, Delivery; status and urgency stay in the header, with what is still needed when the need has one unit), then Fulfillment progress (with Progress by event for a need with an amount per event; separate bars for separate units, never added), then Matches. Already in GIK: the matching engine matches every live resource against every open need and grades each match; a nonprofit sees matches on each need; a supplier sees its matches and starts an offer pre-scoped to the matched resource and line item (Supplier Matches and Supplier Offers specs, drafts); a private resource’s matches are shown only to its supplier. Drawn here, sample matches only: the prototype has no matching engine and no grades, so Matches pairs a requested item with resources whose name fits it (or its category, when the item has one), taken only from resources shared with this network and from the viewer’s own inventory; another organization’s resource that isn’t shared here never appears, and nor does the need’s own organization’s. Actions are existing ones: Offer, on your own resource, opens the offer composer with that resource chosen for the item; View resource opens the resource, where a member can add it to a cart. Not drawn: match grades, sorting and filtering, Marketplace resources outside the network, and the supplier one-step give (Decision 31). Sample needs are existing GIK needs placed in this network in the prototype data, not posted through the walkthrough.

The new need: its fulfilment, every detail including Posted from and Associated events (with Change, for your own need), and Matches, through GIK’s existing matching and offers (not drawn).

Needs visibility (Release 1 scope line 11, checked 2026-10-26): in the prototype only a network’s members reach its needs. Every network page, need, Respond and event screen requires membership (an invited organization sees its invitation, with no needs; a declined, removed or uninvited one is told the network isn’t available), and the Networks page, its map and search show needs only for networks you belong to. A need posted from a network appears in that network only. The earlier notes below that call network-only needs Later describe round 4’s assumption that such a need also stays visible in GIK’s Marketplace, which the prototype doesn’t draw and Release 1 rules out. ▲ For the build (Mike Perry): keeping network needs and shared inventory out of Marketplace search, matching, the API and MCP, which no screen here can show.

An existing GIK need: Salvation Army posted this before joining; it shows in the network because the organization is a member, and it wasn’t reposted. Only its organization can edit it; a Network Admin can’t.

History (round 4), superseded by Release 1 scope line 11: network-only needs. Posting from a network uses GIK’s existing need visibility: other signed-in GIK organizations can see it, and it appears in this network because the posting organization is a member (working decision D17, spec decision 17). No Private / Partner / Public choice is added for needs; selective sharing was confirmed for resources, not needs.

Three different things: an organization’s existing GIK need, a need posted from a network (optionally with an event, proposed), and a future network-only need (Later). The prototype keeps them apart.

▲ Decision pending, suppliers: GIK’s Post a Need is in the Nonprofit portal (My Needs), so Kimball Household Goods, a Supplier, is told suppliers don’t post needs and is pointed to sharing resources instead. Confirm with GIK.

Templates stay planning: an event’s supply plan never becomes a posted need; needs are always posted by hand.

Needs visibility (Release 1 scope line 11, checked 2026-10-26): in the prototype only a network’s members reach its needs. Every network page, need, Respond and event screen requires membership (an invited organization sees its invitation, with no needs; a declined, removed or uninvited one is told the network isn’t available), and the Networks page, its map and search show needs only for networks you belong to. A need posted from a network appears in that network only. The earlier notes below that call network-only needs Later describe round 4’s assumption that such a need also stays visible in GIK’s Marketplace, which the prototype doesn’t draw and Release 1 rules out. ▲ For the build (Mike Perry): keeping network needs and shared inventory out of Marketplace search, matching, the API and MCP, which no screen here can show.

▲ Needs and Resources figures, a UX proposal (2026-10-27): three cards in the Overview’s style above each tab’s filters, for information only. Needs count needs, never amounts: Open needs (not fulfilled) of all needs; High urgency (open needs marked High); Being fulfilled (open needs with orders placed and not yet delivered, the bar’s middle part, using the event’s own amount when a need has one). The Event filter narrows all three to that event’s needs, and the first card names it; search, Status and Urgency don’t change them. A need for two events counts once for each event. Resources are the network’s, never an event’s: Shared resources and how many organizations share them; Available resources, those with supply left for this network (a set-aside amount less what the network has ordered, or else what is left in shared availability); In fulfillment, those with open orders recorded for this network. To decide (Decision 23): what counts as available and as in fulfillment. The sample data links no orders to resources in most examples (the orders behind a need’s bar aren’t tied to a resource), so In fulfillment shows 0 with Not linked to orders yet beneath it, saying why; the Hawaii Island sharing example, which records an order, shows 1.

Round 6, need progress (spec v0.16 Decisions 17 and 22, GIK 2026-10-13): one bar per requested amount, in its own unit, in three parts: Completed (orders delivered), Being fulfilled (orders placed, not yet delivered) and Still needed (what is left). Requested = completed + being fulfilled + still needed, and the three percentages add up to 100. A cart, a shared resource or a pledge never counts (Shabab Gruberg: a cart isn’t committed yet). Orders in another unit are listed beside the bar and never added in or converted. A need for more than one event shows its requested amount and progress for each event on its detail page, and the totals match. Each card leads with the title, the gap still needed and the bar; organization, place and urgency sit on one line.

Illustrative: the sample orders behind each bar, the being-fulfilled amounts and the Pallets order on Shelf-stable food are prototype data; R4 records no orders.

Limitation, event level and item level: progress is recorded for a requested amount, per event (Decision 17). A need’s items show what was requested in each item’s own unit, without progress of their own, because orders aren’t recorded per item. A need asking for items in more than one unit shows each unit as its own amount, never added together; orders on such a need aren’t split by unit, so none are assumed.

▲ Later (not drawn): pledges could become a fourth segment between Being fulfilled and Still needed once pledges exist (Shabab Gruberg, 2026-10-13). They would move only the pledge figure and leave completed and being fulfilled as they are. How the bar shows each figure stays open for review.

Round 4, phase 23 (2026-10-12): Needs sits between Events and Resources: Overview | Events | Needs | Resources | Members, with the open-need count. Network needs, “View needs posted by organizations in this network,” Post a need for organizations that may post, then search and Status, Urgency and Event filters. Cards reuse the Overview’s need card: status, urgency, title, item names, organization, city, related event, disaster tag and progress, with View need. No delivery address on cards.

Order: open needs by urgency (High, Medium, Low), fulfilled last. The count line reads 11 needs from 9 organizations · 10 open; the tab, the Overview’s Open needs and its card all count the same 10 open needs.

History (round 6), superseded by Release 1 scope line 11: the tab lists needs belonging to the network’s organizations (its convener and accepted members). Each keeps GIK’s existing visibility, so other signed-in GIK organizations can see it too. No network-only visibility is created; that remains a separate product decision for stakeholders (D17).

Prototype data: the established network with two events, Coastal Louisiana flooding and Hurricane Odalys, and three more members (River Parishes, Live Oak Shelter, Hope Kitchen). Eight needs relate to one of them, three to none, and the Magnolia Street shelter’s hygiene kits are fulfilled. A need is never tied to an event automatically.

Round 7, Respond (Decision 22; Supplier Offers spec, draft): the composer is opened already scoped to this need: its summary and progress, your own resources with what is available, a quantity for each and the requested item it is for, a note, then a review. It stops before sending and says that nothing was sent and progress did not move. Prototype hand-off; the offer itself is the Supplier Offers feature.

No needs posted yet: “Needs from organizations in this network will appear here,” with Post a need for an organization that may post. The filters are hidden until there’s something to filter.

Search: matches need titles, item names and posting organizations: “cots” finds Cots (Live Oak Shelter) and Cots and blankets (Harbor Light Family Shelter).

Urgency: All, High, Medium or Low, in a compact dropdown.

Status: Open (nothing fulfilled yet), Partially fulfilled or Fulfilled, from the need’s fulfilment so far.

Fulfilled needs: stay in the list for reference, marked Fulfilled; they leave the Overview’s open needs and the counts.

Event: All events, each of this network’s events, or No associated event. A need associated with several events appears under each of them, and still once in All events. Filtering is optional; by default every need shows, whatever its events.

Round 6, associated events (spec v0.16 Decision 17): Post a need, in both form layouts, offers Associated events, a checkbox per network event, optional; a need’s own organization can change them from the need’s details. A need stays one record: it counts once in the network’s totals, keeps one requested amount, its orders and its progress, and appears under each of its events in the Needs and map filters and in each event’s open-need count. Changing its events never changes its amounts or progress.

▲ Estimating default 8, one requested amount per event (Decision 17; Mike Perry, then GIK): drawn: one sample need, Shelf-stable food for pantry restock, has its own amount and progress for each event (250 Cases for Hurricane Odalys, 150 for Coastal Louisiana flooding), and an event’s page shows that event’s amount; the need’s first event sets its one disaster, as the default says. Not drawn: Post a need asks for one amount however many events are ticked; changing a need’s events never splits its amount (the sample need’s events can’t be changed); and Respond, the offer and the order never ask which event they count toward, so the default’s “an order counts toward the event chosen when ordering” is not shown. For the estimate: an amount for each ticked event when posting, with its total; choosing the event when responding or ordering (only for a need with several events); what happens to amounts and orders when events are added or removed; and whether cards show the whole need or one event’s bar.

No associated event: needs don’t need an event to appear.

Combined: search, Status, Urgency and Event apply together; the count line shows how many match, with Clear filters.

No matching needs found: “Try adjusting your search or filters,” with Reset filters. Different from a network with no needs.

▲ Need Detail, a UX presentation (2026-10-27): the page now has the network pages’ width and cards, like the event page: the header with one action (Respond for an organization that can respond; Edit or close in GIK for the need’s own organization), Requested items beside the wider Need details (About this need, Request, Delivery; status and urgency stay in the header, with what is still needed when the need has one unit), then Fulfillment progress (with Progress by event for a need with an amount per event; separate bars for separate units, never added), then Matches. Already in GIK: the matching engine matches every live resource against every open need and grades each match; a nonprofit sees matches on each need; a supplier sees its matches and starts an offer pre-scoped to the matched resource and line item (Supplier Matches and Supplier Offers specs, drafts); a private resource’s matches are shown only to its supplier. Drawn here, sample matches only: the prototype has no matching engine and no grades, so Matches pairs a requested item with resources whose name fits it (or its category, when the item has one), taken only from resources shared with this network and from the viewer’s own inventory; another organization’s resource that isn’t shared here never appears, and nor does the need’s own organization’s. Actions are existing ones: Offer, on your own resource, opens the offer composer with that resource chosen for the item; View resource opens the resource, where a member can add it to a cart. Not drawn: match grades, sorting and filtering, Marketplace resources outside the network, and the supplier one-step give (Decision 31). Sample needs are existing GIK needs placed in this network in the prototype data, not posted through the walkthrough.

Round 6, need progress (spec v0.16 Decisions 17 and 22, GIK 2026-10-13): one bar per requested amount, in its own unit, in three parts: Completed (orders delivered), Being fulfilled (orders placed, not yet delivered) and Still needed (what is left). Requested = completed + being fulfilled + still needed, and the three percentages add up to 100. A cart, a shared resource or a pledge never counts (Shabab Gruberg: a cart isn’t committed yet). Orders in another unit are listed beside the bar and never added in or converted. A need for more than one event shows its requested amount and progress for each event on its detail page, and the totals match. Each card leads with the title, the gap still needed and the bar; organization, place and urgency sit on one line.

Illustrative: the sample orders behind each bar, the being-fulfilled amounts and the Pallets order on Shelf-stable food are prototype data; R4 records no orders.

Limitation, event level and item level: progress is recorded for a requested amount, per event (Decision 17). A need’s items show what was requested in each item’s own unit, without progress of their own, because orders aren’t recorded per item. A need asking for items in more than one unit shows each unit as its own amount, never added together; orders on such a need aren’t split by unit, so none are assumed.

▲ Later (not drawn): pledges could become a fourth segment between Being fulfilled and Still needed once pledges exist (Shabab Gruberg, 2026-10-13). They would move only the pledge figure and leave completed and being fulfilled as they are. How the bar shows each figure stays open for review.

Partial progress: 90 of 400 cases fulfilled. Details show Status, the associated events and the need’s own disaster tag. Convoy of Hope is a Network Admin but can’t edit or close Magnolia’s need; it can offer resources through GIK.

Round 6, need progress (spec v0.16 Decisions 17 and 22, GIK 2026-10-13): one bar per requested amount, in its own unit, in three parts: Completed (orders delivered), Being fulfilled (orders placed, not yet delivered) and Still needed (what is left). Requested = completed + being fulfilled + still needed, and the three percentages add up to 100. A cart, a shared resource or a pledge never counts (Shabab Gruberg: a cart isn’t committed yet). Orders in another unit are listed beside the bar and never added in or converted. A need for more than one event shows its requested amount and progress for each event on its detail page, and the totals match. Each card leads with the title, the gap still needed and the bar; organization, place and urgency sit on one line.

Illustrative: the sample orders behind each bar, the being-fulfilled amounts and the Pallets order on Shelf-stable food are prototype data; R4 records no orders.

Limitation, event level and item level: progress is recorded for a requested amount, per event (Decision 17). A need’s items show what was requested in each item’s own unit, without progress of their own, because orders aren’t recorded per item. A need asking for items in more than one unit shows each unit as its own amount, never added together; orders on such a need aren’t split by unit, so none are assumed.

▲ Later (not drawn): pledges could become a fourth segment between Being fulfilled and Still needed once pledges exist (Shabab Gruberg, 2026-10-13). They would move only the pledge figure and leave completed and being fulfilled as they are. How the bar shows each figure stays open for review.

From the Needs tab: the breadcrumb runs through Needs, and Back to network needs returns there. Offer resources in GIK opens GIK’s existing matching and offers (not drawn): no network checkout, order or fulfilment system.

Your own need: marked Your need, with Edit or close in GIK. Only the posting organization manages it.

Post a need from the Needs tab: opens the existing R4 Post a Need form, in this network’s context. There is no separate posting flow.

Newly posted: Convoy of Hope’s new need (High urgency, Hurricane Odalys) appears in the list straight away, in this session or a preset, with no reset. The confirmation also offers View network needs.

Can’t post needs: Kimball Household Goods, a Supplier, sees every need and can respond through GIK, but has no Post a need; a line explains why (suppliers don’t post needs, decision pending).

Empty, without permission: no needs yet and no Post a need action.

Round 5: this Overview is round 5’s selected dashboard, built from Option A’s cards; step 9, Overview, has its notes and examples. Notes here that describe the Overview’s layout were written for round 4’s baseline Overview; what each card does is unchanged.

Back on the Overview: Members’ open needs shows the most urgent open needs, with View all needs opening this tab; the Open needs count matches the tab. Get your network ready keeps Post a need: it’s marked done only after a need is posted, not when the form is opened, and isn’t undone when a need is fulfilled or closed.

From an event: an event’s page now has View needs for this event, which opens the Needs tab filtered to it; the filter can be changed or cleared.

Kimball Household Goods, a Supplier: 2,403 illustrative inventory resources across ten categories and four locations: R4’s own Kimball resources (Bottled water, 100 cases; Tarps; Cleaning kits) and a generated catalog, 178 of them out of stock and 269 low. The table shows 50 rows a page instead of rendering thousands of cards; each row shows stock and every network the resource is shared with.

Both sharing methods kept for user testing (GIK, 2026-10-13): sharing a resource with a network so its members can see, request and order it is the confirmed baseline (Decision 20, answered by GIK on 2026-10-08); it doesn’t transfer stock. Shabab Gruberg asked to keep both ways, shared availability (first come, first served) and a set-aside quantity for one network, and learn from users (S15). Not final: how the last of the shared availability is held (R29), and whether a supplier sees which networks ordered from its open supply.

Selection persists: Kimball selected four resources, then searched for water in Food & Beverage. Tarps no longer match, and the tray says one selected resource is hidden by the filters; it stays selected. Show selected lists only the selection.

Both sharing methods kept for user testing (GIK, 2026-10-13): sharing a resource with a network so its members can see, request and order it is the confirmed baseline (Decision 20, answered by GIK on 2026-10-08); it doesn’t transfer stock. Shabab Gruberg asked to keep both ways, shared availability (first come, first served) and a set-aside quantity for one network, and learn from users (S15). Not final: how the last of the shared availability is held (R29), and whether a supplier sees which networks ordered from its open supply.

Bulk select: filtered to cleaning supplies that are in stock and not shared yet. Select all matching selects every match across all pages; the checkbox in the header selects this page; Clear selection empties the tray.

Both sharing methods kept for user testing (GIK, 2026-10-13): sharing a resource with a network so its members can see, request and order it is the confirmed baseline (Decision 20, answered by GIK on 2026-10-08); it doesn’t transfer stock. Shabab Gruberg asked to keep both ways, shared availability (first come, first served) and a set-aside quantity for one network, and learn from users (S15). Not final: how the last of the shared availability is held (R29), and whether a supplier sees which networks ordered from its open supply.

No results: nothing matches snow chains. The two selected resources stay in the tray, and Clear filters brings the list back.

Both sharing methods kept for user testing (GIK, 2026-10-13): sharing a resource with a network so its members can see, request and order it is the confirmed baseline (Decision 20, answered by GIK on 2026-10-08); it doesn’t transfer stock. Shabab Gruberg asked to keep both ways, shared availability (first come, first served) and a set-aside quantity for one network, and learn from users (S15). Not final: how the last of the shared availability is held (R29), and whether a supplier sees which networks ordered from its open supply.

From inside a network: Kimball chose Manage resources on Gulf Coast Response Partners’ Resources tab: the breadcrumb reads Networks › Gulf Coast › Resources › Manage resources, Gulf Coast is preselected with shared availability, the tabs are Add from your inventory, Shared with this network and Create new resource, and after sharing the flow returns to Gulf Coast’s Resources tab.

Both sharing methods kept for user testing (GIK, 2026-10-13): sharing a resource with a network so its members can see, request and order it is the confirmed baseline (Decision 20, answered by GIK on 2026-10-08); it doesn’t transfer stock. Shabab Gruberg asked to keep both ways, shared availability (first come, first served) and a set-aside quantity for one network, and learn from users (S15). Not final: how the last of the shared availability is held (R29), and whether a supplier sees which networks ordered from its open supply.

Several networks: Kimball’s three partner networks. Gulf Coast gets amounts set aside; Hawaii Island and Oklahoma share first come, first served.

Both sharing methods kept for user testing (GIK, 2026-10-13): sharing a resource with a network so its members can see, request and order it is the confirmed baseline (Decision 20, answered by GIK on 2026-10-08); it doesn’t transfer stock. Shabab Gruberg asked to keep both ways, shared availability (first come, first served) and a set-aside quantity for one network, and learn from users (S15). Not final: how the last of the shared availability is held (R29), and whether a supplier sees which networks ordered from its open supply.

Review before sharing: for each resource, the amount set aside for Gulf Coast, what each network’s members will see, and the split across networks. First-come networks all see the same open figure: in stock, less what is set aside, less what is on order from the open supply. Nothing changes until Share.

Never more than exists: amounts set aside can’t add up to more than is free, an amount can’t go below what that network already has on order, and out-of-stock resources can’t be set aside. A first-come network sees visibility, not a reservation; only a set-aside amount is held for one network, so stock is never counted twice.

Both sharing methods kept for user testing (GIK, 2026-10-13): sharing a resource with a network so its members can see, request and order it is the confirmed baseline (Decision 20, answered by GIK on 2026-10-08); it doesn’t transfer stock. Shabab Gruberg asked to keep both ways, shared availability (first come, first served) and a set-aside quantity for one network, and learn from users (S15). Not final: how the last of the shared availability is held (R29), and whether a supplier sees which networks ordered from its open supply.

Stock changed after selecting: since Kimball selected the bottled water, 70 cases were ordered from the open supply (illustrative), so only 30 are free and 40 can’t be set aside. Cleaning kits have no amount yet, and one selected resource is out of stock. Share stays disabled until each is fixed.

Both sharing methods kept for user testing (GIK, 2026-10-13): sharing a resource with a network so its members can see, request and order it is the confirmed baseline (Decision 20, answered by GIK on 2026-10-08); it doesn’t transfer stock. Shabab Gruberg asked to keep both ways, shared availability (first come, first served) and a set-aside quantity for one network, and learn from users (S15). Not final: how the last of the shared availability is held (R29), and whether a supplier sees which networks ordered from its open supply.

First come compared with set aside: Kimball’s 100 cases of bottled water: 40 set aside for Gulf Coast; Hawaii Island and Oklahoma first come, first served, with 10 already ordered by a Hawaii Island member (illustrative). Gulf Coast’s members see their 40. The other two each see the same 50 available, marked as also offered to other networks, without learning which. 40 + 50 + 10 = 100: nothing is counted twice.

Both sharing methods kept for user testing (GIK, 2026-10-13): sharing a resource with a network so its members can see, request and order it is the confirmed baseline (Decision 20, answered by GIK on 2026-10-08); it doesn’t transfer stock. Shabab Gruberg asked to keep both ways, shared availability (first come, first served) and a set-aside quantity for one network, and learn from users (S15). Not final: how the last of the shared availability is held (R29), and whether a supplier sees which networks ordered from its open supply.

Change an amount: Kimball tries 95 for Gulf Coast. Only 90 are free (100, less 10 on order), so Save explains the limit. Make first come and Stop sharing are on every row; stopping keeps any orders already placed.

Both sharing methods kept for user testing (GIK, 2026-10-13): sharing a resource with a network so its members can see, request and order it is the confirmed baseline (Decision 20, answered by GIK on 2026-10-08); it doesn’t transfer stock. Shabab Gruberg asked to keep both ways, shared availability (first come, first served) and a set-aside quantity for one network, and learn from users (S15). Not final: how the last of the shared availability is held (R29), and whether a supplier sees which networks ordered from its open supply.

A member’s view, set aside: on Gulf Coast’s Resources tab, Salvation Army, a member, sees Kimball’s 40 cases marked Set aside for this network, and every other resource with its owner, quantity and Shared availability. Members can view and order, never change another organization’s sharing.

Both sharing methods kept for user testing (GIK, 2026-10-13): sharing a resource with a network so its members can see, request and order it is the confirmed baseline (Decision 20, answered by GIK on 2026-10-08); it doesn’t transfer stock. Shabab Gruberg asked to keep both ways, shared availability (first come, first served) and a set-aside quantity for one network, and learn from users (S15). Not final: how the last of the shared availability is held (R29), and whether a supplier sees which networks ordered from its open supply.

▲ Needs and Resources figures, a UX proposal (2026-10-27): three cards in the Overview’s style above each tab’s filters, for information only. Needs count needs, never amounts: Open needs (not fulfilled) of all needs; High urgency (open needs marked High); Being fulfilled (open needs with orders placed and not yet delivered, the bar’s middle part, using the event’s own amount when a need has one). The Event filter narrows all three to that event’s needs, and the first card names it; search, Status and Urgency don’t change them. A need for two events counts once for each event. Resources are the network’s, never an event’s: Shared resources and how many organizations share them; Available resources, those with supply left for this network (a set-aside amount less what the network has ordered, or else what is left in shared availability); In fulfillment, those with open orders recorded for this network. To decide (Decision 23): what counts as available and as in fulfillment. The sample data links no orders to resources in most examples (the orders behind a need’s bar aren’t tied to a resource), so In fulfillment shows 0 with Not linked to orders yet beneath it, saying why; the Hawaii Island sharing example, which records an order, shows 1.

A member’s view, shared availability: on Hawaii Island Relief Partners’ Resources tab, the same water shows 50 available, first come, first served, also offered to other networks. Members never see another network’s set-aside quantity.

Both sharing methods kept for user testing (GIK, 2026-10-13): sharing a resource with a network so its members can see, request and order it is the confirmed baseline (Decision 20, answered by GIK on 2026-10-08); it doesn’t transfer stock. Shabab Gruberg asked to keep both ways, shared availability (first come, first served) and a set-aside quantity for one network, and learn from users (S15). Not final: how the last of the shared availability is held (R29), and whether a supplier sees which networks ordered from its open supply.