2026-01-17 09:21:47 +01:00
|
|
|
# ASL/RESCUE-NODE/1 - Deployment Profile
|
|
|
|
|
|
|
|
|
|
Status: Draft
|
|
|
|
|
Owner: Architecture
|
|
|
|
|
Version: 0.1.0
|
|
|
|
|
SoT: No
|
|
|
|
|
Last Updated: 2026-01-17
|
|
|
|
|
Tags: [ops, rescue, deployment]
|
|
|
|
|
|
|
|
|
|
**Document ID:** `ASL/RESCUE-NODE/1`
|
|
|
|
|
**Layer:** O3 - Rescue node deployment
|
|
|
|
|
|
|
|
|
|
**Depends on (normative):**
|
|
|
|
|
|
|
|
|
|
* `ASL/HOST/1`
|
|
|
|
|
* `ASL/1-STORE`
|
|
|
|
|
* `ASL/LOG/1`
|
|
|
|
|
|
|
|
|
|
**Informative references:**
|
|
|
|
|
|
|
|
|
|
* `ASL/AUTH-HOST/1`
|
|
|
|
|
* `ASL/SYSTEMRESCUE-OVERLAY/1`
|
|
|
|
|
* `ASL/RESCUE-OP/1`
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
## 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-NODE/1 defines the deployment profile for a rescue node that boots
|
|
|
|
|
from a minimal OS and provides local intake into ASL stores.
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
## 2. Node Roles
|
|
|
|
|
|
|
|
|
|
A rescue node MAY host:
|
|
|
|
|
|
|
|
|
|
* A personal domain (new or existing)
|
|
|
|
|
* A courtesy or common domain (shared, e.g. Common/Unity/Rakeroot)
|
|
|
|
|
* Optional read-only caches for foreign domains
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
## 3. Domain Types
|
|
|
|
|
|
|
|
|
|
* **Personal domain** - private, authoritative store
|
|
|
|
|
* **Courtesy domain** - temporary storage with lease enforcement, may store
|
|
|
|
|
encrypted blocks during bootstrap
|
|
|
|
|
* **Foreign domain** - read-only imported artifacts
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
## 4. Storage Layout (Informative)
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
/mnt/rescue/
|
|
|
|
|
personal/
|
|
|
|
|
blocks/
|
|
|
|
|
segments/
|
|
|
|
|
logs/
|
|
|
|
|
common/
|
|
|
|
|
blocks/
|
|
|
|
|
segments/
|
|
|
|
|
logs/
|
|
|
|
|
foreign/
|
|
|
|
|
<domain-id>/
|
|
|
|
|
blocks/
|
|
|
|
|
segments/
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
## 5. Snapshot Strategy
|
|
|
|
|
|
|
|
|
|
* Personal domain snapshots SHOULD be created at intake boundaries.
|
|
|
|
|
* Courtesy domain snapshots SHOULD be pinned until admission is complete.
|
|
|
|
|
* Foreign domain snapshots MUST be read-only and pinned by trust.
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
## 6. Trust and Admission
|
|
|
|
|
|
|
|
|
|
* Admission decisions MUST be verified before publishing to shared domains.
|
|
|
|
|
* Foreign artifacts MUST be pinned by policy hash and offline roots.
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
## 7. PER and TGK Integration
|
|
|
|
|
|
|
|
|
|
Rescue nodes SHOULD generate PER receipts for intake operations. TGK edges
|
|
|
|
|
MAY be produced to capture provenance across personal and common domains.
|
|
|
|
|
|
|
|
|
|
Sedelpress (or equivalent deterministic tooling) MAY be used to normalize
|
|
|
|
|
legacy inputs into artifacts before storage.
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
2026-01-17 10:33:23 +01:00
|
|
|
## 8. Remote Intake Transport (Informative)
|
|
|
|
|
|
|
|
|
|
When intake is performed over a network boundary, the rescue node MAY use:
|
|
|
|
|
|
|
|
|
|
* SSH socket forwarding for secure UNIX-socket transport.
|
|
|
|
|
* `socat` as a local bridge between TCP and UNIX sockets.
|
|
|
|
|
* 9P or SSHFS for remote filesystem access when appropriate.
|
|
|
|
|
|
|
|
|
|
All remote transports MUST be treated as untrusted until artifacts are sealed
|
|
|
|
|
and verified locally.
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
## 9. Versioning
|
2026-01-17 09:21:47 +01:00
|
|
|
|
|
|
|
|
Backward-incompatible changes MUST bump the major version.
|
