GuardianTwin MEDEVAC System

• GuardianTwin (MEDEVAC) is a decision support system that integrates logic programming, real-time data, and integer optimization to manage triage and resource allocation in medical evacuations.
• It employs a multi-layered design with a real-time data ingestion layer, a Datalog-style reasoning engine using PyReason, and a solver-driven optimization layer to orchestrate various triage strategies.
• Simulations demonstrate a 35.75% average reduction in casualties, highlighting its ability to compare and adapt different constraints to maintain the right patient, platform, escort, time, and destination.

GuardianTwin (MEDEVAC) is a logic-driven decision support system for forward medical evacuation (MEDEVAC) operations. The system integrates a Datalog-style logic programming layer with real-time data ingestion and integer programming–based optimization, enabling modular, interpretable, and efficient triage and resource allocation under the imperative of “right patient, right platform, right escort, right time, right destination.” GuardianTwin orchestrates multiple triage optimization variants, reasons symbolically over their outcomes, and provides explainable solutions—demonstrating a 35.75% average reduction in casualties compared to best-practice baselines in simulated high-stakes environments (Patil et al., 14 Jul 2025).

1. System Structure and Data Flow

GuardianTwin’s architecture comprises three key layers:

• Real-time Data Layer: Ingests geolocated casualty reports, asset (e.g., helicopter) statuses, and medical facility locations.
• Logic Programming Layer: Implements domain knowledge in a Datalog-style logic program Π using PyReason. This layer performs fixpoint deduction, which (a) computes triage scores via score(p,x) atoms; (b) determines which constraints use(c) and optimization criteria use(o) to activate; and (c) dynamically orchestrates multiple integer programming (IP) problems, each reflecting a possible triage policy.
• Optimization & Solver Layer: For each combination of selected criteria and constraints, constructs and solves IPs using the Python “MIP” package. Output assignments like assign(p,a), assign(p,f), and evac(p) are fed back into the logic program as ground facts to enable further deduction or explainability, and are surfaced through the system’s user interface.

A typical reasoning flow is as follows:

[Initial Facts & User Settings] ↓ PyReason Deduction ↓ {use(o_i,k), use(c_j,k)} → IP variant framing ↓ IP Construction & Solve ↓ {assign(p,a), assign(p,f), evac(p)} facts ↓ PyReason Deduction (optionally re-run) ↓ Further symbolic reasoning or UI reports

2. Formalization of Optimization Problems

For each candidate IP variant, GuardianTwin defines binary variables $x_{p,a,f} \in \{0,1\}$ representing assignment of casualty $p$ to asset $a$ and facility $f$, with $y_p$ denoting whether $p$ is evacuated.

The IP objective and constraints are determined by logic-derived facts (criteria and constraints in use). Key parameters are:

• $scr(p) \in (0,1)$: normalized triage score.
• $rtd(p) \in \mathbb{R}^+$: return-to-duty time.
• $lsi(p) \in \mathbb{R}^+$: latest allowable “life-saving intervention” time.
• $trip_p(a,p)$, $trip_f(p,f) \in \mathbb{R}^+$: asset-to-patient and patient-to-facility travel times.
• $trip(a,p,f) = trip_p(a,p) + trip_f(p,f)$: total trajectory.

Generic IP Formulation:

$$\text{maximize} \quad O = \sum_{p,a,f} x_{p,a,f} \cdot F_o(p,a,f)$$

subject to:

• $\forall p$: $\sum_{a,f} x_{p,a,f} = y_p$
• $\forall p$: $y_p \leq 1$
• $\forall a$: $\sum_{p,f} x_{p,a,f} \leq 1$
• Additional $c \in C$ s.t. $use(c) \in \Gamma^*(\Pi)$
• $x, y$ binary

Objective terms include:

• Urgency-based triage: $F_{scr}(p,a,f) = 1 + scr(p) - trip(a,p,f)$
• Reverse triage: $F_{rtd}(p,a,f) = 1 + 1/(1+rtd(p)) - trip(a,p,f)$

Common linear constraints are enforced only if activated:

• Life-saving intervention: $x_{p,a,f}=1 \Rightarrow trip_p(a,p) \leq lsi(p)$
• Triage score threshold: $y_p=0 \Rightarrow scr(p)\leq k$
• Return-to-duty threshold: $y_p=0 \Rightarrow rtd(p)\geq k$
• Air-time constraint: $$x_{p,a,f}=1 \Rightarrow trip_p(a,p) \leq k \land trip_f(p,f)\leq k$$

3. Variant Construction, Solving, and Facts Translation

