Skip to content

Research: override-event provenance receipts (T3) — demand-triggered design #8540

Description

@JSONbored

Problem

#8136's threat table left one threat covered by neither reproducibility nor attestation: T3 — the recorded human-override history itself being dishonest. Attestation proves computation ("this exact code ran over data with this checksum"), not data provenance ("the recorded overrides are what the humans actually decided"). Closing T3 needs provenance at event-capture time: receipts verifiable by the humans whose overrides they record (e.g. capture-time signing, countersignature, or anchoring — the design space is open). #8136 explicitly deferred this: "only worth filing if hosted customers actually demand it." This issue is the tracked home for that deferral so the gap is legible on the roadmap rather than rediscovered.

Requirements

⚠️ Demand-triggered — do not start this work on a schedule. The trigger is the first hosted tenant (or an equivalent trust requirement from the network) asking for provenance guarantees beyond attested execution. Until then this issue holds the problem statement only.

Deliverables

  • Written threat-model + mechanism recommendation (post-trigger)
  • Follow-up implementation issues filed per the recommendation (post-trigger)

Links & Resources

Boundaries

Research/design only; no implementation under this issue. Closing the parent epic does not require this issue if the trigger never fires — it can be closed not-planned with a dated rationale instead.

maintainer-only — trust-architecture research.

Metadata

Metadata

Assignees

Labels

maintainer-onlyOwner-only work — yields no Gittensor points.roadmapOn the Wave-2 agent-layer roadmap board (project 9)

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions