# Renewal Reset Capability Boundary
## Status
Accepted for issue #3.
## Decision
Lifeloop models renewal as adapter capability and receipt evidence, not as a
client renewal protocol.
The adapter manifest may expose `renewal.reset.{native,wrapper_mediated,manual}`
and `renewal.continuation.{observation,payload_delivery}`. These fields answer
only whether the harness integration can prove a reset/continuation lifecycle
path and whether it can deliver opaque client facts across that boundary.
Omitting `renewal` means the adapter has not made an evaluated renewal claim;
an explicit all-`unavailable` renewal object means the adapter did evaluate the
path and found no safe reset/continuation support.
Lifeloop receipts carry reset-prepare and continuation evidence through normal
`payload_receipts` provenance. The payload body and any continuation token
semantics remain opaque to Lifeloop.
## Boundary
Lifeloop owns:
- manifest capability claims for reset and continuation delivery;
- negotiation names for renewal capabilities;
- receipt evidence for reset-prepare and post-reset continuation facts;
- failure-class mapping for unsupported, stale, manual-only, or lost-delivery
renewal paths.
Clients own:
- renewal leases;
- continuation token issuance and validation;
- thread/session binding;
- policy deciding whether renewal is allowed;
- recovery state mutation after a reset.
CCD issue https://github.com/nantobv/ccd/issues/705 can depend on this
Lifeloop capability layer without importing CCD renewal policy into Lifeloop.