Approval Is Not Execution

Four Questions Behind “Approved”

An approval record looks like one fact. Before relying on it as evidence, the enterprise has to answer at least four separate questions, and the answer to each can be yes while the others are no:

• Content commitment. Is the record bound to the specific action proposed: this tool, these arguments, this amount, this recipient? Not “a payment,” but this payment.
• Authenticated approval. Can the approver’s identity be verified, rather than merely asserted in a field anyone could have filled in?
• Enforcement at execution. Does something on the execution path check the approval before the action runs? Without it, the action can proceed whether or not an approval exists.
• Evidence of execution. After the fact, is there a verifiable record that what ran matches what was approved?

One distinction belongs at the start, because it is the easiest to lose. Authenticating the approver does not establish that the approver had authority to approve this action. A verified signature shows that a particular signing key was used; attributing it to a person also depends on how that key is bound to their identity and who controls it, and even then it does not show what they saw when they approved. And whether that person was entitled to approve this payment, at this amount, today, is a policy question the record cannot answer on its own. The enterprise has to answer it from its own policy: the approver’s scope, and whether the approval was still valid at the moment of execution. Validity covers expiry, revocation and, where an approval is meant to be used once, replay.

Signatures show why these questions come apart. A valid digital signature establishes that particular content was authenticated under a particular key. On its own it does not establish that the key belonged to the claimed authority, that the attested action occurred, or that the action was authorized under the parameters actually used. That observation is not new. What matters for architecture is that the separation can be tested: a record can be correctly signed, well formed and still assert things nothing supports. A verifier that accepts it because the signature checks out has confirmed the envelope, not the claims inside it.

Three Protocols, Three Different Subsets

Agent protocols are beginning to carry approval records as a first-class feature. In From Approval to Execution (v1.4, September 2026), I asked these questions of three independently designed protocols, each pinned to the exact revision read on 19 September 2026. Each establishes a different subset of the answer:

This is not a ranking, and none of the three is wrong to be scoped the way it is. PACT is unusually candid about its own boundary. A trusted-host model is a legitimate design choice inside an environment the enterprise controls. The finding is that these properties do not come together by default. Each protocol closes some of them deliberately and leaves others to whoever deploys it.

The risk sits with the buyer. A product page that says “approval binding” or “human-in-the-loop” may be making a narrower claim than it sounds like, and the enterprise needs to know which claims it is actually getting.

Approval Assurance Crosses Architectural Layers

The four questions also map onto the layers of the fifth domain, and the mapping explains why they are hard to get from one place:

None of the three protocols analyzed was scoped to answer all four questions, and none of them claims to be. That is not a proof that one integrated component could not answer all four. It is a reason not to assume that any one component does. Approval assurance is a cross-layer property, much as security is a cross-cutting concern in classic enterprise architecture rather than a domain of its own. An approval becomes trustworthy evidence when the layers together answer all four questions, not when one component says “approved.”

A Check That Can Fail

Knowing the four questions is half the work. The other half is testing the answers in a way that could come out badly.

The method I use is claim-level negative testing. For each claim a record asserts, build a record that is format-valid and correctly signed but makes that claim falsely, and require the verifier to reject it. A verifier that only checks the signature passes every well-formed record and fails this test immediately. The rule is simple: a format-valid, correctly signed record whose asserted claims are not supported must not be accepted as verified. Evidence that contradicts a claim makes it Failed; evidence that is missing or insufficient leaves it Unverified.

The ABV approval corpus accompanies the protocol paper. Version 0.1.3 has fifteen vectors: eleven negatives, each a single-property mutation of a valid approval, and four positive controls, which are valid approvals a correct checker must accept. All fifteen behave as specified against the reference checker. The corpus also includes a test of the corpus itself. A deliberately weak checker, one that compares a reference string instead of dereferencing it and never checks attestation, expiry or reuse, rejects all eleven negatives. Scored on negatives alone, it would look perfect while providing no binding at all. Two of the four positive controls catch it, because it also rejects the valid approvals that contain a reference. That is the reason the controls exist: a suite that only checks rejections rewards a checker that rejects everything. The scope of this is narrow. The corpus tests a checker’s logic over modeled execution facts, not a live system, and it does not validate the protocol findings above, which rest on specification and source analysis.

The RCL receipt corpus accompanies Signing Is Not Authorization. It has eleven vectors: nine that a correct verifier must reject and two acceptance controls. An independent developer wrote a separate verifier in a different language against it and matched all eleven verdicts, including both acceptance controls (the interoperability result). They were explicit that this is a compatibility result, not validation or endorsement, and it should be read that way. It does show the test is specified tightly enough for someone else to implement and get the same answers.

The same discipline gives an architect two rules, one before the action and one after:

• Before execution, missing evidence blocks. If the required approval evidence is absent, or the approval is expired, revoked or already used where single use applies, the action does not run. “No approval found” must never default to “allowed.”
• After execution, missing evidence is Unverified, not success. Evidence of execution cannot exist before the action runs. If it is missing afterward, the outcome is marked Unverified and triggers reconciliation by something other than the actor that ran.

Every approval-dependent signal ends in one of three states: Verified (the evidence meets the acceptance criteria for that specific claim), Failed (the evidence shows a criterion was violated) or Unverified (the evidence is missing or insufficient). Only Verified counts as a pass. Each acceptance criterion needs a known-good case the check must accept, a known-bad case it must reject, and a stated behavior when evidence is missing.

What to Require Before You Trust “Approved”

For a CIO, CISO or enterprise architect, the decision is not which protocol to standardize on. It is what to require of any protocol, product or internal platform before its approval records are allowed to stand as evidence. Six conditions cover it:

Ask vendors to demonstrate each condition, not to describe it. An answer describes a proposed design; a demonstration against known-good and known-bad cases, with retained evidence, provides evidence of assurance for the conditions tested. It is not proof of effectiveness across a whole deployment. A vendor that can demonstrate only some of the six has still built something useful, and the enterprise then knows which conditions it must close at another layer.

What This Part Does Not Show

The comparison covers three protocols at specific revisions, read on 19 September 2026, and analyzed from their published specifications and source rather than from production deployments. Later revisions of any of the three may answer questions this analysis found open. The ABV corpus models expiry but not revocation, and it tests a checker over modeled execution facts, not a running system. The preprint is not peer-reviewed, and no claim of independent validation, certification or adoption is made for it. The independent reimplementation described above was of the RCL receipt vectors only, and its author scoped it as compatibility only.

About This Series

An approval is a claim. Architecture decides whether it is also evidence.

Cite This Part

@misc{saleme2026approval,
  author    = {Saleme, Michael K.},
  title     = {From Approval to Execution: Assurance Boundaries in Three Agent Protocols},
  year      = {2026},
  version   = {1.4},
  publisher = {Zenodo},
  doi       = {10.5281/zenodo.22977589},
  url       = {https://doi.org/10.5281/zenodo.22977589}
}