Evaluation Framework for Frontier Computational Systems in Critical Infrastructure

11. Introduction

Advanced computational systems are moving from advisory roles in critical infrastructure into roles where their outputs directly set operating conditions. Grid operators use learned models to forecast load and to recommend redispatch; logistics coordinators use them to route freight and allocate scarce capacity; clearing houses use them to screen and prioritize settlement instructions; communications operators use them to reconfigure traffic during congestion and faults. In each case the decision cycle is shortening, and the share of decisions that are reviewed by a person before they take effect is falling.

The 2026 Research Priorities Statement (DSC-ADM-2026-001) directed the Office of Advanced Artificial Intelligence (OAAI) to establish a repeatable method for evaluating such systems, with emphasis on properties that matter at the level of infrastructure rather than at the level of an individual model. This report describes that method. It was prepared by OAAI with the Office of Strategic Risk Assessment (OSRA) and forms the methodological basis of the Frontier System Evaluation Program.

The framework answers a narrow question: given a system and a proposed deployment role, what evidence is needed to characterize how the system, and the infrastructure that depends on it, will behave when conditions depart from those under which it was developed? It does not license, certify or approve systems for deployment. Decisions on deployment remain with infrastructure operators and the authorities that oversee them; the Department’s role is to generate and share evidence.

Scope

Four sectors are in initial scope: electric grid operations (transmission and distribution control, balancing, and protection coordination); freight and logistics (rail, port and long-haul road coordination, warehouse allocation); financial clearing and settlement (payment and securities settlement, margin and collateral processes); and communications (core network management, routing and traffic engineering). Water, health and food-distribution systems are expected to be added in later revisions. The framework covers systems whose behavior is substantially learned from data, including large general-purpose models adapted to an operational task, specialized learned controllers, and agentic systems that call tools or other models. Conventional deterministic control software is out of scope except where it wraps or constrains a learned component.

22. Background and rationale

Infrastructure failures of consequence rarely arise from a single faulty component. They arise from interactions: a component behaves acceptably in isolation, but its behavior couples with that of other components in ways that operators did not anticipate and cannot correct in time. The general literature on tightly coupled, interactively complex systems has long described this pattern.¹ Learned systems add three features that sharpen it.

1. Opaque failure surfaces. A learned system’s competence boundary is not specified in advance and is often discovered only when crossed. Performance can degrade sharply, without warning signals that a conventional controller would produce.
2. Shared lineage. Many deployed systems derive from a small number of base models, training corpora and toolchains. Systems operated by unrelated organizations may therefore fail on the same inputs at the same time.
3. Speed. Learned controllers can act faster than human supervisors can interpret, so the effective margin for human correction can shrink to zero during precisely the events in which it is most needed.

The Department’s Integrated Civilizational Systems Model (ICSM) treats these features through its Computational Systems and AI module, described in DSC-TR-2026-003. In the version 4.0 baseline that module relies heavily on expert-elicited parameters for failure rates, correlation and override effectiveness. A central purpose of this framework is to replace those elicited values, progressively, with values grounded in direct evaluation (Section 9).

The framework draws on established practice in AI risk management, in particular the organization of risk activities into governance, mapping, measurement and management functions found in widely used voluntary frameworks.² Its distinctive contribution is to measure properties that appear only when several deployments, operators and sectors are considered together.

33. Definitions

System under evaluation (SUE)

The complete deployed configuration: model weights or versions, prompts and policies, retrieval sources, tool interfaces, guard components and the deterministic software that wraps them.

Deployment role

The function the SUE performs in an operational process, classified R1–R4 in Section 5 by how directly its outputs take effect.

Consequence class

A classification (C1–C3) of the worst credible outcome of SUE failure within its deployment, based on the population and services affected and the time to restore them.

Operating envelope

The documented range of input conditions, operating states and action authorities within which the SUE is intended to function.

Distribution shift

Any systematic difference between conditions encountered in operation and those represented in the data used to develop or validate the SUE.

Safe state

A predefined operating condition, specified by the infrastructure operator, to which the process can be brought without the SUE and from which it can be held stable.

Digital twin

A simulation of an infrastructure process, calibrated against operational data, through which an SUE can be exercised in closed loop without access to real infrastructure.

44. Evaluation dimensions

Six dimensions are assessed. They are not independent: a system that is fragile under distribution shift and widely deployed will exhibit correlated failure; a system that is difficult to override amplifies every other weakness. Results are therefore reported dimension by dimension and then combined in a structured judgment, not summed into a single score.

55. Evaluation tiers

Not every deployment warrants the same depth of evaluation. The framework sets evaluation depth by two classifications: deployment role, which captures how directly the system’s outputs take effect, and consequence class, which captures the worst credible outcome of failure.

Role and consequence class together determine one of four evaluation tiers. Higher tiers add dimensions tested in closed loop, extend trial duration, and require independent review of the evaluation itself.

Any material change to the SUE, such as a new model version, altered tool permissions or expanded envelope, triggers re-evaluation at a tier proportionate to the change. Evaluations at T3 and T4 carry a validity period of 12 months, after which a reduced re-evaluation is performed against recorded baselines.

Evaluation process

