# UVO Grounding Receipt 2.0 Specification

**Status:** DRAFT v0.1 · Phase 0
**Replaces:** Grounding Receipt v0.1 (FeedOracle current production)
**Last Updated:** 2026-04-29
**Standardization Path:** IETF RFC submission targeted Q4 2026

## Design Goals

1. **Backwards compatible** with v0.1 receipts (existing fields preserved)
2. **Provider-neutral** — no LLM-vendor-specific fields
3. **Verifiable offline** with public key (ES256K) and KG snapshot
4. **Privacy-preserving** in multi-tenant deployments (ZK-ready)
5. **Audit-grade** — sufficient evidence for DORA Art. 17 / BaFin / MiCA Art. 70

## Top-Level Structure

A Receipt 2.0 is a JSON object with twelve sections:

```
{
  receipt_version: "2.0",
  call_id: ...,                        // unchanged from v0.1
  tool: ...,                           // unchanged
  server_url: ...,                     // unchanged
  server_did: ...,                     // unchanged
  input_hash: ...,                     // unchanged
  output_hash: ...,                    // unchanged
  observed_at: ...,                    // unchanged
  verdict: ...,                        // unchanged

  // === NEW SECTIONS ===

  tier:               { ... },         // Layer 0 output
  claim_layer:        { ... },         // Layer 2 output
  evidence_layer:     { ... },         // Layer 3 output
  formal_layer:       { ... },         // Layer 4 output
  entropy_layer:      { ... },         // Layer 5 metric
  consensus_layer:    { ... },         // Layer 5 output
  gate_layer:         { ... },         // Layer 5 decision
  self_verification:  { ... },         // Layer 6 status
  governance:         { ... },         // human-in-loop info
  privacy:            { ... },         // multi-tenant fields
  validity:           { ... },         // temporal validity
  signature:          { ... }          // ES256K + Polygon anchor
}
```

## Section Details

### tier
- `tier`: T0 | T1 | T2 | T3 | T4
- `tier_confidence`: 0.0–1.0
- `activated_layers`: array
- `latency_budget_ms`, `latency_actual_ms`

### claim_layer
- `claim_graph_hash`: SHA-256 of HalluTree (Merkle root)
- `claim_count`: int
- `provenance_distribution`: {user_input, tool_result_signed, model_inference, rag_retrieval}
- `decomposer_consensus`: bool (two independent decomposers agreed)

### evidence_layer
- `evidence_bundle`: array of evidence-refs (KG entry IDs + receipts of FeedOracle MCP calls)
- `kg_snapshot_hash`: SHA-256 of KG state at verification time
- `authoritative_coverage`: { jurisdiction, indexed_through, completeness_score }
- `negative_evidence_proofs`: array (when claim is "X does not exist")
- `stale_sources_flagged`: array

### formal_layer
- `formalizable_claims`: int
- `proof_status`: VERIFIED | PROOF_FAILED | NOT_FORMALIZABLE | REPAIR_REQUIRED
- `lean_theorem_hashes`: array
- `repair_iterations`: int
- `differential_translation_match`: bool (two LLMs produced equivalent Lean translation)

### entropy_layer
- `semantic_entropy`: 0.0–1.0
- `cluster_count`: int
- `sampling_count`: int
- `auroc_calibration_ref`: hash of last calibration run

### consensus_layer
- `model_roles`: { generator, critic, evidence_judge, legal_classifier, formalizer, refuser }
- `agreement_score`: 0.0–1.0
- `dissenting_opinions_hashes`: array
- `conformal_alpha`: float (statistical guarantee level)

### gate_layer
- `decision`: PASS | REWRITE | ABSTAIN | ESCALATE | BLOCK
- `reason_codes`: array
- `policy_version`: string
- `rewrite_applied`: bool
- `rewrite_diff_hash`: SHA-256 (if rewrite occurred)

### self_verification
- `drift_status`: STABLE | WARNING | DRIFT_DETECTED
- `differential_audit_ref`: hash of last quarterly differential test
- `active_learning_id`: opaque ref to active learning pipeline entry

### governance
- `risk_tier`: low | medium | high | critical
- `escalation_status`: none | pending_review | reviewed
- `human_override`: bool
- `reviewer_id_hash`: SHA-256 of reviewer identity (privacy-preserving)

### privacy
- `tenant_id_hash`: SHA-256 of tenant identifier
- `zk_inclusion_proof_ref`: optional ZK-proof reference for Polygon-anchored inclusion
- `pii_redaction_status`: NONE | PARTIAL | FULL

### validity
- `valid_from`: ISO-8601
- `valid_until`: ISO-8601 (KG-driven; when underlying evidence expires)
- `re_validation_required_at`: ISO-8601
- `previous_receipt_hash`: chain link

### signature
- `alg`: ES256K
- `kid`: key ID
- `jwks_url`: public verification endpoint
- `sig`: signature value
- `signed_at`: timestamp
- `polygon_anchor`: { ledger, merkle_root, batch_id, tx_hash }

## Size Estimate

| Component | Size |
|---|---|
| v0.1 base fields | ~800 B |
| New sections | 4–7 KB |
| **Total Receipt 2.0** | **~5–8 KB** |

## Aggregation Strategy

Per-call Polygon anchoring is uneconomical at scale. Strategy:

- 10,000 receipts → one Merkle tree → one Polygon anchor (~$0.30 per 10k receipts)
- Individual receipts verified via ZK inclusion proof
- Daily aggregation default; configurable per tenant

## Verification API

```
GET  /receipts/jwks.json
GET  /receipts/{call_id}
GET  /receipts/{call_id}/chain
POST /receipts/verify
GET  /receipts/{call_id}/prove_inclusion       (NEW: ZK proof)
GET  /receipts/aggregate/{batch_id}            (NEW: batch verification)
```

## Open Questions for Phase 1

1. Should `formal_proof_certificate` be embedded or external-referenced?
   - Embedded: ~50 KB receipts
   - Referenced: lookup latency, but receipt stays small
2. KG snapshot hash: full KG hash or only consulted-subset hash?
3. Multi-tenant ZK-proof scheme: Halo2 vs Groth16 (perf vs setup complexity)?

## References

- IETF RFC 8785 (Canonical JSON)
- ECDSA ES256K (RFC 6979)
- Polygon mesh-economics-v1 (FeedOracle internal spec)