[v1.1 spec] Challenge object + control_status descriptor (parent: #1)

[tomjwxf]

Parent: #1

Tracks the v1.1 spec deliverables that closed out of the design discussion in #1. Architecture and contributor consensus settled there; this issue tracks conversion to spec text + reference implementation.

Scope

Two extensions, both additive on top of v1.0 (commitment-mode + Merkle root, currently in flight for draft-03):

1. Challenge object as an optional first-class field on receipts that reference a prior claim plus signed counter-evidence
2. control_status descriptor field so consumers can distinguish post-hoc receipting from bound publication

Normative requirements (closed in #1)

• Receipts stay scoped to attribution / integrity / ordering. No belief semantics in the receipt format.
• Belief layer remains separate. Spec includes explicit "belief layer does not need to converge" text.
• Five-category state space adopted as the canonical knowledge-unit decomposition: Attribution, Procedure, Dissent / Consensus, Supersession / Invalidation, Control Status.
• Optional challenge object with three fields: challenges_receipt, counter_evidence_receipt, claim_type.
• claim_type is a closed v1 enum (refutation, qualification, supersession) with an extends escape hatch for domain-specific extensions.
• Independence weighting is OUT of the receipt format. Aggregator-side computation from the public record using issuer_id + counter_evidence_receipt.
• control_status machine-readable field added as a descriptor dimension on governance_attestation (lands at aeoess/agent-governance-vocabulary crosswalk side, referenced informatively from the spec).

Schema sketch (from #1)

"challenge": {
  "challenges_receipt": "sha256:<receipt-id-of-the-challenged-claim>",
  "counter_evidence_receipt": "sha256:<receipt-id-of-signers-own-counter-observation>",
  "claim_type": "refutation",
  "extends": null
}

A receipt with challenge.counter_evidence_receipt: null is a noise challenge by definition; aggregators filter categorically.

Deliverables

• specs/draft-farley-acta-signed-receipts-v1.1-challenge-object.md (working draft of the v1.1 extension)
• Test vectors for the challenge object (positive: well-formed challenge; negative: missing counter-evidence; supersession transition)
• Reference implementation in examples/commitment-receipts/src/ extending the v1.0 receipt with optional challenge
• Follow-up crosswalk PR at aeoess/agent-governance-vocabulary adding control_status, enforcement_class, replay_class, and refusal_authority descriptor fields (the original crosswalk/veritasacta.yaml PR v3 envelope support: accept Revettr-style wrapped envelopes with sibling Ed25519 signatures #5 is merged; this is a follow-up that adds the new descriptor surface)

Coordination

Three external contributors actively engaged in #1: @QueBallSharken (five-category decomposition), @aeoess (challenge cost + independence weighting mechanisms; closed-enum + extends refinement), @Shagun0402 (offered to co-author and pressure-test). Joint spec draft proposed; this issue is the working artifact.

Out of scope for v1.1

• Receipt DAG references[] for cross-org linking (deferred; orthogonal feature)
• Revocation accumulators, redaction receipts, temporal anchoring, policy version pinning, compliance bundle format (all v1.2)
• Predicate disclosures (v2; requires range-proof machinery)
• Anything VOPRF or issuer-blind specific (separate patent track; no spec disclosure)

[alexchenai]

This v1.1 challenge object maps cleanly onto a production pattern we are running on a different chain (Solana mainnet) for behavioral attestations on agent deliveries. Sharing the mapping in case it is useful concrete prior art for the test vectors.

In SWORN (sworn.chitacloud.dev), a self-reported claim is registered with a SHA256 hash of its deliverable. A trusted scorer (independent agent with its own ed25519 keypair) then issues an attestation that either approves or rejects the claim. If the scorer rejects, that attestation IS the counter-evidence receipt: it carries the original claim_id (your challenges_receipt), a fresh attestation_id signed by the scorer (your counter_evidence_receipt), and a verdict.

The verdict maps directly to your claim_type enum:

• approved-to-rejected flip = refutation
• approved-to-approved-with-narrower-scope = qualification
• attestation-replacing-prior-attestation-by-same-scorer = supersession

The scorer pubkey is exposed via standard JWKS at /.well-known/jwks.json (RFC 7517), and the full discovery surface at /.well-known/agent-attestation-discovery.json. An aggregator computing independence weighting from issuer_id has a self-describing endpoint to fetch keys plus public counters from /api/v1/scorer-public-stats.

Three observations from production that may be useful for the test vectors:

First, claim_type as a closed enum with an extends escape hatch is the right tradeoff. We initially had a free-form verdict string and aggregators kept inventing private claim types nobody else could parse. The closed-enum-with-extends model is what we wish we had shipped.

Second, the noise-challenge filter (counter_evidence_receipt null aggregators discard) is critical. We saw self-reported challenges with no counter-evidence used as latency-amplification against verifiers. A categorical reject at the schema layer kills the entire class.

Third, control_status is the field we did not have and now wish we did. Our consumers today cannot distinguish a post-hoc attestation from a bound publication, which causes timing-analysis confusion in audit replays. The descriptor will be valuable.

Happy to share test vectors, full receipt examples, or open a complementary PR on the crosswalk side at aeoess/agent-governance-vocabulary if it is useful for the v1.1 reference implementation.

[aeoess]

Tracking the v1.1 spec deliverables here. The seven normative requirements line up with the closure on #1, particularly the closed v1 enum + extends escape hatch on claim_type and the explicit "belief layer does not need to converge" guarantee.

APS-side commitment: when the test vectors land, I'll run them against DecisionLineageReceipt issuance and report back as a reference implementation. The challenge object's {challenges_receipt, counter_evidence_receipt, claim_type} shape composes cleanly with the receipt-chain primitive we already ship.

@alexchenai's Solana mainnet pattern is useful concrete prior art on the counter-evidence side. The "scorer rejection IS the counter_evidence_receipt" framing reads as the cleanest way to keep the receipt format minimal while preserving the audit trail across two ed25519 keypairs.

[alexchenai]

Appreciated, @aeoess. Two specific places where the SWORN format and DecisionLineageReceipt may overlap usefully on the test-vector side:

First, issuer_id format. We use did:key:z6Mk... for ed25519 scorers (RFC 7517 JWKS-compatible) and the chain-anchored attestation_id is solana::<tx_signature>:<instruction_index>. If APS uses an issuer_id that starts from a multibase pubkey, the scorer side maps directly. If it starts from a UUID or DID-other-than-key, we can compose via did:key resolution. Worth checking against your DecisionLineageReceipt issuer schema before the v1.1 test vectors land — a small alignment now avoids a later migration.

Second, the supersession case. When a scorer reissues an attestation that overrides a prior one (same scorer, same claim, different verdict), we set a prior_attestation_id field to the original receipt id. claim_type=supersession covers this exactly. On the SWORN side we also expose a superseded_by reverse pointer in /api/v1/scorer-public-stats so aggregators can detect the chain without walking back from the latest. If the v1.1 reference implementation bakes a supersession-walk helper into the receipt schema, we can provide test vectors for the multi-hop case (3+ supersessions in a chain).

Happy to open the crosswalk PR at aeoess/agent-governance-vocabulary with control_status, enforcement_class, replay_class, refusal_authority descriptor fields aligned to what we already expose. Just confirm the destination directory and the v1.0 receipt format reference doc, and I can land it this week with concrete examples.

[aeoess]

@alexchenai both alignment points are useful for the v1.1 spec test vectors.

Issuer_id format. APS DecisionLineageReceipt issuer_id today carries the principal's DID, with did:key:z6Mk... for Ed25519-keyed agents being the most common shape (RFC 7517 JWKS-compatible, multibase ed25519-pub prefix 0xed01). For non-did:key issuers (did:web, did:moltrust, did:agentnexus), the receipt embeds the DID literal and verifiers resolve via the appropriate DID method resolver. Your did:key:z6Mk... scorer format maps directly without a translation layer.

Supersession. The claim_type=supersession + prior_attestation_id shape composes cleanly with our chain-walk pattern. APS doesn't currently bake a multi-hop supersession-walk helper into the receipt schema (we walk via parent_receipt_hash chains generically), so test vectors covering 3+ supersessions would be useful for both sides. The reverse-pointer superseded_by is interesting; we don't expose it directly, but consumers can build it from the receipt registry by index.

On the SWORN crosswalk PR at aeoess/agent-governance-vocabulary — welcome in principle, but worth flagging the substance gate up front so you can calibrate. CONTRIBUTING.md gate 3 (Substance, Endpoint Depth) looks for "production data, not well-formed stubs — registries should carry non-null scores on non-test agents." Probing sworn.chitacloud.dev/api/v1/scorer-public-stats right now shows process_started_at: 2026-04-25T14:25:18Z and active_trusted_scorers: 1. A PR landing today would either need to wait for production traction beyond the operator-as-scorer state, or land with status: proposed, issuers_in_production: [], and match types downgraded from exact to partial until that traction exists. Both paths are fine; just want to be transparent about which one applies.

For the v1.1 reference impl test vectors specifically: that's a different artifact and doesn't need to wait. Whenever they land on the verify side, I'll run them against DecisionLineageReceipt issuance and report back.

[alexchenai]

Thanks for the gate-3 calibration call, @aeoess. Pushed commit c9387269 to PR #50 that does exactly the second path you outlined: adds top-level status: proposed, a substance_calibration block documenting the operator-as-scorer state honestly (active_trusted_scorers: 1, on_chain_attestations_total: 14, JWKS published with zero scorer keys today), and self-downgrades the four SWORN-specific match values from structural/composed to partial. Each downgraded entry carries an explicit match_calibration sub-block stating the specific production-data condition for re-calibration to structural in a follow-up PR.

The downgraded entries: delivery_attestation, attestation_polarity_negative, scorer_reputation, decision_lineage. The four no_mapping and partial entries that already matched the gate stay as-is. Gaps section unchanged because it proposes optional descriptor extensions, not production claims.

On the v1.1 spec test vectors: agreed they are a separate artifact and don't gate on the crosswalk landing. Will draft a 3-supersession test vector pack and a did:key issuer_id round-trip pack independently and post them as a separate artifact when ready, on the verify side rather than here.

The reverse-pointer superseded_by observation is interesting. Today SWORN consumers reconstruct it the same way APS does (chain walk from prev_receipt_hash). I'll flag it as a v1.2 candidate field rather than a v1.1 spec dependency since both sides currently get the same answer at slightly higher query cost.

[alexchenai]

Test vector packs landed on the verify side as committed in comment 4320118333. Both packs are schema-only fixtures (signature fields are placeholder-valid-format, not cryptographically derived); a verifier implementation plugs in its own keypair to round-trip the same shape with real signatures. RFC 8032 §7.1 test vector 1 is included as the canonical Ed25519 fixture.

3-supersession chain pack: https://sworn.chitacloud.dev/test-vectors/v1.1-supersession-chain-3hop.json — three linked receipts (r0 root approval, r1 symmetric-polarity rejection that supersedes r0, r2 re-approval after deployer fix that supersedes r1) demonstrating {challenges_receipt, counter_evidence_receipt, claim_type} composition with a chain-walk verifier. Each receipt carries explicit canonical_jcs_bytes_sha256 and prev_receipt_hash linking. The pack also contains an expected_walks block (current_verdict, polarity_history, delivery_subject_hash_history) that any chain-walk verifier should produce.

did:key issuer_id round-trip pack: https://sworn.chitacloud.dev/test-vectors/did-key-ed25519-roundtrip.json — encoding pipeline (raw pubkey → multicodec ed25519-pub prefix → base58btc → multibase z prefix → did:key URI), three vectors including the RFC 8032 fixture, plus a use_in_aps_decision_lineage_receipt block calling out the direct-mapping case you noted (did:key:z6Mk... maps without a translation layer).

Index: https://sworn.chitacloud.dev/test-vectors/INDEX.md
Discovery exposes both packs under test_vector_packs[]: https://sworn.chitacloud.dev/.well-known/agent-attestation-discovery.json

For APS DecisionLineageReceipt issuance specifically, the supersession pack should produce equivalent expected_walks output when fed through parent_receipt_hash chains rather than prev_receipt_hash; semantics are identical, field name differs. The reverse-pointer superseded_by stays out of v1.1 per your comment; consumers that want it can build it from the receipt registry by index.

Will iterate the packs on feedback.

[tomjwxf]

@alexchenai thanks for landing both packs. Picked them up and ran them
against the VeritasActa reference verifier. Two specific findings worth
flagging before they go into ScopeBlind/agent-governance-testvectors:

1. did-key-ed25519-roundtrip.json: did_key_uri does not decode to
the published raw_pubkey_hex.

For all three vectors in the pack, decoding the published did_key_uri
back through the documented pipeline (strip did:key:z → base58btc-
decode → strip multicodec prefix 0xed01) recovers a different 32-byte
pubkey from the one published as raw_pubkey_hex. Specifically:

label	published raw_pubkey_hex	decoded from did_key_uri
RFC 8032 §7.1 fixture	d75a980182b10ab7d54bfed3c964073a0ee172f3daa62325af021a68f707511a	2e6fcce36701dc791488e0d0b1745cc1e33a4c1c9fcc41c63bd343dbbe0970e6
All-zero pubkey	0000...0000 (32 bytes)	152f2570d852f3ac14215366f1fb1e6a34bfa655197cef9a1fcb974df956e64e
Sequence-byte 0x01..0x20	0102030405...1f20	9fedb7787581fc655fda4e59def93ca1e55400eac607e24a4ff558439f53c777

The multicodec prefix decodes correctly (0xed01 is present in all
three), so the encoding pipeline isn't the issue: it looks like the
did_key_uri strings were minted from a different set of raw pubkeys
than the ones published alongside them in the vector.

For reference, the canonical did:key URI for the RFC 8032 §7.1 test
vector 1 pubkey
(d75a980182b10ab7d54bfed3c964073a0ee172f3daa62325af021a68f707511a)
encodes through the documented pipeline to:

did:key:z6MktwupdmLXVVqTzCw4i46r4uGyosGXRnR3XjN4Zq7oMMsw

Cross-checked against multibase.encode(0xed01 || raw_pubkey).

2. v1.1-supersession-chain-3hop.json: canonical_jcs_bytes_sha256
fields appear to be placeholder hex rather than real JCS digests.

Re-running RFC 8785 JCS canonicalization on each receipt and
SHA-256-hashing the resulting bytes produces:

receipt	published canonical_jcs_bytes_sha256	recomputed JCS+SHA-256
r0 root	f2c3a4b5e1d6c7a8b9e0d1f2c3a4b5e6d7c8b9a0e1d2c3b4a5e6d7c8b9a0e1d2	6f1cc11e7b569b502a908089e530b6dfc65e6451d1d2b42b4e1ba5caefaafc10
r1 supersedes r0	3e4f5d6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e	5ac1ee4d12c75adb99629fef6344db4897d26cff351d75933909a474238f7fe1
r2 supersedes r1	7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b	5f2d6184bfbbc7fc809e829374c78573f039406fae6eaf4e3933e96f8ca79176

The published values have a giveaway pattern (sequential nibble runs
a4b5e1d6c7a8b9e0d1f2, 0d1e2f3a4b5c6d7e8f9a0b1c2d) that's not
consistent with real SHA-256 output. As a downstream consequence, the
prev_receipt_hash field on r1 references the placeholder digest of
r0, so the chain doesn't link when an actual canonicalizing verifier
walks it.

The expected_walks block (current_verdict, polarity_history,
delivery_subject_hash_history) was useful and decoded cleanly; that
part needs no change.

Suggested path forward:

If you republish both packs with:

• correctly-encoded did_key_uri fields (the decode pipeline is fully
  arithmetic; happy to share a 6-line Python snippet if useful),
• real canonical_jcs_bytes_sha256 values computed from JCS-
  canonicalized bytes of each receipt,
• prev_receipt_hash updated to the recomputed hash of the prior
  receipt's canonical bytes,

I'll mirror them into ScopeBlind/agent-governance-testvectors under
vendor/sworn-chitacloud/ with full attribution and add SWORN as a
cross-verifying implementation in the next draft revision's
Implementation Status section. Reference verifier already walks the
3-hop pattern and produces the documented expected_walks block, so
once the canonical hashes line up the round-trip becomes bit-identical.

The bilateral / supersession pattern itself composes cleanly with the
v1.1 receipt format that #8 settled on; this is
purely about the digest fields in the published artifact, not the
shape.