DRAFT Date: 2026-10-10 Author: Reuben Bowlby •

Subagent Output Contract: Receipt Discipline for Agent Dispatch

This is an unreleased working revision. Any DOI and earlier PDF shown here identify a previous snapshot and do not certify this revision or imply peer review.

Download working source

Subagent Output Contract: Receipt Discipline for Agent Dispatch

Status: DRAFT — evidence and measurement revision, 2026-10-10

Date seeded: 2026-08-21

Author: Reuben Bowlby (ORCID 0009-0002-5620-1103)

Repository: hummbl-io/hummbl-papers

Study type: Retrospective incident analysis and proposed evaluation

This living Markdown revision corrects the interpretation of the incident. The existing PDF and deposit metadata are historical artifacts and have not been regenerated or republished with this revision.

Abstract

File-producing subagents need a shared specification of where outputs belong and how completion claims will be checked. We propose six prompt sections: output path, naming convention, sibling context, verification step, claim discipline, and return format. The proposal is motivated by a first-party report of three document-producing dispatches whose outputs occupied two directories and used two naming conventions. A reported 979-line completion claim was compared with a PowerShell result of 535, but the incident report also lists a heading at line 869. This inconsistency prevents treating the difference as a verified 83% overcount. A synthetic counterexample confirms that line-counting procedures can disagree when empty lines are handled differently. The resulting contribution is a measurement-aware output contract: receipts should bind a metric definition and measurement procedure to the same artifact snapshot, and a parent should verify that snapshot independently. We provide a portable measurement artifact and a controlled evaluation plan. The case does not establish that the contract reduces error rates, that the subagent fabricated a count, or that a receipt guarantees substantive correctness.

1. Research question and contribution

The question is what must a file-producing dispatch specify so that its output can be located, measured, and reviewed consistently? Task content, output placement, and evidence of completion are separate requirements. A detailed content prompt may leave the other two underspecified.

We examine three possible coordination problems: output locations that differ from the parent's intended directory, inconsistent file names within a series, and numerical claims whose definitions or evidence cannot be reconciled. The contribution is a concrete six-section contract and a verification protocol with explicit artifact identity. Its effectiveness remains a hypothesis. We do not claim to introduce verification, prove that six sections are necessary or sufficient, or establish a gap across all dispatch frameworks.

2. Materials and evidential scope

The motivating source is a HUMMBL incident report dated 2026-08-21, docs/research/2026-08-21_subagent-output-contract.md, originally attributed to the apex-nexus workspace. During the 2026-10-10 audit, an author-accessible copy was found in a local agents checkout. Its SHA-256 is 2ae378b8be91455e1ab3eebf76b01574e6a25ed540acde4c539dd27395755cb9.

That local copy is untracked in the inspected checkout; a historical log entry is not sufficient to pin the current bytes to a commit. This paper therefore cites the inspected document hash and distinguishes its account from independently observed events. The original three prompts, complete return messages, exact incident-time file snapshots, and measurement environment are not bundled here. The report's excerpts support a documentary analysis, not an independently reconstructed dispatch trace. A path or ledger identifier is not evidence that an artifact is publicly accessible.

The paper also reads the MAST and NabaOS primary sources and uses a small, explicitly synthetic counting example. No new model dispatches, treatment comparisons, or corpus-wide performance measurements were performed.

3. Incident reconstruction and correction

3.1 Output placement

The report describes three dispatches for ARCANA Academy faculty documents. Each received substantive content instructions but, according to the report, no explicit output contract. We replace personal machine paths below with stable role labels; this retains directory membership without implying that those paths are reusable replication instructions.

The table identifies two distinct directories, not three. None is the parent's intended faculty directory. It also identifies two naming styles: one hyphenated name and two underscored names. The latter is a distribution of styles, not a 67% compliance score, because no predeclared convention is available for scoring. A mismatch with an unstated parent preference demonstrates coordination ambiguity; it does not by itself demonstrate violation of an explicit instruction.

