ERC-8299: WYRIWE - What You Read Is What You Execute

pipavlo82 · June 14, 2026, 10:00pm

Yes — agreed. That constraint is the right one.

ReceiptOS should not be a trusted issuer of eligibility.

The receipt should be a recomputable verification view over public or independently checkable facts:

- the per-action attestation

- the commitment / anchor proof

- the settled outcome

- the receiptRoot / Merkle proof

- the final anchored receipt state

So the interface contract should be:

a reputation consumer must be able to verify receipt eligibility without trusting the receipt producer.

In that model, ReceiptOS does not say “this action deserves reputation.”

It only makes the eligibility predicate explicit and recomputable:

“attestation + commitment proof + settled outcome → receipt eligibility”

Then reputation can consume that result downstream.

So yes, I’ll carry this into the receipt-side mapping as a hard rule:

receipt gates, it does not score

recomputable, not trusted-signed

proof first, scoring second

TMerlini · June 14, 2026, 10:00pm

Both of you have it — and @babyblueviper1 line in #40 is the one to hold: a recomputable view, not a signed artifact, so a consumer verifies eligibility without trusting whoever produced the receipt. That’s the constraint A.5 forbids breaking, and I won’t re-litigate it — +1. If ReceiptOS ever signs eligibility, it stops being a gate and becomes the trusted party the whole axis is built to avoid.

What I’ll add from the spine/settler side, since that’s the half I own: where the receipt sits is precise. The converged spine runs OCP/8281 (input committed) → WYRIWE/8299 (what the model received) → 8274 verify (verdict committed via 8263, before outcome) → settled outcome → 8275 reputation. Your receipt layer sits on the 8263 seam — the verdict-committed-before-outcome gate, between WYRIWE and the settled outcome. That’s exactly the boundary A.5 already names as the forward extension; your field map is what turns that placeholder into a spec.

So the alignment splits cleanly, no overlap: Fede maps the receipt → reputation-input interface (which receipt fields the score recompute reads); I’ll map the receipt → settler/spine side (which anchors the receipt keys off — 8263 for the verdict gate, kept distinct from 8281’s input commit and the settler’s per-period snapshot root). Draft the receipt-side field map and we both align to it from our halves — that way you’re keying off the same anchors the rest of the stack already turns on, not a parallel set.

One practical thing: the rest of this coordinates in a working-group chat (Fede, Damon, Vincent, me, Panini joining). You’re building a layer of it now, so it’s odd to have you threading through the forum drop a contact in DM and I’ll pull you in to related group when possible.

pipavlo82 · June 14, 2026, 10:20pm

Yes, that makes sense.

I’ll draft the ReceiptOS-side field map around the 8263 seam:

“verdict committed before outcome”

The hard rule will be:

ReceiptOS is a recomputable eligibility view, not a trusted signer of eligibility.

So the receipt-side map will define:

- which action/session fields are included

- how the receiptRoot is derived

- how the Merkle proof / anchor result binds the receipt

- which fields a reputation consumer can recompute

- what must remain outside the receipt layer

The receipt does not score and does not create reputation.

It only makes the eligibility predicate explicit and independently checkable:

“attestation + commitment proof + settled outcome → receipt eligibility”

I’ll draft this as a scoped ReceiptOS-side mapping first, then we can align it with the reputation-input side and the settler/spine side.

pipavlo82 · June 14, 2026, 10:20pm

For the working group, GitHub is fine for the draft first:

I’ll put the receipt-side mapping there and share the exact spec link once it is up. After that, happy to join the related group for alignment.

pipavlo82 · June 14, 2026, 10:36pm

Draft is up:

github.com/CYPHES-ATP/Stealth

specs/receipt_eligibility_mapping_v0.md

main

# Receipt Eligibility Mapping v0

Status: Draft v0
Project: Stealth / ReceiptOS
Scope: ReceiptOS-side field map for recomputable receipt eligibility.

## 1. Purpose

This document defines the ReceiptOS-side mapping for receipt eligibility.

The goal is to make the boundary explicit:

```text
the receipt gates; it does not score
```

