Partner Networks

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, private and partner networks grouped). 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).

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.

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.

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.

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

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.

▲ R5 proposal (phase 1): 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.

▲ R5 proposal (phase 1): 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.

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, private and partner networks grouped). 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).

R5 proposal (phase 2): Create network first asks which kind, after Brian Anderson’s R4.5 create flow (Decision 5 as he drew it). Partner Network continues to R4’s Create unchanged: name required, description optional, Create, then the Overview with Get your network ready; inviting stays a separate step afterwards. Private Network is a proposal and says so.

▲ Kept from R4, differs from R4.5: R4.5 lets you invite organizations while creating a partner network. R5 keeps R4’s simpler Create and invites afterwards.

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 Response 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. Response 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.

▲ Decision pending (D1): creating a network without an event matches the review’s direction that a network may outlive one event. ERD round 1 already allows it (networks.disaster_id and event_label are optional), but D-b and the ontology call such a network “still event-scoped, never standing”; whether a network can exist with no event, and later take on several, needs Shabab and GIK.

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 5: this Overview is drawn as Option A, Refined Existing; 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.

Stakeholder review (2026-10-08): Create network makes the network and opens its Overview directly, with a confirmation. Get your network ready offers four optional next steps (Invite organizations, Add event, Add resources, Post a need) that can be done in any order, now or later; there is no second setup wizard.

Starts empty: no event, no invited or joined organizations, no shared resources and no supply plan. The creating organization is the network’s first Network Admin. Creating sends no invitations and makes no one a member (model R2, D-a).

Each step lives somewhere else too: Invite organizations is in the header and on Members; Add event is on Event context; Post a need is on Members’ open needs. Get your network ready is a shortcut to them for a Network Admin, marks each as done, and disappears once all four are done.

Not drawn in this round: adding an event and sharing resources are their own steps (3 and 5), including for Convoy of Hope, the network’s creator.

▲ Open (R11) and the review: the review lists Add resources as a creator’s next step; the prototype’s working rule has been that the creating organization is not offered sharing while its membership is open (R11). For an organization that owns inventory, the step opens Add resources only where that rule already allows it. Which applies needs GIK.

Stakeholder review (2026-10-08): templates move out of Create, not out of the product. Response 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.

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 2): a private network of the organization’s own locations, after R4.5 (create, networks and network pages), drawn with R4’s Create form. Name required and description optional, as in R4; the locations are R4’s saved delivery locations for Convoy of Hope. Only the organization can see the network.

▲ Decision pending (Decision 21, R23, R24), for stakeholder validation: whether a private network holds an organization’s locations, related organizations, or both; whether it needs at least two locations; whether one is created automatically; whether an organization can have several; how permissions work; and what moving goods between sites does. GIK left private versus partner networks open at the 2026-10-08 review; R4.5’s answers are Brian Anderson’s direction (2026-10-10), not GIK’s. Nothing here enforces them.

▲ Decision pending, minimum locations: R4.5 requires at least two locations (“one site has nothing to move between”). R5 accepts one as an illustrative assumption; neither minimum is approved, and whether private networks hold locations at all is still open.

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).

Validation, R4’s pattern: the name is required, as in R4.

▲ R5 assumption, not a requirement: at least one location, so the network has something in it. Illustrative only: whether a minimum applies, and whether it counts locations or related organizations, needs stakeholder validation (Decision 21, R23).

▲ Illustrative edge case: a private network with no locations. R5’s Create asks for at least one location (an illustrative assumption), so this state only exists if that minimum is dropped; it shows what the Overview would offer first.

Private Network Overview: Option A as R4 draws it, with what applies to a private network: Add a location instead of Invite organizations, Locations instead of Member organizations and Pending invitations, Manage locations instead of Manage members, and Get your network ready with Add locations in place of Invite organizations. Events, shared resources and needs work as in a partner network.

▲ R5 proposal: events, shared resources and needs in a private network follow R4.5; whether a private network has them, and how, is not confirmed.

▲ Decision pending (Decision 21, R23, R24), for stakeholder validation: whether a private network holds an organization’s locations, related organizations, or both; whether it needs at least two locations; whether one is created automatically; whether an organization can have several; how permissions work; and what moving goods between sites does. GIK left private versus partner networks open at the 2026-10-08 review; R4.5’s answers are Brian Anderson’s direction (2026-10-10), not GIK’s. Nothing here enforces them.

Locations tab: in place of Members. The network’s locations with their addresses, Add a location for a Network Admin, and Move goods as a disabled placeholder: what moving goods between sites does is open (R24), so nothing moves.

