Committee Discussion — Aims & Priorities

DRAFT ONLY

This Plan is currently only a DRAFT and has not been accepted or implemented by WICEN WA. It is largely incomplete.

Why this page exists

The rest of this plan describes how WICEN WA communicates. It doesn’t yet say what for, at what scale, or in what priority order — because those are Aims questions, and Aims are a committee decision, not something to be assumed while drafting the operational detail.

This page exists to surface that gap as a concrete set of questions, so the committee has something specific to discuss rather than an open-ended “what should WICEN WA’s aims be?” Each cluster below feeds the next: Aims decide scope → scope decides which PACE domains get finished first → that decides which capabilities are actually load-bearing → that decides what the Capability Self-Assessment and Training pages should test and teach. Right now that chain runs backwards — the plan has state-wide ambition built into it by default, without the committee having decided that’s the aim.

What’s already implicit, scattered across the site

  • The About page’s Mission is broad and generic — “support government agencies, emergency services, and the community during times of emergency, disaster, or special need.” It doesn’t say which agencies, at what scale, or in what priority.
  • The homepage states WICEN WA is “in a rebuilding phase” — a real capacity constraint the PACE plan doesn’t currently reflect anywhere.
  • The Capability Self-Assessment already encodes a working capability model (Physical, Mental Readiness, Radio & Equipment, Availability) and a set of operational roles (Field HF Operator, Net Control, Winlink/Digital Operator, APRS Tracker, etc.), and references AIIMS (the incident management system WICEN operates under) — none of which is referenced anywhere else in this plan.
  • Recent WICEN WA activity (Dementia Walk, POTA activations, community events) is small-scale, local, single-day. This plan as drafted is written at full state-wide disaster scale — interstate liaison, regional HF gateways, statewide nets. That’s a real gap between the organisation’s current lived activity and the plan’s ambition — see §1 below for the full breakdown.
  • Local/Tactical Field Comms (MeshCore) doesn’t appear anywhere in the Capability Self-Assessment’s model — so the assessment tool and this plan are currently describing two different pictures of what WICEN WA does.

Questions for the team

1. Mission & scope

What the record actually shows. The About page’s Mission lists five activities as if equally weighted — emergency communications support, community event support, training, equipment/infrastructure, rapid response. WICEN WA’s own published post history tells a more specific story. Of the seven posts published between March 2025 and August 2026: two are community walk support (the Dementia Walk, in consecutive years), two are governance (a committee meeting, the AGM), one is an amateur radio contest (John Moyle), one is an explicitly-labelled training activation combining POTA with emcomm practice (around nine participants, on Herrison Island), and one is informational (the newly-noticed 5MHz allocation). None are an actual emergency deployment. That’s not a criticism — training and event support build real skill and community visibility — but it means the plan’s mission statement and WICEN WA’s lived activity are currently describing two different organisations, and the committee should decide which one this plan is actually for.

Models to compare. Research into comparable organisations (see the Domain Summary References) surfaced a few genuinely different operating models, rather than trying to be all of them at once:

  • Event-support and training club — closest to current lived activity. Regular, low-stakes, builds real operating skill and community goodwill, easy to resource with a small membership. Doesn’t by itself build emergency-response readiness — a Sunday at a fun run or a POTA park doesn’t test net discipline under real pressure or a multi-day commitment the way an actual deployment does.
  • Served-agency emergency auxiliary — the traditional WICEN/ARES model (see WICEN Victoria and ARES West Central Florida in the Domain Summary References): a standing relationship with DFES/SES/similar, on-call readiness, integration with AIIMS (the incident management doctrine used by every fire, emergency, and land management agency in Australia — already referenced in the Capability Self-Assessment, but not cited anywhere else in this plan), and a higher and more consistent training bar. This is what the About page’s Mission describes — but it’s not what recent activity has actually been, and §2 below shows it currently lacks the formal agency recognition it would need.
  • Community-resilience / welfare-focused — the model raised in §6: direct-to-public welfare messaging and neighbourhood-level support, not routed through a served agency at all. A different skill set again — community engagement and message intake matter as much as net control.
  • Staged hybrid — deliberately be the event-support/training club now, while explicitly working toward the served-agency model as membership and capability grow, picking up cheap pieces of the community-resilience model (§6) opportunistically along the way. This is the model the Implementation Roadmap currently assumes — but that assumption hasn’t actually been confirmed by the committee.

