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.
|
||
|
||
|