amduat-api/ops/asl-rescue-operation-1.md

ASL/RESCUE-OP/1 - Rescue Operation Flow

Status: Draft Owner: Architecture Version: 0.1.0 SoT: No Last Updated: 2026-01-17 Tags: [ops, rescue, operations]

Document ID: ASL/RESCUE-OP/1 Layer: O3 - Rescue operation profile

Depends on (normative):

• ASL/RESCUE-NODE/1
• ASL/HOST/1

Informative references:

• PEL/1-CORE
• TGK/1-CORE

---

0. Conventions

The key words MUST, MUST NOT, REQUIRED, SHOULD, and MAY are to be interpreted as in RFC 2119.

---

1. Purpose and Scope

ASL/RESCUE-OP/1 defines the operational flow for personal rescue and bootstrap into a personal domain with optional courtesy storage.

---

2. Phases

2.1 Intake

• Collect legacy material and intent artifacts.
• Normalize inputs into artifacts for deterministic processing (e.g. Sedelpress).

2.2 Deterministic Processing

• Execute PEL programs over the intake snapshot.
• Generate PER receipts and optional TGK edges.

2.3 Courtesy Bootstrap (Optional)

• Store encrypted blocks in a courtesy domain (Common/Unity/Rakeroot).
• Seal segments and pin snapshots for determinism.

2.4 Personal Domain Minting

• Create a personal domain and copy sealed artifacts.
• Generate DAM and policy artifacts.
• Produce receipts that bind provenance to the new domain.

2.5 Publication (Optional)

• Publish selected artifacts to a common domain.
• Enforce policy hash and visibility rules.

---

3. Constraints

• Intake artifacts MUST be treated as untrusted until verified.
• Courtesy storage MUST enforce lease limits.
• Publication MUST be gated by admission and policy compatibility.

---

4. Outputs

A rescue operation SHOULD produce:

• PER receipts for each processing phase
• Sealed snapshots for replay
• DAM and policy artifacts for domain admission

---

5. Versioning

Backward-incompatible changes MUST bump the major version.