Agent Action Capsule · explain
09 / 11

Evidence grades

A record may say how much evidence stands behind it; a verifier works that out again from the record's own bytes and the proofs it can check, and reports any claim they do not support.

A verifier re-derives cross_party_rung and reports an overclaim Step 1: a record box on the left carries the claim cross_party_rung: full_bilateral. Step 2: in the middle, a verifier box reads the record's own cross_party block: initiator_ref present, marked green; counterparty_ref absent, marked grey; correlator and substantive absent, marked grey; a note says the digests are not opened and the other side's signature is not checked. Step 3: on the right, a box reads derived from the block's bytes: unilateral_fallback, only the initiator's half is referenced. Step 4: the record's claim full_bilateral is struck through and replaced by unilateral_fallback. Step 5: a red finding box at the bottom reads check 7, assurance_overclaim, severity info, ok true; claimed full_bilateral, derived unilateral_fallback; no score, no rating. Record payload + producersignature claims cross_party_rung: full_bilateral full_bilateral unilateral_fallback Verifier reads the cross_party block ✓ initiator_ref: present — counterparty_ref: absent — correlator, substantive: absent Digests are not opened; the other side's signature is not checked here. derived from the block's bytes unilateral_fallback no counterparty_ref present Finding: assurance_overclaim (check 7, info; ok stays true) claimed: full_bilateral · derived: unilateral_fallback The report names the claim and the derived value. No score, no rating.

1What it is

The evidence layer names three levels of assurance a record can reach, self-attested (signed only by its producer, with neither a witness nor a countersignature), witnessed and countersigned, but defines no rule for a verifier to re-derive them.

The Agent Action Capsule draft does define such a rule for its own assurance fields: a verifier re-derives each one from what it can check, for cross_party_rung from the record's own cross_party block, and reports the derived value.

When a record claims more than that, the verifier reports the claim as an overclaim beside the derived value, and no draft turns any of this into a reputation number.

2Design choices

Chosen: a verifier re-derives each assurance mode from the evidence present and reports any overclaim.
Rejected: accepting the producer's label; a producer MUST NOT record a mode it did not achieve, and the verifier does not take its word for it. (AAC -05 §5.4, §6 check 7)
Chosen: how much of the other side's signed evidence is bound in is its own axis, cross_party_rung.
Rejected: folding a countersigned value into attestation_mode, which would make "both sides signed, not yet anchored" impossible to express. (AAC -05 §5.4.1)
Chosen: an overclaimed custody or cross-party grade is an informational finding, and the derived value replaces the claim.
Rejected: treating every overclaim alike; an unsupported time_rung: "witnessed" on a backfilled record fails verification, because the claim is unsupported and "falsifiable from the record's own bytes". (AAC -05 §6 checks 7 and 9)
Chosen: a record's epistemic_type (how its content came to be known) is fixed at commit and never upgraded.
Rejected: letting a later signature, receipt or countersignature change what kind of statement a record was. (Evidence layer -00 §4.1)
Chosen: report per record what the evidence supports, and leave weighing it to the relying party.
Rejected: a score for parties; the settlement draft "does not rank, rate, or otherwise grade the parties", and the bilateral draft "neither scores counterparties nor defines a vocabulary for doing so". (Settlement -00 §1.1; bilateral -02 §12.2)

3What it shows / what it does not

Shows

  • For each assurance field, the value the verifier can support: chained from an intact chain block, anchored only after it verifies an inclusion proof against a trusted log key.
  • For cross_party_rung, what the record's own cross_party block contains: an initiator_ref digest, a counterparty_ref digest and correlator, and a substantive flag.
  • Where a record claimed more than that, as a named finding with the claimed and the derived value.

Does not show

  • That the record's content is true; a grade says who signed and how it was committed, not how its content was known.
  • More than inclusion, from a Receipt: it shows a statement is in a log. Checking that each checkpoint extends the one before is a witness's job, a separate party (evidence layer -00 §3).
  • That a witness or countersigner is independent of the producer; that is a claim about who runs it.
  • That the other side signed anything: cross_party_rung is derived from the block's own bytes, without opening the digests it cites or checking the counterparty's signature; substantive: true is the producer's word.
  • Anything about a party's other records. There is no reputation number anywhere in these drafts.

4Example

A test vector for exactly this case: a record claims full_bilateral (both parties' evidence bound in) but its cross_party block holds only initiator_ref, a digest of the initiator's own signed half, and no counterparty_ref. The input, then the verifier's expected result.

// input.json
{
  "action_id": "cp-overclaim",
  "action_type": "decide",
  "assurance": {
    "attestation_mode": "self_attested",
    "cross_party_rung": "full_bilateral",
    "effect_mode": "not_applicable",
    "ledger_mode": "standalone"
  },
  "capsule_id": "6bddc7510b73ee2b0a3b3d4cea9e8aceb3c6786fa6f5a58d56b11723d14bb1e4",
  "cross_party": {
    "initiator_ref": "1111111111111111111111111111111111111111111111111111111111111111"
  },
  …
}

// expected.json
{
  "capsule_id_recomputed": "6bddc7510b73ee2b0a3b3d4cea9e8aceb3c6786fa6f5a58d56b11723d14bb1e4",
  "derived": {
    "attestation_mode": "self_attested",
    "cross_party_rung": "unilateral_fallback",
    "effect_mode": "not_applicable",
    "ledger_mode": "standalone"
  },
  …
  "findings": [
    {
      "check": 7,
      "code": "assurance_overclaim",
      "detail": "claimed cross_party_rung 'full_bilateral' but verifier derived 'unilateral_fallback' (§5.3 Cross-party assurance)",
      "severity": "info"
    }
  ],
  "kind": "overclaim",
  "ok": true,
  …
}
FieldTypeMeaning
assurance.cross_party_rungtstrThe producer's claim: full_bilateral, both sides' evidence bound in.
cross_party.initiator_refhex tstrDigest of the initiator's own signed half; the only half present.
cross_party.counterparty_ref(absent)No other-side half is referenced, so the claim cannot hold.
derived.cross_party_rungtstrWhat the verifier derives: unilateral_fallback.
findings[].codetstrassurance_overclaim: claimed above derived.
findings[].severitytstrinfo: reported, does not fail the record.
okboolTrue: no failing check; the overclaim is reported and the derived value stands.

The section number inside detail is the vector's own text; in the -05 draft the subsection is §5.4.1.

Source: action-state-group/agent-action-capsule:vectors/capsule/neg-cross-party-overclaim/input.json and expected.json @ 2ef8aeb49e2334e24c404bd62d3fdb161770873c

5Specs