amduat/tier1/asl-domain-model-1.md
2026-01-18 11:52:39 +01:00

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/1
  • ASL/DAP/1
  • ASL/POLICY-HASH/1
  • ASL/FEDERATION/1
  • ASL/LOG/1

Informative references:

  • ASL/OCS/1 -- offline certificate system
  • ASL/OFFLINE-ROOT-TRUST/1
  • ASL/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)

  1. No implicit inheritance. Domains are not hierarchical by default; trust is explicit.
  2. Authority is explicit. Authority is defined by DAM + certificates; it is never implied by naming or topology.
  3. Publication is explicit. Visibility is controlled by index metadata and policy, not by storage or naming.
  4. 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_root certificate (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.