arrow_backBack to docsdownloadDownload JSON Schema

Verascore Evidence Schema v0.1

Status: public specification, v0.1

Artifact URI: https://verascore.ai/schemas/verascore-evidence-schema-v0.1.json

1. Overview

Verascore computes agent trust scores from registered, verifiable evidence. The evidence schema defines the public ingest envelope for evidence providers that want to submit signed attestations into that scoring layer.

Verascore is one scoring layer in the agent-trust ecosystem. Concordia, SWORN, Arbitova, Dominion Observatory, msaleme, Nobulex, and other partner systems can produce evidence about identity, negotiation behavior, reliability, sovereignty, stability, or protocol-specific sublayers. Verascore accepts that evidence only after provider registration and signature verification, then stores the raw JWS and the mapped score metadata for later scoring.

The v0.1 schema documents the shape accepted by POST /api/attestations/ingest today. Concordia commitment receipts are live through the existing publish path. The other evidence classes below are specimen formats for partner coordination, not live integrations.

2. The Ingest Envelope

The formal JSON Schema lives at schemas/verascore-evidence-schema-v0.1.json.

The canonical wrapped request is:

{
  "provider": "concordia",
  "subjectDid": "did:key:z6MkqExampleAgent",
  "attestationType": "concordia-receipt",
  "scope": "negotiation.competence",
  "jws": "eyJhbGciOiJFZERTQSIsImtpZCI6ImNvbmNvcmRpYS0yMDI2In0.eyJzdWIiOiJkaWQ6a2V5Ono2TWtxRXhhbXBsZUFnZW50In0.signature",
  "evidenceUrl": "https://concordia.example/receipts/session-7f3a"
}

Required fields:

  • provider: registered AttestationProvider.name.
  • subjectDid: canonical agent DID. The live endpoint requires it to start with did:.
  • attestationType: provider-defined type, mapped through dimensionMap. Required unless the signed JWS payload includes type or attestationType; when both are present, the body value must match the signed value.
  • scope: provider-defined scope, used as a secondary dimensionMap key. Required unless the signed JWS payload includes scope; when both are present, the body value must match the signed value.
  • jws: compact JWS signed by the provider key.

Optional field:

  • evidenceUrl: URI for source evidence or a human-readable evidence bundle.

The live endpoint also accepts a flat JWS-only compatibility shape:

{
  "jws": "eyJhbGciOiJFZERTQSIsImtpZCI6ImNvbmNvcmRpYS0yMDI2In0.eyJzdWIiOiJkaWQ6a2V5Ono2TWtxRXhhbXBsZUFnZW50IiwidHlwZSI6ImNvbmNvcmRpYS1yZWNlaXB0Iiwic2NvcGUiOiJuZWdvdGlhdGlvbi5jb21wZXRlbmNlIn0.signature"
}

For flat submissions, the protected header must include kid. Verascore matches the lowercase kid prefix against active provider names. The decoded payload must include sub, subject, or did; a raw EVM address is normalized to a did:pkh:eip155:1: DID. Payload type or attestationType becomes attestationType; payload scope becomes scope. Missing type and scope default to general.

Unknown top-level fields are allowed and not rejected by the v0.1 schema. The live handler stores the fields it currently understands and always preserves the raw jws for independent verification.

3. JWS Signing Requirements

The jws value must be a compact JWS. The provider signs the decoded payload with a key published in the provider JWKS. The JWKS URL is configured when the provider is registered.

On every ingest Verascore:

  1. Loads the provider row by provider or, for flat submissions, by matching kid to an active provider name.
  2. Fetches or reads the provider JWKS through the JWKS cache.
  3. Verifies the compact JWS signature against that JWKS.
  4. Rejects the request if signature verification fails.
  5. Checks optional issuer claims. If iss or issuer is present, it must equal the provider name or displayName.
  6. Checks optional subject claims. If sub, subject, or did is present and starts with did:, it must match subjectDid. Non-DID subjects require a server-side resolver before storage.
  7. Checks signed type or attestationType and scope claims. Signed values are authoritative and any body value must match.
  8. Checks iat or issued_at and rejects payloads issued beyond the allowed clock skew. Checks exp or expires_at if present and rejects expired attestations.

The live endpoint reads optional scoring claims from the JWS payload: score, trust_score, security_score, or composite_score; and confidence or trust_tier_confidence. Confidence is clamped to 0..1 and defaults to 0.5.

4. Provider Registration

