Harness² report verification

Type: agentic-system-analyses/types/agentic-system-verification.md

Verification

The current pinned reports support a bounded implementation account. The earlier WorkBuddy withholding blocker is repaired, and the earlier trial-ranking inventory limit is now covered by the records. I read the complete invocation, governing contracts, supplied reports, correction answers, structural check and previous verification. The structural check reports no failures. I independently checked the checkout HEAD and tracked root tree against the Source register, then inspected the consequential source paths below. All source inspection concerns SRC-1 at the frozen revision. No target code, tests, examples, model services or external evidence were executed or acquired. The previous judgment and analyst answer were assessed as arguments, not proof of repair.

Runtime and workflow

Independent reads of SRC-1 harness2/cli/run_sweep.py, harness2/core/schedule.py and harness2/core/recursion.py support RT-RTE-task-recursion: code owns task order and phase progression, parallel proposals finish before their rollouts and compositions, and sequential rounds reconstruct history around the current harness. All sequential composition checkpoints are eligible finals. The 4k accounting describes scheduled rollouts rather than total model calls, successful executions or empirical improvement.

I checked rejection and fallback branches in _run_stage and _accept_tree, together with surface reading/writing and validation in SRC-1 harness2/core/tree.py. RT-RTE-edit-admission correctly distinguishes successful new-tree admission from inherited fallback and weaker direct materialization APIs. Context-build failure and exhausted invalid attempts can return the fallback; a final position need not contain a changed harness. Shape, compilation and adapter checks establish neither semantic correctness nor benign execution. The separate theory-builder, learning, reflection and autonomy assessments do not infer exercised criticism or improved capacity from retained files.

For RT-RTE-output-selection, I traced selection_pool, _render_pool, run_selection, _fallback, trivial_selection and _persist in SRC-1 harness2/core/selection.py, then their scheduler consumers. Finals-only construction is enforced in the shipped scheduler; lower-level mixed pools do not contradict that scoped guarantee. State-deliverable trajectory fallback, k=1 delivery without comparative selection, and a fallback label without successful selection are preserved. Reflection requires selection success and a library. These checks support the workflow account and its three annotations: code owns fan-in, rejection recovery and delivery, rather than an autonomous supervisor model. Workflow declares no independent records or supersessions.

I inspected substrate materialization and component advertisement in SRC-1 harness2/substrate/opencode.py and harness2/substrate/codex.py, WorkBuddy component/plugin installation in third_party/wb_runner/agents/oc_harness_agent.py, and LAB adapter validation in harness2/benchmarks/lab.py. They support RT-RTE-solver-execution, RT-OBJ-harness-text, RT-OBJ-harness-code and RT-BAP-harness-consumption. Prose interpretation and executable extension dispatch have different force. Surface acceptance is not mediation of every possible tool or subprocess. The external-runtime and deployment limits remain beside those conclusions.

The four component records—RT-CMP-proposer, RT-CMP-selector, RT-CMP-solver and RT-CMP-judge—appropriately distinguish inference configuration and external weights from editable local harness organization. They do not establish exact weight identity, provider immutability or observed training behavior. Scheduler reuse predicates in SRC-1 harness2/core/schedule.py support RT-RTE-resume-reuse, including successful saved state, output availability, optional artifact checks, fingerprint checks and library reconstruction; these predicates are not semantic revalidation.

Correction and alternate-path checks

The runtime correction was checked through producer, branch and consumer, not merely its new quotation. SRC-1 harness2/benchmarks/workbuddy.py validates supported subsets and selects names-only evidence only for code. Web and office select contents; office supplies raw assets. SRC-1 harness2/core/context.py uses that spec in both _write_rollout and _write_pool: names-only avoids artifact bodies, images and raw assets on those branches, whereas contents can supply renderings and, on the per-file branch, assets. reflect_adoption invokes the same builder. Selection independently renders candidate outputs. The current runtime forcing-route account and RT-CLM-answer-free preserve these conditions. The previous blocker is therefore dismissed as repaired; there is no remaining universal WorkBuddy withholding claim.

I also retraced WorkBuddy _rank, _trial_graded, _launch, execute and execute_many, including the stable grade-first helper in SRC-1 harness2/core/selection.py. Fresh and batched reused trials prefer parseable grade availability, retaining recency within groups; single-rollout reuse selects the newest reusable trial. This does not rank by higher score. The updated execution and reuse records now include this predicate, and reconciliation connects it to the separate post-hoc measurement account without inventing an adaptation answer oracle. The previous inventory limit no longer applies.

For the broader answer-free claim, I independently inspected path exclusions and suffix-limited marker checks in SRC-1 harness2/core/context.py, plus copied-session, inherited-environment and permission branches in harness2/core/proposer.py. These support the report's bounded tripwire/policy interpretation, not universal contamination isolation. JobBench's reachable raw extraction fallback in SRC-1 harness2/benchmarks/jobbench.py also defeats identical-rendering generalizations; the current report retains that qualification. No unchecked branch is treated as a demonstrated exploit, and no type or prompt instruction is treated as a universal enforcement guarantee.

