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

First release, item 1: name, event and template. Every optional part can be skipped: with no template the network is created with no invite candidates, and organizations are found in Invite organizations.

Network first: the card asks for the network’s name, then its initial event, so the event reads as the network’s starting context rather than its identity. The sample network is named for the group (Gulf Coast Response Partners), not for Hurricane Odalys.

Prototype refinement (2026-10-07, April Sousa): reusing previous networks’ members moved from Create into Invite organizations, so Create stays short and the template’s suggestions are not followed by a second long list. Both capabilities are kept. A UX and information-architecture change for this prototype, not a confirmed GIK requirement.

▲ Conflict, D2: spec section 5 allows a network without a disaster record; the decision record adds a free-form event (ERD event_label, ontology “Event”). Both readings are drawn: existing disasters, Other event, or no event. GIK has confirmed neither.

▲ 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 decision D5: five-minute setup is a design target; nothing here measures it.

Working internal direction (2026-10-07 internal review): a true preview, not an editor: a summary of what the template prepares, a short peek at its organizations and starter items, and View all for the rest. Apply template prepares the whole contribution; removing items happens afterwards on Create, where each keeps its template label. Recommend a manageable subset, search the full set.

Prototype refinement (2026-10-07, April Sousa): the counts read “Prepares N invite candidates · M starter supply items” because applying prepares organizations for review in Invite organizations; it invites no one.

Templates follow the response, not the network: the initial event suggests a template (Hurricane Odalys suggests Hurricane), and applying it prepares candidates and a starter supply list for this response. It does not make this a “hurricane network”; changing the event changes only the suggestion, never an applied template.

Working decision D4: a template pre-fills suggested members and a starter supply list. ▲ Conflict on types: spec section 5 starts with Hurricane; the decision record names Hurricane, Wildfire, Coordination and Start Empty. All four are drawn.

Starter supply list: a planning checklist, kept apart from inventory and posted needs: it is not a Network Resource Share (model R4) and creates no need. Gap: where it appears after creation is not defined; template storage is open (T8, ERD R10).

Later: back-office template management, user-created templates and generated templates are outside this round.

Working internal direction (2026-10-07 internal review): carried forward from the v1 setup wireframe (partner-network-setup-npo.html): the applied template meaningfully populates what follows. Its organizations become invite candidates and its starter items become the starter supply list, each labelled with the template it came from and each removable here, in the preview, or (for organizations) in the invitation review. The v1 page’s receives and supplies network roles are not carried over: no source confirms them, and organizations are treated by capability.

Working decision D4: a template pre-fills both suggested members and a supply list; Hurricane and Wildfire contribute different organizations and items, and Start Empty contributes neither. ▲ Conflict on types as noted on the preview.

Prototype refinement (2026-10-07, April Sousa): the invite-candidate card stays a compact count; the organizations are reviewed, with previous networks and search, in Invite organizations. Replacing the template swaps only its contribution; Remove template drops it; Edit reopens the preview.

Nothing else changes: applying a template sends no invitations, creates no membership, posts no needs, shares or reserves no inventory, and implies no supplier commitment. The starter supply list is a planning list kept on the network for its creating organization; where else it should appear is not defined in the spec (T8, ERD R10).

Working decision D11: spec default and decision record agree a network may have no supplier, with a warning at setup. It is information only and appears when candidates include no supplier.

Prototype refinement (2026-10-07, April Sousa): reusing previous networks’ members moved from Create into Invite organizations, so Create stays short and the template’s suggestions are not followed by a second long list. Both capabilities are kept. A UX and information-architecture change for this prototype, not a confirmed GIK requirement.

Nothing was sent: creating the network made no invitations and no memberships (model R2, D-a). It opens Invite organizations over the new network’s overview; closing it leaves the overview with no one invited.

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.

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): an editable invitation review before anything is sent, which brings together the template’s suggestions, previous networks and search across GIK.

Prototype refinement (2026-10-07, April Sousa): reusing previous networks’ members moved from Create into Invite organizations, so Create stays short and the template’s suggestions are not followed by a second long list. Both capabilities are kept. A UX and information-architecture change for this prototype, not a confirmed GIK requirement.

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.

Working decision D10 and spec D19: a convener can invite a supplier directly; suggested organizations are invite candidates and still accept.

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

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

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

Prototype refinement (2026-10-07, April Sousa): Add from previous networks is a secondary action that opens a compact picker: search, the networks you chose as chips, four networks first (event matches lead) and Show all for the rest. Nothing is listed until you open it.

Event and reuse stay independent: the network’s event only orders the picker and marks “Matches this event”; it never adds or removes a network you chose. Previous networks are named for the group (Hawaii Island Relief Partners) and described by the event they started around (“Started around Hurricane Lala”), which is context, not their identity.

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.

Working decision (spec D19): reused organizations are candidates, not members; each accepts again. Only member lists carry forward, never resources, needs, commitments or activity.

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.

Candidate rules, to try here: remove Iowa River Valley Partners and only Delta Building Supply leaves the list; Mobile Community Pantry, Salvation Army and Coastal Water Co. stay because the template or Hawaii Island Relief Partners also suggests them. Mercy Medical Supply was left out and stays out if you remove and re-add a source. Lakeside Hygiene Supply was added by search and stays whatever sources change.

Nothing is sent by adding sources, searching, filtering or selecting. Only Send invitations creates invitations, and organizations must accept before they join.