▲ Decision pending (Decision 21, R23, R24), for stakeholder validation: whether a private network holds an organization’s locations, related organizations, or both; whether it needs at least two locations; whether one is created automatically; whether an organization can have several; how permissions work; and what moving goods between sites does. GIK left private versus partner networks open at the 2026-10-08 review; R4.5’s answers are Brian Anderson’s direction (2026-10-10), not GIK’s. Nothing here enforces them.

An established private network (illustrative): Kimball Household Goods created it with three of its four locations: its R4 Theodore warehouse plus three of R4.5’s sample sites; one event, and Cleaning kits shared between its sites. It was not created automatically. Kimball can’t post needs here either (R4’s rule for suppliers, decision pending).

Add a location: lists the organization’s locations not yet in the network; Add puts one in, recorded in the network’s activity. A location can be in more than one private network (R4.5’s proposal).

▲ Decision pending (Decision 21, R23, R24), for stakeholder validation: whether a private network holds an organization’s locations, related organizations, or both; whether it needs at least two locations; whether one is created automatically; whether an organization can have several; how permissions work; and what moving goods between sites does. GIK left private versus partner networks open at the 2026-10-08 review; R4.5’s answers are Brian Anderson’s direction (2026-10-10), not GIK’s. Nothing here enforces them.

On the Networks page: private networks sit apart, above partner networks, marked proposed; each card lists its first three locations and its counts. The section appears only when the organization has one, and none is created automatically. Private networks never appear in Invite’s previous networks or in another organization’s Networks page.

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: Response 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.

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.

Not in the spec or model yet: 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.

▲ Proposed MVP capability, pending confirmation (D12): inviting an organization that is not on GIK by email. The page marks the section Proposed.

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.

▲ Decision pending (with D12): how the recipient joins or creates a GIK organization, who accepts for it, and when the invitation becomes membership.

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 drawn as Option A, Refined Existing; 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: Response 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.

▲ Decision pending: The prototype currently demonstrates multiple Network Admins and Members for management testing. The final governance model, role names, designated contacts, and detailed permissions require GIK stakeholder validation.

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.

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.

▲ Exploratory, not GIK requirements: the fields (name, type, disaster record, area, description), the event types and the Events tab are design proposals for review.

▲ Decision pending (D1, with Shabab and GIK): several events per network goes beyond ERD round 1, which scopes a network to one event (R1; networks.disaster_id and event_label). An events table (R9) is the open question this draws.

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).

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.

Event type, proposed: 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.

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.

Round 4, phase 13 (2026-10-09), proposed: a Response 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.

Not confirmed: the 2026-10-08 review set the direction (standing networks, several events); how event-level templates behave is not defined by stakeholders yet. This is a UX proposal.

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.

▲ Departs from working decision D4: D4 has a template pre-fill suggested members and a supply list. This proposal drops the members on events; round 3 keeps the original behavior for comparison.

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 drawn as Option A, Refined Existing; 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.

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: Event context on the Overview shows the most recent event and how many there are. Whether a network has a current event, and who sets it, is for stakeholders.

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.

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.

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.

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 drawn as Option A, Refined Existing; 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.

▲ Decision pending: The prototype currently demonstrates multiple Network Admins and Members for management testing. The final governance model, role names, designated contacts, and detailed permissions require GIK stakeholder validation.

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.

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: Kimball’s bottled water is also shared with Hawaii Island Relief Partners; its tarps are public on the Marketplace; its cleaning kits are private.

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.

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).

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.

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).

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.

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.

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 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.

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).

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.

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.

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).

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.

Newly created partner network: nothing has happened yet: no members have joined and there are no events, needs or shared resources. Compare the Overview options in the Explorer bar.

Partly set up: Hurricane Odalys added and three invitations out, but nobody has joined and there are no needs or resources yet.

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.

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.

▲ 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).

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.

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, or a private network’s own 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 (and a private network’s locations), 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.

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.

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.

▲ Proposed, event selector: 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.

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, or a private network’s own 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 (and a private network’s locations), 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.

Network Admin: Convoy of Hope sees Invite organizations as the one primary action, with Post a need, Manage resources, Add event and Manage members under More actions, plus pending invitations in the metrics and Edit details.

Member: Salvation Army’s primary action is Post a need, with Manage resources in the menu; no invitations, Add event or member management, and no pending-invitation count.

