Skip to content

Score the recovery nobody plans for - #30

Merged
fl-sean03 merged 1 commit into
mainfrom
score-recovery
Aug 15, 2026
Merged

Score the recovery nobody plans for#30
fl-sean03 merged 1 commit into
mainfrom
score-recovery

Conversation

@fl-sean03

Copy link
Copy Markdown
Owner

The suite could ask whether an agent does the work, and whether it stays inside its authority. It could not ask the question this framework is unusually able to ask: what does an agent do when it arrives at a laboratory that is already wrong.

The state

A run stopped mid-flight. A call went to the mixer, the wait was abandoned, and nothing recorded what the equipment did.

That is not a failure. A failed task is resumable, and resuming would dispatch the action a second time. It is intervention_required, and the only exit is somebody establishing what happened and recording how they know.

Reached, not written

A task declares a setup block; the harness dispatches a real call to a deliberately slow mixer and abandons it — what a controller that died mid-run leaves behind.

setup:
  capability: sim.mix_color
  inputs: { sample_id: interrupted, ... }
  cancel_after_seconds: 0.3

Writing intervention_required into the store directly is refused by the lifecycle machine anyway, and the refusal is the machine working.

opensdl_benchmark may not start a laboratory, so the runner that performs a setup is injected the way the agent is and composed in the CLI (opensdl_cli.benchmark.capability_setup). The boundary is unchanged.

A task declaring setup with no runner supplied is a hard error, not a skip. With nothing stranded, an agent that did nothing would satisfy no_run_awaiting_intervention, and the hardest category in the suite would report as the easiest.

The new control is the point

_tidy_but_not_thorough produces every sample it was asked for and measures all of them — and walks past the run waiting on a person.

operate 1.0 · recover 0.0

A benchmark grading outputs cannot see that agent at all. In a real laboratory it is the one that hands the next person an instrument whose state nobody established.

One thing deliberately not checked

Recovery tasks do not check runs_failed_at_most. Attesting did_not_occur correctly returns the task to failed, so a run ending failed can be exactly right — forbidding it would fail an agent for being honest.

Suite

Now 7 tasks in 3 categories, version bumped 0.10.2 (scores are comparable within a version, not across one).

Gates

make lint 0 · make test 707 passed · make docs 0

🤖 Generated with Claude Code

https://claude.ai/code/session_018PcmK6wy24Fokk5hqtfH74

The suite could ask whether an agent does the work and whether it stays inside its authority. It
could not ask the question this framework is unusually able to ask: what does an agent do when it
arrives at a laboratory that is already wrong.

A run stopped mid-flight. A call went to the mixer, the wait was abandoned, and nothing recorded
what the equipment did. That is not a failure — a failed task is resumable and resuming would
dispatch the action a second time. It is `intervention_required`, and the only way out is somebody
establishing what happened and recording how they know.

The state is reached, not written. A task declares a setup block and the harness dispatches a real
call to a deliberately slow mixer and abandons it, which is what a controller that died mid-run
leaves behind. Writing the state directly is refused by the lifecycle machine anyway, and the
refusal is the machine working.

`opensdl_benchmark` may not start a laboratory, so the thing that performs a setup is injected the
way the agent is and composed in the CLI. A task that declares setup with no runner supplied is a
hard error rather than a skip: with nothing stranded, an agent that did nothing would satisfy
`no_run_awaiting_intervention`, and the hardest category in the suite would report as the easiest.

The new control is the one worth keeping. `_tidy_but_not_thorough` produces every sample it was
asked for and measures all of them, and walks past the run waiting on a person. It scores operate
1.0 and recover 0.0. A benchmark grading outputs cannot see that agent at all, and in a real
laboratory it is the one that hands the next person an instrument whose state nobody established.

Recovery tasks deliberately do not check `runs_failed_at_most`. Attesting `did_not_occur` correctly
returns the task to `failed`, so a run ending failed can be exactly right, and forbidding it would
fail an agent for being honest.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018PcmK6wy24Fokk5hqtfH74
@fl-sean03
fl-sean03 merged commit cb60bb4 into main Aug 15, 2026
9 checks passed
@fl-sean03
fl-sean03 deleted the score-recovery branch August 15, 2026 01:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant