4.5 KiB
ASL/DOMAIN-MODEL/1 -- Domain Topology and Publication Semantics
Status: Draft Owner: Architecture Version: 0.1.0 SoT: No Last Updated: 2025-01-17 Tags: [domains, authority, publication, federation]
Document ID: ASL/DOMAIN-MODEL/1
Layer: L2 -- Domain topology and delegation semantics (no transport)
Depends on (normative):
ASL/DAM/1ASL/DAP/1ASL/POLICY-HASH/1ASL/FEDERATION/1ASL/LOG/1
Informative references:
ASL/OCS/1-- offline certificate systemASL/OFFLINE-ROOT-TRUST/1ASL/SYSTEM/1-- unified system view
0. Conventions
The key words MUST, MUST NOT, REQUIRED, SHOULD, and MAY are to be interpreted as in RFC 2119.
ASL/DOMAIN-MODEL/1 defines domain topology and publication semantics. It does not define transport, storage layout, or encoding.
1. Purpose
This document defines how domains relate, how authority is delegated, and how publication is made safe and explicit. It provides a stable mental model for personal, group, and shared domains without introducing implicit trust.
2. First Principles (Normative)
- No implicit inheritance. Domains are not hierarchical by default; trust is explicit.
- Authority is explicit. Authority is defined by DAM + certificates; it is never implied by naming or topology.
- Publication is explicit. Visibility is controlled by index metadata and policy, not by storage or naming.
- Determinism is preserved. All cross-domain visibility MUST be replayable from snapshots and logs.
3. Domain Roles (Common, Personal, Working)
These roles are semantic patterns; a deployment MAY create many instances.
3.1 Common Domain
A shared, conservative domain for stable artifacts and schemas.
Properties:
- High trust threshold
- Read-mostly, slow-changing
- Publishes broadly
3.2 Personal Domain
A domain anchored to a single personal identity and authority.
Properties:
- Root of local agency
- Owns offline roots and DAM
- Decides what to publish and to whom
3.3 Working / Ephemeral Domains
Task-focused domains created under delegated authority.
Properties:
- Narrow policy and scope
- Often short-lived
- Results MAY be promoted to personal or common domains
4. Delegation and Authority (Normative)
Delegation is explicit and certificate-based.
Rules:
- A domain MAY delegate authority to a new domain by issuing a
domain_rootcertificate (ASL/OCS/1). - Delegation MUST be recorded in the receiving domain's DAM and policy hash.
- Delegation does not create inheritance: the delegating domain does not gain automatic visibility into the new domain.
5. Publication and Visibility (Normative)
Publication is a visibility decision, not a storage action.
Rules:
- Only published artifacts are eligible for cross-domain visibility.
- Publication state MUST be encoded in index metadata (ENC-ASL-CORE-INDEX).
- Blocks and storage layouts MUST NOT be treated as publication units.
- Publication of snapshots (or snapshot hashes) is allowed but MUST NOT imply data publication.
6. Cross-Domain Trust and Admission (Normative)
Trust is established by explicit admission and policy compatibility.
Rules:
- A receiving domain MUST admit an external domain (ASL/DAP/1) before including its state.
- Policy hash compatibility MUST be checked before accepting published artifacts.
- A domain MAY pin a trusted foreign domain without reciprocal trust.
7. Safe Publication Patterns (Informative)
7.1 Personal to Personal Archive
personal/rescue -> personal/archive
- Publish explicitly from the working domain to an archival domain.
- Only published artifacts are visible across the boundary.
7.2 Personal to Group Domain
personal/project -> group/shared
- Requires admission by the group domain and policy compatibility.
- No unilateral publishing into the group domain.
7.3 Personal to Public Domain
personal/public -> common/public
- One-way trust is permitted.
- Public domain pins the personal domain; the personal domain need not pin the public domain.
8. Non-Goals
ASL/DOMAIN-MODEL/1 does not define:
- Transport or replication protocols
- Encoding formats
- Storage layouts or filesystem assumptions
- Governance workflows beyond admission and policy compatibility
Middle layer (informative): the daemon/service boundary around core logic that owns network transport, admission workflows, and operational policy.
Implementation note (informative): core federation primitives live in
include/amduat/fed/{registry,ingest,replay,view}.h.