# Harness operations lab: receipts, budgets and workload ownership

Rethinking Agents · October 1, 2026 · Executed synthetic experiment

**40 checks passed: 32 synthetic contract checks and eight lifecycle checks combining real Docker observations with controller simulations.** No language model, coding client, external provider or production gateway was tested. PASS means the stated fixture assertion held; it does not grade a commercial product or establish general security.

[Download the reproduction script](https://rethinkingagents.com/research/harness-operations-lab.py) · [Operations kit](https://rethinkingagents.com/resources/harness-operations-kit) · [Earlier filesystem lab](https://rethinkingagents.com/research/harness-effects-lab.md)

## What was executed

The Python standard-library driver has two modes. `--contracts-only` executes fixed receipt, adapter and retry inputs plus a concurrent local mock budget ledger. The default mode also creates two restricted Docker containers and checks their internal HTTP services, descendant processes, ownership decisions and removal. It writes JSON to stdout only after all assertions pass. Unexpected setup, observation or assertion failures exit nonzero; unavailable infrastructure is not a successful boundary test.

The receipt examples model evidence supplied by a trusted observer. They do **not** implement an observer or prove that a real harness captures its effects. The separate downloadable receipt record is a proposed review format, not an input file accepted by this script. The operations checks have their own IDs. The existing HB-01–24 evaluation specifications remain **NOT RUN**.

## Receipt and adapter results

All RC and AD cases below are synthetic contract fixtures. A fixture explicitly provides whether the legitimate task was verified, whether capture was complete, and whether an effect occurred; a worker's success string cannot override those fields. `reconcile` means inspect authoritative state before deciding what to do next. It never grants an automatic retry.

| ID | Fixture | Observed scheduler decision |
|---|---|---|
| RC-01 | Completed task, verified output and complete capture | advance |
| RC-02 | Verified legitimate read-only no-op, no effect | advance |
| RC-03 | Failure after partial effect | reconcile |
| RC-04 | Completion claim with unverified task result | reconcile |
| RC-05 | Missing receipt | reconcile |
| RC-06 | Blocked operation, confirmed no effect | stop_policy |
| RC-07 | Cancelled operation, confirmed no effect | stop_cancelled |
| RC-08 | Completed task with valid authorized retained-service lease | handoff |
| RC-09 | Blocked claim contradicts confirmed effect | reconcile |
| RC-10 | Capture incomplete despite completion claim | reconcile |
| RC-11 | Cancelled operation with unknown effect | reconcile |
| RC-12 | Retention approved after prior expiry | reconcile |
| RC-13 | Completed claim with only partial effect | reconcile |
| RC-14 | Malformed retained-service lease | reconcile |
| RC-15 | Task does not permit a no-op | reconcile |
| RC-16 | Lease generation differs from observed workload | reconcile |
| RC-17 | Lease belongs to another session owner | reconcile |
| RC-18 | Lease names another workload | reconcile |
| RC-19 | Approval time is in the future | reconcile |
| RC-20 | Lease already expired | reconcile |
| AD-01 | Two invented adapter shapes describe the same verified task | equal normalized inputs; advance |
| AD-02 | Unknown adapter, malformed nested shape, absent receipt, null/list payloads and list outcome | all six rejected with ValueError |

No-op completion requires explicit permission from the task contract. Retention compares the lease's owner, workload ID and generation against the fixture's independently supplied workload identity. Approval must already have occurred, precede the prior expiry and extend to a still-valid expiry. Those trusted inputs are modeled here; establishing them in a real scheduler remains an integration task.

The two adapters are named `fixture-a` and `fixture-b`. Neither maps to a vendor API. This demonstrates an explicit normalization point and rejection of unsupported shapes. It does not establish cross-provider compatibility, semantic equivalence of models or comprehensive JSON-schema validation.

## Retry results

These are deterministic response sequences, not calls to a language model. They test scheduler interpretation, not whether a model follows a refusal.

| ID | Fixture | Attempts | Observed decision |
|---|---|---|---|
| RT-01 | Terminal policy refusal | 1 | stop_policy |
| RT-02 | Repeated transient errors, each confirmed without effect | 3 | exhausted |
| RT-03 | Unknown outcome | 1 | reconcile |
| RT-04 | Transient label accompanied by confirmed effect | 1 | reconcile |

The retry budget is three total attempts. A transient classification alone does not authorize replay after an effect. No result here establishes that terse denials reduce adaptive model attacks.

## Budget results

The local ledger uses a thread lock and **artificial integer units**, not money, tokens, prices or estimates. Reservations are checked against settled spend plus all pending reservations. The fixture has no provider dispatch, durable storage, remote cancellation or real charging path.

| ID | Fixture | Observation |
|---|---|---|
| BU-01 | Eight concurrent requests reserve 3 units each against a 10-unit cap | Three admitted, five denied; 9 units reserved |
| BU-02 | Original request reserves 6; retry asks for 6 and fallback for 5 | Both new requests denied against the same cap |
| BU-03 | Original acknowledgement and cancellation outcome remain unknown | Original 6-unit reservation retained; duplicate attempt rejected |
| BU-04 | Reconcile original charge at 4 units, then admit a 6-unit request | 4 settled plus 6 reserved; repeated settlement rejected |
| BU-05 | Accounting unavailable, then an unpriced route, on an otherwise empty ledger | Both invalid admissions denied; dispatch counter zero; priced useful control subsequently admitted |
| BU-06 | Charge of 7 presented against a 6-unit declared bound | Contract violation raised; reservation retained |

BU-03 supplies unknown acknowledgement/cancellation states; it does not contact or cancel a remote job. BU-06 detects a broken upper-bound contract; it cannot prevent a provider from charging beyond its declared bound. Reserving an estimate is not proof of a hard cost cap. Deduplicating an operation's effect would not, by itself, deduplicate separate provider charges. This mock does not establish conformance of LiteLLM or any other existing gateway.

## Runtime and ownership results

Two synthetic sessions run in separate Docker containers. Each starts an internal HTTP service on `127.0.0.1:3187` and a detached sleeping child. The service returns a run ID, session ID, generation and synthetic build marker. The driver queries it with `docker exec`; there are **no published host ports**, repository mounts or host data mounts.

Both containers use the same immutable local image ID, unprivileged UID 65534, read-only root filesystem, a 1 MiB temporary filesystem, no network attachment, no added capabilities, `no-new-privileges`, and CPU/memory/PID limits. An in-container 90-second alarm bounds the service lifetime; `--rm` requests automatic removal on exit. The driver registers the exact container IDs returned by its own creation calls and checks a per-run label before removal. If the create acknowledgement is lost, it can recover only containers carrying this invocation's random run label, then check each recovered immutable ID and label again before cleanup. It never selects cleanup targets by port, process name or a shared container name.

| ID | Check | Actual versus simulated | Observation |
|---|---|---|---|
| LC-01 | Distinct service identity | Actual internal HTTP responses from two containers | Both returned their expected session/generation/build marker |
| LC-02 | Occupied service port | Actual second socket bind inside session A | `EADDRINUSE`; both original listeners still answered |
| LC-03 | Detached descendant | Actual `/proc` command line and OS session ID inside A | Sleeping child alive in a separate OS session within A |
| LC-04 | Stale generation requests cleanup | Controller equality check against A's actual endpoint marker | Stale generation rejected; container left running |
| LC-05 | Retained-service authorization | Simulated clock and lease, actual live container | Pre-expiry authorization accepted; late approval rejected |
| LC-06 | Missing cleanup acknowledgement | Simulated unavailable acknowledgement, actual live container | Cleanup remains UNKNOWN |
| LC-07 | Remove A while preserving B | Actual label-checked Docker removal and independent query to B | A absent from successful inventory; B still returned its marker |
| LC-08 | Remove B and verify final state | Actual Docker removal and successful inventory | Neither owned container remained |

LC-04–06 are controller examples around real workloads, not a production lease manager or reproduced Docker failure. The fixture deliberately supplies a lost acknowledgement; it does not induce a daemon outage. A port conflict does not authorize listener termination. LC-07 demonstrates cleanup scoped to an immutable container ID; it does not test a hostile tenant, forged marker or generation race in an external supervisor.

The original services are the useful-work controls: both answer after the port collision, and B answers after A is removed. This is a bounded service-availability check, not representative completion of a software engineering task.

## Reproduction and recorded environment

Executed with Python 3.12.6 on Linux kernel `6.8.0-142-generic`. The code uses Python 3.10-compatible standard-library features. The executed image was:

- Image ID: `sha256:25c5b8011a3425a140bf5fa73be0feabd3c0d5b323eecb19dc02437a368ae075`.
- Registry digest: `python@sha256:57cd7c3a7a273101a6485ba99423ee568157882804b1124b4dd04266317710de`.

Save the script locally as `harness-operations-lab.py`. Without Docker:

```sh
python3 harness-operations-lab.py --contracts-only > /tmp/harness-contracts.json
```

Expected: exit 0, `mode: "contracts-only"`, `passed: 32`; every case has `result: "PASS"`.

With a working local Docker daemon and the specified image already present:

```sh
python3 harness-operations-lab.py --image python@sha256:57cd7c3a7a273101a6485ba99423ee568157882804b1124b4dd04266317710de > /tmp/harness-operations.json
```

Expected: exit 0, `mode: "full"`, `passed: 40`; LC-08 reports `remaining: 0`. The script never pulls images. Its default selector is the already-present `python:3.12-slim`; it resolves that selector to an immutable image ID before execution. Record the actual image ID when using another image. Runtime JSON is a local artifact and is not committed with this method.

## Limits and cleanup

The host kernel, Docker daemon and driver are trusted. These checks do not implement runtime event capture, prove receiver-side authorization, test secret redaction, contain arbitrary host-side MCP tools, or certify a sandbox. A service marker is useful correlation evidence here; an adversarial service could forge one. Production ownership should come from trusted workload identity and controller state.

There is no live port allocator, port handoff protocol, lease renewal service, authenticated cleanup API, durable budget ledger or provider adapter. Concurrency is within one process. A scheduler crash can lose this mock ledger; a distributed budget implementation needs additional guarantees. The receipt classifier handles these enumerated fixture contracts and is not a general-purpose validator for arbitrary untrusted payloads.

Normal and exceptional paths attempt removal of only the run's own container IDs and verify absence through a successful Docker inventory. A failed run-label inventory does not suppress attempts to clean up already recorded IDs; failures are collected while attempting every candidate. If the daemon becomes unavailable, cleanup cannot be verified and the script reports `Cleanup UNKNOWN` and fails; do not infer absence from an unsuccessful query. The in-container lifetime bound and automatic removal limit the workload, but an infrastructure failure may require later inspection of this run's IDs/labels. Lost creation acknowledgements and unavailable-daemon recovery are defensive code paths, not experimentally injected failures in this run. No unrelated workload cleanup is authorized.

The 40 passing checks establish this implementation's narrow contracts and the reported Linux Docker behavior. They do not establish customer demand, incident prevalence, model behavior, commercial product failures or suitability for production deployment.