A question for people, not the site. This site’s own record only goes back to March 2025. Longer-serving members will know whether the recent event-support-heavy pattern is new — a symptom of the current rebuilding phase specifically — or whether it’s actually how WICEN WA has operated for a long time, with genuine emergency deployments always being the exception rather than the rule. That history should shape whether “rebuilding” means returning to something WICEN WA used to do at scale, or building toward something it’s never really done before.

Capability reality check. The largest single activity visible in the record is the POTA training activation, at around nine participants. This plan’s domains assume roles across Strategic Coordination, Long-Haul Message Traffic, Local/Tactical, and Cross-State Coordination being staffed simultaneously — Net Control, Winlink/digital operators, Field HF operators, and more (see the Capability Self-Assessment’s role list). Before setting scope, the committee needs an honest count: how many current members are actually trained and available for a multi-day commitment, as opposed to a single Sunday — and does that number support the served-agency model at all right now, regardless of which model the committee would prefer?

Questions:

  • Does the membership want WICEN WA to primarily be an events-and-training club that also stands ready for emergencies, or a genuine emergency-response auxiliary that also does events to stay sharp and visible? These sound similar but lead to different training priorities and different time commitments asked of members.
  • Which of the four models above — or some other combination — does the committee actually want, rather than the plan continuing to describe a served-agency auxiliary by default while lived activity says something else?
  • For longer-serving members: has WICEN WA’s activity always looked like this, or is the recent event-support-heavy pattern specific to the current rebuild?
  • How many current members are trained and genuinely available for a multi-day emergency deployment, not just a single-day local event? Is there a realistic gap between what this plan assumes WICEN WA can field and who’s actually available to field it?
  • Given the “rebuilding phase,” what’s a realistic 12–24 month capability ceiling — and should this plan document current capability, target capability, or both, clearly labelled as which?
  • Should the plan set a concrete minimum-viable-roster gate (e.g. “N members trained and available in roles X, Y, Z”) before WICEN WA considers itself ready for the served-agency model, rather than leaving readiness as an open aspiration?

2. Served agencies

A concrete, checkable finding: WICEN WA doesn’t currently appear anywhere in WA’s official emergency management framework. Western Australia’s all-hazards arrangements sit under the Emergency Management Act 2005 and are governed by the State Emergency Management Committee (SEMC), whose current membership runs WA Health, WA Police, DFES, Department of Communities, DBCA, WALGA, and Disability Assembly WA — no amateur radio or volunteer communications body. The State Support Plan – Emergency Public Information — WA’s actual governing document for how warnings and public information reach the community — doesn’t mention WICEN either.

Compare that with Victoria, where WICEN has a formal, published role statement within Emergency Management Victoria’s State Emergency Management Plan — a named, official role in the state’s own emergency management documentation, not just an informal understanding. WA doesn’t have an equivalent for WICEN WA that this research could find.

This changes the shape of the question. “Which agencies does WICEN WA have a relationship with” isn’t only about picking DFES or SES informally — it’s about whether WICEN WA wants to pursue the kind of formal recognition Victoria’s WICEN already has, which would likely be a prerequisite for the served-agency model in §1 to mean anything operationally, rather than staying an aspiration written into this plan’s mission statement without institutional backing.

Questions:

  • Which agencies does WICEN WA actually have, or want, a standing relationship with — DFES, SES, WA Police, Red Cross, local government? The Deployment Model page currently just says “Supported Agency” generically.
  • Do any of those relationships already dictate a comms platform or reporting format WICEN has to interoperate with, rather than choose?
  • Is formal inclusion in WA’s SEMC framework (a WICEN WA role statement, mirroring Victoria’s) worth actively pursuing, and if so, who owns that relationship-building — the committee, or a specific liaison role?
  • Given WICEN WA isn’t currently named in the State Support Plan – Emergency Public Information, should the organisation seek inclusion there specifically, since that’s the actual document governing the Incident Information domain this plan already describes?

3. Domain priority

  • Of the five domains in the Domain Summary — Activation & Alerting, Strategic Coordination, Long-Haul Message Traffic, Local/Tactical, Cross-State Coordination — which should be finished and drilled first, given current membership numbers?
  • Is Cross-State Coordination a near-term priority at all, or aspirational for a later, larger membership?

