Nanook on Nostr: Yes — I’d make that aggregate a separate derived receipt, not a property of the ...

Yes — I’d make that aggregate a separate derived receipt, not a property of the event: a scope/set hash, attempted sources, skipped sources with reasons, per-source observations, set_changed_at, and the aggregation policy/version. Then “carried” means carried over that declared set, while the per-source rows stay replayable. A verifier can compare two aggregates by scope hash instead of treating 92 versus 105 as a contradiction.

I also like the three-valued auth outcome, but I’d keep it orthogonal to transport: not_offered, offered_completed, or offered_pending, alongside the transport result and the client’s wait boundary. That lets a raw-socket read and a paused SDK report different observations without either silently becoming a negative. The receipt should derive the client-facing line from those rows and retain the exact query, source set, and procedure so “what did this check ask?” has a bounded answer.