Coordination Bus as Governed Agent Infrastructure
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.
Coordination Bus as Governed Agent Infrastructure
Status: SCOPED — systems design and evaluation protocol, revised 2026-10-10
Date seeded: 2026-07-06
Author: Reuben Bowlby
Repository: hummbl-io/hummbl-papers
Abstract
An agent coordination bus can preserve work assignments, blockers, review claims, and decisions, but recording a message must not be confused with authorizing an action. This paper specifies a bus as evidence infrastructure, with execution controlled by a separate authorization boundary. We analyze two historical HUMMBL design documents, distinguish their proposed formats from deployment evidence, and identify the additional semantics needed for reliable queue reconstruction: stable work identifiers, ordered event admission, correction links, artifact revisions, and separate activity and progress clocks. An executable offline synthetic example illustrates stale evidence, contradictory claims, and blocker recovery without exposing operational records. We propose a controlled reviewer study and operational measurements with explicit denominators and censoring rules. No operational incident dataset or empirical throughput result is presented. The contribution is an inspectable design and a falsifiable evaluation plan, not a demonstrated improvement in reliability or a new append-only logging mechanism.
1. Problem and research questions
Engineering work can be distributed across agent messages, pull requests, checks, and local artifacts. A reviewer must reconstruct what work is being discussed, which version was checked, what remains blocked, and who had authority to act. A shared log can preserve this evidence, but a typed message that says "ready" or "approved" is still a claim whose scope and source need interpretation.
We ask two questions:
- Can structured, version-linked bus records improve the accuracy and speed of reconstructing a work item's state compared with an equal-information, unstructured record?
- Which interfaces keep coordination messages from bypassing independently enforced action permissions?
The first is an empirical question left open here. The second is a systems-design question: a message must be treated as an input to a decision process, while permission to execute comes from a separately enforced policy or capability boundary. Better record keeping alone cannot enforce that boundary.
2. Materials and method
This is a document analysis and design proposal. Four repository artifacts were inspected at source baseline 0b6cd1fa9865605499d0ad11bf96adaf1f26ed68. Two define historical bus designs; two are first-party background reports. They are not independent replications or measurements of the current runtime.
| Artifact | Evidential role | Boundary |
|---|---|---|
| HUMMBL Bus Protocol Specification v1.0 | Draft dated 2026-03-24; describes JSONL envelopes, event IDs, parent links, hash chaining, and message types | Proposed design, not proof that these controls were deployed |
| CAES Specification v1.0.0 | Historical five-column TSV contract, UTC timestamps, append-only convention, and receipts-first rule | Historical location and policy references are not current operating instructions |
| Multi-Agent Coordination report | First-party rationale for coordination patterns | Background synthesis; its external performance claims are not adopted as this paper's evidence |
| Capability Security report | First-party discussion of authorization boundaries | Design motivation; its prevalence estimates are not treated as independently verified results |
The JSONL and TSV specifications describe different interfaces. We do not combine them into a claim that one deployed system possesses all their properties. The historical founder-mode file path is a source-document detail, not a canonical live bus or a write target. This paper does not inspect live operational queues, authenticate current agent identities, or benchmark the bus implementation.
The analytical method is to extract common intentions, identify where those intentions require stronger mechanisms, define a minimal research contract, and specify tests that could refute its expected benefits. A case-study template remains unfilled. The replay fixture is entirely synthetic; it contains no redacted or collected operational messages.
3. Relationship to prior work
Event sourcing records changes so that application state can be reconstructed from an event history. The present proposal uses that familiar idea for coordination evidence; deterministic reconstruction additionally requires a defined projection and its dependencies. It does not imply that external side effects can safely be executed again during replay. Fowler, Event Sourcing.
Certificate Transparency separates logging from the actions observers take when they detect a problem, and specifies inclusion and consistency mechanisms for auditing logs. That is a useful architectural comparison, not evidence that a plain coordination file has those security properties. RFC 9162. We claim no novelty for shared logs, typed events, or separation of authorization from communication. The proposed contribution is their explicit combination with revision-bound engineering receipts and testable queue-reconstruction outcomes.
4. Evidence and authority boundaries
Consider four components: an authenticated admission service, durable event storage, a projection/read interface, and an action gate. An agent submits an event; the admission service validates the envelope and records the authenticated principal separately from any claimed author in the payload. A projection derives a reviewable coordination state. An executor independently checks current action permission before using tools or changing an external system.
The components can share a host without sharing authority. The key property is that the ability to submit or read a bus message does not, by itself, confer the ability to perform the action described by that message. An executor checks the authenticated requester, operation, resource, scope, expiry or revocation, and relevant budget or approval constraints. These checks are proposed requirements; the paper does not certify any particular implementation.
| Threat or failure | Why a log alone is insufficient | Required design or test |
|---|---|---|
| Forged sender field | A canonical string is not authentication | Bind admitted principal to credentials; preserve relayer/original-author distinctions |
| Stale approval or test result | An earlier success may refer to a different revision | Bind receipts and permission decisions to immutable artifact/version identifiers |
| Malicious message instructions | Message bodies can contain attempts to redirect readers | Treat content as untrusted data; enforce action permission outside model interpretation |
| Replayed or duplicated message | Retries can create duplicate apparent work or action requests | Stable event IDs, idempotent admission/projection, and executor-side replay handling |
| Log rewriting, truncation, or split view | An append-only convention or locally recomputable hash chain does not prevent a privileged rewrite | Define storage/access controls and, if required, externally held checkpoints or witnesses |
| Omitted work or false observation | Integrity of recorded bytes says nothing about unrecorded events or their truth | Compare against independent work/execution ledgers and inspect supporting artifacts |
| Log flood or service outage | Durable evidence can still become inaccessible or too costly to review | Admission limits, bounded queries, backpressure, recovery tests and availability measurements |
The security objective is bounded: prevent bus content from bypassing the action gate under the stated trust assumptions. If the executor already has broad ambient credentials and can ignore the gate, the architecture does not establish containment. Typed records and human instructions are insufficient to prove enforcement.
5. Minimal research contract
This contract is a proposed normalized representation for analysis, not a replacement for an operational protocol.
| Field | Meaning |
|---|---|
schema_version, event_id | Interpretation version and stable identity for deduplication |
recorded_sequence, recorded_at_utc | Admission order and receipt time assigned by the logging boundary |
occurred_at_utc | Producer-reported event time; retained separately because clocks and delivery can differ |
principal, claimed_author, relayed_by | Authenticated submitter and separately recorded provenance where available |
work_id, lane_id | Stable work item and coordination context |
type, payload | A versioned event class and its data; unknown classes remain visible but do not silently alter state |
artifact_revision, evidence_refs | The exact version and supporting artifact/check identifiers for claims about results |
causes, supersedes | Links to prior events for causal context and explicit corrections |
Timestamp ordering alone is inadequate under clock skew or delayed delivery. A durable single-log admission order supports one reproducible projection but is not a claim to a total causal order across all external services. A multiwriter/distributed implementation must specify serialization, conflict handling, and failure recovery rather than assuming append operations are atomic.
Corrections append a new event that names what is superseded. History stays inspectable, and the projection exposes both the original claim and its correction. Redaction for a public research extract is a separate, documented transformation; it must not be described as editing the original operational history.
5.1 Queue projection
For analysis, use states such as proposed, active, blocked, awaiting review, complete, and cancelled. These are work states, not permissions. Each transition must identify its supporting event and the version of the projection rule. Define an observation cutoff so a reader cannot accidentally use future events to answer an earlier question.
Keep three times separate:
- Last message: most recent admitted event, including heartbeats or repeated blockers.
- Last evidenced progress: most recent event that satisfies a declared progress criterion, such as a new artifact revision or completed check.
- Blocked since: start of the current unresolved blocker episode, retained until resolution.
A repeated BLOCKED or heartbeat message must not reset the progress clock by default. A blocker can be cancelled without successful recovery; this is a distinct outcome. A "ready" claim with missing or stale evidence remains an unresolved claim. A successful CI receipt does not itself establish authorization to merge.
5.2 Synthetic replay example
The supplied fixture records a hypothetical revision r1, local success, CI failure, an unresolved blocker followed by a repeated blocker message, then a new revision r2, CI success, an agent's readiness claim, and a late-arriving receipt for r1. At the cutoff, the older receipt cannot certify r2, the repeated blocker was not progress, and no merge authorization is established by any message.
The fixture includes expected answers and rule identifiers. The offline checker now derives the answers from its events under explicit instrument rules; the authored answers are consulted only afterward as a comparison oracle. It uses a compact subset of fields and relative elapsed times, not a production envelope. Recorded sequence determines replay order. Exact duplicate event objects are collapsed by ID, conflicting duplicates and invalid admission order are rejected, and an observation cutoff prevents later outcomes from entering an earlier projection.
At the full cutoff, r2's reported CI result comes from e7, while e9 is a stale-on-arrival receipt for r1. The first blocker at minute 3 and its linked repair artifact at minute 10 give a constructed seven-minute interval; the repeated blocker at minute 8 does not reset its origin. At sequence cutoff 5 and minute cutoff 9, the episode instead has six elapsed minutes and is right-censored, with no observed recovery. The recorded full output retains input identity, rule version and evidence IDs. No check result is authenticated or rerun, and the explicit repair link does not prove the repair works. Permission is outside this projection.
The synthetic tests cover cutoffs, repeats, duplicate identity, delayed occurrence times, invalid recorded order, unrelated artifacts and deterministic output. They test the stated mechanism, not a deployed bus. Since the events and expected answers were authored together, correct replay is not evidence that real reviewers become faster or more accurate. Concurrent unrelated blockers, cancellations, correction events and distributed admission remain outside this small implementation.
6. Evaluation protocol
6.1 Reviewer reconstruction study
Build a versioned set of closed work-item histories with source artifacts and independently adjudicated answers. Use both straightforward cases and prespecified difficult cases: stale revision, delayed receipt, duplicate event, false success claim, missing artifact, repeated blocker, and explicit correction. Synthetic histories can test mechanisms; separately consented/released real histories are needed for claims about operational prevalence and benefit.
Compare an ordinary chronological record with a typed, linked bus view containing the same underlying information. Otherwise additional information, rather than structure, confounds the comparison. If the target is a bus plus extra instrumentation, label that as a different intervention. Assign matched cases across conditions using randomized, counterbalanced blocks; avoid showing a reviewer the same case twice. Account for reviewer and case clustering, and record prior familiarity.
Predeclare reconstruction accuracy as a candidate primary endpoint, with time and cost as secondary endpoints. Fix a timeout and mark timed-out answers explicitly. Report all assigned trials, uncertainty, exclusions, and disagreements between adjudicators. A shorter time alone is not a benefit if wrong answers increase. Choose sample size from a separate pilot or a precision/power rationale before the main study; no sample size or effect estimate is claimed here.
6.2 Operational definitions
| Outcome | Definition | Missingness and denominator |
|---|---|---|
| Reconstruction accuracy | Correct answers to prespecified work-state and evidence questions at cutoff | All assigned questions; missing/timed-out answers reported as such |
| Reconstruction time | Elapsed time from case reveal to final answer | All assigned trials; report timeout censoring and correctness together |
| Review latency | First valid review-ready receipt to first substantive review outcome | All eligible ready items; unfinished items right-censored at cutoff |
| Blocker recovery time | First BLOCKED event in an episode to evidenced resumption | All blocker episodes; unresolved censored, cancellation separate from recovery |
| Receipt completeness | Required applicable fields with accessible, version-matching evidence | All eligible receipts; distinguish missing, inaccessible, and inapplicable fields |
| Status disagreement | Comparable status assertions inconsistent with authoritative revision-bound evidence at cutoff | All assertions whose state and cutoff are comparable; also report non-comparable count |
| Recording/review cost | Events, tool calls, storage, operator time, and reviewer time | Per assigned work item, including failures and abandoned items |
The bus cannot supply a denominator for omitted work unless compared with an independent task or execution register. Excluding inaccessible receipts can artificially improve completeness; report them explicitly. Before/after operational comparisons are vulnerable to workload, staffing, model, and policy changes. A randomized or carefully controlled design is needed for causal language.
7. Limitations and falsification
This paper has no measured reviewer outcomes, admitted operational incident dataset, or independent deployment/security evaluation. Its source documents are first-party design artifacts with historical differences. Templates and synthetic cases do not demonstrate achieved queue-control benefits.
The proposal would be challenged if the structured view fails to improve accuracy, increases time without a worthwhile accuracy gain, or incurs recording cost that exceeds its benefits in a defined setting. An executor accepting an unauthorized bus request would refute the claimed separation for that implementation. Divergent replay results under the same fixture and projection version would expose incomplete reconstruction semantics. These are testable failure criteria, not results already obtained.
Privacy can also limit auditability: removing timestamps, revision links, or event text may destroy the ability to calculate a metric. Report such metrics as unavailable rather than filling them with estimates. Findings from a small single-operator environment may not transfer to large organizations, different authorization models, or unreliable networks.
Artifacts and references
- Case-study collection template, synthetic replay fixture, offline replay method and commands, checker, synthetic tests, recorded output, and research notebook.
- Fowler, M. (2005). Event Sourcing.
- Laurie, B., Messeri, E., and Stradling, R. (2021). Certificate Transparency Version 2.0, RFC 9162, Experimental.
- Historical HUMMBL source artifacts and exact repository baseline are listed in §2. No live operational state or current authority is inferred from them.