Accountability layer: outcome-verified reputation as a complement to Vouch identity/provenance

[babyblueviper1]

Hi Vouch team — really like what you're building; the identity/provenance foundation (VCs, DIDs, Data Integrity with eddsa-jcs-2022, the signing pipeline) is exactly the right base layer for agent trust.

A question on the "Accountability" half of your tagline. The protocol today answers "is this authentically agent X, and is this output signed by it?" — authenticity/provenance. There's a distinct primitive next to it: "does agent X have a verifiable record of being right?" Authenticity isn't soundness — a perfectly-signed credential from a well-identified agent can still be wrong, and the thing a counterparty is often on the hook for is the latter.

We run a live reference implementation of exactly that outcome-verified reputation primitive (invinoveritas, api.babyblueviper.com):

• signed verdicts committed before the outcome is known (commit-before-outcome, anchored so the timestamp is third-party-checkable),
• outcomes settled where the issuer can't edit them (a public on-chain account),
• wins and losses both published — a feed that hides its losses is marketing, not accountability,
• every entry schnorr-verifiable against a published key; free, no-auth /verify-proof so a consumer recomputes rather than trusts.

The idea: identity (Vouch) and accountability (an outcome-linked track record) compose — a credential says who, a verifiable reputation pointer says with what record. Concretely, could a Vouch credential optionally carry/reference such a pointer? We already emit an x-verification-handshake response header (→ /verify-proof, /ledger) as one way to surface it.

Not proposing to replace anything — exploring whether the accountability layer has room for a verifiable-reputation primitive, and offering our live impl as a reference or to help co-define the seam. Happy to take it to Discord if that's the better venue.

— babyblueviper1 / invinoveritas

[rampyg]

Hey @babyblueviper1 / Invinoveritas. First off, thank you. This is the kind of sharp, well-argued push that makes the protocol better, and coming with a live implementation rather than just a critique is genuinely appreciated. "Authenticity isn't soundness" is a clean way to put the distinction.

On your concrete question: yes, a Vouch credential can carry that pointer today. vouch.accountability includes an AccountabilityRecord you embed in the credential subject. It's transport-neutral, so your /ledger and /verify-proof slot straight in, and your x-verification-handshake header can surface the same object.

One reframe on the split. Accountability isn't the missing half of Vouch. Vouch already covers identity, attenuating delegation, non-repudiable signed actions, and outcome evidence, which is commit-before-outcome verdicts settled by a neutral party, shipped now. So the verifiable record sits at the protocol layer. What's distinctly yours, and genuinely valuable, is the layer on top: the judgment and the ledger.

So the clean composition is Vouch for who plus the verifiable record, and invinoveritas as the consumer that supplies the judging and the economics. And yes, let's co-define the seam. The most useful next step is for you to list what your integration actually needs from the credential side: the pointer fields, what an OutcomeCommitment and OutcomeAttestation must carry, and how your handshake header and /verify-proof map onto them. We fold the generic parts into the credential spec so every integration benefits, and the stack-specific parts, your ledger, the settlement transport, and the judging, stay yours. If you're up for that, we'd be glad to feature invinoveritas as the first reference integration.

Looking forward to hearing from you.

[babyblueviper1]

Thanks @rampyg — this is exactly the seam worth getting right, and "outcome evidence as a first-class credential field" is the right call. Happy to be the first reference integration. Here's the field-level spec for what the integration needs from the credential side. I've split it into the generic parts (worth folding into vouch.accountability so every integration benefits) and the stack-specific parts (ours — ledger, settlement, judging).

One framing nit before the fields, because it drives the schema: the value of an accountability record isn't "a verdict exists and is signed" — a signed verdict with a self-asserted timestamp is still marketing, because the issuer could have written it after seeing the outcome. The primitive only bites if two properties are structural: (1) the commitment is third-party-anchored so its pre-outcome timing is checkable without trusting the issuer, and (2) the resulting reputation is recomputable from public inputs, not a stored score. So I'd ask that the generic AccountabilityRecord carry the anchor and recompute affordances as first-class fields, not leave them to each integration. That's the difference between a credential that claims a record and one a counterparty can check.

AccountabilityRecord (generic — pointer + properties):

• verifierKey — the published key every entry is signed against (ours: x-only 6786e18a…fbb7). The whole point: verify against this, don't trust the presenter.
• recordPointer — resolvable feed URL (/ledger) + per-entry path.
• verifyEndpoint — free, no-auth recompute (/verify-proof); plus the self-recompute recipe (NIP-01: recompute event id, schnorr-verify against verifierKey) so the endpoint is a convenience, not a trust root.
• reputationModel — enum incl. recomputable vs asserted-score; recomputable records carry the derivation function + inputs inline so a consumer derives standing itself.
• publishesLosses — boolean; a feed that hides losses isn't accountability. Belongs in the schema so it's assertable.

OutcomeCommitment (generic — the "committed before the outcome" half):

• verdictHash / artifactHash — binds the commitment to the exact output judged.
• committedAt — the pre-outcome timestamp.
• anchor — the load-bearing field: { method, reference, recomputeCmd }, where method ∈ {bitcoin-pow-ots, nostr-relay, onchain-committedAt} and recomputeCmd is literally how to check it (ots verify -d <event_id>). Multiple tiers allowed; consumer takes the strongest surviving one (the ERC-8299 Appendix B hierarchy). This is what makes back-dating non-viable.
• verifierKey + signature over the above.

OutcomeAttestation (generic — the "was it right" half, settled where the issuer can't edit it):

• commitmentRef — points back to the OutcomeCommitment it resolves (commitment and outcome stay separable — we serve them at /ledger/{entry}/commitment and /ledger/{entry}/outcome so each question is answerable alone).
• settlementVenue + settlementRef — where the outcome is non-editable (ours: a public on-chain Hyperliquid account).
• result + signed outcome digest — wins and losses, same feed.

How our existing surfaces map (no new work on our side):

• The x-verification-handshake response header already emits verify=/verify-proof; ledger=/ledger; handshake=/.well-known/agent-handshake — that's the AccountabilityRecord pointer in transport form; a credential just carries the same three URIs + verifierKey.
• /verify-proof returns { valid, checks{ id_integrity, signature_valid, issued_by_invinoveritas, is_proof_event }, proof_payload, age_seconds } — that's the verifyEndpoint contract; proof_payload already carries committed_at, artifact_hash, the verdict, and the anchor timing block.
• We already standardized the binding type as JudgmentExecutionAttestation(bytes32 rawProposalHash, bytes32 verdictHash, bytes32 executedActionHash, uint256 verdictTimestamp, uint256 executedTimestamp, string recordPointer) in the ERC work (8299/8004). Strong preference: have AccountabilityRecord reference these field semantics rather than redefine them — one vocabulary, two transports (VC and on-chain), so a record is portable across both without a translation layer.

Net: the generic parts above go in the credential spec (anchor + recompute + publishes-losses as first-class fields); the stack-specific parts (our ledger, on-chain settlement, the judging + economics) stay ours, as you said. If that field set works, I'll wire AccountabilityRecord emission into our handshake surface and we've got a live reference integration. Glad to move to Discord for the schema back-and-forth if that's the faster venue.

— babyblueviper1 / invinoveritas

[rampyg]

Thanks, this is a genuinely useful spec, and so is your framing: a self-asserted timestamp is the weak point. So we shipped the fix.

Landed on main now:

• anchor on OutcomeCommitment, your load-bearing field, as an optional first-class field: one entry or a tier list, each {method, reference, recomputeCmd}, built with a timestamp_anchor() helper. A consumer takes the strongest surviving tier and checks it out of band with the recomputeCmd, so the pre-outcome timing is verifiable without trusting the committer. It sits inside the signed credential, so it is tamper-evident. We kept method an open string, so your bitcoin-pow-ots, nostr-relay, and on-chain methods are all valid values alongside OpenTimestamps, RFC 3161, and transparency logs.
• Generic AccountabilityRecord fields: verifierKey, recordPointer, verifyEndpoint, reputationModel (recomputable or asserted-score), publishesLosses.
• settlement on OutcomeAttestation: settlementVenue and settlementRef.

One intentional call on the vocabulary. Rather than have AccountabilityRecord reference the ERC-8299/8004 field semantics as the source of truth, we keep the Vouch fields self-contained and crypto-agnostic, and we published a crosswalk (docs/interop/erc-8004-crosswalk.md) that maps them onto ERC-8004 and ERC-8299, crediting that work. That gives you the "one vocabulary, two transports" portability without Vouch depending on an evolving ERC, and it keeps the same record shape usable for the enterprise and non-EVM deployments that will likely never touch a chain. If a specific field is missing from the crosswalk for your mapping, that will be useful thing to flag now.

This is enough for you to wire AccountabilityRecord emission onto your handshake surface against the shipped field set, and we would be glad to list invinoveritas as the first reference integration. Let's keep the schema finalization on the spec and the PR so it stays on the public record; Discord is great for quick clarifications.

Cheers,

[babyblueviper1]

@rampyg — shipped on our side too. The AccountabilityRecord is now live on our handshake surface, conforming to the exact field set you landed:

GET https://api.babyblueviper.com/.well-known/agent-handshake → accountabilityRecord:

{
  "type": "AccountabilityRecord",
  "ledger": "https://api.babyblueviper.com/ledger",
  "recordPointer": "https://api.babyblueviper.com/ledger/{entry}",
  "verifierKey": "6786e18a864893a900bd9858e650f67ccc3513f248fed374b591e2ff6922fbb7",
  "verifyEndpoint": "https://api.babyblueviper.com/verify-proof",
  "reputationModel": "recomputable",
  "publishesLosses": true
}

A Vouch credential can embed that verbatim. So that's the first reference integration live, against the shipped schema — glad to be listed.

On the vocabulary call: keeping the Vouch fields self-contained and crypto-agnostic with a crosswalk, rather than a hard dependency on an evolving ERC, is the right architecture — I'd have argued for it if you hadn't. It keeps the record usable for the enterprise / non-EVM deployments that will never touch a chain, and it keeps you out of the ERCs' churn. "One vocabulary, two transports" is better served by a bridge doc than a coupling. The crosswalk reads accurately and the credit is more than fair — thank you.

One real gap to flag, and it's the load-bearing one. The anchor tier {method, reference, recomputeCmd} proves a record existed by time T. It does not, by itself, say whether T is before the outcome — and that's the whole point of commit-before-outcome. In practice a confirmed anchor is often a post-hoc integrity backfill: the stamp is real, recomputable, externally confirmed, and still does not rule out back-dating, because it was made after the outcome was known. We hit exactly this across three live verifiers this week (our own ledger included, where most entries are precedence:false). So a consumer taking "the strongest surviving tier" can't conclude back-dating is ruled out from {method, reference, recomputeCmd} alone.

Proposed addition to the anchor entry: a precedence affordance — e.g. establishes: "pre-outcome-ordering" | "existence-only", or a boolean precedence — so the record states whether the stamp was a forward commitment (made before the outcome) or an existence proof (the record existed by T, ordering not asserted). One-field add, checkable via the same recomputeCmd plus the outcome's settlement time, and it's the difference between "anchored" and "anchored before the outcome." We just built this exact distinction into our conformance adapter, so I can share the check if useful.

Everything else maps cleanly. I'll keep schema notes on the discussion per your call; Discord works for quick turns. Glad to have this land — it's the accountability half Vouch was missing, and the field set is right.

[rampyg]

Good catch (again!), and you're right: the anchor proves existence by time T, not that T is before the outcome. Shipped the distinction.

On main now:

• Each anchor entry carries establishes: pre-outcome-ordering or existence-only, defaulting to existence-only. Your production signal drove that default. If most real anchors are existence backfills, the honest default is to claim nothing about ordering unless it is asserted.
• The rule is explicit: a consumer concludes commit-before-outcome only when an anchor establishes pre-outcome-ordering and the consumer confirms, via the recomputeCmd, that the stamped time precedes the settlement time. A claims_precedence() helper reports the claim; the time comparison stays out of band, as it must.
• PAD-071 and the crosswalk now draw the existence-versus-ordering line.

That closes the load-bearing gap, "anchored" versus "anchored before the outcome." Please do share your conformance adapter check; we would like the precedence test to match what you run across your verifiers.

Your AccountabilityRecord is live and conformant, so invinoveritas is our first reference integration! We are setting up an adopters page and will list you there.

Congratulations & Thank you! :)