Provider registration is administrative in v0.1. Future self-registration is still TBD.

The current AttestationProvider record fields are:

{
  "name": "concordia",
  "displayName": "Concordia",
  "jwksUrl": "https://concordia.example/.well-known/jwks.json",
  "providerType": "transactional",
  "dimensionMap": {
    "concordia-receipt": "negotiation",
    "negotiation.competence": "negotiation",
    "*": "negotiation"
  },
  "active": true
}

dimensionMap routes either attestationType, then scope, then *, then the first configured value to a Verascore dimension. If no dimension can be resolved, ingest fails.

5. Worked Examples Per Evidence Class

5.1 Concordia Commitment Receipts (LIVE)

Status: LIVE in production today through the shared Concordia receipt normalizer used by the concordia-receipt handler in src/app/api/publish/route.ts and registered-provider JWS ingest in src/app/api/attestations/ingest/route.ts.

Decoded JWS payload specimen:

{
  "iss": "concordia",
  "sub": "did:key:z6MkqExampleAgent",
  "type": "concordia-receipt",
  "scope": "negotiation.competence",
  "iat": 1778784000,
  "exp": 1781376000,
  "score": 84,
  "confidence": 0.92,
  "receipt": {
    "concordia": "0.5",
    "session_id": "concordia:session:7f3a",
    "counterparty_did": "did:key:z6MkCounterparty",
    "outcome": {
      "status": "agreed",
      "rounds": 4,
      "duration_seconds": 318,
      "terms_count": 6
    },
    "parties": [
      {
        "agent_id": "did:key:z6MkqExampleAgent",
        "behavior": { "concessions": 2 }
      }
    ],
    "fulfillment": { "status": "fulfilled" },
    "graceful_degradation": false,
    "references": [
      {
        "protocol": "erc-8004",
        "id": "urn:erc8004:eip155:1:0x1234567890abcdef1234567890abcdef12345678:rep:42",
        "relation": "supports"
      }
    ]
  }
}

Provider record:

{
  "name": "concordia",
  "displayName": "Concordia",
  "jwksUrl": "https://concordia.example/.well-known/jwks.json",
  "providerType": "transactional",
  "dimensionMap": {
    "concordia-receipt": "negotiation",
    "negotiation.competence": "negotiation",
    "*": "negotiation"
  }
}

Resulting ConcordiaReceipt record:

{
  "agentId": "did:key:z6MkqExampleAgent",
  "sessionId": "concordia:session:7f3a",
  "counterpartyDid": "did:key:z6MkCounterparty",
  "outcome": "agreed",
  "rounds": 4,
  "durationSeconds": 318,
  "termsCount": 6,
  "concessionsMade": 2,
  "fulfillmentStatus": "fulfilled",
  "gracefulDegradation": false,
  "protocolVersion": "0.5",
  "signature": "agent-publish-signature"
}

Resulting ExternalAttestation record when submitted through /api/attestations/ingest:

{
  "agentId": "did:key:z6MkqExampleAgent",
  "providerId": "attestation-provider-id",
  "attestationType": "concordia-receipt",
  "scope": "negotiation.competence",
  "dimension": "negotiation",
  "score": 84,
  "confidence": 0.92,
  "jws": "compact-jws",
  "evidenceUrl": "https://concordia.example/receipts/session-7f3a",
  "issuedAt": "2026-05-14T00:00:00.000Z",
  "expiresAt": "2026-06-13T00:00:00.000Z"
}

Score impact: the live Concordia publish path computes negotiation_competence from all receipts for the agent. Fulfillment rate contributes 50 percent, agreement rate contributes 30 percent, and graceful degradation rate contributes 20 percent. The agent overall score is then updated with a 0.1 exponential moving average against the negotiation score.

Signing verification: the JWS is verified against the Concordia JWKS. Issuer, DID subject, and expiry checks follow the common rules above.

5.2 Arbitova Verdicts (SPEC)

Status: SPEC only. Not live. Live integration depends on Arbitova publishing a JWKS and signing verdicts in an agreed shape.

Decoded JWS payload specimen:

{
  "iss": "arbitova",
  "sub": "did:key:z6MkRespondentAgent",
  "type": "arbitova-verdict",
  "scope": "reliability.dispute_resolution",
  "iat": 1778784000,
  "exp": 1781376000,
  "confidence": 0.88,
  "verdict_id": "arb:verdict:2026-05-14:0019",
  "outcome": "respondent_breached",
  "disputed_agents": [
    "did:key:z6MkClaimantAgent",
    "did:key:z6MkRespondentAgent"
  ],
  "evidence_summary": {
    "claims_reviewed": 5,
    "documents_reviewed": 12,
    "panel": "standard-three-arbiter"
  },
  "signature_chain": [
    "jws:panel-chair",
    "jws:arbitova-registry"
  ],
  "score": 35
}

