What Almighty does, in the language of the exercise.
Exercise Control
EXCON consoles that understand why officers made the calls they made.
Almighty is built around the exercise controller, not the after-action analyst. Every sensor return, effector engagement, and commander order is a node in a PyRapide directed acyclic graph (DAG) with its causal predecessors recorded — the EW cone that triggered the radar return, the radar return that cued the engagement, the commander order that authorized it. Controllers see the chain of decision live — not as a post-hoc reconstruction. Branch points are explicit. Override authority is explicit. The white cell never has to guess what an agent was about to do, because the DAG already says what the agent's last decision was caused by.
- Live PyRapide DAG visualization
- Per-event override authoring
- Capability-profile-bound officer interfaces
- Resium 3D battlespace with effect overlays
- Tenant-scoped event stream
White Cell Adjudication
The white cell sits outside blue and red. So does the override gateway.
The white cell adjudicator agent runs after blue and red between turns. It enforces three override scopes in strict priority — per-event beats per-agent-per-turn beats per-turn. The default is review: an empty policy table means everything pauses for human decision. Adjudication state machine is explicit, audited, and replayable.
- Three override scopes with strict precedence
- Default-to-review policy posture
- Contested-effect resolution workflow
- Cross-tenant visibility within tenant scope
- Capability-profile authoring tools
Live-Fire Augmentation
From synthetic exercise to live-fire range — same DAG, same officers.
Distributed Interactive Simulation (DIS) and High-Level Architecture (HLA) adapter contracts let real device telemetry commit into the same PyRapide kernel that ran the synthetic rehearsal. Officers stay in their lane: Sensor officers detect, Effector officers engage, Communicator officers manage EW posture. Capability profiles validate every action against what the device can actually do. When the ethics envelope permits, agents can run autonomously — but the white cell still owns override authority.
- DIS / HLA adapter contracts
- Live sensor and effector telemetry into the kernel DAG
- Capability-profile validation at the edge
- Bounded autonomous operation under white cell oversight
- Continuous AAR across synthetic and live phases
After Action Review
AAR is a re-walk of the DAG, not a scrub of in-memory state.
Replay is implemented by reading committed events from the per-tenant Postgres and re-walking PyRapide in causal order up to any turn N. There is no rollback API on the in-memory DAG; replay is always a fresh build, and the re-walk visits each event in the order its predecessors resolved — not the order it was inserted. This is a feature, not a limitation: replays are bit-identical across thousands of executions, the durable store is the system of record, and AAR readouts answer 'why did this happen in this sequence?' rather than 'what was on screen at minute 17?'
- Deterministic replay to any turn
- Per-tenant Postgres as system of record
- Bit-identical reproduction across executions
- Causal-order traversal independent of insertion order
- Exportable AAR PDF with unclassified banner
Multi-Tenant Range
Hard tenant isolation. Per-tenant VPC, RDS, S3, KMS.
Many scenarios. Many tenants. Zero cross-talk. Every record carries a tenant_id; every query is parameterized on it; every WebSocket fan-out delivery is filtered on it. PyRapide's Poset is partitioned per (tenant_id, scenario_id) so cross-namespace leakage is structurally impossible — no read path can return events from outside the namespace. Tested at four concurrent tenants with zero cross-talk required.
- Per-tenant VPC subnet, RDS, S3, KMS
- JSON Web Token (JWT)-bound tenant_id on every endpoint
- Namespaced PyRapide Posets — no shared event store
- WebSocket fan-out filtered on tenant_id
- Stress-tested at 4 concurrent tenants
Forward Deployment
GoRapide on hardware where Python cannot live. ACTA-hardened on every image.
Some environments do not host Python. The GoRapide engine variant is a single binary with an offline feed cache, suitable for on-device DAG execution behind hardware or firmware constraints. ACTA pre-hardening maps every container finding to DISA controls, CCI identifiers, and NIST 800-53 baselines, producing eMASS-importable POA&M CSVs and STIG CKL XML directly from the deployment image. Event triggers can be written in Go, C++, or Rust for low-level integration.
- GoRapide single-binary engine variant
- Offline feed cache (EPSS / KEV / NVD)
- ACTA-generated ATO artifacts on every build
- DISA Container Image Creation Guide compliance
- Go / C++ / Rust event trigger bindings