Abstract
Commercial frontier AI advances through a global system of computation, research, software development and feedback. Deploying a model inside a defense network does not reproduce the system that continually advances its capability. Physical separation and controls on information exchange change both what can execute and how improvements can reach the mission environment. This structural barrier affects the development tempo of AI-assisted engineering, scientific computation and mission preparation. PALLC’s research addresses the architectures and transition processes required to develop and sustain AI-augmented Digital Engineering, Modeling & Simulation (DEM&S) under those conditions. The objective is to turn commercial advances into usable mission capability while protecting the information and systems on which the mission depends.
The model is one product of a larger system
Frontier AI here refers to the leading large commercial AI models. Their development and application draw on a much larger system: computing infrastructure, research, training and evaluation, shared software, engineering tools and experience from deployment. A model release captures a result of that process. The process continues after the release.
The surrounding software develops through contributions across companies, research organizations and developer communities. The Agentic AI Foundation provides a concrete example: competing suppliers contribute shared protocols and engineering tools that other developers extend and integrate. Capability advances through new combinations of models, tools and methods as well as improvements to individual models. Agentic AI Foundation.
PALLC’s central argument is that importing the products of this ecosystem is different from participating in the continuing system that produces them. Installing a model and an internal toolset can provide substantial capability at a given point in time. Sustaining the pace of improvement requires an architecture for incorporating subsequent advances and evaluating them against mission needs.
Physical separation changes the development process
A desktop interface can coordinate inference, retrieval and execution performed on remote infrastructure. Moving the interface onto a defense network does not move that infrastructure. A physically disconnected network has no route to external services; a restricted but connected network can reach only the endpoints and exchange only the information its architecture and authorization permit.
This boundary constrains more than tool availability. It changes how developers obtain new models and software, consult external information, collaborate on failures and improvements, and incorporate operational experience. Mission data that cannot leave the boundary cannot participate directly in external development and evaluation. External improvements must enter through permitted transfer, assessment and deployment processes. The two environments therefore operate through different information flows and change processes.
Google’s air-gapped reference architecture illustrates the internal infrastructure required: inference servers, accelerator hardware, model storage, an artifact registry and network controls. Its open-weight deployment provides a self-contained operating environment. That environment still requires its own process for obtaining, evaluating and incorporating subsequent model and software releases. Air-gapped deployment architecture.
The resulting research question is how much useful capability can be transferred, sustained and advanced within the mission boundary—and how long that process takes as the commercial ecosystem continues to change.
Improved access does not remove the structural barrier
Government model access has advanced. CDAO’s September 2026 modernization report describes expanded platforms and programmatic access to frontier models through GenAI.mil. PALLC’s assessment incorporates that progress: model availability has improved, while the broader problem of sustaining an evolving engineering capability across the boundary remains. CDAO modernization report.
Technical documentation shows specific consequences of separate deployment environments. For Foundry Agent Service in Azure Government, Microsoft lists prompt agents, code interpretation, file search and function calling, while hosted agents, web search, browser automation and computer use are unavailable in that service in the listed US Gov Virginia and Arizona regions. Its model policies also describe different model selections and staged release availability. These are observable differences in what can be deployed and when. Government agent capabilities · Model lifecycle · Government release policy.
Internal inference, persistent memory, semantic retrieval and agent coordination can operate within a closed network. Google describes purpose-built disconnected infrastructure and an internal agent architecture. Such implementations address local execution; their sustained effectiveness also depends on model access, available compute, engineering integration and controlled updates. Disconnected infrastructure and agent architecture.
The distinction is between deploying a capability and sustaining the process that improves it. Project memory, software improvements and changes to foundation-model weights are different mechanisms. Each requires appropriate data, infrastructure and authority; their effects must be assessed separately.
Consequences for digital engineering and mission preparation
Consider an AI-assisted response to a changed mission requirement. The activity may require interpreting source documents, updating a semantic model and system architecture, generating or modifying code, executing coupled simulations and assessing the results. A model that can explain those steps still depends on access to the actual models, solvers, interfaces and execution environment to perform them. Missing dependencies interrupt the engineering process and return the burden to manual reconciliation.
That limiting factor affects model-based systems engineering (MBSE), scientific code generation, computational physics and doctrine-informed modeling. It also affects exercise preparation, analytical wargaming and operational assessment when scenario development and analysis depend on those engineering outputs. The consequences reach development schedules, test preparation and the ability to assess alternatives under operationally relevant conditions.
DoDI 5000.97 places digital models and their underlying data within an integrated lifecycle engineering approach. Its digital engineering ecosystem encompasses hardware, software, networks, tools and workforce; its capability includes V&V, configuration management and test infrastructure. AI-assisted automation has to operate within that ecosystem to contribute to the program. Official digital engineering summary.
Section 221 of the FY2026 National Defense Authorization Act requires military-department digital engineering reference architectures, including requirements for tools, data management and modeling standards. PALLC’s research addresses a related implementation challenge: how to incorporate commercial AI advances into these engineering environments while preserving authoritative models, traceability and controlled execution. Public Law 119-60, Section 221.
Develop the capability within the mission environment
PALLC develops AI-augmented DEM&S architectures that connect source information, semantic models, executable system architectures, engineering tools and computational methods. Frontier models support interpretation, reasoning and generation. Explicit interfaces, configuration control and verification checks connect those outputs to model execution and engineering assessment. Customer-sponsored research and development adapts this integrated capability to the infrastructure and authorities available to the program.
Development begins by identifying the required engineering activity and its dependencies. We map the models, data, compute, tools, permissions and information flows needed to complete it. That assessment establishes which capabilities can transfer, which require an internal implementation and which remain limited by model or service availability.
Where the information permits, unclassified development can participate in the commercial ecosystem. Controlled software and model baselines then support transition into the target environment through the customer’s assurance and authorization processes. Internal orchestration, persistent context and defined tool interfaces support operation within the boundary. Model interchange, governed updates and repeatable evaluation support continued development as the external ecosystem advances.
Acceptance should measure completion of the engineering task in the intended environment: correctness, elapsed time, analyst intervention, traceability and recovery when a dependency fails. It should also measure the time and effort required to incorporate a subsequent model or software improvement. M&S verification and validation must address the models’ intended use; cybersecurity authorization addresses a different decision. Exercises, analytical wargames and operational assessment examine how the integrated capability supports mission objectives.
The development opportunity is to reduce the interval between an advance in commercial AI and its effective use in a defense mission environment. PALLC connects the architecture, computational science and mission understanding needed to identify limiting factors, develop the required capability and assess performance through successive changes.
Speed from Rigor.