Good — this can be *very small* and still complete.
Below is a **minimal, sufficient Domain Authority Manifest (DAM)** that fits your ASL / PEL / TGK / federation model **without introducing bureaucracy, PKI sprawl, or OS-level users**.

This is intentionally *boring, deterministic, snapshot-friendly, and artifact-centric*.

---

# Domain Authority Manifest (DAM)

### Minimal Specification

---

## 1. Purpose

The **Domain Authority Manifest (DAM)** defines **who may assert truth on behalf of a domain**.

It governs:

* Who can **produce** artifacts
* Who can **emit PERs**
* Who can **seal and publish snapshots**
* Who can **federate state**

It is:

* Immutable once sealed
* Snapshot-pinned
* Deterministic and replayable
* Interpreted identically across nodes

---

## 2. Location & Storage

The DAM is stored as an **ASL artifact** and referenced by snapshot.

Canonical location (logical, not filesystem-bound):

```
ArtifactKey("domain-authority-manifest")
```

Typical ZFS-backed layout:

```
/asl/domain/authority.manifest
```

The manifest itself is **content-addressed** and immutable.

---

## 3. Identity Model

### 3.1 Principals

A **principal** is a cryptographic public key.

No usernames.
No UIDs.
No machines.

```text
PrincipalID = HASH(public_key)
```

---

### 3.2 Roles (Minimal Set)

| Role       | Capability                                          |
| ---------- | --------------------------------------------------- |
| `produce`  | Create artifacts (internal only)                    |
| `execute`  | Emit PERs                                           |
| `publish`  | Publish artifacts/snapshots to domain-visible state |
| `federate` | Export published state to other domains             |
| `audit`    | Verify, but never mutate                            |

Roles are **capabilities**, not permissions.

---

## 4. Manifest Format (Minimal)

### 4.1 Logical Schema

```text
DomainAuthorityManifest {
    domain_id        : DomainID
    version          : u32
    root_key         : PublicKey
    principals[]     : PrincipalEntry
    policy_hash      : Hash
}
```

---

### 4.2 Principal Entry

```text
PrincipalEntry {
    principal_id : Hash
    public_key   : PublicKey
    roles[]      : Role
}
```

No expiry.
No rotation logic in-spec.
Rotation is done by publishing a **new manifest**.

---

## 5. Example (Canonical Text Form)

```yaml
domain_id: "example.org/build"
version: 1

root_key: ed25519:9f2c...a71b

principals:
  - principal_id: 3a91...ff02
    public_key: ed25519:3a91...ff02
    roles: [produce, execute]

  - principal_id: b822...19de
    public_key: ed25519:b822...19de
    roles: [publish, federate]

policy_hash: sha256:4e7b...c912
```

---

## 6. Root Key Semantics

The **root key**:

* May sign new DAM artifacts
* May revoke all other principals implicitly
* Is not required for day-to-day operation

Think of it as a **domain constitution**, not an admin account.

---

## 7. Policy Hash (Why it Exists)

The `policy_hash` binds:

* Snapshot publication rules
* Federation constraints
* Visibility guarantees

This allows:

* Policy documents to evolve
* Manifests to remain small
* Deterministic policy verification

If policy changes → new DAM → new snapshot.

---

## 8. Validation Rules (Normative)

A node **must reject** any action unless:

1. The DAM artifact is visible in the snapshot
2. The DAM hash matches the snapshot reference
3. The action is signed by a principal listed in DAM
4. The principal has the required role
5. The signature covers:

   * artifact/per hash
   * logseq
   * snapshot ID

---

## 9. Interaction with PEL & PERs

### PER Certification

A PER is authoritative **iff**:

```
PER.signature.principal ∈ DAM
AND role ∈ {execute}
AND snapshot_id matches
```

The PER signature is stored as an **artifact** and linked via TGK.

---

## 10. Federation Rules

A receiving domain must verify:

1. Snapshot is published
2. Publishing principal has `publish`
3. Federation principal has `federate`
4. DAM artifact is included or referenced

No trust in transport.
No trust in machines.

---

## 11. Key Rotation & Revocation (Minimal)

* Rotation = publish new DAM
* Revocation = omit key in new DAM
* Old snapshots remain valid
* New snapshots use new DAM

No CRLs.
No live checks.

---

## 12. Why This Is Enough

This manifest:

✔ Anchors authority
✔ Enables certification
✔ Preserves determinism
✔ Survives replay
✔ Works offline
✔ Scales across federation
✔ Avoids OS/user entanglement

---

## 13. One-line Summary

> **The Domain Authority Manifest defines who is allowed to say “this happened” — and makes that statement replayable, verifiable, and permanent.**

---

If you want next, we can:

* Specify **PER signature layout**
* Define **policy hash contents**
* Walk through **“home directory archived” as a certified execution**
* Add **hardware-backed keys (TPM / HSM) without changing the model**

Just say the word.