ABOUT // ALMIGHTY

A causal event engine, not a simulation framework.

Almighty was created at the Special Competitive Studies Project (SCSP) hackathon by Shane Morris, Devin Hill, and Alex Curnow. It is now engineered, deployed, and supported by Dynamo Technologies as a defense-grade wargaming, exercise control, and live-fire training platform.

◆ ORIGIN ◆

Built at the SCSP hackathon. Operated by Dynamo.

Created atSCSP Hackathon
FoundersShane Morris
Devin Hill
Alex Curnow
EnginePyRapide
Edge variantGoRapide
HardeningACTA · SCAP · STIG
ReadinessTRL-9
PostureUNCLASSIFIED // DEMO
OperatorDynamo Technologies

Almighty did not exist as a Dynamo product before the Special Competitive Studies Project (SCSP) hackathon. It was built there, in a single working session, by Shane Morris, Devin Hill, and Alex Curnow — to answer a question exercise controllers and white cell operators kept asking about every wargame and live-fire rotation: not what happened, but why it happened in that order.

The kernel is a tenant- and scenario-namespaced wrapper around PyRapide, the Python implementation of Stanford's RAPIDE causal event architecture. Every event lands in a directed acyclic graph (DAG) with its causal predecessors recorded — a sensor return, the electronic warfare cone that triggered it, the commander order that authorized response. Reading the graph gives the white cell the chain of decision, not a timeline of outcomes.

CrewAI agents — blue battalion, red Opposing Forces (OpFor), and the white cell adjudicator — use the native PyRapide connector to adapt and react to those DAGs in real time. As the kernel commits new events, agents consume the updated causal graph immediately and reorder their next moves against it. Officer interfaces validate every action against capability profiles before commit. The override gateway sits between agents and the DAG with three policy scopes; the white cell retains authority over everything irreversible.

Almighty does not replace the human in the loop. It clarifies what the human is in the loop for.

◆ PRINCIPLES ◆

Six design choices that shape every release.

  • 01

    Causality, not timeline

    Every event records its causal predecessors. A timeline tells you what happened in order; the directed acyclic graph (DAG) tells you why each step was the consequence of the steps before it.

  • 02

    Default to review

    An empty override policy table means everything pauses for white cell decision. Automation is a posture, not an assumption.

  • 03

    Hard tenant isolation

    PyRapide Posets are partitioned per (tenant_id, scenario_id). No read path can return events from outside the namespace.

  • 04

    Capability-bound officers

    Sensor, Effector, Mover, Communicator, and Commander interfaces validate every action against an immutable capability profile before commit.

  • 05

    TRL-9 posture

    Almighty is fielded at Technology Readiness Level 9 posture: SCAP- and STIG-hardened images, scanner-clean against grype, trivy, and anchore, with ACTA-generated XML and YAML artifacts ready for ATO and continuous ATO (cATO) pipelines.

  • 06

    Forward-deployable by default

    Single-binary GoRapide variant, air-gap-ready offline feed cache, ACTA-generated Authority To Operate (ATO) artifacts on every container image.

◆ PROVENANCE ◆

Upstream, downstream, and the hardening pipeline.

PyRapide is upstream at github.com/ShaneDolphin/pyrapide. The Almighty kernel layers tenant and scenario namespacing on top. ACTA is the Authority To Operate (ATO) readiness tool that hardens every Almighty container image — SCAP- and STIG-compliant, scanner-clean against grype, trivy, and anchore — and emits machine-generated XML and YAML artifacts (POA&M, STIG CKL, NIST 800-53 control assessments) consumable by any continuous ATO (cATO) CI/CD pipeline. GoRapide is the Go reimplementation for environments where Python is not viable.