Summary

  • draft-sankarshan-agent-registry-protocol-04 requires a threshold, quorum or role decision to bind to one identified membership/controller and exercise-rule snapshot.
  • In a local 2-of-3 construction, B's approval is valid under S1 and D's is valid under S2, but neither snapshot contains two valid approvals. Counting the rows together creates authority that neither committee possessed.
  • Cross-snapshot composition remains possible only when the governing rule explicitly permits it and the evidence proves the permitted transition; a stable committee name or authentic signature is not enough.

The arithmetic that lies without changing a number

Take a committee with the members A, B and C. Its rule is simple: two distinct current members must approve the exact action. Call that state S1. B approves. The threshold is not met.

B then leaves and D joins. The committee is now A, C and D, still operating under a 2-of-3 rule. Call this state S2. D approves. S2 also has only one approval.

A database query that groups by action and counts distinct approvers returns two: B and D. Every row may be authentic. Both may carry the same exact action digest. Each signer may have been eligible when signing. Yet the result is not a quorum. B is not a member of S2; D was not a member of S1. There is no single collective state in which both contributions can be counted.

Our local construction records that contrast. Its action digest is sha256:8b826aaafbce2a9ca1b653ba3ae6992074fff22fa3b261b49f27704b2afab5c3. The unversioned count says allow. Grouping by S1 and S2 produces one eligible approval in each and therefore no allow. This is an explanatory finite-set test, not an ARPA implementation, deployment finding or conformance result.

The error is subtle because no number is false. Two approval records exist. What is false is the proposition silently attached to the number: that both records exercise the same collective authority.

Revision 04 names the missing coordinate

Section 23.4 of the Agent Registry Protocol draft says that a collective-principal evaluator must establish the current membership or controller set, the current exercise rule and the contributions counted toward it. Membership does not give a participant independent possession of the collective authority. Stale membership and superseded rules cannot authorize a new material action.

Section 25.4 makes the join condition explicit. The decision must bind to one stated membership/controller and exercise-rule snapshot, identified by a stable checkpoint, version or digest. Each counted approval must be valid under that same snapshot. Approvals collected across removal and re-addition, material role change, exercise-rule change or stale membership must not be combined by default. Decision evidence must retain the checkpoint used.

That language protects something more fundamental than audit neatness. A collective principal is not the committee's name. It is the authority exercised by a defined set under a defined rule at a defined state. Keep the name and discard the state, and software can turn succession into simultaneous power.

Four questions, not one green check

An approval workflow needs four separate results.

First, authenticity: did the asserted approver or its system produce the record? Second, action binding: does the record cover this exact resource, amount, counterparty and material parameter? Third, individual validity: was the approver eligible under the applicable role, membership, time and status? Fourth, collective satisfaction: do enough distinct eligible contributions coexist under one stated exercise-rule snapshot?

Signature verification can help answer the first. A canonical action digest can help answer the second. Current authority resolution can help answer the third. None automatically answers the fourth. The B@S1 and D@S2 records can pass the first three questions and still fail the fourth.

This is why an approval schema that stores only action_id, approver_id and approved=true is not merely incomplete metadata. It has erased the object against which the collective claim must be evaluated.

Transition is evidence, not a permission slip

Revision 04 does not impose an absolute ban on carrying approvals across change. It says the governing rule must explicitly permit cross-snapshot composition and the evidence must prove the permitted transition. Both conditions are necessary.

A valid carry-forward rule might specify that an approval survives an unrelated seat change for a defined period, but not if the signer is removed, the action changes, a required role changes or the threshold increases. It might require revalidation by the new committee or identify which old checkpoint can feed which new one. The protocol draft does not choose that governance rule for everyone. It prevents software from inventing it after the fact.

A stable committee label is not such a rule. Neither is record order, the identity of a chair, a later membership list or the convenience of preserving an almost-complete workflow. Transition evidence must show the state change that occurred and why the earlier contribution remains countable under the later decision.

Removal and re-addition is especially revealing. The same identifier can appear before and after a gap, but the two eligibility intervals are not one continuous grant. A system that sees only the name may revive an old approval. A snapshot-bound evaluator sees two authority states and asks whether the governing rule connects them.

Time and freshness do not collapse into the checkpoint

A checkpoint does not prove everything. It identifies the membership and rule state used. The evaluator still has to establish that the state was authoritative, complete and fresh at evaluation time.

The draft specifies half-open authority validity: valid_from <= evaluation_time < valid_until. It says stale, conflicting, unavailable or indeterminate material authority cannot produce an affirmative result. It also says a stale cached response cannot support an affirmative decision when the applicable freshness policy requires newer state.

RFC 3339 timestamps help represent time; RFC 9111 explains HTTP caching; neither turns a cache timestamp into proof that the correct committee was evaluated. The decision record needs the requested state, its source and checkpoint, the evaluation time, later changes relevant to interpretation and any reconstruction limitation.

Events add another boundary. Duplicate processing must not expand authority, and sequence gaps must remain visible. If the removal of B is missing from a consumer's event stream, the consumer does not possess S1 forever. It possesses incomplete state.

The smallest useful decision record

The practical response is not to centralize every organization's governance. It is to preserve the minimum evidence another authorized party needs to reproduce the decision.

For a consequential collective action, that record should bind the exact action digest; collective-principal identifier; membership/controller checkpoint; exercise-rule checkpoint or combined snapshot; evaluation time; approvals and their validation snapshots; distinct-controller and role accounting; material parent-authority, lifecycle, conflict and freshness inputs; outcome and reason; and the action actually sent downstream.

If cross-snapshot composition is invoked, add the explicit rule identifier and transition evidence. If the downstream system executes under a materially different action or authority state, it needs a new evaluation or a policy-proven equivalence.

Those are Daniel Kade's operational requirements derived from the draft's boundaries, not invented ARPA wire fields. Deployments may use a signed decision object, an append-only ledger, versioned database rows or access-controlled evidence references. The format can vary. The invariant cannot: the quorum must be reproducible without borrowing members from a committee that never existed.

Reality layers are a control discipline

Heng Lu's reality-layer doctrine helps explain why this narrow rule matters. The committee's public name, its legal or administrative membership, its exercise rule, each approval, the aggregate decision, downstream execution and external effect are separate realities. They can be linked, but one does not substitute for another.

Running-code primacy places responsibility where it belongs. The actual control surface is the evaluator and its joins. A policy manual may say “two current members,” but a query that counts valid signatures without joining their snapshot has implemented a different constitution.

Minimum initial specification offers the right remedy. Do not prescribe every future governance arrangement. Require enough stable identifiers, state and failure behavior to prevent accidental authority expansion. Missing checkpoint, stale membership or conflicting rule state should remain non-affirmative, not be converted into a convenient success.

Sources and limits

The evidence was frozen on 30 September 2026 Asia/Shanghai. Revision 04 is an active individual Internet-Draft, not an RFC, IETF consensus, adoption report or deployed product. The Datatracker gives it no formal standing. The local S1/S2 construction explains the specified boundary only; it does not demonstrate an exploit, malicious actor, broken signature, implementation failure, real committee decision or loss. The document may change, be replaced or expire.