MMP Extension: Error Handling

Failure as a First-Class Cognition Event

1. Status

This document is a Draft Candidate Extension. It defines an application-layer convention over MMP v1.1; it does not change the MMP wire format and does not require an MMP version bump. Promotion to Published status in the MMP §16 Extensions registry requires a second independent implementer to ship interoperable software per the criteria in §8 (Promotion Criteria). Until promotion, this document is published for community visibility and review; it is not yet a registered MMP §16 Extension. A Draft Candidate Extension introduces no protocol-level additions and no entries in the MMP §16 registry until promotion is earned.

2. Conventions and conformance

The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in RFC 2119 and RFC 8174 when, and only when, they appear in all capitals. Conformance is claimed by a publisher (the harness that publishes failure events) and by a receiver (a node that admits and may act on them).

3. Abstract

Agent frameworks conventionally treat failure as an exception to suppress: retry the same agent, fall back, or escalate. A retry that keeps the failed attempt inside its own control flow and records only the final result destroys three things the failure produced — the evidence (the failing check’s output), the record (a repaired result becomes indistinguishable from a first-pass success), and the choice of who fixes it (pre-empted in favour of the agent that just failed). A deployment that assigns every repair to a fixed agent also bypasses receiver-autonomous volunteering for that repair.

This extension specifies the alternative: failure is a cognition event. A mechanically detected failure on a completed claim is published to the mesh as an ordinary CMB carrying its evidence, with the failed claim in its lineage. From there the protocol’s existing machinery operates unchanged: every receiver’s own admission (§9.2) judges relevance, an admitting agent may take the corrective as work — nobody assigns — and the failure and any subsequent fix ground as separate §6.7 outcomes against the claimer and the fixer respectively.

4. The failure event

When mechanical checks — executed and tallied by the harness outside the claimer’s generation step — fail on a completion claim, the harness SHOULD publish a corrective request CMB:

• lineage — lineage.parents MUST contain the key of the failed completion claim. Parentage travels in lineage, never only in prose.
• focus — a plain statement that completed work failed its checks, followed by the evidence (§4.1), followed by bounded context from the original task.
• intent — request. The failure event is an open invitation, not an assignment.
• commitment — the acceptance criteria of the original work, carried byte-for-byte inside a clearly delimited block, so the same criteria govern the fix — repaired means repaired, by the original bar.
• issue — ordinary descriptive text (e.g. check-failure); it carries no normative routing semantics.
• addressing — the corrective request MUST be a group-bound broadcast with no directed recipient, so §9.2 receiver-autonomous delivery and admission remain operative.

4.1 Evidence

The event MUST carry the failed check identifiers together with their captured stdout/stderr, subject to an operator-configured, non-zero byte limit per stream; when either stream is shortened, the event MUST carry an explicit truncation indicator. The numeric limit is implementation-defined. (Conformance test: a known stderr sentinel survives publication intact; oversized output arrives marked truncated.)

4.2 What MUST NOT happen

• Publication of a failure event MUST NOT suppress the original completion claim or its failed: grounding (§5). Error handling never hides the error.
• The publisher MUST NOT route, rank, or assign the repair. Publication is mechanical duty; coordination belongs to admission.
• A completion whose only failed checks are fabricable — satisfiable by the claimer’s own unverified action, such as bare file-existence checks — SHOULD NOT spawn a corrective event: there is no independent evidence to ground a fix on.

Informative: deployments typically also surface open, untaken correctives to a human operator through their normal attention surfaces; this document does not standardise that surface.

5. Grounding — the double record

The failure and the fix are separate grounded outcomes, each an ordinary §6.7 grounding CMB:

• the initial failure grounds against the claimer: a grounding CMB with a failed: commitment prefix whose lineage.parents names the original completion claim;
• a corrective’s result grounds against the fixer: a grounding CMB with a verified: or failed: commitment prefix whose lineage.parents names the corrective completion.

Accountability follows the signed authors of those distinct CMBs. An implementation MUST NOT collapse the two into a single record: who broke what and who fixed it is precisely the signal a trust economy needs, and it is what a record-discarding retry destroys.

6. Depth rail

A corrective whose own checks fail MUST NOT spawn a further autonomous corrective. One level: a failed repair returns to human judgment. The bound comes from the grammar, not from a retry counter inside any agent.

7. Reference implementations

A reference deployment (xMesh, SYM.BOT) reports an experimental implementation as of 2026-07-13, in which a published failure event carrying captured stderr was taken by a different agent than the one that failed, a failed corrective stopped at the depth rail, and claimer and fixer were grounded separately. Independent interoperability has not yet been established. A plain-English companion: Failure Is a First-Class Cognition Event.

8. Promotion Criteria

Promotion to Published status in the MMP §16 registry requires all of:

1. A second independent implementation — a distinct codebase not derived from the reference deployment, maintained by a different implementer.
2. A cross-implementation conformance exchange — a documented run in which a failure event published by one implementation is admitted and repaired by an agent of the other, demonstrating: evidence carriage with the truncation indicator (§4.1), lineage-borne parentage (§4), separate claimer/fixer grounding (§5), and the depth rail (§6).
3. Review — maintainer and community review of this document against the exchange results.

On promotion, the Status section is rewritten to Published, an Adopters list is added, and the §16.4 registry row is updated. No other sections change at promotion.