amduat-api/notes/asl-core-patch-block-semantics.md

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.