# Operational autonomy: verified-progress and source-isolation audit

**Publication date:** 29 October 2026  
**Evidence class:** Privacy-minimized operational reliability audit  
**Scope:** 669 recorded autonomy-cycle outcomes, cycle IDs 1–669

## Decision

**HOLD production promotion.** The operational loop has not produced a verified completion in the inspected records, and the current source-sync/worktree path is not usable under the restricted service identity. This is an infrastructure and evidence-quality finding, not evidence that the model itself became more or less intelligent.

The systemd service was active at the time of the audit, but the last recorded state was still at 05:29:49 UTC on 29 October 2026. No production code, graph, model weights, or service configuration were changed by this audit.

## Recorded outcomes

| Measure | Count |
|---|---:|
| Cycle records inspected | 669 |
| Verified completion evidence bundles | 0 |
| Explicit progress=true | 0 |
| Worker exit code zero without the complete evidence bundle | 401 |
| Verification list present | 74 |
| Verification list missing or empty | 595 |
| Before/after repository HEAD equal | 664 |
| Missing HEAD evidence | 5 |

A zero process exit code is not proof of completed work. In these records, every zero-exit cycle lacked the full independent completion evidence bundle used by this audit.

### Recorded terminal statuses

| Status category | Count |
|---|---:|
| No verified progress | 327 |
| Free-provider execution failed | 139 |
| Local-model execution failed | 124 |
| Workspace changed during/after verification | 72 |
| Local model unavailable | 5 |
| Verification failed | 2 |

The 72 post-verification mutation blocks included successful cleanup records and unchanged repository HEADs. Historical ignored-path data was dominated by generated installation/build artifacts. The verifier's cleanup command is at the end of the configured command list, while the command runner stops on the first failing check. Therefore cleanup can be skipped when an earlier check fails, after which the safety gate sees the generated artifacts and blocks the candidate. The safety gate should remain; cleanup ordering is the likely repair target.

## Source isolation findings

The audit identified three independent obstacles to reliable unattended operation:

1. The automation checkout was on a feature branch while its launcher requires the main branch.
2. The isolated service identity could read the shared checkout but could not write the repository metadata needed for fetch/worktree operations. Historical service logs also recorded permission-denied failures creating a cycle worktree.
3. Read-only authentication probes to the configured upstreams were unsuccessful. No credentials were printed, changed, or copied.

These findings explain why simply restarting the service or making the verification gate less strict would be the wrong fix. The recovery must separate the low-privilege worker from human-owned repository metadata and establish a narrowly scoped source credential first.

## Chronological hold-out

The final 20% of the recorded cycles were evaluated as a chronological hold-out without fitting any model.

- Held-out cycles: 134
- Worker exit code zero: 102
- Verified completions: 0
- Cycles without an explicit progress flag: 134

The hold-out reproduces the completion-evidence gap. With no verified-positive operational examples, true-positive recall cannot be estimated and a real-world gain from a context-aware procedural graph cannot be demonstrated.

## Recommended recovery sequence

1. Restore narrowly scoped, read-only access for the isolated service identity to the self-hosted source of truth.
2. Use a service-owned source clone/cache, rather than broadening write permissions on a human-owned repository's .git directory.
3. Verify fetch plus temporary worktree create/remove using the exact service identity.
4. Move verification-artifact cleanup into an unconditional cleanup path. Preserve all content-fingerprint, verification, ignored-artifact, and rollback gates.
5. Re-run a bounded pilot and require independently adjudicated positive and negative operational examples before considering promotion.

## Promotion gate

Production promotion remains on hold until there are at least 30 independently adjudicated positive and 30 negative held-out examples across at least three operational contexts; zero unsupported success claims; at least a five-percentage-point absolute improvement over a preregistered baseline; no context regression greater than one percentage point; and passing privacy, verifier-integrity, and rollback checks.

## Privacy and limitations

Only aggregate counts and high-level findings are public. Raw traces, prompts, messages, filesystem paths, request IDs, command output, diffs, and credentials are not published.

This is a rule-based audit of structured cycle records, not a model-learning result. Its evidence gate corroborates the runner's own records but is not fully independent ground truth. No verified-positive operational outcome was found, so sensitivity and real-world decision improvement remain unmeasured.

## Cycle 670 addendum — 29 October 2026

The original audit above covers cycles 1–669. The next recorded cycle is now available and does not change the decision to hold promotion:

- Completed cycles: 670.
- Last cycle status: `NO_VERIFIED_PROGRESS`; the configured local model was reported ready, returned process code zero, and proposed no file changes.
- Consecutive no-progress streak: 670.
- Repository HEAD before and after the cycle remained `475634ed1ac5daf3d41280c2ac3904ec6bff890f`; the recorded working tree was clean.
- No verification checks ran because there was no candidate change. The cycle therefore does not count as a verified completion.

This new record supports the operational finding that the loop is repeatedly abstaining despite its model health check passing. It does not prove whether model capability, prompt/context selection, or task difficulty is the unique cause. The next experiment should isolate one narrow change with a regression test and require a complete independent evidence bundle. No production deployment, source push, or model-weight update is claimed by this addendum.