Refine federation replay and authority specs

tier1/asl-dam-1.md

@@ -42,6 +42,7 @@ It binds domain identity to principals, roles, and a policy hash.
 * **Principal**: a cryptographic public key
 * **Role**: capability granted to a principal
 * **Policy hash**: canonical hash binding policy constraints to a domain
+* **Authority scope**: explicit actions this DAM authorizes within the domain
 
 ---
 
@@ -68,6 +69,7 @@ DomainAuthorityManifest {
     root_key     : PublicKey
     principals[] : PrincipalEntry
     policy_hash  : Hash
+    scope[]      : AuthorityScope
 }
 
 PrincipalEntry {
@@ -79,9 +81,34 @@ PrincipalEntry {
 
 The DAM is immutable once published. Rotation is performed by publishing a new DAM.
 
+### 4.1 Authority Scope
+
+The optional `scope[]` constrains what this DAM authorizes. If omitted, scope is
+assumed to include all roles defined in this document.
+
+```text
+AuthorityScope = {
+  "produce",
+  "execute",
+  "publish",
+  "federate",
+  "audit"
+}
+```
+
 ---
 
-## 5. Validation Rules (Normative)
+## 5. Admission and Pinning (Normative)
+
+Before a DAM is trusted, a receiving domain MUST:
+
+1. Admit the domain (see `ASL/DAP/1`).
+2. Pin the DAM artifact to a snapshot.
+3. Pin the DAM's `policy_hash` for that snapshot lineage.
+
+---
+
+## 6. Validation Rules (Normative)
 
 A node MUST reject any action unless:
 
@@ -90,16 +117,25 @@ A node MUST reject any action unless:
 3. The action is signed by a principal listed in the DAM.
 4. The principal has the required role.
 5. The DAM `root_key` is certified by the offline root trust chain.
+6. The action is within the DAM's declared `scope[]` (if present).
 
 ---
 
-## 6. Policy Binding
+## 7. Policy Binding
 
 The DAM `policy_hash` binds the domain to a specific policy document. If policy changes, a new DAM MUST be published and referenced by new snapshots.
 
 ---
 
-## 7. Non-Goals
+## 8. Idempotency and Rotation
+
+* Replaying the same snapshot + DAM MUST yield identical authority decisions.
+* Rotation is done by publishing a new DAM and referencing it in new snapshots.
+* Old snapshots remain valid with the DAM they reference.
+
+---
+
+## 9. Non-Goals
 
 * Encoding format
 * Key rotation workflow
@@ -107,6 +143,6 @@ The DAM `policy_hash` binds the domain to a specific policy document. If policy
 
 ---
 
-## 8. Summary
+## 10. Summary
 
 ASL/DAM/1 defines the minimal authority document for a domain, binding principals and roles to a policy hash under an offline root trust chain.

tier1/asl-dap-1.md

@@ -59,7 +59,26 @@ No artifacts, blocks, or logs are required for admission.
 
 ---
 
-## 4. Admission Flow (Normative)
+## 4. Admission Record (Normative)
+
+The receiving domain MUST persist an admission record that is snapshot-pinned:
+
+```text
+AdmissionRecord {
+  domain_id
+  dam_hash
+  policy_hash
+  admitted_scope[]
+  decision
+  decision_epoch
+}
+```
+
+The `decision_epoch` is a monotonically increasing local counter (not wall time).
+
+---
+
+## 5. Admission Flow (Normative)
 
 1. **Submission**
 
@@ -80,7 +99,7 @@ No artifacts, blocks, or logs are required for admission.
 
 ---
 
-## 5. Admission Guarantees
+## 6. Admission Guarantees
 
 If accepted:
 
@@ -92,7 +111,15 @@ Admission does not imply trust in artifacts beyond the granted scope.
 
 ---
 
-## 6. Courtesy Lease (Optional)
+## 7. Scope Enforcement (Normative)
+
+* Admission scope MUST gate federation view construction and replay admission.
+* A receiving domain MUST NOT admit state outside the granted scope.
+* Scope changes require a new admission decision and updated AdmissionRecord.
+
+---
+
+## 8. Courtesy Lease (Optional)
 
 A courtesy lease is a **bounded, revocable grant of resources** without semantic trust.
 
@@ -125,7 +152,7 @@ Courtesy storage MAY be deleted upon lease expiry. Courtesy does not grant feder
 
 ---
 
-## 7. Non-Goals
+## 9. Non-Goals
 
 * Transport format
 * PKI integration
@@ -133,6 +160,6 @@ Courtesy storage MAY be deleted upon lease expiry. Courtesy does not grant feder
 
 ---
 
-## 8. Summary
+## 10. Summary
 
 ASL/DAP/1 defines a deterministic admission process for domains, with optional courtesy leasing for rescue and bootstrap scenarios.

tier1/asl-federation-1.md

@@ -55,6 +55,7 @@ ASL/FEDERATION/1 defines the **multi-domain model** for ASL-based systems:
 | Published state      | Artifacts/snapshots visible to other domains. |
 | Federated snapshot   | Snapshot with visibility state that may be imported by other domains. |
 | Cross-domain reference | Reference to a published artifact from another domain. |
+| Federation view      | A deterministic view constructed by combining local internal state with admitted published state from other domains. |
 
 ---
 
@@ -75,6 +76,7 @@ ASL/FEDERATION/1 defines the **multi-domain model** for ASL-based systems:
    * Only published artifacts MAY be referenced by other domains.
    * Cross-domain references are read-only and immutable.
    * The consuming domain indexes imported artifacts using normal ASL index semantics.
+   * Imported entries MUST preserve origin metadata (domain identity and visibility) for deterministic replay.
 
 ---
 
@@ -83,6 +85,7 @@ ASL/FEDERATION/1 defines the **multi-domain model** for ASL-based systems:
 * Snapshot IDs are unique per domain.
 * Federated snapshot identity is `(DomainID, SnapshotID)`.
 * A federated snapshot MAY include cross-domain references only to published artifacts.
+* Replay of federated state MUST be bounded by the source domain's `{SnapshotID, LogPrefix}`.
 
 ---
 
@@ -102,17 +105,35 @@ ASL/FEDERATION/1 defines the **multi-domain model** for ASL-based systems:
 
 ---
 
-## 6. Cross-Domain Operations
+## 6. Federation View Construction
+
+To construct a federation view for a domain:
+
+1. Start with the local domain's internal + published state at `{SnapshotID, LogPrefix}`.
+2. For each admitted foreign domain, include only published state that is:
+
+   * Visible under that domain's `{SnapshotID, LogPrefix}`, and
+   * Allowed by the receiving domain's admission and policy rules.
+
+3. Apply normal ASL index shadowing and tombstone rules within each domain's log order.
+
+Federation MUST NOT bypass ASL/LOG/1 ordering or ASL/1-CORE-INDEX semantics.
+
+---
+
+## 7. Cross-Domain Operations
 
 1. **Import published artifacts**
 
    * A domain MAY import a published artifact from another domain.
    * Imported artifacts MUST be treated as immutable.
+   * Import MUST be gated by admission and policy compatibility (see `ASL/DAP/1` and `ASL/POLICY-HASH/1`).
 
 2. **Export published artifacts**
 
    * Internal artifacts MAY be promoted to published state.
    * Promotion MUST be snapshot-bound and log-ordered.
+   * Publication MUST respect the domain's policy hash and DAM roles.
 
 3. **Federation log propagation**
 
@@ -121,7 +142,7 @@ ASL/FEDERATION/1 defines the **multi-domain model** for ASL-based systems:
 
 ---
 
-## 7. Provenance and Traceability
+## 8. Provenance and Traceability
 
 * Execution receipts MAY include cross-domain inputs.
 * Provenance MUST preserve origin domain and snapshot identity.
@@ -129,7 +150,7 @@ ASL/FEDERATION/1 defines the **multi-domain model** for ASL-based systems:
 
 ---
 
-## 8. Normative Invariants
+## 9. Normative Invariants
 
 1. **Determinism:** Reconstructing CURRENT in a domain yields the same visible state given the same snapshot and log prefix.
 2. **Immutability:** Published artifacts and snapshots are immutable.
@@ -139,7 +160,7 @@ ASL/FEDERATION/1 defines the **multi-domain model** for ASL-based systems:
 
 ---
 
-## 9. Integration with Other Layers
+## 10. Integration with Other Layers
 
 | Layer              | Role in Federation |
 | ------------------ | ------------------ |
@@ -151,7 +172,7 @@ ASL/FEDERATION/1 defines the **multi-domain model** for ASL-based systems:
 
 ---
 
-## 10. Non-Goals
+## 11. Non-Goals
 
 * Transport protocols
 * Network replication
@@ -160,6 +181,6 @@ ASL/FEDERATION/1 defines the **multi-domain model** for ASL-based systems:
 
 ---
 
-## 11. Summary
+## 12. Summary
 
 ASL/FEDERATION/1 defines the semantic rules for multi-domain visibility and cross-domain reference. It keeps federation deterministic, snapshot-safe, and read-only across domain boundaries.

tier1/asl-federation-replay-1.md

@@ -21,6 +21,8 @@ Tags: [federation, replay, determinism, tgk, pel]
 
 * `ASL/SYSTEM/1` -- unified system view
 * `ENC-ASL-CORE-INDEX` -- domain metadata
+* `ASL/DAP/1` -- admission gating
+* `ASL/POLICY-HASH/1` -- policy compatibility
 
 ---
 
@@ -47,22 +49,39 @@ This document defines how artifacts, PERs, and TGK edges are propagated and repl
 
 ---
 
-## 3. Propagation Rules
+## 3. Replay Record Requirements
 
-### 3.1 Artifacts and PERs
+Each propagated record MUST be replayable without external context. Records MUST carry:
+
+* `domain_id` (source domain)
+* `record_type` (artifact, PER, TGK edge, tombstone)
+* `logseq` (source-domain ordering)
+* `snapshot_id` and `log_prefix` bounds for which the record is visible
+* Canonical identity (ArtifactKey or Canonical Edge Key)
+* Visibility metadata (internal/published, cross-domain source when applicable)
+
+Records MAY include optional integrity fields (hashes, signatures), but replay MUST
+remain deterministic without them.
+
+---
+
+## 4. Propagation Rules
+
+### 4.1 Artifacts and PERs
 
 * Artifacts and PERs are propagated with their `ArtifactKey` and `logseq`.
 * Only artifacts visible under a published snapshot MAY be propagated.
 * Duplicate ArtifactKeys MUST be de-duplicated by identity.
+* Imported entries MUST preserve origin metadata (domain identity and visibility).
 
-### 3.2 TGK Edges
+### 4.2 TGK Edges
 
 * TGK edges are propagated with their canonical edge identity and `logseq`.
 * Edge propagation MUST preserve the same snapshot/log visibility constraints as artifacts.
 
 ---
 
-## 4. Deterministic Replay Ordering
+## 5. Deterministic Replay Ordering
 
 Replay order MUST be deterministic across nodes:
 
@@ -73,14 +92,34 @@ This ordering MUST be applied identically by all receivers.
 
 ---
 
-## 5. Snapshot Bounds
+## 6. Snapshot Bounds
 
 * Replay MUST be bounded by `{SnapshotID, LogPrefix}`.
 * Records with `logseq` greater than the replay prefix MUST be ignored.
+* Replay MUST use the source domain's `{SnapshotID, LogPrefix}` as the bound for imported state.
 
 ---
 
-## 6. Conflict Handling
+## 7. Federation View Construction
+
+Receivers construct a federation view by combining:
+
+1. Local domain state at `{SnapshotID, LogPrefix}`.
+2. Admitted foreign published state bounded by the source domain's `{SnapshotID, LogPrefix}`.
+
+Admission and policy compatibility MUST be enforced before any foreign state is admitted.
+
+---
+
+## 8. Tombstones and Shadowing
+
+* Tombstones MUST be replayed in log order and apply only within their source domain.
+* A tombstone from domain A MUST NOT shadow artifacts from domain B.
+* Shadowing is resolved per-domain using ASL/LOG/1 order and ASL/1-CORE-INDEX semantics.
+
+---
+
+## 9. Conflict Handling
 
 1. **ArtifactKey collision**
 
@@ -97,7 +136,17 @@ This ordering MUST be applied identically by all receivers.
 
 ---
 
-## 7. Provenance and Audit
+## 10. Replay State and Idempotency
+
+Replay MUST be idempotent:
+
+* Re-applying the same record set MUST NOT change the resulting state.
+* Receivers SHOULD track `{domain_id, logseq}` high-water marks per peer.
+* Checkpointing MUST be aligned to `{SnapshotID, LogPrefix}` boundaries.
+
+---
+
+## 11. Provenance and Audit
 
 Receivers SHOULD maintain:
 
@@ -108,7 +157,7 @@ This supports deterministic audit and replay verification.
 
 ---
 
-## 8. Non-Goals
+## 12. Non-Goals
 
 * Transport protocol selection
 * Streaming formats
@@ -116,6 +165,6 @@ This supports deterministic audit and replay verification.
 
 ---
 
-## 9. Summary
+## 13. Summary
 
 ASL/FEDERATION-REPLAY/1 defines a deterministic replay ordering and conflict rules to ensure federation is reproducible across nodes and snapshots.

tier1/asl-ocs-1.md

@@ -70,6 +70,26 @@ AuthorityCertificate {
 
 * `domain_root`: certifies a domain root key for DAM issuance.
 * `principal`: certifies a principal key for roles under a policy hash.
+* `roles[]` MUST be empty for `domain_root` certificates.
+* `policy_hash` MUST match the DAM policy hash for the domain when used.
+
+---
+
+## 3.3 Authority Request (Normative)
+
+An authority request is a deterministic, offline-signable object:
+
+```text
+AuthorityRequest {
+    subject_type
+    subject_pubkey
+    domain_id
+    roles[]
+    policy_hash
+}
+```
+
+The offline signer MUST validate the request against the offline root trust rules before issuing a certificate.
 
 ---
 
@@ -83,7 +103,15 @@ No online checks are required after import.
 
 ---
 
-## 5. DAM Validation Chain
+## 5. Certificate Visibility and Idempotency
+
+* AuthorityCertificate artifacts MUST be visible in the snapshot that uses them.
+* Replaying the same snapshot + certificate set MUST yield identical authority results.
+* Duplicate certificates for the same subject_id MUST be rejected within a snapshot.
+
+---
+
+## 6. DAM Validation Chain
 
 A DAM is valid iff:
 
@@ -93,13 +121,13 @@ A DAM is valid iff:
 
 ---
 
-## 6. Revocation Model
+## 7. Revocation Model
 
 There is no live revocation. Revocation is performed by publishing a new DAM and new certificates, and referencing them in new snapshots.
 
 ---
 
-## 7. Federation Verification
+## 8. Federation Verification
 
 When receiving state from another domain:
 
@@ -110,6 +138,6 @@ When receiving state from another domain:
 
 ---
 
-## 8. Summary
+## 9. Summary
 
 ASL/OCS/1 defines immutable authority certificates signed by offline roots and bound to policy hashes, enabling deterministic, offline trust validation.

tier1/asl-system-1.md

@@ -23,7 +23,10 @@ Tags: [deterministic, federation, pel, tgk, index]
 * `ASL/INDEX-ACCEL/1`
 * `TGK/1` — Trace Graph Kernel semantics
 * PEL draft specs (program DAG, execution receipts)
-* Federation and domain policy drafts
+* `ASL/FEDERATION/1` — core federation semantics
+* `ASL/FEDERATION-REPLAY/1` — cross-node deterministic replay
+* `ASL/DAP/1` — domain admission
+* `ASL/POLICY-HASH/1` — policy binding
 
 ---
 
@@ -135,6 +138,9 @@ Deterministic replay across nodes MUST respect:
 Federation does not change PEL semantics. It propagates artifacts and receipts
 that were already deterministically produced.
 
+Admission and policy compatibility gate foreign state: only admitted domains and
+policy-compatible published state may be included in a federation view.
+
 ---
 
 ## 7. Index Alignment