Key User Requirements

Five candidate requirements guide the W.O.L.F evaluation model.

The W.O.L.F Key User Requirements define the user needs, required outcomes and proposed measures that should be evaluated before any decision on wider trial or deployment.

The requirements remain candidates for sponsor and requirement-owner review. Their numerical thresholds are proposed validation measures and do not represent approved Army requirements.

  1. 01 Managed LPHD security
  2. 02 Controlled communications
  3. 03 Lifecycle management
  4. 04 W.O.L.F Sustain
  5. 05 Scalable and resilient service
Requirements
05
Evaluation status
Candidate
Decision basis
Evidence

Evaluation model

Each KUR connects an operational need to a required outcome, proposed threshold, future objective, validation method and evidence requirement.

The KURs support structured evaluation. They do not represent approved Army requirements or authority to deploy W.O.L.F.

  1. 01

    Define the need

    Identify the user problem and operational outcome required.

  2. 02

    Set the measure

    Define a proposed threshold, future objective and validation method.

  3. 03

    Gather the evidence

    Test the requirement through controlled activity and record the outcome.

  4. 04

    Inform the decision

    Use the evidence to support sponsor, assurance and risk decisions.

KUR 1 — Managed LPHD Security

01
Requirement status
Candidate
Capability maturity
Demonstrated at pilot scale

A consistent device-security baseline, controlled identity, private access and rapid removal of access.

User need
Units require locally purchased Android handheld devices to be prepared, issued and operated to a consistent security baseline.
Required outcome
Approved devices and users are attributable, protected services are accessed through a controlled private path, and access can be removed when no longer authorised.
Proposed thresholds
  • An approved baseline is applied to every issued device.
  • Every device and user has a unique attributable identity.
  • Protected services are restricted to approved managed devices.
  • A central device and account record is maintained.
  • Network and service access can be removed within 15 minutes of an authorised revoke instruction.
  • A revoked device can no longer access protected services.
Future objective
Automated provisioning, compliance reporting, controlled remote lock and wipe, role-based administration, central monitoring and exception alerts.
Current position
Ten pilot devices have operated using the current managed baseline and private service boundary. Device check-in, service revoke and controlled wipe have been technically demonstrated. Formal assurance and validation at larger scale remain outstanding.
Proposed validation
Conduct a phased device trial and confirm that all issued phones meet the approved baseline, are linked to an authorised user and can be revoked within the proposed response time.

KUR 2 — Controlled Communications and Information Services

02
Requirement status
Candidate
Capability maturity
Core functions demonstrated

Controlled messaging, files, collaboration and authorised situational-awareness functions.

User need
Users require controlled communications and information sharing without relying on personal applications or directly exposing protected services to the public internet.
Required outcome
Issued devices can access approved communications, files and authorised location functions through controlled accounts and an approved private access path.
Proposed thresholds
  • Approved messaging and file-sharing functions are available.
  • Authorised location or common-operating-picture functions are supported where required.
  • Protected services remain inaccessible outside the approved access path.
  • User accounts are centrally controlled and attributable.
  • A user can be removed from relevant services within 15 minutes of an authorised instruction.
  • The trial environment supports at least 100 registered devices and 50 simultaneously active users without unacceptable degradation.
Future objective
Approved voice or PTT, collaborative document editing, separate project environments, controlled information sharing and support for alternate or degraded connectivity.
Current position
Messaging, file collaboration and situational-awareness services have been integrated into the current pilot. Formal performance testing, independent assurance and validation at the proposed scale remain outstanding.
Proposed validation
Conduct a representative communications exercise and measure service access, account removal, availability, user success rate, response times and faults.

KUR 3 — Device Lifecycle Management and Accountability

03
Requirement status
Candidate
Capability maturity
Partially demonstrated

Accountable preparation, issue, registration, revoke, return, rebuild and reissue.

User need
Units require a repeatable and auditable way to manage LPHDs throughout their operational lifecycle.
Required outcome
Commanders and G6 staff can determine which devices exist, who they are assigned to, which identities they use and what lifecycle actions have been completed.
Proposed thresholds
  • An authoritative record is maintained for 100% of issued devices.
  • Each device is linked to its user, project, network identity and service accounts.
  • Issue, return, revoke, rebuild and reissue actions are recorded.
  • Protected access is removed following an authorised revoke.
  • A returned or replacement device can be rebuilt within four working hours, excluding external repair or operating-system download time.
  • Privileged lifecycle actions produce an attributable audit record.