4. Capabilities & training

  • Should the Capability Self-Assessment be extended to cover MeshCore/Local-Tactical now, or only once that domain’s doctrine is settled?
  • What’s the minimum role set WICEN WA needs covered at all times (e.g. one Net Control, one Winlink operator) versus roles that are “nice to have when available”?
  • Does the organisation want a formal training pathway (newbie → intermediate → advanced, tied to the roles already listed in the Capability Self-Assessment), or does the current quarterly ad-hoc Training schedule remain sufficient at current size?

5. Testing what matters

  • Should PACE domain readiness be tested at exercises the same way individual capability is self-assessed — i.e. does a domain’s “Contingency” tier only count as real once it’s been exercised, not just documented?

6. Community-to-community welfare messaging

Sections 1–5 are about WICEN’s role supporting agencies and its own field teams. This is a different question: a public-facing role serving the community directly — passing basic welfare information between people when their usual means of contact (phone, internet) have failed. It doesn’t fit any domain in the Domain Summary as currently written, because every domain there assumes the message is moving through a WICEN operator on both ends, in support of an incident or an agency. Welfare traffic moves between ordinary people, and WICEN would only be the relay in the middle.

There’s real evidence this is a distinct, worthwhile need rather than a nice-to-have add-on:

  • A 2014 Australian study of two disasters (Ingham QLD flood, Beechworth VIC bushfire) found neighbour-to-neighbour communication predicted household preparedness far better than broadcast media, and recommended appointing “neighbourhood hazard wardens” as a named, structural role.
  • In the US, ARES/RACES operators have a long-established “Health and Welfare” traffic role: a ham inside a disaster area passes a basic “I’m safe” message to a ham outside it, who registers it with the Red Cross’s Safe and Well system on behalf of someone with no other way to reach it.
  • Australia’s equivalent is Australian Red Cross’s Register.Find.Reunite service — but it depends on internet/mobile access, or physically reaching an evacuation or relief centre. A community that’s genuinely cut off, which is the exact scenario this plan’s Emergency tiers already assume, has no way to reach it.
  • Closer to home, Victoria’s CFA Community Fireguard groups — mature neighbourhood bushfire-preparedness networks — have no formal communications component at all. South Australia’s Radio Rescue Emergency Communications Inc. deliberately uses licence-free UHF CB rather than ham bands, specifically so community members without a licence can take part directly.
  • This isn’t just informal observation — it’s the basis of Australia’s own national doctrine. The Australian Institute for Disaster Resilience’s Community Engagement for Disaster Resilience and Public Information and Warnings handbooks — part of the nationally-endorsed Australian Disaster Resilience Handbook Collection — set out the same principle at the national level: two-way, locally-trusted engagement is treated as core doctrine, not an optional extra.

Questions:

  • Does WICEN WA want to provide a welfare-message relay service — carrying basic “I’m safe” / “we need X” messages from a cut-off community to Register.Find.Reunite or to a named contact elsewhere — as a distinct aim, separate from supporting agencies or field teams?
  • If so, how does someone who isn’t a WICEN member actually get a message into that chain? Options span a spectrum: a doorknock/neighbourhood-warden model (an on-street volunteer, possibly unlicensed, relaying to a nearby WICEN operator), a public drop-off point (evacuation centre, community hall), or no public intake at all — WICEN only relays messages it already receives via served-agency channels.
  • Would this sit inside the existing Long-Haul Message Traffic domain (as a defined use case for the Winlink/JS8Call gateway network), or does its public-facing nature make it a distinct domain in its own right?
  • Is this worth a formal approach to Australian Red Cross about integrating amateur relay into Register.Find.Reunite, mirroring the US ARES/Red Cross relationship — or is that better left informal, community by community?
  • Welfare traffic has historically been given the lowest priority precedence precisely so it never competes with operational/incident traffic. Does the site’s three-level Priority scheme (EMERGENCY/PRIORITY/ROUTINE) on the Message Handling page already cover that, or does welfare traffic need to be explicitly named as the bottom of ROUTINE so it’s never assumed more urgent than it is?
  • Given the “rebuilding phase,” is this a first-priority capability alongside Strategic Coordination and Local/Tactical, or a later-stage aim once those are mature?

7. Capability investment: reaching beyond licensed operators

Sections 1–6 all assume messages move between WICEN operators, or between a WICEN operator and one other party. These two questions are about a different kind of investment: infrastructure that would let WICEN extend basic connectivity to people who aren’t hams at all — either by radio or by internet.

Mobile repeater with radios for non-ham distribution