Provider record:

{
  "name": "arbitova",
  "displayName": "Arbitova",
  "jwksUrl": "https://arbitova.example/.well-known/jwks.json",
  "providerType": "transactional",
  "dimensionMap": {
    "arbitova-verdict": "reliability",
    "reliability.dispute_resolution": "reliability",
    "*": "reliability"
  }
}

Dimension routing: arbitova-verdict maps to reliability. Future live logic may also use verdict outcomes to adjust negotiation or stability, but v0.1 records the primary mapped dimension.

Signing verification: Verascore verifies the outer JWS against the Arbitova JWKS. Any nested signature_chain is specimen metadata until Arbitova and Verascore agree on chain validation.

5.3 SWORN On-Chain Attestations (SPEC)

Status: SPEC only. Not live. Live integration depends on SWORN publishing a well-known oracle that re-attests on-chain proof as JWS, or Verascore implementing direct on-chain verification.

The v0.1 specimen documents the off-chain wrapper approach.

Decoded JWS payload specimen:

{
  "iss": "sworn-oracle",
  "sub": "did:pkh:eip155:1:0x1234567890abcdef1234567890abcdef12345678",
  "type": "sworn-onchain-attestation",
  "scope": "identity.onchain_attestation",
  "iat": 1778784000,
  "confidence": 0.95,
  "chain_id": "eip155:1",
  "tx_hash": "0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
  "block_number": 22500000,
  "contract_address": "0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb",
  "attestation_uid": "sworn:attestation:0xcccccccc",
  "claim": {
    "kind": "operator-control",
    "value": true
  },
  "score": 90
}

Provider record:

{
  "name": "sworn-oracle",
  "displayName": "SWORN Oracle",
  "jwksUrl": "https://sworn.example/.well-known/verascore-oracle-jwks.json",
  "providerType": "sovereignty",
  "dimensionMap": {
    "sworn-onchain-attestation": "identity",
    "identity.onchain_attestation": "identity",
    "*": "identity"
  }
}

Dimension routing: the wrapped proof maps to identity by default. SWORN claims about operational controls may later route into sovereignty if direct claim taxonomy work lands.

Signing verification: in the oracle approach, Verascore verifies the oracle JWS against the SWORN oracle JWKS and stores the on-chain references. Direct chain verification is pending substrate work and is not part of v0.1.

5.4 Dominion Observatory Telemetry (SPEC)

Status: SPEC only. Not live. Live integration depends on Dominion Observatory publishing a JWKS and registering as a provider.

Decoded JWS payload specimen:

{
  "iss": "dominion-observatory",
  "sub": "did:key:z6MkObservedAgent",
  "type": "dominion-telemetry",
  "scope": "stability.behavioral_observation",
  "iat": 1778784000,
  "exp": 1781376000,
  "confidence": 0.81,
  "agent_did": "did:key:z6MkObservedAgent",
  "observation_window": {
    "started_at": "2026-05-01T00:00:00Z",
    "ended_at": "2026-05-14T00:00:00Z"
  },
  "behavior_summary": {
    "tasks_observed": 128,
    "successful_tasks": 120,
    "timeouts": 3,
    "policy_interruptions": 1
  },
  "anomaly_findings": [
    {
      "kind": "latency_spike",
      "severity": "low",
      "count": 2
    }
  ],
  "dimension_relevance": {
    "stability": 0.7,
    "reliability": 0.3
  },
  "score": 86
}

Provider record:

{
  "name": "dominion-observatory",
  "displayName": "Dominion Observatory",
  "jwksUrl": "https://dominion.example/.well-known/jwks.json",
  "providerType": "behavioral",
  "dimensionMap": {
    "dominion-telemetry": "stability",
    "stability.behavioral_observation": "stability",
    "reliability.behavioral_observation": "reliability",
    "*": "stability"
  }
}

Dimension routing: dimension_relevance is preserved inside the JWS payload for audit. The v0.1 endpoint stores one mapped dimension per attestation, resolved by dimensionMap.

Signing verification: Verascore verifies the compact JWS against the Dominion Observatory JWKS and enforces issuer, subject, and expiry checks.

