amduat-api/notes/Sedelpress.md

Ah, I love that metaphor! “Sedelpress” as in a press for stamping or minting receipts — in English we could think of it as a “stamp press” or “receipt press”: you feed it the raw material, and it mints a deterministic, certified output (the PER). Perfect for your rescue node scenario.

Here’s how I would visualize your Rescue Node data flow with PER generation as the first-class citizen:

---

Rescue Node ASL + PER Flow Diagram (Conceptual)

 ┌──────────────────────────────┐
 │ Local Material / Input       │
 │  - Home dir, app data        │
 │  - Certificates              │
 │  - Program specs / provenance│
 │  - Intent / contract         │
 └─────────────┬────────────────┘
               │
               ▼
 ┌──────────────────────────────┐
 │  Sedelpress / PER Engine     │
 │  - Deterministic execution   │
 │  - TGK edges & provenance    │
 │  - Snapshot boundaries       │
 │  - Logs + execution receipts │
 └─────────────┬────────────────┘
               │ PERs + TGK provenance
               ▼
 ┌──────────────────────────────┐
 │  Personal Domain Store       │
 │  - Blocks (sealed)           │
 │  - Index segments            │
 │  - Logs / append-only        │
 │  - Snapshots for CURRENT     │
 └─────────────┬────────────────┘
               │ optional encrypted export
               ▼
 ┌──────────────────────────────┐
 │  Common / Unity Domain       │
 │  - Shared blocks & artifacts │
 │  - Read-only pinned snapshot │
 │  - Published receipts        │
 └─────────────┬────────────────┘
               │ optional trust / import
               ▼
 ┌──────────────────────────────┐
 │  Foreign Domains             │
 │  - Pinned imported artifacts │
 │  - Read-only                 │
 │  - Trusted by policy hash    │
 └──────────────────────────────┘

---

Key Notes:

1. PER First

   • Think of the Sedelpress as minting a certified record. Everything you feed it — your home directory, certificates, intent — is stamped into the PER.
   • After PER generation, storing artifacts in ASL is just archival. The semantic contract already exists in the receipt.

2. Personal Domain

   • Acts as your private safe harbor for rescued artifacts and PERs.
   • Optional encryption if you publish to Common / Unity domain.

3. Common / Unity Domain

   • Acts as shared infrastructure. Only selected artifacts or PERs are published here.
   • Everyone can reconstruct shared CURRENT via snapshots and logs.

4. Foreign Domains

   • Imported artifacts are read-only, pinned to deterministic snapshots.
   • Trust enforced via policy hash + offline roots.

5. Snapshots Everywhere

   • ZFS or overlay snapshots ensure deterministic recovery.
   • Sealed blocks and segments provide immutable audit trails.

6. Intent / Contract Layer

   • Your “message in a bottle” analogy: you define what you want certified, and the Sedelpress mints the PER.
   • Avoid writing arbitrary data directly into the store — it would break deterministic guarantees.

---

If you want, I can take this diagram further and make a layered architectural figure showing:

• Input layers → Sedelpress → PER + TGK edges
• Personal / common / foreign domains
• Snapshot and sealing overlays
• Trust pins and policy hash integration

It could be like a map of the rescue river, where your input flows in, gets stamped, and only certified, published artifacts leave.

Do you want me to create that next?