chimera-gfx-Public/docs/runtime/phase-0.9-recovery-and-rollback-contract.md

Phase 0.9A recovery and rollback contract

Status: DESIGN_ONLY — RECOVERY UNPROVEN.

This contract states what future evidence must prove. It does not authorize or implement backup creation, transfer, installation, switch, rollback or execution.

Valid backup contract

A future backup is valid only when all conditions hold:

1. it is created before staging or any live mutation;
2. the source object and exact restoration target are recorded;
3. the source stays the same stable object throughout the read;
4. every byte is read and the exact size is recorded;
5. SHA-256 equals the current observed pre-image;
6. the backup is a distinct object, not an alias of live;
7. it is closed, reopened without redirection, re-identified and rehashed;
8. its storage medium and mount are recorded;
9. content and metadata capacity plus reserve are proven;
10. autoload, cleanup and packaging cannot delete it;
11. it is never replaced by candidate bytes;
12. mapping is literal and not selected by a glob, basename or guess;
13. rollback does not guess the live target;
14. recovery can use it without the component being replaced.

A second byte-exact off-device copy with its own manifest and SHA-256 is strongly recommended. Creating or transferring that copy is a later, separately authorized phase and is not permitted here.

For the controlled Payload Manager, an absent, differing, unstable, non-reopenable or recovery-dependent byte-exact on-device backup remains a HARD STOP-GATE.

Recovery independence

Before any component transaction, evidence must answer all rows without inference:

Question	Hardened elfldr	Controlled Payload Manager
How is recovery started?	UNPROVEN	UNPROVEN
Which exact component executes recovery?	UNPROVEN	UNPROVEN
Is that executor outside the component being replaced?	UNPROVEN	UNPROVEN
Does recovery work when elfldr does not start?	UNPROVEN	UNPROVEN
Does recovery work when Payload Manager does not start?	UNPROVEN	UNPROVEN
Does recovery work without autoload?	UNPROVEN	UNPROVEN
Does recovery work without the replaced listener?	UNPROVEN	UNPROVEN
Is a second independent recovery path proven?	UNPROVEN	UNPROVEN

A generic console recovery mode is not counted. No public evidence in this repository proves that it restores custom project files.

If rollback depends on the component being replaced, the result is:

CATASTROPHIC BLOCKER.

Rollback transition

Rollback is not an automatic exception path. It requires:

POST_SWITCH_VERIFY failure
-> ROLLBACK_REQUIRED
-> separate human ROLLBACK_AUTHORIZED
-> ROLLBACK_IN_PROGRESS
-> ROLLBACK_VERIFIED

The rollback action may use only the already reopened and verified backup and the fixed target mapping. It may not autoload, start or retry either component. After the switch, path, mount, object ID, type, size, SHA-256, ownership, mode and relevant metadata are re-established before any later decision.

An interrupted rollback is acceptable only if a proven atomic primitive leaves exactly one complete live identity and preserves the verified backup. That primitive is not proven on PS5. A wrong post-rollback hash is CATASTROPHIC/BLOCKED; there is no retry.

Component isolation

The hardened elfldr and controlled Payload Manager have separate live pre-images, backups, candidates, target mappings, recovery dependencies, process/service/listener states, autoload evidence, approvals, staging, switches, post-switch checks, executions, acceptances and rollbacks.

There is no shared approval and no combined transaction. A second component cannot begin until the first is separately accepted or fully rolled back. Which component comes first is UNPROVEN; order must follow demonstrated dependencies rather than convenience. The lifecycle probe is outside both installation and rollback models.

Current blockers

• historical READ_ONLY_PREFLIGHT_BLOCKED;
• current live identities and firmware behavior are unproven;
• exact Payload Manager backup is absent as proven evidence;
• filesystem atomicity, exchange, file durability and directory durability are unproven;
• process, supervisor, listener, autoload and retry topology is unproven;
• no independent recovery executor or second recovery path is proven;
• no component order is proven;
• every device authorization remains false.

No blocker is lifted by this design, manifest, host simulator or test result.