Prototype refinement (2026-10-07, April Sousa): one column, so the recipients get the room: the GIK search across the full width (capped at 25 results with a prompt to narrow), then compact source controls (Response Template with Review; Previous networks with Add from previous networks and a count of the networks selected, each collapsed until opened), then the invitation list, in two columns on a desktop and one on a phone, which wraps long names and gains a filter once it grows. A row with one source names it; a row with several says “From 3 sources” and reveals the names on request. The count and Send stay pinned below and never cover the last row.

Modal kept, deliberately: the review opens over the screen it came from, sized to the window. A dedicated page remains a scalability option if the interaction grows; the 2026-10-07 review did not settle modal versus page.

Type-ahead search finds any organization on GIK (prototype data: a few dozen organizations). Adding one that was not a candidate gives it the source “Added by you”, which no source change removes.

Gulf Coast Food Bank is the reviewers’ uninvited organization: leave it out to check that an organization never invited cannot open the network.

Two tabs, kept at the top: “Find an organization on GIK” and “Invite by email”. The email path stays separate from the invitation list, and switching tabs keeps what was typed and what was selected; nothing is sent until Send.

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.

Gap, first release item 8 and T6: leaving and removing a member (S5), and resending or revoking 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.

First release, item 9: invited organizations get an in-app cue; notification types are open (T6).

▲ Conflict, D12: spec section 5 has no default and first-release item 2 covers organizations already on GIK; the decision record says deliver email invitations in v1 (ERD R3 target_email). Drawn as round 2 drew it, as a concept, in its own tab beside the GIK search. Its presence here does not mean first-release approval; the 2026-10-07 review did not approve it.

Later: full off-platform onboarding is outside this round (S8).

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.

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 whose acting user can manage the organization’s resources, and which has eligible resources, sees Add resources until it shares something, then Manage resources, in the same header position. Working internal direction: the Q4 roadmap and first-release item 6 describe suppliers making inventory available, which this does not contradict; ERD R4 records the sharing organization without restricting its type. The network’s creating organization is not offered it while its membership is open (R11).

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.

Gap, first release item 8 and T6: leaving and removing a member (S5), and resending or revoking 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.

Settled (Q4 roadmap) and first release, item 6: inventory is made available only to the network; nothing is shared by default.

Resource action, the same for every organization type: an accepted member whose acting user can manage the organization’s resources, and which has eligible resources, sees Add resources until it shares something, then Manage resources, in the same header position. Working internal direction: the Q4 roadmap and first-release item 6 describe suppliers making inventory available, which this does not contradict; ERD R4 records the sharing organization without restricting its type. The network’s creating organization is not offered it while its membership is open (R11).

Model R4: a Network Resource Share is recorded apart from the resource’s own visibility. ▲ Open (T2, R7): new share record or the unfinished partners visibility value. ▲ Open: which people in an organization may share.

Edge case, annotated only: a resource shared with more than one network, and which network an order would record (ERD R5 holds one network_id), is not designed in this round.

First release, item 6 and Before release (T5, D-c): the supplier previews the member view; shared inventory is visible only to members, enforced by the platform, and never reaches non-members through matching or search.

Sharing leaves stock unchanged and unselected resources private; the header action becomes Manage resources. Gap: stopping a share is not described in the spec or the model.

Same pattern, Non-Profit member: Salvation Army has eligible resources and its acting user can manage them, so it gets Add resources in the same place and style as Kimball Household Goods did.

Resource action, the same for every organization type: an accepted member whose acting user can manage the organization’s resources, and which has eligible resources, sees Add resources until it shares something, then Manage resources, in the same header position. Working internal direction: the Q4 roadmap and first-release item 6 describe suppliers making inventory available, which this does not contradict; ERD R4 records the sharing organization without restricting its type. The network’s creating organization is not offered it while its membership is open (R11).

Same flow: choose, preview and share work the same for a Non-Profit member; nothing is shared until it confirms.

Resource action, the same for every organization type: an accepted member whose acting user can manage the organization’s resources, and which has eligible resources, sees Add resources until it shares something, then Manage resources, in the same header position. Working internal direction: the Q4 roadmap and first-release item 6 describe suppliers making inventory available, which this does not contradict; ERD R4 records the sharing organization without restricting its type. The network’s creating organization is not offered it while its membership is 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.

Gap, first release item 8 and T6: leaving and removing a member (S5), and resending or revoking 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.

Gap, first release item 8 and T6: leaving and removing a member (S5), and resending or revoking 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.

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 whose acting user can manage the organization’s resources, and which has eligible resources, sees Add resources until it shares something, then Manage resources, in the same header position. Working internal direction: the Q4 roadmap and first-release item 6 describe suppliers making inventory available, which this does not contradict; ERD R4 records the sharing organization without restricting its type. The network’s creating organization is not offered it while its membership is open (R11).

▲ 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 whose acting user can manage the organization’s resources, and which has eligible resources, sees Add resources until it shares something, then Manage resources, in the same header position. Working internal direction: the Q4 roadmap and first-release item 6 describe suppliers making inventory available, which this does not contradict; ERD R4 records the sharing organization without restricting its type. The network’s creating organization is not offered it while its membership is open (R11).

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.

Gap, first release item 8 and T6: leaving and removing a member (S5), and resending or revoking 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.

Gap, first release item 8 and T6: leaving and removing a member (S5), and resending or revoking 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.

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.