WICEN WA’s members must be licensed amateur operators, and amateur licence conditions don’t allow handing out ham-band radios for unlicensed people to transmit on. To distribute radios that a community member, evacuation centre volunteer, or served-agency liaison could actually use, WICEN would need to operate on a non-amateur frequency:

  • UHF CB (476.425–477.4125 MHz) — the handheld radios themselves are licence-free for anyone to use, which is why South Australia’s Radio Rescue Emergency Communications Inc. uses it for exactly this reason. But operating a repeater on UHF CB still requires its own ACMA apparatus licence — CB repeaters aren’t covered by the general class licence that covers handheld use.
  • A dedicated private/business band frequency — fully licensed via ACMA (an ongoing cost, plus coordination to avoid interfering with existing licensees), but gives WICEN a channel that isn’t shared with general public CB traffic.

Either path is a genuinely new capability, not an extension of what WICEN already does on ham bands. NSW WICEN already has experience deploying portable repeaters into the field during bushfire operations — but for its own licensed members, not for handing to the public.

Note: a fixed repeater may not be the only way to get here. §8 below covers MeshCore, which can bridge to non-hams peer-to-peer without necessarily needing dedicated repeater infrastructure at all — a cheaper path to the same “non-ham can get a message in” outcome, worth weighing against this section before committing to a repeater build.

Ad-hoc satellite internet for community access

This isn’t hypothetical for comparable Australian organisations — it’s becoming standard equipment for them. NSW SES has been rolling out 70+ portable Starlink kits for severe weather deployment, and NSW RFS has been retrofitting over 5,000 operational vehicles with Starlink under a “Vehicle as a Node” program, with NSW Government funding a $5 million backup-connectivity fleet specifically so communities — not just responders — stay online after disasters.

This would change the shape of the PACE plan itself, not just add a capability: several domains in the Domain Summary list “Internet Collaboration Platform” as their Primary tier, on the assumption that internet is what fails first. If WICEN can restore internet at a deployment site, Primary doesn’t have to stay failed — it can be re-established, which is a different posture than cascading down to Alternate/Contingency/Emergency and staying there.

Questions:

  • Does WICEN WA want to invest in a mobile repeater capability aimed at non-ham community members, rather than only its own licensed operators? If so, UHF CB repeater (cheaper, shared spectrum, still needs an ACMA licence) or a dedicated licensed business-band channel (more control, ongoing cost)?
  • Who would actually be handed these radios in a real deployment — evacuation centre staff, a served agency’s own personnel, or members of the public directly? That changes both the licensing path and the training/distribution logistics.
  • Does WICEN WA want to invest in ad-hoc satellite internet (Starlink or equivalent) as a community-facing capability, following NSW SES/RFS’s lead — or does that sit outside WICEN’s amateur-radio identity and belong to a different organisation to provide?
  • If satellite internet is added, is it treated as restoring the Primary tier in place, or as a new tier of its own? Either answer means changes to the Domain Summary table, not just an equipment purchase.
  • Both of these represent real capital cost (equipment, ACMA licensing, ongoing satellite subscription) for an organisation currently in a “rebuilding phase.” Are either of these near-term priorities, or aims for a later, better-resourced stage?

8. Local/Tactical technology choice — different tools for different links, not one winner

The first draft of this section framed MeshCore, APRS messaging, and AREDN as competing options to pick one from. That’s the wrong frame — MeshCore ended up in the Local/Tactical Alternate tier because a full handbook was written for it before the rest of this draft had even been reviewed, and the natural reaction is to look for what should replace it. But these technologies don’t compete with each other; they answer different questions about who is on the other end of the link:

Community intake layer — licensed operator to someone who isn’t licensed at all, and never will be. This is the same problem §7 raises for a mobile repeater, and these two technologies solve it without necessarily needing one:

  • MeshCore (or similar LoRa mesh) — licence-exempt under Australia’s LIPD class licence, and as far as this research found, LIPD doesn’t carve repeater/relay roles out of that exemption the way the CB class licence does (worth confirming directly with ACMA, not just assumed here). If that holds, a MeshCore node handed to a non-ham needs no ACMA apparatus licence at all, at any role in the network — a genuinely lower-friction path to “a community member can get a message in” than the UHF CB repeater discussed in §7. It carries text/status/position only, not voice.
  • UHF CB — also licence-exempt for handheld use, but voice rather than data, and already familiar to much of the public (four-wheel-drivers, tradies, farmers) in a way MeshCore isn’t yet. The repeater-licensing cost from §7 applies to CB, not to MeshCore.