Memory and epistemic records

Independent reads of SRC-1 harness2/core/library.py, harness2/core/context.py, harness2/core/proposer.py and scheduler restoration support all five memory object declarations: MEM-OBJ-experience, MEM-OBJ-library-index, MEM-OBJ-evidence-tree, MEM-OBJ-cached-response and MEM-OBJ-call-fingerprint. Content, navigation and cache metadata remain distinct. The call key hashes mission/system/evidence identity and bytes, not model name itself; namespace checks are a separate layer.

MEM-RTE-evidence-frame and MEM-RTE-library-withdrawal correctly distinguish automatic full-library supply from model-directed browsing, temporary cleanup from surviving audit/evidence copies, and prefix deletion from reconstruction or global revocation. OpenCode rendering in SRC-1 harness2/substrate/opencode.py confirms per-item clipping, schema selection and whole-prefix caps. The report does not claim a complete Codex event inventory or exact external model-window reconstruction. The memory annotations preserve runtime referents and separate read availability from actual rationale use or direct solver installation.

SRC-1 third_party/wb_runner/agents/oc_agent.py supports MEM-CLM-compaction-boundary: configuration of a declared context limit is not an inspected native compactor. SRC-1 harness2/demo.py supports MEM-CLM-demo-experience, including scripted authorship rather than ordinary model reflection. These are scoped positive findings, not negatives about inaccessible external machinery.

I checked the epistemic objects and each ledger function against the relevant producer and consumer. EPI-OBJ-execution-evidence and EPI-OBJ-experience remain attributed payloads, not independently warranted knowledge. SRC-1 harness2/core/selection.py confirms EPI-RTE-lesson-parse: unkeyed continuation lines disappear, repeated keys overwrite, and nonempty required fields gate admission. The concrete continuation example is a valid implementation deduction, not an observed response. Library formatting does not restore discarded qualifiers. Both Part of: relations—the payload and parser within RT-RTE-experience-admission—are substantively valid despite their different record kinds.

The experience route and its memory annotation accurately trace execution evidence through reflection, parsing, field/marker admission, tree/experience persistence and later improver access. SRC-1 harness2/core/prompts.py requests component contrasts, confounding caution and abstention. These requests do not prove model compliance, content-directed criticism or evidence-consuming acceptance of lesson truth. The ledger keeps checking, disposition, retention and advisory consumption separate; the absence of generated content justifies leaving the truth-apt transformation indeterminate.

I independently traced EPI-OBJ-score-rows, EPI-RTE-judge-result, EPI-RTE-score-cache and EPI-RTE-score-report through SRC-1 harness2/core/judge.py, harness2/cli/judge.py, harness2/core/report.py and adapter scoring branches. The records preserve heterogeneous units, benchmark-specific missing-output handling, same-run graded-cache retention after failed re-judging, and graded-only denominators. Arithmetic licenses only conclusions over the imported rows, not evaluator correctness or a population result. SRC-1 harness2/demo.py supports EPI-OBJ-demo-ledger and EPI-RTE-demo-check: signed Decimal arithmetic, substring matching, k=1 bypass and scripted reflection do not establish whole-answer correctness or model learning.

The source claims in EPI-CLM-evidence-lessons and EPI-CLM-benchmark-gains remain doctrine/design and reported operation respectively. No observed-run or causal evidence upgrades them. Across all declarations I checked source-anchor relevance, evidence strength, conclusion-status meaning and applicable route fields. No evidenced-absence records are declared. Supported architectural paths coexist with unobserved activation, benefit, transfer and exercised self-improvement.

Reconciliation and omission-search disposition

The current reconciliation makes no supersession. Its distinctions between persisted experience document and cross-stage payload, filesystem evidence container and consumer projections, response content and lookup metadata, and demo claim/object/route are supported. The parser is a valid subroute, not a reason to supersede its valid parent container. Memory's integration issues are disposed as compatible qualifications: rendering budgets, demo authorship/oracle scope, opaque native memory, withdrawal lifetimes and unobserved rationale use. The updated WorkBuddy connections preserve both subset conditions and upstream grade-availability selection. No unresolved cross-report disagreement or missing required part needing an Unresolved conflict: paragraph was identified.

Omission questions were selected from the frozen tree, installed dispatch and producer/consumer dependencies: whether alternate shipped modes invalidate model-only or oracle-free generalizations; whether acquired data bypasses copied-context controls; whether supported adapter subsets invalidate withholding; and whether grade-related upstream selection changes the measurement account. Demo, proposer permission/environment branches, context/adapter projections and trial ranking give supported bounded dispositions for these questions. Further optional expansion stopped because no identified material challenge remains undisposed, and the central admission, retention, read-back and delivery conclusions do not assert an exhaustive inventory of external tool loops or every operational cache. External native compaction, private delegated conversations and grading correctness remain explicitly unestablished rather than evidenced absent. Those faithfully scoped uncertainties need no additional publication limit.

Blockers

none

Limits

none