Supplier Network Admin: in this network Kimball Household Goods, a Supplier, is also a Network Admin: Invite organizations leads, with Manage resources, Add event and Manage members under More actions. It can’t post needs (suppliers don’t, decision pending), so Post a need isn’t offered. Network Admin gives it no control over other organizations’ needs or resources.

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, or a private network’s own 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 (and a private network’s locations), 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): 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, or a private network’s own 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 (and a private network’s locations), 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): 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, or a private network’s own 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 (and a private network’s locations), 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 5 navigation: partner networks: Overview, Needs, Resources, Events, Members, Impact (Exploration). 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. Private networks: Overview, Locations, Resources, Needs, Events.

Round 5: this Overview is drawn as Option A, Refined Existing; 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, event beneath: the header names the network; the event it started around (Hurricane Odalys, a Disaster) sits beneath it as context, beside who convened it. No event history, adding or switching events, or current and past event states are drawn (D1 is pending).

▲ Decision pending (D1, with Shabab and GIK): This scenario shows a Network created around one Event. Internal review proposed that a Partner Network may be longer-lived and support multiple Events over time. Shabab/GIK still needs to validate that relationship.

Open questions: Can a Network exist without an Event? One Network to one Event, or one Network to many Events? Can several Networks support the same Event? Is a Disaster one type of Event? How does future Blue Sky (ongoing) collaboration fit this model? And, from the 2026-10-07 review (Brian): might a Network have a changing “current focus”? That stays a stakeholder question; no field is added for it.

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.

Model constraint, preserved and labelled: 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.

Round 5 navigation: partner networks: Overview, Needs, Resources, Events, Members, Impact (Exploration). 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. Private networks: Overview, Locations, Resources, Needs, Events.

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.

▲ Decision pending: The prototype currently demonstrates multiple Network Admins and Members for management testing. The final governance model, role names, designated contacts, and detailed permissions require GIK stakeholder validation.

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.

▲ Decision pending: The prototype currently demonstrates multiple Network Admins and Members for management testing. The final governance model, role names, designated contacts, and detailed permissions require GIK stakeholder validation.

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.

▲ Decision pending: The prototype currently demonstrates multiple Network Admins and Members for management testing. The final governance model, role names, designated contacts, and detailed permissions require GIK stakeholder validation.

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.

▲ Decision pending: The prototype currently demonstrates multiple Network Admins and Members for management testing. The final governance model, role names, designated contacts, and detailed permissions require GIK stakeholder validation.

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 drawn as Option A, Refined Existing; 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 a Network Admin: it sees Invite organizations and Manage members, and, separately, Manage resources for its own resources. Type does not decide either.

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.

▲ Decision pending: The prototype currently demonstrates multiple Network Admins and Members for management testing. The final governance model, role names, designated contacts, and detailed permissions require GIK stakeholder validation.

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, Impact (Exploration). 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. Private networks: Overview, Locations, Resources, Needs, Events.

Round 5: this Overview is drawn as Option A, Refined Existing; 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, Impact (Exploration). 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. Private networks: Overview, Locations, Resources, Needs, Events.

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.

▲ Decision pending: The prototype currently demonstrates multiple Network Admins and Members for management testing. The final governance model, role names, designated contacts, and detailed permissions require GIK stakeholder validation.

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 drawn as Option A, Refined Existing; 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.

▲ Decision pending: The prototype currently demonstrates multiple Network Admins and Members for management testing. The final governance model, role names, designated contacts, and detailed permissions require GIK stakeholder validation.

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 drawn as Option A, Refined Existing; 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 drawn as Option A, Refined Existing; 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 drawn as Option A, Refined Existing; 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 drawn as Option A, Refined Existing; 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.

▲ Decision pending: The prototype currently demonstrates multiple Network Admins and Members for management testing. The final governance model, role names, designated contacts, and detailed permissions require GIK stakeholder validation.

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.

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: proposed network attribution on the cart line only. 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.

Exploration, proposed (R4.5): the Impact tab. the sixth tab on a partner network, after Brian’s network page (Decision 26) and Impact (Decision 27), drawn with R4’s cards and tables: figures so far (orders completed, goods value, donated transport, organizations that gave and received, people served), a By event table with what was delivered in each unit, the completed orders behind it, and the network’s stories. Any member can see it. Private networks don’t have it (their tabs are Overview, Locations, Resources, Needs, Events).