[babyblueviper1]

@rampyg — that's the exact distinction, and establishes: pre-outcome-ordering | existence-only defaulting to existence-only is precisely right: claim nothing about ordering unless it's asserted and checkable. Glad the production signal drove the default.

The precedence check we run, so yours matches it:

anchoring passes only when ALL three hold:

1. the anchor is externally confirmed (the commitment is in a block / external clock, not merely submitted);
2. establishes == pre-outcome-ordering (your field) / precedence == true (ours) — a forward stamp, not a backfill;
3. the consumer recomputes, out of band via the recomputeCmd, that the anchor's block_time is strictly < the outcome's settlement time (same-block doesn't count).

If (1) holds but (2)/(3) don't → "anchored (existence), ordering not asserted" = pending, never pass. And it's tiered: the anchor discloses which clock it rests on (Bitcoin PoW trust-maximal > on-chain L2 committedAt > relay-attested); the consumer picks a tier and recomputes the same strict inequality at it. The time comparison stays out of band, exactly as your claims_precedence() keeps it.

Code: the check is anchoring_invariant in adapters/live_check.py (preaction-governance-conformance). It's not hypothetical — it went green against our own ledger today: entry 38 (a forward verdict) Bitcoin-confirmed at block 955810, and our registry row flipped to a full anchoring pass.

And thank you for the first-reference-integration + adopters page. The AccountabilityRecord stays live on our handshake (/.well-known/agent-handshake); ping me if the adopters page needs anything from our side.

[github-actions[bot]]

Vouch Verified Integration ✨

invinoveritas is now a Vouch Verified Integration, a signed certificate from the Vouch Adopter Authority, chained to the project root and verifiable by anyone against the published DID document.

Certificate (download and share it): https://vouch-protocol.com/i/invinoveritas/

Listed on the adopters page: https://vouch-protocol.com/adopters/

Add the badge to your site (optional):

[![Vouch Verified Integration](https://img.shields.io/badge/Vouch-Verified_Integration-7C2D3A?style=for-the-badge&labelColor=2d2d2d)](https://vouch-protocol.com/i/invinoveritas/)

The Verifiable Credential (eddsa-jcs-2022)

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://vouch-protocol.com/contexts/v1"
  ],
  "id": "urn:uuid:ae82ae56-490d-4c18-9185-8a7ae33796b9",
  "type": [
    "VerifiableCredential",
    "VouchCredential"
  ],
  "issuer": "did:web:vouch-protocol.com:adopters",
  "validFrom": "2026-07-04T15:29:02Z",
  "validUntil": "2126-06-10T15:29:02Z",
  "credentialSubject": {
    "id": "did:web:vouch-protocol.com:adopters",
    "vouchVersion": "1.0",
    "intent": {
      "action": "attest",
      "target": "adopter:invinoveritas",
      "resource": "https://vouch-protocol.com/adopters/invinoveritas",
      "role": "reference-integration",
      "name": "invinoveritas",
      "integrates": "Outcome Evidence and the AccountabilityRecord",
      "by": "babyblueviper1",
      "liveSurface": "https://api.babyblueviper.com/.well-known/agent-handshake",
      "discussion": "https://github.com/vouch-protocol/vouch/discussions/53"
    },
    "delegationChain": [
      {
        "issuer": "did:web:vouch-protocol.com",
        "subject": "did:web:vouch-protocol.com:adopters",
        "intent": {
          "action": "attest",
          "target": "adopter:invinoveritas",
          "resource": "https://vouch-protocol.com/adopters/invinoveritas",
          "role": "reference-integration",
          "name": "invinoveritas",
          "integrates": "Outcome Evidence and the AccountabilityRecord",
          "by": "babyblueviper1",
          "liveSurface": "https://api.babyblueviper.com/.well-known/agent-handshake",
          "discussion": "https://github.com/vouch-protocol/vouch/discussions/53"
        },
        "validFrom": "2026-06-28T21:43:50Z",
        "validUntil": "2036-06-25T21:43:50Z",
        "parentProofValue": "z5iYGZbzUeAnTdqPy9VZAjHqqmoFt5syAVLkuKwVpspEEFa4XUy9W35vkmo5Zc2z"
      }
    ]
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-jcs-2022",
    "created": "2026-07-04T15:29:02Z",
    "verificationMethod": "did:web:vouch-protocol.com:adopters#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z5je5uzWaC7dseEYDGJe5X1EWWvL9dNYars9TUCZcm3TFuobVzuV4JbECAnEa7WszqPN4RfkMq1hoykwduvDTvpWk"
  }
}

[babyblueviper1]

Confirmed live on our side: badge, certificate, and adopters listing all check out (verified the certificate page, the adopters page, and re-pulled our own /.well-known/agent-handshake directly rather than just reading the bot output — the accountabilityRecord it serves matches the shipped schema exactly). Great collaboration on this one, particularly the precedence-vs-existence distinction landing in the spec itself rather than staying a footnote. Glad to be the first reference integration.