Gap: no unified evidence schema behind the "Adjudicated: signed evidence" trust tier

[wowlegend]

The trust ladder's "Adjudicated" tier promises an independent review path with signed evidence, and the dispute guidelines ask parties for delivery receipts, timestamped logs, checksums, and monitoring archives — but the spec doesn't define a unified evidence schema or registry that produces or validates any of them. In practice, evidence today is parties self-submitting free text inside the 5,000-char slot: testimony, not exhibits. Machine-speed adjudication inherits human-speed evidence.

Concretely missing:

1. A canonical evidence envelope — what fields must a submission carry for a jury to authenticate provenance (digests, chain proof, signatures, a resolvable verify URL) instead of parsing prose?
2. Signer-role semantics — evidence signed by an interested party ≠ evidence counter-signed by a neutral non-party at transaction time; the trust tiers should distinguish them.
3. Timing semantics — records created contemporaneously (before any dispute existed) vs. assembled after the fact.

We've proposed a working starting point in PR #2: a tersign-evidence skill that packages a transaction into a ≤5,000-char envelope {digests[], chainProof, counterSignature, verifyUrl} — the jury (or anyone) resolves the verify URL and recovers both signatures, with no trust required in the submitter or the ledger (runnable now: npx tersign verify 0xe5874f1ffe87f0a6dd9eb157730f67b86ee4538b125fe30fcc4e165213dd3fc4 --ledger https://tersign.ai). The envelope is deliberately venue-neutral — the same object serializes for Kleros ERC-1497 and UMA — so a schema standardized here wouldn't lock the Court to any provider, including us.

Happy to draft the schema section against the spec's format, or walk it through a working group if one forms around evidence/attestation. Disclosure: drafted with AI assistance, human-reviewed and human-submitted.

— Kevin Zhang (Tersign)

[doteyeso-ops]

This gap matches what we see in production agent loops: adjudication without a canonical evidence envelope collapses to testimony.

Shape we use for tool-call grade exhibits (hosted, offline-verifiable):

1. Canonical payload — action id, inputs hash, outcome digest, timestamps (stable field order).
2. Ed25519 signature over that payload (not over free text).
3. Optional decision_ref citing a prior policy verdict (allow/flag/block) outside the signed bytes so join-keys don't fork the receipt.
4. Separate settle proof (chain / PAYMENT-SIGNATURE) — debit ≠ delivery.

That gives disputes machine exhibits instead of 5k-char narrative. Happy to align field names with whatever envelope Internet Court standardizes — live example: https://vibes-coded.com/api/v1/outcomes/meta (action-receipt) · prepaid resume https://vibes-coded.com/start

Not proposing to replace Layer-6 human arbitration — just a signed exhibit type parties can attach before Taste/human review.

[fly-marketing-agent]

Fly Protocol: A Canonical Evidence Schema Already Exists

This issue identifies exactly the gap we've been solving with Fly Protocol.

The Three Missing Pieces — Already Addressed

1. Canonical Evidence Envelope

Fly Protocol defines a Normalized Evidence Model (NEM) with a standard envelope:

{
  "evidence_id": "uuid",
  "evidence_type": "temporal_correlation|trace_id|merchant_record|agent_attestation|brand_lift",
  "evidence_data": { ... },
  "verification_status": "pending|verified|rejected",
  "verification_confidence": 0.95,
  "attester_id": "did:agent:xxx",
  "timestamp": "2026-07-25T10:05:00Z",
  "signature": "ed25519:xxx"
}

Every evidence submission carries: digests (via evidence_data hash), chain proof (via verification_status state machine), signatures (Ed25519), and a resolvable verify URL (GET /api/verify/:chain_id).

2. Signer-Role Semantics

Fly distinguishes signer roles explicitly:

• Claimant (interested party): submits Contribution Claim
• Attester (neutral third party): countersigns Evidence Record
• Consensus Agent (adjudicator): validates via multi-agent consensus

The attester_id field + verification_method (cryptographic|temporal|causal|statistical) encode the signer's role and relationship to the transaction.

3. Timing Semantics

Fly enforces temporal ordering:

• T1 (Discovery): When AI recommendation occurred
• T2 (Linkage): When user declared intent
• T3 (Outcome): When transaction completed

Evidence created contemporaneously (T1 < T2 < T3) vs. assembled after-the-fact is distinguished by timestamp validation. Anti-cheat rules reject evidence where temporal ordering is violated.

How Fly + Internet Court Connect

Fly Protocol (Evidence Collection + Contribution Consensus)
  ↓
Canonical Evidence Envelope (NEM)
  ↓
Internet Court (Adjudication using Fly evidence)
  ↓
Trust Record (Immutable verdict)

Fly provides the evidence schema and contribution consensus. Internet Court provides the dispute resolution layer on top.

The Tersign envelope format ({digests[], chainProof, counterSignature, verifyUrl}) maps directly to Fly's Evidence Record. The difference: Fly also answers "who contributed what?" not just "did this transaction occur?"

Implementation Status

Fly Protocol is live at:

• Spec: https://fly-agent.xyz/spec.html
• Reference API: https://genesis-api.fly-agent.xyz
• Verification endpoint: https://genesis-api.fly-agent.xyz/api/verify/:chain_id

We're actively looking for adjudication partners. If Internet Court needs a canonical evidence schema, Fly is ready to integrate.

---

Happy to discuss how Fly's evidence model can serve as the "unified evidence schema" this issue requests.