100 lines
3.3 KiB
Markdown
100 lines
3.3 KiB
Markdown
|
# ASL-CORE Patch: Block Semantics
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 1. Purpose
|
|||
|
|
|
|||
|
|
Introduce **blocks** into the ASL-CORE semantic model to provide a minimal foundation for:
|
|||
|
|
|
|||
|
|
* Artifact → block → bytes mapping
|
|||
|
|
* Immutability guarantees
|
|||
|
|
* Snapshot-safe references
|
|||
|
|
|
|||
|
|
The patch is **minimal**, leaving lifecycle, sealing, retention, and GC to ASL-STORE-INDEX.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 2. New Core Concepts
|
|||
|
|
|
|||
|
|
### 2.1 Block
|
|||
|
|
|
|||
|
|
* **Definition:** A block is an **atomic, immutable storage unit** containing a sequence of bytes.
|
|||
|
|
* **Identifier:** `BlockID` — opaque and unique across the system.
|
|||
|
|
* **Properties:**
|
|||
|
|
|
|||
|
|
1. Contents are immutable once created (semantic guarantee).
|
|||
|
|
2. Blocks can be referenced by one or more artifacts.
|
|||
|
|
3. Blocks are existential; their layout, size, and packing are **implementation concerns**.
|
|||
|
|
* **Notation:** `(BlockID, offset, length)` denotes a **byte slice** within a block.
|
|||
|
|
|
|||
|
|
* Offset and length must refer to bytes **inside the block**.
|
|||
|
|
* Semantic operations may reference these slices but **cannot modify them**.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### 2.2 Artifact and Block Relationship
|
|||
|
|
|
|||
|
|
* Each **Artifact** in ASL-CORE can be fully or partially contained in one or more blocks.
|
|||
|
|
* Semantic mapping:
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
ArtifactKey → {ArtifactLocation1, ArtifactLocation2, ...}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
Where each `ArtifactLocation` is:
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
ArtifactLocation = (BlockID, offset, length)
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
* Guarantees:
|
|||
|
|
|
|||
|
|
1. **Determinism:** Given the same ArtifactKey, the locations are always the same at the same snapshot.
|
|||
|
|
2. **Immutability:** The bytes addressed by ArtifactLocation never change.
|
|||
|
|
3. **Snapshot consistency:** If an artifact is referenced by a snapshot, the bytes remain valid for the lifetime of that snapshot.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### 2.3 Block Visibility and Referencing
|
|||
|
|
|
|||
|
|
* **Blocks themselves** are not directly visible in ASL-CORE; they exist as **supporting storage units for artifacts**.
|
|||
|
|
* **ArtifactKey references** to blocks must only point to **immutable bytes**.
|
|||
|
|
* Operations on artifacts **cannot modify or relocate block bytes**; only new artifacts can be created referencing blocks.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### 2.4 Minimal Invariants
|
|||
|
|
|
|||
|
|
1. **Block Immutability:** Once a block exists semantically, its bytes never change.
|
|||
|
|
2. **Artifact Integrity:** ArtifactKey → ArtifactLocation mapping is stable and deterministic.
|
|||
|
|
3. **Existence:** A referenced BlockID must exist in the system at the semantic level (physical existence is store-level concern).
|
|||
|
|
4. **Slice Validity:** `(offset, length)` is always within the bounds of the block.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### 2.5 Non-Goals of ASL-CORE Regarding Blocks
|
|||
|
|
|
|||
|
|
* **Sealing mechanics** – handled by ASL-STORE-INDEX
|
|||
|
|
* **Retention / GC** – handled by ASL-STORE-INDEX
|
|||
|
|
* **Snapshot pinning or lifecycle events** – store concern
|
|||
|
|
* **Size class, packing, or performance optimizations** – store concern
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 3. Summary
|
|||
|
|
|
|||
|
|
This patch introduces:
|
|||
|
|
|
|||
|
|
* **BlockID**: opaque, unique identifier
|
|||
|
|
* **Blocks**: immutable byte sequences, existential atoms
|
|||
|
|
* **ArtifactLocation**: `(BlockID, offset, length)` primitive to map artifacts to blocks
|
|||
|
|
|
|||
|
|
It **does not define storage, GC, or lifecycle mechanics**, leaving these to ASL-STORE-INDEX.
|
|||
|
|
|
|||
|
|
**Semantic impact:**
|
|||
|
|
|
|||
|
|
* Artifacts can now reference storage in a stable, deterministic, and immutable way.
|
|||
|
|
* Higher layers (index, store, encoding) can build on blocks for deterministic persistence, snapshot safety, and replay without modifying ASL-CORE semantics.
|
|||
|
|
|
|||
|
|
|