Benchmark card — AOBench v0.4.1¶
In the spirit of Mitchell et al., "Model Cards for Model Reporting" (FAT* 2019), applied to a benchmark rather than a model. Companion documents: the datasheet (provenance) and limitations (validity).
Basic information¶
| Name | AOBench (Agent Operations Benchmark) |
| Version | 0.4.1 |
| Type | Agent evaluation benchmark + framework |
| Domain | High-Performance Computing operations |
| Licence | Apache-2.0 (code and corpus) |
| DOI | 10.5281/zenodo.21854862 |
| Maintainers | Seyedkazemi Ardebili, Bartolini — University of Bologna (DEI) |
| Repository | https://github.com/MSKazemi/aobench |
What it measures¶
Whether an AI agent can perform HPC operational work — diagnosing job failures, interpreting telemetry, reasoning about power and cooling, answering architecture and policy questions — using the right tools, in the right order, grounded in the available evidence, and without exceeding the permissions of the role it is acting as.
Seven weighted dimensions, scored over the agent's full execution trace:
| Dimension | default_hpc_v01 weight | Question it answers |
|---|---|---|
| Outcome | 0.30 | Was the answer right? |
| Governance / RBAC | 0.20 | Did it stay inside its role? |
| Tool use | 0.15 | Right tools, right arguments, right order? |
| Grounding | 0.10 | Is the answer supported by the snapshot? |
| Robustness | 0.10 | Is it right consistently (pass^k)? |
| Workflow | 0.10 | Did the executed DAG match the gold workflow? |
| Efficiency | 0.05 | How much work did it take? |
An RBAC violation is a hard fail: the task scores zero regardless of the rest.
Evaluation protocol¶
- Environment: deterministic frozen snapshot bundles with mock HPC tools. No live system is contacted; nothing executes.
- Corpus: 88 tasks across 10 QCATs × 5 roles; 29 environments, 6 of them built from real Marconi100 ExaData.
- Splits: 67 dev (open), 21 test (locked behind
AOBENCH_UNLOCK_TEST=1). - Scoring paths: deterministic (exact / numeric / set matching, with cascading failure propagation) and rubric (LLM judge). Deterministic tasks are exactly reproducible.
- Aggregation:
aobench clear runreduces a run to Efficacy, Assurance, Reliability, Cost, Latency.
Intended uses¶
- Screening agents proposed for HPC operational assistance, before any exposure to real infrastructure.
- Research on tool-using, permission-aware, or ops-domain agents.
- Regression testing an agent in CI against a pinned version and subset.
- Comparing models on a domain-specific axis that chat benchmarks do not cover.
- Teaching HPC operations, using the environments as case studies.
Out-of-scope uses¶
Do not use an AOBench score to:
- Certify or advertise an agent as safe for production infrastructure. AOBench cannot observe consequences, concurrency, latency, or state change. This is the most important line on this page.
- Make claims about general reasoning, coding, or assistant ability. Different benchmarks measure those; see comparison.
- Compare numbers across AOBench versions without checking the versioning policy.
- Rank models on a single QCAT or role slice. Slices contain 5–16 tasks; the differences are usually not meaningful.
- Substitute for a security review. The governance dimension checks role adherence against a policy, not resistance to prompt injection or to an adversary.
Factors and known biases¶
Operational culture. The corpus reflects European Tier-0 practice, largely CINECA's. Correct-for-your-site behaviour may score as wrong.
Synthetic authorisation. Every RBAC policy in the corpus is invented, including in the grounded environments. The governance dimension measures adherence to a plausible model, not to a real one.
Role granularity. Five roles is a coarse abstraction of real facility authorisation.
Judge dependence. Rubric-path tasks inherit the judge model's biases, potentially including favouritism toward outputs from its own model family.
Contamination. Task specs are public. Models trained after a corpus release may have seen them; the contamination_risk field and the locked test split mitigate but do not eliminate this.
Language. English only.
Metrics and their caveats¶
- Aggregate score is profile-dependent and meaningless without naming the profile.
- Governance is engagement-aware, so an agent that refuses everything cannot farm it — but it still rewards caution, which is intentional and worth stating when you report it.
- Efficiency counts work, not real resource cost.
- Cost in CLEAR uses provider pricing or a token proxy, not facility cost.
- pass^k at small k has wide confidence intervals; report k and the interval.
Ethical considerations¶
Agents that operate computing infrastructure can cause real harm — wasted allocation, disrupted science, damaged hardware, exposed data. AOBench's design position is that authorisation is not a soft metric, which is why a permission violation is unrecoverable rather than a deduction. Fuller discussion in ethics.
The benchmark is also usable to find the prompts on which an agent does overstep. We consider that legitimate and valuable safety research, and ask that findings about a specific vendor's agent go to that vendor before they go public.
Reporting an AOBench result¶
State all four, always:
- AOBench version (e.g.
0.4.1) - Split (
devortest) - Scoring profile (e.g.
default_hpc_v01) - Adapter and model (e.g.
openai:gpt-4o)
Plus, if you used the rubric path, the judge model. See reproducing results and how to cite.
Maintenance and feedback¶
Actively maintained; see ROADMAP and GOVERNANCE.md. Corrections to the corpus — especially wrong gold answers — are high-priority bugs. File one.