3.9 KiB
Yes — and that’s a very reasonable moment to do it. Below is a compact, structured condensation of the actual conclusions reached, stripped of detours, phrased so you can paste it into a new document or start a new thread cleanly.
ASL / PEL / Domain Model — Compact Working Summary
1. Domains (Git-like, clarified)
-
Common A normal domain. Holds its own log, index, and store. Acts as a shared “main branch”.
-
root.alice Alice’s public-facing sub-domain.
- Sub-domain of Common
- Also sub-domain of alice
- Only place Alice publishes to Common
- Has its own log/index/store
- May publish snapshot hashes to Common (existence proofs)
-
alice (private) Alice’s private working domain.
- Never visible to Common
- Contains secrets, experiments, raw data
- Artifacts move outward only by explicit copy/promote into
root.alice
Mental model:
alice (private working tree)
→ root.alice (publishable branch)
→ common (main branch)
Groups are just domains under Common with multiple authorities.
2. Logs & Indexes (key clarification)
-
There is one authoritative append-only log per domain.
-
The ASL log records index-segment events, not individual artifact bytes.
-
The index is reconstructed as:
snapshot + replay(log) -
No “second log” is needed:
- Index segments are immutable
- The log references sealed segments
- Blocks are never logged semantically
3. Blocks (demoted correctly)
-
Blocks are NOT semantic units
-
Blocks are storage-only atoms
-
Blocks:
- may contain many artifacts
- may contain one artifact
- may be regenerated
- may differ across domains
Publication never publishes blocks. Only index entries define visibility.
This avoids leaks like:
secret + recipe accidentally in same block
4. Artifacts & Storage
-
Artifacts are defined by identity (hash), not storage.
-
Storage may:
- pack artifacts
- encrypt artifacts
- discard artifacts
- recompute artifacts
-
Index entries may point to:
- stored blocks
- encrypted blocks
- virtual (recomputable) locations
Blocks never cross trust boundaries implicitly.
5. PEL (major conclusion)
There is only ONE PEL.
No meaningful split between “PEL-S” and “PEL-P”.
PEL is:
A deterministic, snapshot-bound, authority-aware derivation language that maps artifacts → artifacts.
Key points:
-
Any PEL output may be:
- stored
- cached
- discarded
- recomputed
-
Authority & provenance always apply
-
“Semantic vs physical” is store policy, not language design
6. Deduplication (important insight)
Deduplication is semantic, not block-based.
The system may track:
Artifact A
├─ derived via PEL program X
├─ derived via PEL program Y
└─ imported from domain Z
This enables:
- semantic equivalence
- alternate provenance paths
- stronger trust reasoning
Blocks follow later as optimization.
7. Publication semantics
-
Domains never “push blocks”.
-
Domains publish:
- index entries
- optional snapshot hashes
-
Common indexes
root.alicelike any other sub-domain. -
Proof-of-existence is achieved by publishing snapshot hashes, not data.
8. Mental hierarchy (final)
PEL (pure derivation)
↓
Artifacts (semantic facts)
↓
Index (visibility + truth)
↓
Store policy (encrypt / pack / discard / cache)
↓
Blocks (pure implementation detail)
One-sentence takeaway
PEL defines truth derivation, indexes define visibility, stores decide materialization, and blocks are just a packing trick.
If you want, next time we can:
- restate this as a single clean spec,
- or start fresh from “ASL vNext minimal principles”,
- or jump directly into implementation decisions without re-deriving theory.
You’re at a very solid conceptual checkpoint now.