Post-merge incident: gittensory's obligations to the customer

[JSONbored]

Context

#4809's kill-switch and #4806's escalation path both cover a misbehaving, in-flight loop. Neither covers the scenario where a loop already completed and its PR already merged into a customer's live repository, and is only later discovered to be broken or harmful. #4805 (Terms of Service) itself frames the core risk explicitly: "An autonomous agent merging code into a paying customer's live repository... carries real liability exposure."

Note: the reporting-path/audit-trail engineering half of this issue has been split out into #5672 (Post-merge incident audit-trail & reporting wiring), which is now open to Gittensor contributors. This issue covers only the policy/legal question of what gittensory's obligations actually are once a report comes in.

Dependencies

Blocked on #4805 (Terms of Service & liability terms) — obligations here are part of the same liability surface.

Requirements

1. Define gittensory's obligations once an already-merged rented-loop PR is reported harmful: revert assistance, compute credit, notification, or some combination.
2. Define how this feeds back into Launch-readiness gate #4810's launch-readiness pilot criteria.
3. Out of scope: the reporting path and audit-trail record itself — see Post-merge incident audit-trail & reporting wiring #5672.

Deliverables / Acceptance Criteria

• A documented policy defining gittensory's actual obligations for a confirmed post-merge incident
• Sign-off that the policy aligns with Terms of Service & liability terms #4805's eventual Terms of Service
• The policy explicitly feeds Launch-readiness gate #4810's launch-readiness pilot criteria

Links & Resources

• Terms of Service & liability terms #4805 (Terms of Service, same liability family)
• Incident runbook for the kill-switch #4809 (the pre-merge kill-switch/runbook this is the post-merge counterpart to)
• Post-merge incident audit-trail & reporting wiring #5672 (the reporting-path/audit-trail engineering half split from this issue)

---

Part of #4778.

[linear-code]

JSO-3685

[JSONbored]

Decision: notification-only, no revert/credit obligation (Option D in the research, not A)

Flagging a label correction here for the record: this was requested as "Option A" but described as "customer accepts all liability / no refunds" — that description is actually Option D (notification-only), not A (which still commits to best-effort revert assistance). Going with what was described, not the label — if that's wrong, this is a one-line fix.

Decision: once an already-merged rented-loop PR is reported harmful, gittensory's obligation is notification only — informing the customer, no revert assistance commitment, no compute-credit refund. The customer bears responsibility for reviewing and accepting merged output, consistent with #4805's now-decided liability-cap/disclaimer-heavy direction (see that issue) and #5136's similarly minimal-obligation posture.

This is the lowest-cost, lowest-exposure end of the researched options — worth being aware the tradeoff is real: several AI-coding-agent ToS take this position, but it's the weakest fit among the options for a product where gittensory (not the customer) performed the merge, and may read as undercutting trust during an early pilot phase. Recording that tradeoff here rather than silently picking the cheapest option without noting the cost.

#5672 (the reporting-path/audit-trail engineering half) is already closed — this is the obligation-policy content that scopes what that reporting path actually needs to communicate (a notification, not a remediation offer); worth a quick check whether it already supports a notification-only flow before assuming new implementation work is needed.

Aligns with #4805 — final sign-off pending that issue's actual legal review.