3.2 The disputed line count

The source reports a return claim of 979 lines and the following measurement:

(Get-Content <path> | Measure-Object -Line).Lines = 535

The arithmetic difference is 444; dividing by 535 gives approximately 83.0%. However, calling that an agent overcount assumes both values count the same thing in the same file version. The report itself lists Select-String heading positions up to line 869, which is incompatible with 535 total physical lines if the file snapshot and definition are the same. The source does not resolve this contradiction.

In a synthetic check on PowerShell 7.6.6 during this audit, the following returned two lines:

@('a', '', 'b') | Measure-Object -Line

There are three input strings, one empty. This supplies a concrete alternative explanation for differing counts. Microsoft documents that text measures count within input strings as well as across them, and that Get-Content without -Raw emits an array of lines. It should not be assumed that every use of a tool named "line count" implements the same measurement. Microsoft, Measure-Object.

This check does not show that blank-line handling caused the historical discrepancy, that 979 was correct, or that the historical PowerShell version behaved identically. Other explanations include file revisions, transcription mistakes, or an inaccurate agent estimate. Without the original bytes and commands, the overcount and its cause remain unresolved. The earlier manuscript's assertion of a verified 83% overcount is withdrawn.

3.3 Section count and content quality

The report lists 18 second-level headings: numbered sections 0 through 16 (17 headings) plus Emergent Gaps. The return phrase "16 sections + Emergent Gaps" is ambiguous: it could exclude the prologue numbered zero, but it is not an exact count of all 18 headings. A verification receipt should state the counting convention and list the headings.

The source author's positive assessment of the documents is not a blinded content-quality evaluation. Neither byte count, heading count, nor successful placement establishes factual accuracy or pedagogical quality. We retain the reported file sizes as documentary observations without converting them into a quality score.

4. The proposed output contract

The contract is a design proposal for file-producing tasks. The parent resolves any template variables before dispatch, confirms the write scope is authorized, and supplies six sections:

An absolute path is useful within one host; a repository-relative path plus a resolved worktree root can express the same intent more portably. In either case, the parent and child must agree on the resolved destination. Mentioning a path in a prompt does not grant filesystem permission, prevent symlink traversal, or enforce isolation. Concurrent writers require explicit ownership or isolated outputs so that verification is not racing another edit.

4.1 Contract, receipt, and acceptance

These are three distinct objects:

1. Contract: the intended output and criteria specified before execution.
2. Receipt: an execution and measurement record bound to a particular artifact snapshot.
3. Acceptance: a parent decision based on independent checks and the substantive task requirements.

A contract is not itself evidence that the work happened. A child-produced hash is not authentication of the child or proof of correctness. Raw command output pasted into a return can also be inaccurate or copied from another run; the parent should remeasure the actual artifact, compare digests, and inspect failed or missing checks.

4.2 Minimal parent verification

The parent resolves the returned path against the authorized workspace; checks that the expected output exists; measures the same byte snapshot using the declared procedure; compares the digest and numerical claims; and records discrepancies separately from the final disposition. If the file changed after the child's receipt, classify it as a snapshot mismatch before interpreting a count difference. Do not silently replace an incorrect child claim with a new count and call the original verified.

The measurement protocol and measure_file.py provide a deliberately narrow, local research artifact for UTF-8 Markdown. It reports byte count, newline count, logical line count, nonempty and nonblank counts, lexical ## headings, and a SHA-256 digest from one byte buffer. These measurements support comparison; they do not validate document semantics or implement a secure agent runtime.

5. Relationship to prior work

5.1 MAST as an analytical frame

Cemri et al. report a taxonomy with 14 failure modes in three broad categories, developed through analysis of 150 traces and accompanied by a dataset of more than 1,600 annotated traces. The reported inter-annotator agreement pertains to that study, not this incident. MAST, arXiv v3.

