M-DASH BATTLE MANAGEMENT MISSION WORKSPACE

An Engineering White Paper on Mission-Driven Battle Management and Human-Machine Teaming

Document Class: Engineering Specification (Conceptual) Audience: Air Force Research Laboratory stakeholders, mission operators, program managers, system integrators, and acquisition leaders Scope: Conceptual architecture only. This document contains no source code, credentials, cryptographic key material, or implementation-specific detail.

Abstract

The M-DASH Battle Management Mission Workspace is the flagship mission implementation of the Symphony Mission Workspace: a mission-agnostic operational experience framework in which a battle management mission runs as a live, governed decision environment rather than a static dashboard. It connects the operational picture (tracked entities and available effectors on one geographic view), the decision pipeline (observations assessed for actionability, matched to eligible effectors, and expressed as versioned courses of action), and the human decision (a named operator's approval, rejection, or request for analysis, recorded with its time, actor, and rationale).

Four commitments distinguish the implementation. First, the system proposes and the human decides: every course of action is a system recommendation with stated evidence and confidence, and the authoritative decision of record is made by a named human reviewer. Second, one pipeline for every event: external orchestrator events and internal mission events flow through the identical processing path, so integration cannot introduce a shadow workflow. Third, every record carries provenance: an entity's state, an observation's source, an option's evidence, and a reviewer's action are all traceable, and the trace survives export into the audit log. Fourth, the interface contract is versioned and provisional until proven: the AFRL Digital Orchestrator integration runs today against a clearly labeled provisional schema, and official specifications arrive through schema import and field mapping, never through processing changes.

1. Introduction

1.1 Purpose of This Document

This document serves four audiences:

• The mission operator who must maintain custody of a fast-moving operational picture and needs assessments and options that arrive with their evidence attached.
• The human-machine teaming authority who must certify that automation assists rather than displaces the operator, and needs structural guarantees rather than policy statements.
• The integration engineer who must connect an external mission orchestrator without bending the platform to it, and needs a versioned, testable interface contract.
• The program manager and evaluator who must show that the system's behavior is deterministic, auditable, and honest about what it does not know.

The document stays at the conceptual level: what the workspace guarantees and why it is built the way it is.

1.2 What the M-DASH Mission Workspace Is

The workspace is best understood as four cooperating systems over one mission record:

1. The Mission Workspace: the manifest-driven operator surface, with an operational world map, entity and asset tables, decision threads, a mission timeline, and the outcomes record.
2. The Processing Pipeline: the reasoning core that assesses observations, matches actionable entities to eligible effectors, and proposes versioned courses of action.
3. The Governance Layer: human review with accountability trails, dynamic reassessment, supersession of stale options, and the exportable audit log.
4. The Integration Adapter: the bidirectional, headless bridge to the AFRL Digital Orchestrator, schema-versioned, validated, and testable.

1.3 What It Is Not

It is not a map viewer with a chat box, and not an autopilot. It does not select targets, commit effects, or close decisions on its own. It is a governed decision environment in which the system's reasoning is inspectable, the human's decision is authoritative, and nothing of operational consequence happens without a record.

2. The Operational Problem

• The picture and the decision live in different rooms. Entities on one screen, asset availability on another, courses of action in a slide deck. The distance between the picture and the option list is where speed and accuracy are lost.
• Options arrive without their reasoning. A recommendation that cannot show which observations support it, which constraints bind it, and what would invalidate it is an assertion.
• Asset contention is invisible. When one effector is demanded by several live decisions, the conflict is discovered at execution time or not at all.
• Conditions change under open decisions. A track moves, an asset degrades, a conflicting report arrives, and the option approved an hour ago is quietly stale.
• Integration becomes a rewrite. A bespoke orchestrator path brings its own validation, logging, and failure modes, diverging from the internal pipeline the day it ships.
• The audit is assembled by hand. Reconstructing who saw what and who decided what takes days of forensic work after the mission.

The M-DASH Mission Workspace closes these failures structurally.

3. Design Philosophy

1. The system proposes; the human decides. Assessments, matches, and options are system recommendations with distinct provenance. Approval, rejection, or analysis requests are human actions recorded by name and time.

2. One pipeline, every source. External and internal events take the identical path through observation, assessment, matching, and proposal. No integration side door means no unrecorded workflow.

3. Provenance on every record. Entities carry source systems and observation histories; observations carry source, time, and classification; options carry their evidence; review actions carry actor and rationale. A trace can be walked in either direction.

4. Determinism where operators must trust it. Effector matching is rule-based and deterministic: capability, readiness, proximity, and existing commitments. Stochastic reasoning is labeled as system-generated wherever it appears.

5. The mission is a manifest, not a hardcode. Views, terminology, metrics, and entity types are declared in the mission's published manifest. A new mission type is a configuration event, not a rebuild.

4. System Architecture Overview

• The manifest layer. Each mission publishes a workspace manifest declaring mission type, enabled views, visualization, terminology, entity types, metrics, and governance. Superseding publishes a higher version; prior versions remain for rollback.
• The record layer. Tracked entities and effectors, observations, decision threads, and versioned courses of action, all linked, all carrying their synthetic-versus-live distinction.
• The pipeline layer. The observe, assess, match, and propose engines, running per processing tick as a scheduled headless process that continues whether or not a workstation is open.
• The review layer. Decision threads in explicit states (monitoring, matching, course-of-action generation, human review, decided, closed) with accountability trails.
• The integration layer. The versioned adapter: transports, validation, field mapping, correlation, message logging, and the readiness console.
• The audit layer. A chronological, exportable log combining observations, entity changes, option updates, and human reviews.

Each layer produces records the audit layer can read. Any decision can be walked back to the observations that triggered it and the reviewer who closed it.

5. The Mission Workspace

5.1 The Operational Picture

The primary visualization is a zoomable, pannable geographic map on which tracked entities and available effectors plot by domain. Selection-driven investigation lets an operator pick a contact and read its state, confidence, actionability assessment, and observation history without leaving the map. The entity and asset tables share selection state with the map, so tabular and spatial views stay one picture, and the map freezes in place while the tables scroll beside it.

5.2 The Manifest

The manifest is the mission's contract with its workspace: which views are enabled, what the primary visualization is, which terminology and metrics apply, and what governance governs. View keys resolve through aliases so a manifest-enabled view never silently disappears.

5.3 Stewardship of Attention

The overview presents mission state, processing latency, and the entities that currently require action. Dense surfaces stay collapsed by default and expand on demand.

6. The Processing Pipeline

6.1 Observe

Events become observations: bounded records with source system, source type, observation time, classification, and content. Track updates, new entities, conflicting reports, asset degradations and restorations, and mission communications all land here. Nothing enters the mission record outside this path.

6.2 Assess

The assessment stage updates entity state and confidence, and assigns each entity an actionability level (none, low, moderate, high) with a stated reason citing the observations behind it. Confidence drops explicitly when sources disagree, so the operator sees the disagreement rather than a smoothed-over average.

6.3 Match

The matching stage is deterministic. For each actionable entity it scores available effectors on capability coverage, readiness, and proximity, and flags effectors committed to another active course of action. Candidate matches carry per-candidate rationale and declared conflicts.

6.4 Propose

The proposal stage expresses the match as versioned options on the entity's decision thread: a direct engagement using the best-positioned asset, an ISR-led confirmation path that preserves decision quality at a timeline cost, and a paired-effects option that compresses the decision cycle. Each option carries required resources, constraints, assumptions, dependencies, risks with severity and mitigation, expected effects, an uncertainty statement tied to state confidence, and a numeric confidence derived from the evidence. Proposing never executes anything.

6.5 Reassess

When conditions change under an open or decided thread, affected options are superseded and new versions are re-proposed, with the reason recorded. Prior versions remain readable, so a reviewer sees both what was considered before and what changed.

7. Decision Threads and Versioned Courses of Action

A decision thread opens when an entity becomes actionable, carries its triggering observation, and advances through explicit states: monitoring, matching, course-of-action generation, human review, decided, closed. The state machine is the contract; no stage is skipped and no stage is silent.

Options are versioned records, not overwritten drafts. Contention is declared, not discovered: an effector committed to an active option is flagged in every subsequent match, and approved options on decided threads release their effectors back to the pool so concluded decisions cannot starve new ones. Conflict is a first-class field on every proposal.

8. Human-Machine Teaming and Review

8.1 The Review Contract

A proposed option reaches human review and waits. The operator approves it (deciding the thread and rejecting the alternatives by selection), rejects it, or requests deeper analysis. Every action appends to the accountability trail on both the option and the thread: time, actor, action, and note.

8.2 What the Reviewer Sees

The review surface shows the option's evidence, rationale, confidence, risks, conflicts, and uncertainty statement, alongside the alternatives it beat and the observations that triggered the thread. A reviewer approves an argument, not a headline.

8.3 The Outcomes Record

Decided threads close into the outcomes record: the selected option, the assets it committed, the alternatives rejected, and the full accountability trail. The outcomes view is read-only by design; it is the authoritative record, not a working surface.

9. The AFRL Digital Orchestrator Integration

9.1 Headless and Bidirectional

The adapter runs independently of the operator interface. Inbound orchestrator events are validated, normalized through field mappings, and injected into the identical pipeline that processes internal events; outbound processing results are published with the correlation identifier propagated end to end.

9.2 A Provisional, Versioned Contract

Until AFRL supplies official interface specifications, the adapter operates against a clearly labeled provisional schema version used for integration testing only. Official specifications arrive as an import: a new schema version carrying the interface definition, field mappings, a compatibility analysis, and the gaps requiring mapping decisions. Activation is an administrative action, and processing logic does not change when the schema does.

9.3 Validation and Correlation

Every inbound message is validated against the active schema (strict or permissive mode). Every message, inbound and outbound, is logged with direction, transport, schema version, validation status, payload, latency, and traceability references. Malformed input is quarantined with its errors recorded, never silently reshaped.

9.4 Readiness Before Claims

The integration readiness console exercises the adapter end to end: configuration, schema versions, message log, and a persisted acceptance suite covering valid, malformed, interrupted, and concurrent event streams. What the console reports is what the integration has actually passed.

10. Provenance and Audit

Provenance is a structured field on mission records: source system, last observation references, and a bounded change history on every entity and effector. The audit export assembles observations, entity changes, option updates, and human reviews into one chronological, machine-readable log, downloadable as JSON or CSV and previewable in place. Reconstructing a mission takes minutes, not days.

11. From Synthetic to Production

The mission environment ships with a synthetic operational world, clearly labeled on every seeded record, exercised through deterministic scenario plans (baseline, rapidly changing picture, resource degradation, conflicting observations, concurrent threads, human-machine review, reassessment, end to end). Production is a configuration event, not a rebuild:

• The event feed changes hands: orchestrator inbound events replace scenario generation through the same pipeline.
• The world changes hands: orchestrator tracking and force-status data replaces the seeded world, with every production record carrying live provenance.
• The contract changes hands: the official schema version is imported, its compatibility reviewed, and it is activated over the provisional one.
• The transport changes hands: endpoints and the government-specified authentication mechanism are configured, and the readiness suite is re-run against the real transport.

Replay and reset controls are synthetic-environment conveniences and do not carry into a production manifest.

12. Security Architecture

Role-gated administration governs simulation controls, adapter configuration, schema imports, and audit export. Row-level rules constrain every mission record family. Human review actions are attributed to their named actor and cannot be attributed to the system. The adapter's provisional transport token is server-side only and redacted from every client response. External transport authentication remains inactive until the government specifies its mechanism, and the readiness console makes that posture explicit. Classification labels ride on records where applicable, so handling follows the record.

13. What the M-DASH Mission Workspace Delivers

13.1 Speed With Accountability

The observe-assess-match-propose cycle shortens the distance between a change in the picture and a defensible option on the thread, and the human review contract keeps speed from outrunning accountability.

13.2 Options That Argue

Every proposed option carries its evidence, constraints, risks, and confidence. Reviewers approve reasoning, and the record preserves the argument.

13.3 A World Without Shadow Workflows

External and internal events share one pipeline, one validation path, and one audit trail. Integration adds sources, not side doors.

13.4 An Honest Transition

The provisional contract is labeled provisional, the synthetic world is labeled synthetic, and the readiness console separates what is proven from what is planned.

14. Governance, Compliance, and Assurance

The governance posture combines structural separation of system recommendation from authoritative decision; deterministic matching with declared contention; provenance and accountability on every record; versioned interface contracts with compatibility analysis and gap tracking; persisted integration test results; role-gated controls; and the exportable chronological audit log. For a human-machine teaming evaluation, the question "what did the system do and who approved it" is answered from records, in order, without reconstruction.

15. Conclusion

Battle management rewards environments that keep the picture, the options, and the decision in one governed place. The M-DASH Mission Workspace keeps the reasoning inside the record: every observation sourced, every match explained, every option versioned, every decision attributed. It is not an autopilot with a map; it is a decision environment in which automation does the assembly and the human retains the authority.

Appendix A. Glossary

• Mission Workspace: The mission-agnostic Symphony operator surface: operational picture, decision threads, timeline, and outcomes, enabled by the mission's published manifest.
• Workspace Manifest: The mission's configuration record declaring enabled views, primary visualization, terminology, metrics, and governance posture, versioned for rollback.
• Mission Observation: A bounded record of something the mission saw: source system, source type, time, classification, and content.
• Tracked Entity: An operational entity the mission tracks, with state, confidence, domain, actionability, and provenance.
• Effector: An available operational asset or capability, with readiness, employment constraints, and capability declarations.
• Actionability: The assessment-stage classification of an entity's need for action (none, low, moderate, high), always carrying its stated reason.
• Decision Thread: The explicit-state record that opens when an entity becomes actionable and advances through monitoring, matching, course-of-action generation, human review, decided, and closed.
• Course of Action (COA): A versioned system-proposed option on a decision thread, carrying evidence, constraints, assumptions, risks, conflicts, expected effects, uncertainty, and confidence.
• Dynamic Reassessment: The automatic supersession and re-proposal of affected options when conditions change under an open or decided thread.
• PAE: The perception and assessment stage of the processing pipeline: observation ingestion, state and confidence update, and actionability assessment.
• MEF: The mission-effector fit stage: deterministic scoring of candidate effectors on capability, readiness, proximity, and existing commitments.
• GBC: The course-of-action generation stage: versioned, evidence-backed option proposals on decision threads.
• AFRL Digital Orchestrator: The external orchestrator the integration adapter connects to bidirectionally, headlessly, and through the same processing pipeline as internal events.
• Integration Adapter: The versioned bridge handling transports, validation, field mapping, correlation, and message logging for orchestrator traffic.
• Schema Version: A stored, labeled interface contract version (provisional, imported, or active), with field mappings and compatibility analysis.
• Field Mapping: The logical-to-physical field resolution that lets a new official schema activate without processing changes.
• Correlation Identifier: The identifier propagated from an inbound event through its processing results, enabling end-to-end trace.
• Integration Readiness Console: The administrator surface that exercises configuration, schemas, message traffic, and the persisted acceptance test suite.
• Synthetic World: The clearly labeled seeded operational environment and scenario plans used for evaluation before live orchestrator data arrives.
• Accountability Trail: The append-only record of human review actions: time, actor, action, and note, kept on both the option and the thread.
• Audit Log: The chronological, exportable record combining observations, entity changes, option updates, and human reviews.