▲ Not a confirmed requirement: the Impact tab is Brian Anderson’s exploration (Decisions 24 and 27, his direction, 2026-10-10 and 10-11), not GIK-confirmed and not in the MVP. It is labelled Exploration on the tab. Who writes, approves and sees stories, consent before naming a receiving organization, story visibility, and where people served comes from are Decision 24’s open questions; the stories table is round 3’s R22 (open).

▲ Illustrative data: R5 has no order records, so every figure comes from a short list of illustrative completed orders whose quantities equal the fulfilled amounts R4’s sample needs already show (24 of 60 Cases of bottled water, 150 of 150 hygiene kits, and so on). Each order is counted once; quantities are never added across units; goods value is an illustrative value per unit times quantity (T12); transport and people served are illustrative shipment estimates, and an order without one leaves people served out. Only Gulf Coast, Hawaii Island and Iowa River Valley have orders.

Event filter: with two or more events, narrow the figures to one; events in the table open R4’s event page. Coastal Louisiana flooding has one completed order (propane for Bayou Relief Kitchen).

▲ Illustrative data: R5 has no order records, so every figure comes from a short list of illustrative completed orders whose quantities equal the fulfilled amounts R4’s sample needs already show (24 of 60 Cases of bottled water, 150 of 150 hygiene kits, and so on). Each order is counted once; quantities are never added across units; goods value is an illustrative value per unit times quantity (T12); transport and people served are illustrative shipment estimates, and an order without one leaves people served out. Only Gulf Coast, Hawaii Island and Iowa River Valley have orders.

Supporting records: every figure can be traced to the orders behind it; each order links to its need. The orders are illustrative.

▲ Illustrative data: R5 has no order records, so every figure comes from a short list of illustrative completed orders whose quantities equal the fulfilled amounts R4’s sample needs already show (24 of 60 Cases of bottled water, 150 of 150 hygiene kits, and so on). Each order is counted once; quantities are never added across units; goods value is an illustrative value per unit times quantity (T12); transport and people served are illustrative shipment estimates, and an order without one leaves people served out. Only Gulf Coast, Hawaii Island and Iowa River Valley have orders.

A story waiting on you: Salvation Army sees that Water for Gulf Coast shelters names it and waits for its approval. A draft is visible only to the organization writing it; a story waiting for approval only to its writer and the organizations it names; approved and published stories to every member (fixing R4.5, which showed drafts to every member).

▲ Not a confirmed requirement: the Impact tab is Brian Anderson’s exploration (Decisions 24 and 27, his direction, 2026-10-10 and 10-11), not GIK-confirmed and not in the MVP. It is labelled Exploration on the tab. Who writes, approves and sees stories, consent before naming a receiving organization, story visibility, and where people served comes from are Decision 24’s open questions; the stories table is round 3’s R22 (open).

A published story: its text, quote, approvals and the sources it was drawn from, with links to the need and the event. “Published by GIK” is illustrative.

▲ Not AI, not published: the draft is a fixed prototype template filled from the chosen orders, after R4.5 (Brian’s draftFrom). It is labelled as such and must be checked before sending. Approvals are recorded per organization in this session; Ask GIK to publish only records a request. Nothing is published, and no AI drafts or approves anything.

Exploration, proposed (R4.5): drafting a story. any member can start one (who may write is open, Decision 24). Choose what it is about: each choice is one need with completed orders in this network, with its orders, amount, who gave, who received, dates and people served.

▲ Not AI, not published: the draft is a fixed prototype template filled from the chosen orders, after R4.5 (Brian’s draftFrom). It is labelled as such and must be checked before sending. Approvals are recorded per organization in this session; Ask GIK to publish only records a request. Nothing is published, and no AI drafts or approves anything.

Choosing the orders: untick an order to leave it out; the draft uses only what is ticked (working here; inert in R4.5).

▲ Not AI, not published: the draft is a fixed prototype template filled from the chosen orders, after R4.5 (Brian’s draftFrom). It is labelled as such and must be checked before sending. Approvals are recorded per organization in this session; Ask GIK to publish only records a request. Nothing is published, and no AI drafts or approves anything.

The draft and its sources: edit the title and text, add a quote. The Sources panel shows every fact and where it comes from. Save draft keeps it private to your organization.

▲ Not AI, not published: the draft is a fixed prototype template filled from the chosen orders, after R4.5 (Brian’s draftFrom). It is labelled as such and must be checked before sending. Approvals are recorded per organization in this session; Ask GIK to publish only records a request. Nothing is published, and no AI drafts or approves anything.

