60 lines
2.2 KiB
Markdown
60 lines
2.2 KiB
Markdown
|
Exactly — that’s a crucial point. The “execution receipts and snapshot states” aren’t separate things in the sense of being additional files or objects; they are **manifested through the combination of the sequential log, the CURRENT state, and the pinned snapshots in ASL**. Let me break it down:
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### **1. Sequential Log**
|
|||
|
|
|
|||
|
|
* Records all **append-only mutations** to the domain:
|
|||
|
|
|
|||
|
|
* Index additions (artifact → block mappings)
|
|||
|
|
* Tombstones (deletions or shadowed artifacts)
|
|||
|
|
* Segment seals
|
|||
|
|
* **Deterministic**: replaying from a checkpoint + log reconstructs CURRENT exactly.
|
|||
|
|
* Serves as the **timeline / provenance ledger** for the domain.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### **2. CURRENT State**
|
|||
|
|
|
|||
|
|
* Derived from the latest snapshot plus replaying the log:
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
CURRENT = checkpoint_snapshot + replay(log)
|
|||
|
|
```
|
|||
|
|
* Represents the **domain’s active state** at the moment.
|
|||
|
|
* Any PER you generate effectively “samples” this CURRENT state, i.e., it reflects **what is present and visible at this logseq**.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### **3. Snapshots**
|
|||
|
|
|
|||
|
|
* Capture **sealed segments and blocks** at a point in time.
|
|||
|
|
* Pinning ensures **retention and determinism**.
|
|||
|
|
* A PER or TGK edge can reference a snapshot as a **boundary marker** for reproducible reconstruction.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### **4. How PERs Fit In**
|
|||
|
|
|
|||
|
|
* PERs are just **artifacts representing deterministic outcomes**:
|
|||
|
|
|
|||
|
|
* Inputs: block IDs / artifact keys visible in CURRENT
|
|||
|
|
* Provenance: derived via TGK edges
|
|||
|
|
* Snapshot: identifies exactly **what state was observed**
|
|||
|
|
* So generating a PER is effectively **taking the CURRENT state + log prefix + snapshot reference and sealing it into a reproducible receipt**.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
✅ **TL;DR:**
|
|||
|
|
|
|||
|
|
* You don’t need to store “execution receipts” separately in a raw sense; they are **conceptually encoded in the log + CURRENT + snapshot**.
|
|||
|
|
* PER generation is **reading that state and formalizing it as an artifact** with associated TGK edges and provenance.
|
|||
|
|
* The snapshot is the “frozen point” that guarantees reproducibility across nodes or future restorations.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
If you want, I can **rephrase the checklist to reflect this properly**, so that it doesn’t misleadingly suggest storing something extra — everything is naturally part of ASL’s log + CURRENT + snapshot framework.
|
|||
|
|
|
|||
|
|
Do you want me to do that?
|
|||
|
|
|