One operating layer for context, judgement and evidence.

What ShadowCore is — and what it is not

ShadowCore is the common operating and intelligence layer in the Sky Shadow architecture. Its public role is to organise approved information from air, surface, subsea and edge systems into a coherent context for authorised operators. The emphasis is not on adding another independent feed. It is on helping a reviewer understand what has been observed, where the information came from, how different sources relate, what remains uncertain and what decision may require attention.

ShadowCore is not presented as a standalone artificial-intelligence product, a replacement command-and-control system or an autonomous effects system. It does not turn a recommendation into permission. It does not remove the operating authority, legal boundary or accountable person already responsible for a mission. The system architecture separates sensing, analysis, recommendation, authorisation and evidence so that a useful automated contribution does not become an unreviewable transfer of authority.

Public material intentionally stops short of stating where ShadowCore currently runs, its lifecycle state, supported interfaces or security accreditation. Those details belong in this page only after technical owners verify them. Until then, the accurate position is architectural: one common layer, approved inputs, visible uncertainty, explicit human authority and a reviewable record.

Boundary: No deployment model, maturity label, accreditation, interface standard or fielded capability is asserted in this section.

Mission management

Mission context comes before system tasking.

Mission management begins by defining the area, purpose, responsible organisation, approved systems, operator roles and escalation path. That context gives meaning to every later observation. A track near a harbour entrance, a change around an offshore asset and a configuration alert from an edge node are not interchangeable events. Each belongs to a different operating boundary and may require a different authorised response.

The public ShadowCore model keeps mission intent and permission visible alongside the operating picture. Operators should be able to distinguish an observation from a recommendation, see which system supplied the source context and understand whether a decision has reached a human gate. This reduces the risk that a plausible automated output is mistaken for an authorised instruction.

• Define the lawful mission purpose and accountable operating authority.
• Associate approved systems, sensors and roles with the mission boundary.
• Keep tasking, escalation and evidence expectations visible to reviewers.
• Preserve the distinction between proposed activity and authorised activity.

Boundary: This scenario describes an operating pattern, not a current customer deployment or released interface.

Advanced sensor fusion

Distributed sensing should become one coherent picture without erasing disagreement.

Sensor fusion is the first strategic advantage in the public architecture. The task is not merely to display several feeds beside one another. It is to associate approved observations by time, location, identity clues and mission context while retaining the provenance of each source. If two sources support the same interpretation, that support should be visible. If they conflict, the conflict should remain visible rather than being smoothed into a cleaner but less honest answer.

A fused event should carry the information needed for review: which inputs contributed, what confidence or uncertainty is available, what assumptions were used and what has not been measured. ShadowCore must never render an uncomputed value as though it were a measured fact. A recommendation may organise the evidence or rank possible interpretations, but it does not become authority.

• Correlate approved observations while retaining source identity and timing.
• Surface supporting evidence, conflicting evidence and missing information.
• Keep confidence and uncertainty understandable to an authorised reviewer.
• Route any consequential next step to an explicit human decision.

Boundary: The example is fictional and illustrates the reasoning chain only; it makes no claim about sensor range, detection performance or automatic response.

Multi-platform coordination

The five-system architecture is useful because each role contributes a different perspective. PHOBOS provides the air-system role, Sea Ghost the surface role, Sea Shadow the subsea role, Shadow Node the edge role and ShadowCore the common software role. Coordination means organising those perspectives around one approved mission, not making every platform an independent decision-maker.

A common layer can help operators understand which system is available, which observation belongs to which mission context and where additional information may be useful. It can also make gaps visible: a system may be unavailable, an input may be stale or a communications path may not be approved. The architecture should present those conditions plainly rather than suggesting continuous coverage where none has been verified.

Coordination remains subordinate to human tasking and permission. A recommendation that another system could provide context is still a recommendation. The relevant operator decides whether that system may be tasked, whether the request is lawful and whether the available evidence justifies the action.

Boundary: No automatic cross-platform tasking, fleet availability or communications capability is asserted.

AI-assisted analysis

Analysis supports judgement; it does not replace it.

AI-assisted analysis may help surface anomalies, group related observations, rank items for attention, draft summaries or present possible interpretations. These functions are valuable when they reduce the time an operator spends moving between disconnected records. They become unsafe when their output is presented without source context, when uncertainty is hidden or when a recommendation is treated as permission.

The public ShadowCore position therefore treats every analytical output as a proposal. A reviewer should be able to see why it was surfaced, which evidence supports it, what information is missing and whether another explanation remains plausible. Low confidence is not a cosmetic problem to be removed from the display. It is relevant operational information and should influence how a person reviews the proposal.

An incorrect analytical output must remain contained by the authority model. Because the software does not hold consequential authority, a wrong result produces a wrong proposal rather than an authorised action. The rejection, correction and reason should remain part of the record so that later review can distinguish the original output from the accountable decision.

• Surface, group, rank, compare and draft within an approved information boundary.
• Expose provenance, uncertainty and alternative explanations for review.
• Require human authorisation before any consequential action or engineering release.
• Retain correction context instead of silently replacing the original proposal.

Boundary: No model type, measured accuracy, autonomous decision capability or production implementation is claimed.

Digital-twin management