As an author interpretation, placement ambiguity resembles the system-design category, while a numerical claim with an unresolved measurement definition resembles the task-verification category. We have not applied the complete MAST annotation procedure, obtained independent annotator agreement, or established a specific failure label for the historical subagent. A taxonomy can organize hypotheses; it does not validate this intervention or supply a causal diagnosis.

5.2 Tool receipts and authenticated execution records

Basu's NabaOS proposal classifies claims by evidence source and uses HMAC-authenticated tool receipts. Its reported 94.2% fabricated-tool-reference detection and sub-15 ms verification overhead come from the author's NyayaVerifyBench evaluation of 1,800 scenarios with injected hallucinations. They are not estimates of this prompt contract's performance or total end-to-end runtime. Basu, arXiv v1.

Authenticated records and explicit contracts address related but different problems. Under a trusted tool/issuer and protected-key assumption, receipt authentication can help detect record modification or unauthorized construction. It does not establish that a tool measured the intended quantity, that the correct file version was read, or that an artifact is substantively correct. The counting ambiguity in this case would remain possible even if a receipt's bytes were authenticated.

Our prompt-level proposal has token, tool, latency, and review costs that have not been measured. It has no runtime enforcement and cannot inherit NabaOS's detection rates. Systems with a trusted tool boundary may combine the two approaches, provided their trust assumptions and verification coverage are stated.

5.3 The scope of the specification gap

The incident report examined a small set of internal dispatch rules and skills whose "self-contained" language emphasized task context. This is evidence of a local documentation concern as described by the author. It is not a systematic literature review and does not support the claim that all dispatch literature omits output requirements. Earlier novelty claims using "never" are withdrawn.

6. Prospective evaluation

No controlled evaluation has been run. A future study should distinguish prompt specification from parent verification with a factorial design: ordinary task prompt versus six-section contract, crossed with ordinary completion handling versus independent parent verification. All conditions receive the same substantive task and tool permissions. Outputs are scored by an independent evaluator using an archived rubric; absence of a required output counts as a failure, not an excluded observation.

Use multiple task templates, sessions, and model/runtime versions; randomize within task blocks and isolate workspaces. Run order and retries must be fixed or recorded, and use session/task clustering when estimating uncertainty. A six-dispatch demonstration can test feasibility but cannot establish general reliability. Select a sample size using a declared minimum meaningful error-rate reduction or interval-width target, informed by a separate pilot.

Report claim coverage as well as discrepancy rate: a system that stops making numerical claims must not appear perfectly accurate simply because the denominator vanished. Predeclare a primary endpoint, distinguish secondary/exploratory analyses, retain raw traces under an explicit access policy, and report confidence intervals and failure examples. Test whether added contract language displaces useful task context or creates compliance without substantive success.

7. Limitations and availability

This is a single-operator report of one session, selected after an incident. It has no intervention comparison, complete raw prompts, model/version record, or incident-time file snapshots. The parent preference may have been unstated; the alleged line-count error may partly reflect measurement mismatch. The case cannot estimate prevalence, attribute intent, demonstrate that a prompt section prevents a failure, or guarantee reproduction on any other system.

The synthetic measurement checks are reproducible examples of metric semantics, not replications of the three dispatches. The internal incident and rule identifiers are provenance locators, not public datasets. A public incident package would need reviewed prompts, returns, immutable files or permitted minimal extracts, measurement commands/versions, redaction documentation, and access/licensing terms. Until then, external users can evaluate the proposed protocol but cannot independently reproduce the historical incident.

References and local artifacts

• Cemri, M. et al. (2025). Why Do Multi-Agent LLM Systems Fail?. arXiv v3.
• Basu, A. (2026). Tool Receipts, Not Zero-Knowledge Proofs: Practical Hallucination Detection for AI Agents. arXiv v1; reported evaluation not independently replicated here.
• Microsoft. Measure-Object documentation. Accessed 2026-10-10.
• HUMMBL internal incident report (2026-08-21), inspected local-copy SHA-256 given in §2; original artifact package not bundled.
• Measurement protocol, measurement script, synthetic checks, and research notebook.