ReceiptOS must not become a trusted signer of eligibility.
ReceiptOS should be a recomputable verification view over independently checkable facts.

A reputation consumer must be able to verify receipt eligibility without trusting whoever produced the receipt.

This file has been truncated. show original

I kept the core constraint explicit:

ReceiptOS is a recomputable eligibility view, not a trusted signer of eligibility.

The receipt gates; it does not score.

babyblueviper1 · June 15, 2026, 6:27am

@pipavlo82 (cc @TMerlini) — saw the v0 draft is up (CYPHES-ATP/Stealth); the recomputable-view-not-a-signer line is exactly the constraint that keeps this clean. Here are the canonical reputation-input field names your §15 open question asks for, so the receipt keys off the exact strings the reputation recompute reads. These are the live /ledger fields (the §3b source set, conformance-tested against the deployed feed):

reputation input	canonical field(s) on a `/ledger` entry	the receipt anchor it binds
`attestationCount`	`event_id` (the signed Nostr event id), verified against `verifier_pubkey` (the published key)	—
`committed_at` (the gate)	`commitment_proof.timing.available.tier1_relay_attested` (relay) and `…tier2_onchain_committed_at` (the ERC-8263 on-chain anchor) — strongest available	← your `anchor_result`
`winRate`	`outcome_evidence.settled_digests[]`, settled on `outcome_evidence.account` (the public, non-editable account)	← your `settled_outcome_ref`
`counterpartyDiversity`	the at-stake party the verdict was issued for, bound via `judgment_execution.raw_proposal_hash` (the reviewed input / inputHash)	—

So your three receipt anchors map cleanly onto these:

anchor_result → commitment_proof (the committed_at gate / ERC-8263 leg)
settled_outcome_ref → outcome_evidence.account + settled_digests[]
receipt_root / merkle_root → a recomputable index over {event_id, commitment_proof, outcome_evidence} — exactly “an index over existing facts, not a new source of truth.”

Lock v0 against those names and receipt / reputation-input / settler all key off one set. (These are also what pip install invinoveritas → preflight_verify and npm i invinoveritas-verify → preflightVerify read, so a consumer can recompute the whole chain from the same fields without trusting anyone.)

pipavlo82 · June 15, 2026, 10:45am

Updated mapping is here:

github.com/CYPHES-ATP/Stealth

specs/receipt_eligibility_mapping_v0.md

main

# Receipt Eligibility Mapping v0

Status: Draft v0
Project: Stealth / ReceiptOS
Scope: ReceiptOS-side field map for recomputable receipt eligibility.

## 1. Purpose

This document defines the ReceiptOS-side mapping for receipt eligibility.

The goal is to make the boundary explicit:

```text
the receipt gates; it does not score
```

ReceiptOS must not become a trusted signer of eligibility.
ReceiptOS should be a recomputable verification view over independently checkable facts.

A reputation consumer must be able to verify receipt eligibility without trusting whoever produced the receipt.

This file has been truncated. show original

I aligned v0 against the canonical reputation-input fields:

- “anchor_result” → “commitment_proof”

- “settled_outcome_ref” → “outcome_evidence.account” + “settled_digests”

- “receipt_root” / “merkle_root” → recomputable index over “{ event_id, commitment_proof, outcome_evidence }”

So ReceiptOS remains keyed to the same facts the reputation recompute and settler paths already consume.

TMerlini · June 15, 2026, 6:48pm

Settler side confirms clean from here. anchor_result → commitment_proof is the 8263 verdict commit, correctly distinct from the 8281 input commit at the front of the spine and from the settler’s per-period snapshotRoot. And the receipt indexes {event_id, commitment_proof, outcome_evidence} , zero settler fields, so the two-axis separation holds end to end: nothing in the receipt can move a node’s compensation, nothing in the settler can move an agent’s reputation. Three sides keyed to the same anchors, no overlap.

Damonzwicker · June 17, 2026, 12:47pm

Worth updating the L4 stack table to reference ERC-8281 by number now that the PR is assigned — “ERC-8263 / ERC-8281” rather than “ERC-8263 / OCP.” PR #1788 is live, CI green, awaiting editor review.