Every evaluation follows the same five stages regardless of tier. At intake, the developer and operator supply the system description, lineage record and operating envelope, and the operator specifies the safe state and the task metrics against which performance will be judged. At classification, OAAI assigns role and consequence class; disagreements with the operator are recorded and, where unresolved, the higher classification is used. At planning, evaluators select catalogue entries, red-team objectives and scenario seeds, and fix the analysis plan before any results are seen. At execution, tests are run and results recorded against the plan, with any departures documented. At review, the reviewing body named in Table 3 examines methods and results, and may require additional tests before the report is issued.

Fixing the analysis plan in advance is deliberate. Closed-loop evaluation generates large volumes of results, and an evaluator free to choose which scenarios to emphasize after the fact can, without intending to, produce whatever conclusion the evidence most readily supports. Pre-registration of the plan within the program limits this, and departures from it are reported rather than prohibited.

66. Test environments at Facility Alpha

Closed-loop evaluation requires environments in which a system can act, observe the consequences of its actions and act again, without any connection to real infrastructure. The Frontier System Evaluation Program is establishing four sector digital twins at Continuity Research Facility Alpha in southern Nevada, on a partition of the facility’s primary system, ALPHA-1, that is physically and logically separated from production workloads such as ICSM runs. At the date of this report the twins are in commissioning ahead of the facility’s planned initial operating capability; pilot evaluations to date have used reduced-scale versions.

The twins can be coupled. A coupled run links, for example, the grid twin’s supply to the communications twin’s power-dependent nodes, and the communications twin’s availability to the clearing twin’s message delivery. Coupled runs are used at T4 to observe whether a fault introduced in one sector, or a system’s response to it, propagates to others.

Isolation and handling

Systems under evaluation are run on evaluation hardware with no route to external networks; developers supply artifacts through a controlled ingest process with integrity verification. Where a system can only be evaluated through a developer-hosted interface, the evaluation is limited to T2 and the report records the limitation. Red-team tooling and the results of adversarial testing are held on a segregated store and released only under the arrangements in Section 8.

Twin fidelity is itself evaluated. Each twin carries a validation record comparing its behavior against held-out operational episodes, and evaluators report results with reference to that record. A twin is a model, and a system that performs well in it has demonstrated performance in the model, not in the infrastructure.

77. Metrics and indicative acceptance criteria

Table 5 lists the core metrics recorded for each dimension and the indicative criteria evaluators apply at T3 and T4. The criteria are reference points for structured judgment, not pass–fail gates. A result outside a criterion is reported with its context, the mitigations proposed by the operator, and the evaluators’ view of whether those mitigations are adequate.

Uncertainty is reported for every metric. Performance retention ratios are given with bootstrap intervals over scenario seeds; correlated failure coefficients, which are estimated from comparatively rare joint failures, are reported with intervals and the number of joint events observed. Where the number of joint events is below 20, the coefficient is reported as indicative only.

88. Reporting

Evaluations are conducted under cooperative agreements with the system developer and the infrastructure operator. Each evaluation produces three outputs with different audiences.

• Evaluation report. The full record of methods, results, limitations and evaluator judgment, provided to the developer and operator. Adversarial findings are shared first with the party able to remediate them, with a remediation period agreed before wider disclosure.
• Sector summary. An aggregated account of results across evaluated systems in a sector, without identifying systems or vendors, shared with the relevant sector oversight bodies and with participating operators.
• Public summary. An annual, aggregated account of the program’s activity, the distribution of results by dimension and tier, and changes to the framework. Individual systems are not identified.

The Department does not publish rankings of systems or developers. Its interest is in the characteristics of the infrastructure as a whole, and rankings would create incentives to optimize for the evaluation rather than for the properties it is designed to measure.

99. Relation to the ICSM Computational Systems and AI module

The Computational Systems and AI module of the ICSM represents, for each modeled sector, the share of operational control exercised by learned systems, the rate at which those systems fail, the degree to which failures coincide, and the effectiveness of human override in limiting consequences. These quantities shape how stress in the module propagates to the Energy, Finance and Trade, Supply Chain and Manufacturing, and Information and Communications modules, and therefore the Composite Systemic Stress Index.

Evaluation results feed the module through a defined mapping maintained jointly by OAAI and OSRA (Table 6). Results are pooled across evaluations within a sector and role class before use; no single evaluation sets a model parameter. As the evidence base grows, parameters move from elicited distributions toward empirically constrained ones, and the module’s contribution to ensemble uncertainty is expected to narrow.³

The mapping also runs in reverse. ICSM sensitivity analysis identifies which parameters most influence systemic outcomes, and the Frontier System Evaluation Program uses that ranking to prioritize which sectors, roles and dimensions to evaluate next. In the version 4.0 baseline, inter-deployment correlation and override effectiveness in grid and communications operations rank highest, and the program’s first evaluation cycle is weighted accordingly.

1010. Limitations

• Twin fidelity. Results are conditional on how well the digital twins represent real operations, particularly under rare conditions for which calibration data are, by definition, scarce.
• Coverage of the shift catalogue. A catalogue records conditions evaluators can imagine. Failures arising from conditions outside it are not measured, and the framework cannot bound them.
• Access. Evaluation depth depends on the cooperation of developers and operators. Systems evaluated only through hosted interfaces cannot be tested to T3 or T4.
• Pace of change. Deployed systems are updated more frequently than evaluations can be repeated. Validity periods and change-triggered re-evaluation mitigate but do not remove this gap.
• Rare joint events. Correlated failure is hardest to measure precisely where it matters most, in rare, severe conditions.

OAAI will revise this framework annually. The first revision will incorporate experience from the initial evaluation cycle at Facility Alpha and extend scope to water system operations.