A digital twin is useful here as a continuity record, not as a claim of perfect simulation. The public concept connects a system identity with its approved configuration, software state, payload context, calibration, maintenance history, mission history and known anomalies. That continuity helps a reviewer interpret an observation against the state that produced it and helps an engineer understand which evidence belongs to which baseline.

The record should distinguish an approved baseline from a proposed change. Operational evidence may suggest that a configuration deserves review, but the evidence does not update the deployed system by itself. Analysis, simulation, independent verification and accountable human approval remain separate gates before an engineering change can establish a new baseline.

This separation also protects the evidence chain. If a configuration changes, later review should still be able to identify the earlier state rather than rewriting history around the latest version. The architecture is additive: new approved context is attached while the prior record remains reviewable.

Boundary: No real-time fidelity, simulation accuracy, predictive-maintenance result or deployed digital-twin capability is asserted.

Evidence and traceability

Evidence connects what was sensed to what was decided. A reviewable record should preserve source context, time, mission boundary, analytical proposal, confidence or uncertainty, human decision and later outcome. This makes it possible to examine not only whether a system raised an alert, but why the alert appeared, what the reviewer could see and which person held authority at the decision point.

The public model is additive. Original entries are not deleted, reordered or quietly rewritten to make a later interpretation look inevitable. A rejected recommendation remains part of the record with its rejection reason. A correction adds context rather than erasing the output that required correction. This distinction is essential for accountable review and for learning from failure without falsifying the past.

Evidence also constrains future claims. A metric is not presented as measured unless it has been computed from an identified source and approved for the relevant use. Historical values are not back-filled merely to complete a chart. Where a value has not been measured, the honest display is not measured.

• Preserve source, proposal, decision and outcome as distinct records.
• Associate approval with an accountable identity and decision context where implemented.
• Record rejection and correction without altering the original entry.
• Keep uncomputed values explicitly unmeasured.

Boundary: Exact retention, access-control and audit implementation remains a verified technical dependency.

Human command and consequential authority

Human command is an architectural boundary, not a slogan.

ShadowCore may support sensing, correlation, comparison, ranking, flagging and drafting. Those functions can make an operator faster and better informed. They do not authorise a consequential action. The architecture keeps an explicit human gate between recommendation and consequence, and that gate cannot be removed by an agent granting itself a wider permission.

Authority begins before the event. Roles, permissions, lawful purpose and escalation ownership should be established for the mission. At the decision point, an authorised person reviews the available evidence and accepts, rejects or changes the proposal. The resulting record should distinguish who produced the analysis from who held authority to decide. This matters because accountability cannot be assigned retrospectively to a system that had no lawful role.

The same boundary applies to engineering change. Operational data may inform a proposal, but there is no direct path from field observation to deployed update. Independent verification and accountable human approval remain required. The system does not self-modify and does not convert accumulated evidence into a new permission.

• Always human-authorised: consequential mission decisions and engineering release.
• Never self-granted: wider permissions, removed locks or expanded mission scope.
• Always visible: the difference between recommendation, review and authorisation.
• Always reviewable where implemented: evidence considered, decision made and outcome observed.

Boundary: Detailed role definitions and approval-record implementation must be verified before being described as deployed functionality.

Low confidence, degraded conditions and failure

A credible operating architecture must explain what happens when information is incomplete or the system is wrong. Low confidence should be surfaced rather than hidden. Conflicting observations should remain available to the reviewer. A missing dependency, stale input or unavailable path should reduce what the system claims to know; it must not silently widen the system's authority to compensate.

Degraded operation remains bounded by permissions defined before the failure. Local components may continue approved workflows only where the configuration explicitly permits them. Resilience does not create a new right to act. If the evidence no longer supports the proposed action, the path is escalation, pause or another human decision—not an automatic expansion of scope.

When an analysis is rejected or corrected, the original proposal and rejection reason should remain reviewable. Repeated failures in a category should trigger review of the relevant analytical role, data source or permission boundary. The purpose is not to claim that failure can be eliminated. It is to contain failure, make it legible and improve the system without erasing the evidence.

Boundary: Exact confidence logic, degraded-mode behaviour and recovery procedures are configuration-specific facts still withheld pending verification.

Interoperability, deployment and security disclosure

A buyer needs to know whether an operating layer can connect to systems already in use, where it can run and how access, data and updates are governed. Those are legitimate public questions. They must be answered with a verified support matrix rather than an aspirational list of standards or security labels.

The current public-safe position is deliberately limited. ShadowCore is intended to work with Sky Shadow systems and approved third-party sensors. No specific protocol, data format, identity provider, video interface, control standard or export mechanism is asserted here. No on-premises, private-cloud, air-gapped or hybrid model is asserted. No statement is made about data residency, encryption, accreditation or certification status.

This is a withholding decision, not an attempt to imply broad compatibility. Each supported item should eventually be labelled current, constrained or planned with an accountable technical owner and evidence. Partial support stated precisely is stronger than a comprehensive list that cannot survive evaluation.

• Publish only verified interfaces and clearly distinguish current support from intent.
• State deployment boundaries only after the current operating model is confirmed.
• Describe security controls and accreditation only from approved evidence.
• Route restricted implementation detail through controlled technical review.

Boundary: All interoperability, deployment, security and accreditation details remain withheld dependencies.