Skip to main content
Sky Shadow Systems Request a briefing
Unmarked grey VTOL aircraft on a wet coastal hardstand under an overcast sky.
Concept visualisation — not a photograph of deployed hardware.

Human-commanded multi-domain architecture

An airborne sensing role within one governed mission picture.

PHOBOS is described only at architecture level: a mature VTOL engineering foundation configured around approved sensors, mission context and human-commanded workflows.

Public architecture

What this page establishes

Public material describes roles, interfaces and governance boundaries without unsupported operational claims.

01

Engineering foundation

The aerial architecture builds upon an extensively developed and field-proven VTOL engineering foundation rather than a first-generation clean-sheet prototype. It is designed around high availability, repeatable operation and low failure rates; no unsupported reliability percentage is asserted.

02

PHOBOS Maritime

The public air-system role for wide-area maritime, port and offshore awareness. Payload, communications, range, endurance and operating-condition claims remain configuration-dependent and unpublished until verified.

03

PHOBOS Infrastructure

The public air-system role for energy, transport and remote-asset inspection, selected around the lawful operating boundary, evidence need and integration context.

04

PHOBOS Geo

The public air-system role for mapping, photogrammetry, LiDAR and environmental survey. No accuracy, coverage or payload claim is made without a verified configuration.

05

PHOBOS Government

The public air-system role for inspection, emergency response and authorised situational awareness, with mission objectives and consequential decisions retained under human command.

06

Mission-configurable integration

Payload, communications and command interfaces are selected for a defined mission and disclosed only at the appropriate review level.

07

Serviceability and evidence

Configuration control, maintenance context and digital-twin continuity are intended to keep the approved system identity attached to reviewable evidence; implementation detail remains subject to verification.

Digital twin lifecycle

Configuration continuity across asset life
Digital twin lifecycle timeline The lifecycle follows platform identity, components, approved configuration, software version, payload, calibration, maintenance, mission history, anomalies, engineering change and verification. 01PLATFORM ID 02COMPONENTS 03APPROVEDCONFIG 04SOFTWAREVERSION 05PAYLOAD 06CALIBRATION 07MAINTENANCE 08MISSIONHISTORY 09ANOMALIES 10ENGINEERINGCHANGE 11VERIFICATION VERIFIED STATE RETURNS TO THE CONTINUOUS RECORD Digital twin lifecycle, vertical layout Eleven vertically ordered stages preserve configuration continuity from platform identity through verification. 01PLATFORM IDENTITY 02COMPONENTS 03APPROVED CONFIGURATION 04SOFTWARE VERSION 05PAYLOAD 06CALIBRATION 07MAINTENANCE 08MISSION HISTORY 09ANOMALIES 10ENGINEERING CHANGE 11VERIFICATIONRETURN TO RECORD
The digital twin maintains a continuous record across platform identity, components, approved configuration, software, payload, calibration, maintenance and mission history. Anomalies lead to engineering change and verification before the state returns to the record.

Start a controlled briefing request

Share only your name, work email and enquiry type. Do not include sensitive detail; fuller mission context follows only through an agreed handling route.

Briefing requests are not yet open. The monitored handling and privacy review must be confirmed before this form can accept submissions.
Briefing enquiry
Use an organisation email address; free webmail addresses are not accepted.
Enquiry type