90 lines
1.9 KiB
Markdown
90 lines
1.9 KiB
Markdown
|
|
# 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.
|