Users in the Strategy Builder can choose subsets of constraints $C$ and one or more objectives $O$. The logic program Π derives use(o_k,j), use(c_i,j) atoms—one set per variant indexed $j$.

The execution procedure is as follows (paraphrased from provided pseudocode):

1. Deduce in Π to collect which variants and constraints are “in use.”
2. For each selected $(o,i)$,
   • Build IP with criterion $o$ and constraints $C_i = \{c | use(c,i)\}$.
   • Solve IP; translate the solution into logical facts: assign(p,a,i), assign(p,f,i), evac(p,i).
   • Insert new facts into Π; optional further deduction for cross-variant reasoning or recovery from infeasibility.
3. Present outcomes or traces in the UI.

This multi-variant orchestration supports direct symbolic comparison across alternative triage strategies and enables adaptive relaxation of infeasible constraints when necessary.

4. Formalization of the “5 R’s” Principle

GuardianTwin ensures the “right patient, right platform, right escort, right time, right destination” as follows:

5-R Component	Representation in GuardianTwin	Logic/Constraint Implementation
Right patient	Maximize $\sum y_p$ weighted by $scr(p)$ or $1/(1+rtd(p))$	Objective function selection (use(o_{scr}), etc.)
Right platform	Explicit $a$ selection in $x_{p,a,f}$	Platform domain; constraints (e.g., duty hours)
Right escort	Asset duty hours, range as constraints	use(air_range)-type constraints in Π
Right time	Enforced deadline on $trip_p(a,p)$ (life-saving intervention window)	$c_{lsi}$: $trip_p(a,p) \leq lsi(p)$
Right destination	Facility $f$ selection in $x_{p,a,f}$ plus air-time constraints	$c_{air}^k$: $trip_f(p,f) \leq k$

Declarative rules in Π encode these mappings; for example, score(P, niss(P)) ← insultsAvailable(P), ¬vitalsAvailable(P), and always enforcing the life-saving constraint with use(c_{lsi}).

5. Triage Orchestration and Coordination Algorithms

GuardianTwin’s decision coordination operates as follows (“OrchestrateTriage” procedure):

• Run logic deduction to determine which optimization problems to instantiate.
• For every criterion–constraint variant, build and solve the IP.
• Translate all IP solutions to symbolic facts (assign(p,a,i), etc.), which are integrated back into the logic program.
• Optionally, deduce again on the augmented fact base, supporting both post hoc analysis and further explainability.

Additional rules in Π can, for example, compare different Sol_i solutions or trigger progressive relaxation of constraints (e.g., triage score/rtd thresholds) in cases of infeasibility, yielding fully symbolic and explainable adaptation.

6. Experimental Evaluation

GuardianTwin was evaluated in simulation using exercise-grade data:

• Scenario: 25 casualties, 10 facilities, 1–25 assets per run, geodata over AZ–UT–CO, 10 repetitions per asset count, totaling 250 runs.
• Baselines:
  • B1: random assignment under life-saving constraint
  • B2: highest-scr first
  • B3: lowest-rtd first
• Metrics: Number evacuated, $\sum scr(p)$ on evacuated patients.
• Performance: Average IP solve time ≈ 6 ms; PyReason deduction 3–5 seconds.
• Results:
  • Single-criterion urgency/reverse triage doubled to 61% improved evacuations over B1–B3.
  • Multi-variant orchestration/constraint relaxation produced a 35.75% average casualty reduction compared to best single-criterion baseline.
  • Constraint relaxation experiments demonstrated feasibility recovery as thresholds were relaxed.
  • Gantt charts illustrated multi-asset assignment schedules and re-tasking as missions completed.

This demonstrates operational effectiveness and computational efficiency, with explainable adaptation and policy-level comparison (Patil et al., 14 Jul 2025).

7. User Interface, Explainability, and Interaction

GuardianTwin’s interface comprises:

• Strategy Builder: UI toggles directly map to logic facts (use(o), use(c)), allowing non-technical users to frame complex triage strategies.
• Mission Details: Tabular report of assignments (assign(p,a), assign(p,f)) with visual indicators for urgency and expected return-to-duty.
• Explainable Trace: PyReason can selectively output the subset of rules and facts that fired for a particular IP run or solution (“Used o_scr; c_lsi was enforced; c_scr^0.8 was relaxed to 0.9 after infeasibility in variant 2”), providing transparent justifications.
• Iterative Feedback: As real-time status changes, deduction and orchestration automatically update, with UI highlighting only outcome deltas (e.g., duty time depletion and re-tasking triggers).

The integration of symbolic logic and numerical optimization provides a modular and auditable approach to MEDEVAC resource planning, supporting explainable automated reasoning in mission-critical situations (Patil et al., 14 Jul 2025).