Partner Networks

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

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 3, Add 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).

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 3, Add 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.

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

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

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 3, Add 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.