▲ Illustrative data: R5 has no order records, so every figure comes from a short list of illustrative completed orders whose quantities equal the fulfilled amounts R4’s sample needs already show (24 of 60 Cases of bottled water, 150 of 150 hygiene kits, and so on). Each order is counted once; quantities are never added across units; goods value is an illustrative value per unit times quantity (T12); transport and people served are illustrative shipment estimates, and an order without one leaves people served out. Only Gulf Coast, Hawaii Island and Iowa River Valley have orders.

Number check: a number that doesn’t match the orders (30 cases here, against 24) shows a warning that approvers will also see (R4.5 promised that but didn’t show it). It never blocks sending. Dates are left out of the check.

▲ Not AI, not published: the draft is a fixed prototype template filled from the chosen orders, after R4.5 (Brian’s draftFrom). It is labelled as such and must be checked before sending. Approvals are recorded per organization in this session; Ask GIK to publish only records a request. Nothing is published, and no AI drafts or approves anything.

Who it names: every organization named in the story, other than the writer, will be asked to approve it before members see it. A story naming nobody else is approved straight away.

▲ Not a confirmed requirement: the Impact tab is Brian Anderson’s exploration (Decisions 24 and 27, his direction, 2026-10-10 and 10-11), not GIK-confirmed and not in the MVP. It is labelled Exploration on the tab. Who writes, approves and sees stories, consent before naming a receiving organization, story visibility, and where people served comes from are Decision 24’s open questions; the stories table is round 3’s R22 (open).

Approving: Salvation Army approves, or asks for changes with a required comment. Once every named organization approves, members can see it; a Network Admin or the writer can then ask GIK to publish it beyond the network.

▲ Not a confirmed requirement: the Impact tab is Brian Anderson’s exploration (Decisions 24 and 27, his direction, 2026-10-10 and 10-11), not GIK-confirmed and not in the MVP. It is labelled Exploration on the tab. Who writes, approves and sees stories, consent before naming a receiving organization, story visibility, and where people served comes from are Decision 24’s open questions; the stories table is round 3’s R22 (open).

▲ Not AI, not published: the draft is a fixed prototype template filled from the chosen orders, after R4.5 (Brian’s draftFrom). It is labelled as such and must be checked before sending. Approvals are recorded per organization in this session; Ask GIK to publish only records a request. Nothing is published, and no AI drafts or approves anything.

Your own draft: only Convoy of Hope sees it. Edit reopens the editor with its orders and sources.

▲ Not AI, not published: the draft is a fixed prototype template filled from the chosen orders, after R4.5 (Brian’s draftFrom). It is labelled as such and must be checked before sending. Approvals are recorded per organization in this session; Ask GIK to publish only records a request. Nothing is published, and no AI drafts or approves anything.

Per network: Hawaii Island Relief Partners has its own impact: one illustrative order of meals for Hilo shelters. Nothing from Gulf Coast appears.

▲ Illustrative data: R5 has no order records, so every figure comes from a short list of illustrative completed orders whose quantities equal the fulfilled amounts R4’s sample needs already show (24 of 60 Cases of bottled water, 150 of 150 hygiene kits, and so on). Each order is counted once; quantities are never added across units; goods value is an illustrative value per unit times quantity (T12); transport and people served are illustrative shipment estimates, and an order without one leaves people served out. Only Gulf Coast, Hawaii Island and Iowa River Valley have orders.

No completed orders yet: Impact fills in as deliveries land. Draft a story isn’t offered without orders.

Round 5: this Overview is drawn as Option A, Refined Existing; 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.

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

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).

▲ Later, not modelled: 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.

▲ Proposed, related event and disaster: Event and deadline opens on its own when you arrive from an event (Post a need for this event, on the event’s page). choosing a network event that is linked to a disaster shows that disaster, marked From this event, instead of asking again. Choose a different disaster switches to the search; once you’ve picked one yourself, changing the event never overwrites it (Use the event’s disaster puts it back). With no event, the disaster is searched directly. Needs have no event or network link in ERD round 1 (R5); this needs the event model.

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, related event 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 drawn as Option A, Refined Existing; 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.

The new need: its fulfilment, every detail including Posted from and Related network event, and Matches, through GIK’s existing matching and offers (not drawn).

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.

▲ Later, not modelled: 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.

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.

▲ Visibility unchanged, network-only needs pending: 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.

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 related event. Filtering is optional; by default every need shows, whatever its event.

No related 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.

Partial progress: 90 of 400 cases fulfilled. Details show Status, the related network event 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.

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 drawn as Option A, Refined Existing; 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.