Operator-to-operator layer — WICEN operator to WICEN operator, both licensed and trained. A completely separate problem, with its own two candidates:

  • APRS messaging — not just position beacons; APRS carries genuine text messages and bulletins to all stations in range. This already has a foothold in WICEN WA: the Capability Self-Assessment already tests members on APRS RX/TX, and Operational Comms already names an “APRS Beacon Station” role. Extending an existing, already-partly-trained capability costs nothing new to acquire.
  • AREDN — turns off-the-shelf Wi-Fi routers into a genuine amateur-radio mesh network (real amateur allocations, not ISM spectrum), with vastly higher bandwidth than LoRa (5–150 Mbit/s) — enough to carry VoIP, video, or an email gateway, not just short text. Requires licensed operators, more technical setup (flashing firmware, line-of-sight for WiFi-band hops), and real per-node cost.

Packet radio / Outpost PMM (§9) is a third option for the operator-to-operator layer, oriented around structured, logged, form-based messaging rather than speed.

Framed this way, the real question isn’t “which single system does Local/Tactical use” — it’s which of these two layers WICEN WA actually wants to build, independently of each other, and in what order:

Questions:

  • Does WICEN WA want a community intake capability at all (MeshCore and/or UHF CB), separate from the question of what it uses operator-to-operator? These can be adopted on entirely different timelines.
  • If both MeshCore and UHF CB are on the table as intake options, is there a reason to run both — data versus voice — or does one alone cover the need, given the licensing-cost gap between them?
  • For the operator-to-operator layer, does “builds on a skill members already have” (APRS) outweigh “higher capability, higher cost” (AREDN) given the rebuilding phase — or does the committee want to defer this layer entirely and rely on VHF/UHF voice alone until there’s more capacity?
  • Does the Domain Summary’s single “Alternate” cell for Local/Tactical Field Comms need to become two cells — an intake layer and an operator layer — rather than staying one line that implies a single technology?

9. Software integration — should we standardise a platform?

This plan already names several separate applications — Winlink, JS8Call, VARA, FLDIGI, APRS clients — without ever saying what runs them, on what machine, or how message logs get kept and handed to net control or incident command. Three existing, actively used tools are worth the committee’s attention:

  • EmComm Tools Community (ETC) — a free, bootable Linux image built specifically for this use case: it bundles Pat (Winlink), JS8Call, VARA, VarAC, YAAC (an APRS client with a search-and-rescue plugin), fldigi, and Dire Wolf, pre-configured and ready to run from USB on a field laptop. Instead of every operator individually installing and configuring five separate apps, a station could boot one known-working image. Worth trialling on a single gateway or field station before recommending it more broadly.
  • Outpost Packet Message Manager — the long-standing ARES/RACES standard for structured message handling: an email-client-style interface over packet radio, with a built-in ICS-213 form generator, producing the same kind of logged, numbered message record the Message Handling page already calls for. Windows-only and dates back to the early 2000s, but still actively used and maintained specifically because the message-logging problem it solves hasn’t gone away.
  • NCLog — purpose-built net-control logging software for ARES/RACES/public-service nets, distinct from the two above: it logs check-ins, roles, and time-on-net in real time and exports directly to ICS-214/309/205-style forms. This is specifically the tool for the Net Control logging responsibility now named in Operational Comms’s Station Modes and detailed in Message Handling’s Net Control Logging section — neither ETC nor Outpost solve that particular job.

Questions:

  • Is there value in standardising on one platform (e.g. ETC) for field and gateway stations, so a station can be handed to any trained operator rather than depending on whoever set up their own laptop?
  • Does WICEN WA want a formal, logged message record (Outpost-style, tied to ICS-213) rather than relying on individual operators’ personal notes — and if so, should that become part of the Message Handling page’s standard format, rather than a separate tool decision made later?
  • Who owns evaluating and maintaining a shared software image, given the “rebuilding phase” — is this a task for one technically-minded member to trial now, or does it wait until there’s more capacity?
  • Net Control now has a documented logging responsibility it didn’t have before this update — is paper-and-pen sufficient at current net sizes, or is NCLog worth adopting now rather than waiting for a larger, busier net to expose the gap?

10. Permanent/standing infrastructure vs portable/deployable capability