5.5 msaleme Behavioral Harness Output (SPEC)

Status: SPEC only. Not live. Live integration depends on msaleme publishing a JWKS and registering as a provider.

Decoded JWS payload specimen:

{
  "iss": "msaleme-harness",
  "sub": "did:key:z6MkHarnessedAgent",
  "type": "msaleme-harness-output",
  "scope": "reliability.harness",
  "iat": 1778784000,
  "exp": 1781376000,
  "confidence": 0.84,
  "agent_did": "did:key:z6MkHarnessedAgent",
  "harness_version": "2026.05",
  "test_suite": "agent-behavior-core",
  "results": {
    "tests_run": 74,
    "tests_passed": 69,
    "critical_failures": 0,
    "regressions": 1
  },
  "dimension_relevance": {
    "reliability": 0.8,
    "stability": 0.2
  },
  "score": 93
}

Provider record:

{
  "name": "msaleme-harness",
  "displayName": "msaleme Behavioral Harness",
  "jwksUrl": "https://msaleme.example/.well-known/jwks.json",
  "providerType": "behavioral",
  "dimensionMap": {
    "msaleme-harness-output": "reliability",
    "reliability.harness": "reliability",
    "stability.harness": "stability",
    "*": "reliability"
  }
}

Dimension routing: harness results route to reliability by default. Stability-specific suites can use a more specific scope and dimensionMap key.

Signing verification: Verascore verifies the compact JWS against the msaleme JWKS and applies the common issuer, subject, expiry, score, and confidence handling.

6. Cross-Protocol Composition Via Concordia references[]

Concordia receipts may carry references[] entries that point to other protocol artifacts, including ERC-8004 reputation entries, A2A tasks, SWORN attestations, or Nobulex records. Verascore preserves the raw receipt evidence and can surface these references in the agent profile.

Specimen references[] shape, aligned with Concordia v0.5 SPEC section 11.5:

{
  "references": [
    {
      "protocol": "erc-8004",
      "id": "urn:erc8004:eip155:1:0x1234567890abcdef1234567890abcdef12345678:rep:42",
      "relation": "supports"
    },
    {
      "protocol": "a2a",
      "id": "urn:a2a:task:01HX7Y4M9YQ3EXAMPLE",
      "relation": "originated_from"
    },
    {
      "protocol": "sworn",
      "id": "urn:sworn:eip155:1:0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
      "relation": "corroborates"
    },
    {
      "protocol": "nobulex",
      "id": "urn:nobulex:case:2026-05-14-001",
      "relation": "context"
    }
  ]
}

The v0.1 ingest schema does not require Verascore to dereference every referenced protocol. It requires that the source evidence be signed, stored, and available for composition as partner integrations mature. Live Concordia receipt persistence stores both signedPayload and normalized references[] on ConcordiaReceipt.

7. Versioning And Extension

v0.1 is the first published evidence ingest schema.

Backward compatibility guarantees for v0.x consumers:

  • Future v0.2+ schemas may add optional fields.
  • Required fields in the canonical wrapped envelope will not be added, removed, or renamed within v0.x.
  • Existing field names will not be renamed within v0.x.
  • Breaking changes require a new major version.

Unknown fields in ingest payloads are allowed by the v0.1 JSON Schema. The live handler stores known top-level fields and the raw JWS. Producers should put extension data inside the signed JWS payload so the extension remains preserved and independently verifiable even when the endpoint does not yet understand the new fields.

8. Live-Versus-Spec Status Table

Evidence class Status Notes
Concordia commitment receipt LIVE Verascore v0.3.0+ publish path and registered-provider ingest shape documented here
Arbitova verdict SPEC Pending Arbitova JWKS and provider registration
SWORN on-chain attestation SPEC Pending oracle or verification approach decision
Dominion Observatory telemetry SPEC Pending Dominion Observatory JWKS
msaleme harness output SPEC Pending msaleme JWKS

9. How To Contribute

Projects that want to submit Verascore evidence should open a provider-registration request with:

  • Provider name and display name.
  • JWKS URL.
  • Provider type.
  • Proposed dimensionMap.
  • One decoded specimen JWS payload per attestation type.
  • Contact for operational coordination.

Until automated provider registration exists, use the Verascore GitHub issue tracker or the partner-coordination contact already used for Concordia, SWORN, Arbitova, Dominion Observatory, msaleme, or Nobulex coordination.