Future objective
Automated build packs, compliance status, electronic issue and return, controlled lock and wipe, RBAC, audit export and central monitoring.
Current position
Device registration, Guardian check-in, revoke, rebuild and controlled wipe have been demonstrated at pilot scale. Full automated compliance and administration of a 100-device estate remain to be validated.
Proposed validation
Conduct issue, transfer, loss, revoke, return, rebuild and reissue drills and measure completeness, access removal and rebuild time.

KUR 4 — W.O.L.F Sustain

04
Requirement status
Candidate
Capability maturity
Development required

Controlled location, holdings, shortage and resupply reporting through managed LPHDs.

User need
Users require a controlled method for submitting sustainment information, while commanders require an attributable and current view of holdings and shortages.
Required outcome
Authorised users can submit location, quantities, shortages and resupply requests, and commanders can view the latest information by user, call sign, vehicle or sub-unit.
Proposed thresholds
  • Users can submit authorised location, holdings, shortages and resupply information.
  • The latest information is displayed by user, device, call sign or vehicle.
  • Quantities are aggregated at troop, squadron or sub-unit level.
  • The author and time of the latest update are visible.
  • Changes are recorded in an audit history.
  • Revoked users and devices cannot submit or view protected information.
  • Connected submissions update the dashboard within 60 seconds.
  • Validation achieves at least 95% accuracy between submitted test holdings and displayed totals.
Future objective
Role-based views, offline update queues, map presentation, automated shortage alerts, resupply workflows and approved situational-awareness integration.
Current position
The existing dashboard, managed identities, device register and private service boundary provide the foundation. The Sustain module itself remains to be developed, tested and assured.
Proposed validation
Conduct an 8–12-week development and exercise trial using representative users, vehicles and holdings. Measure accuracy, update time, permissions, revoke behaviour and audit completeness.

KUR 5 — Scalable, Resilient and Supportable Service

05
Requirement status
Candidate
Capability maturity
Validation required

A supportable service that can operate at the approved scale and recover from failure.

User need
Units require W.O.L.F to remain supportable, measurable and recoverable as the number of users, devices and projects increases.
Required outcome
The underlying service provides sufficient capacity, monitoring, backup and recovery to support the proposed trial without relying on one untested server or one individual administrator.
Proposed thresholds
  • At least 100 registered devices are supported.
  • At least 50 simultaneously active users are supported.
  • Availability is at least 95% during defined trial periods, excluding approved maintenance.
  • Administrators are alerted before CPU, memory or storage reaches approved critical thresholds.
  • Critical data and configuration are backed up to a separate protected location.
  • A representative service can be restored within the approved provisional Recovery Time Objective.
  • The service can operate without dependence on one individual administrator.
Future objective
Service redundancy, automated failover, geographically separate recovery, continuous monitoring, multiple trained administrators and migration between approved VPS, dedicated hosted and organisation-owned on-premises environments.
Current position
The VPS pilot demonstrates the core service and administration model. Full recovery, load testing, support depth and alternate-hosting validation remain outstanding.
Proposed validation
Progress through staged tests using: 10–20 devices → 40–50 devices → up to 100 devices Measure concurrent activity, service availability, CPU, memory, storage, network use, backup success, restore time, support demand and administrator handover.

Validation matrix

The matrix summarises the validation focus and principal evidence associated with each candidate requirement.

RequirementValidation focusPrincipal evidence
KUR-1Device baseline, attribution and revokeCompliance records, revoke timing and lost-device exercise
KUR-2Communications, controlled access and service capacityFunctional test, user results, availability and account-removal evidence
KUR-3Issue, return, revoke, rebuild and auditLifecycle records, access-removal proof and measured rebuild time
KUR-4Sustainment accuracy, latency, permissions and auditTest holdings, dashboard totals, update timing and role tests
KUR-5Capacity, availability, recovery and supportabilityLoad results, monitoring records, restore exercise and handover proof