Every technology discussed in §8 and §9 can be built two different ways, and so far this plan hasn’t distinguished them: permanent infrastructure that’s in place all the time, providing baseline coverage regardless of whether WICEN is activated, versus portable kit that gets carried to wherever a specific deployment needs it. They have different cost, maintenance, and governance profiles, and conflating them risks either under-investing in the standing network that makes portable kit useful in the first place, or over-investing in permanent sites the organisation can’t yet maintain.

WICEN WA doesn’t start from zero here — there’s already real standing infrastructure to document and lean on:

  • South West WA’s APRS digipeater network — already in place and already providing baseline coverage, independent of any WICEN activation or exercise.
  • An expanding MeshCore coverage area — newer, but already real and growing, not hypothetical.

Neither of these needed WICEN to build them. That’s precisely why the first useful step may not be a new build at all — it’s an honest inventory: what standing coverage already exists, who put it there, who maintains it, and whether WICEN can formally rely on it or is just informally aware of it.

By contrast, AREDN sited permanently in major centres — genuinely new, high-bandwidth, standing infrastructure — is a real capital project: site agreements, hardware, and someone accountable for keeping each node up, not something to assume exists already.

Portable/deployable capability is a separate axis again, and cuts across every technology already discussed rather than picking one: a go-kit brought to an incident could reasonably contain a MeshCore node, an APRS tracker, UHF CB handhelds, a portable AREDN “fly-away” node, or a Starlink terminal, chosen for what that specific deployment needs — independent of whatever’s permanently sited nearby.

Questions:

  • Does WICEN WA have a full picture of what standing infrastructure already exists in WA (APRS digipeaters, MeshCore coverage, anything else run by other clubs or individuals) — or is this currently informal, member-by-member knowledge that should be turned into a documented asset register?
  • For infrastructure WICEN doesn’t own or operate itself (e.g. digipeaters run by other groups), does the plan need a formal arrangement to rely on it operationally, or is “it’s there and it works” good enough for a volunteer organisation?
  • Is permanent AREDN siting in major centres worth pursuing now, given it’s a genuinely new capital and maintenance commitment — or does it wait until the organisation is larger, the same way §7’s mobile repeater and satellite proposals were deferred?
  • Who is accountable for a permanent node’s uptime once it exists — an individual member, a formal WICEN role, or is that exactly the kind of standing commitment a rebuilding-phase organisation should avoid taking on?
  • Should the standard field go-kit be defined now (which portable technologies, in what combination) even before the permanent-infrastructure questions above are settled, since portable capability doesn’t depend on what’s permanently sited?

11. Voice procedure and message precedence

WICEN WA’s archived Radiotelephone (RATEL) Procedure for Operators in WICEN (about 2002) has been adapted as the plan’s Voice Procedure page. It fills a real gap — the plan said which system to use at each tier but not how to talk on it, including how the voice relay network actually works.

  • Should WICEN WA formally adopt the adapted RATEL procedure as its standard voice procedure, and make it the baseline for operator training?
  • Should message precedence change from ROUTINE / PRIORITY / EMERGENCY to RATEL’s ROUTINE / PRIORITY / IMMEDIATE? “EMERGENCY” collides with the PACE Emergency tier on a live net (see Message Handling). If adopted, where does welfare traffic (§6) sit — explicitly at the bottom of ROUTINE?
  • Should the plan adopt RATEL’s fuller formal message — IN/OUT serial numbers, date-time group, operator R/D blocks — as the standard message form?
  • How does RATEL’s abbreviated procedure (dropping call signs after the first exchange) sit with the ACMA call-sign identification rule? Needs a clear answer that operators can apply on air.

Government & regulatory references

These are official Australian government and regulatory documents with a genuine crossover with WICEN WA’s plans and principles — cited inline above, and gathered here as one list. They’re context for the committee’s decisions, not something this plan can unilaterally adopt as policy; several (the SEMC framework in particular) would require WICEN WA to actively seek inclusion, not just cite.

Outcome

Answers to these questions should feed back into the Overview and Domain Summary pages as explicit scope and priority statements, not stay only on this page. Until the committee has worked through them, treat the rest of this plan’s scale and priority ordering as a draft assumption, not a decision.

Given WICEN WA’s current capacity, not everything raised above is achievable at once — see the Proposed Implementation Roadmap for an assessment of relative cost and effort, and a suggested phased sequence for the committee to review. A first-draft Mission Statement and Aims is also available, built on the same working assumptions as the Roadmap — both need revisiting once the committee has actually answered §1.