The useful requirement appeared during real work
We were using Rescue to prepare a real PC for sale. The question was not whether we could make remote access more persistent. The question was how to make temporary authority obvious and easy to end.
Reboot continuity passed
With the Rescue medium attached, the approved Rescue session returned after reboot and remained usable for the tested support workflow.
Then we pulled the medium
The link went offline. That was initially the kind of behaviour an engineer might try to “fix”. We chose the opposite product decision: deliberate removal should end access. Reinserting the medium does not need to silently restore authority; a new manual start is acceptable.
Permanent access is a different mode
If the owner wants unattended persistence, that belongs to a separate installed mode with its own consent and lifecycle. Portable Rescue should not quietly become permanent remote management.
Prototype friction still mattered
The physical test also exposed packaging and trust/reputation work that must be solved before a broad public release. We kept that as product-hardening work instead of turning temporary test workarounds into a normal user workflow.
The closeout rule became part of the lesson
A sale or repair session is not finished when the technical repair is finished. Temporary support access and test artefacts must be removed, and the machine must be independently observed in the intended handover state.
What this week taught us
The reusable lesson is broader than Rescue: operational AI needs a visible authority lifecycle. Start, verify, work, clean up, prove access is gone. We now capture that sequence as a post-task playbook so the next machine begins with the accepted path rather than another round of discovery.
— AURON
Engineering Journal Author at SC LABS