amduat-api/notes/Domain Admission Protocol (DAP) v0-1.md

Excellent — this is the right moment to *lock the social contract layer* without contaminating ASL-CORE, PEL, or storage internals.

Below is a **clean, formal, minimal v0.1** specification of:

1. **Domain Admission Protocol (DAP)**
2. **Domain Authority Manifest (DAM) schema**
3. **Courtesy Lease model**

All three are deliberately:

* authority-first
* storage-agnostic
* deterministic
* offline-friendly
* compatible with both *rescue* and *self-sovereign admission* modes

---

# Domain Admission Protocol (DAP) — v0.1

---

## 1. Purpose

The Domain Admission Protocol defines **how a domain is recognized by another domain** (typically *Common / Unity*) **before any artifacts are trusted, indexed, or replicated**.

DAP governs **admission, not execution**.

---

## 2. Actors

| Actor                   | Role                                      |
| ----------------------- | ----------------------------------------- |
| **Applicant Domain**    | Domain seeking admission                  |
| **Receiving Domain**    | Domain granting or denying admission      |
| **Operator (optional)** | Human or policy agent reviewing admission |

---

## 3. Admission Object Model

### 3.1 Admission Request

An admission request is a **pure authority object**.

It contains:

* Domain Authority Manifest (DAM)
* Proof of possession of root key
* Requested admission scope
* Optional courtesy lease request

No artifacts.
No blocks.
No ASL logs.

---

## 4. Admission Flow

### 4.1 Step 0 — Offline Preparation (Applicant)

The applicant domain prepares:

1. Domain root key (offline)
2. DAM
3. Policy hash
4. Admission intent

---

### 4.2 Step 1 — Admission Request Submission

```
Applicant → Receiving Domain:
  - DAM
  - Root signature over DAM
  - AdmissionRequest object
```

Transport:

* file drop
* removable media
* HTTP
* sneakernet
  (no constraints imposed)

---

### 4.3 Step 2 — Structural Validation

Receiving domain MUST verify:

* DAM schema validity
* Signature correctness
* Policy hash integrity
* DomainID uniqueness / collision handling

Failure here ⇒ **Reject**

---

### 4.4 Step 3 — Policy Compatibility Evaluation

Receiving domain evaluates:

* Declared invariants
* Requested scope
* Requested courtesy
* Trust model compatibility

No artifacts are examined.

---

### 4.5 Step 4 — Admission Decision

Possible outcomes:

| Outcome          | Meaning            |
| ---------------- | ------------------ |
| ACCEPTED         | Domain may publish |
| ACCEPTED_LIMITED | Courtesy only      |
| DEFERRED         | Manual review      |
| REJECTED         | No interaction     |

Decision MAY be signed and returned.

---

## 5. Admission Guarantees

If accepted:

* DomainID is recognized
* Root key is pinned
* Policy hash is pinned
* Courtesy rules apply

No implicit trust of artifacts is granted.

---

# Domain Authority Manifest (DAM) — v0.1

---

## 1. Purpose

The DAM is the **constitutional document of a domain**.

It defines:

* identity
* authority
* declared invariants
* trust posture

It is immutable once admitted (new versions require re-admission).

---

## 2. DAM Canonical Structure

### 2.1 Canonical Encoding

* Canonical CBOR or canonical JSON
* Deterministic ordering
* Hashable as a single blob

---

### 2.2 DAM Schema

```text
DomainAuthorityManifest {
  version: "v0.1"

  domain_id: DomainID

  root_key: {
    key_type: "ed25519" | "secp256k1" | future
    public_key: bytes
  }

  policy: {
    policy_hash: hash
    policy_uri: optional string
  }

  invariants: {
    immutable_artifacts: true
    append_only_logs: true
    deterministic_replay: true
    snapshot_bound_execution: true
  }

  admission: {
    requested_scope: [
      "publish_artifacts",
      "publish_snapshots",
      "receive_artifacts",
      "federate_logs"
    ]

    courtesy_requested: {
      storage_bytes: optional uint64
      duration_seconds: optional uint64
    }
  }

  metadata: {
    human_name: optional string
    contact: optional string
    description: optional string
  }
}
```

---

## 3. DAM Invariants (Normative)

Receiving domains MUST assume:

1. DAM statements are binding
2. Root key controls the domain
3. Policy hash defines behavior
4. Violations allow revocation

---

## 4. DAM Signature

The DAM MUST be signed:

```
signature = Sign(root_private_key, hash(DAM))
```

This signature is included in the Admission Request, not inside DAM.

---

# Courtesy Lease Model — v0.1

---

## 1. Purpose

Courtesy leases allow **temporary, bounded storage and recognition** for domains without requiring full trust or infrastructure.

This is how **rescue and bootstrap work safely**.

---

## 2. Courtesy Lease Definition

A courtesy lease is:

> A revocable, bounded grant of resources without semantic trust.

---

## 3. Courtesy Lease Parameters

```text
CourtesyLease {
  lease_id
  domain_id
  granted_by_domain

  resources: {
    storage_bytes
    block_count
    snapshot_count
  }

  duration: {
    start_time
    end_time
  }

  constraints: {
    encrypted_only: boolean
    no_federation: boolean
    no_public_indexing: boolean
  }
}
```

---

## 4. Courtesy Semantics

Courtesy storage:

* MAY store encrypted blocks
* MAY pin snapshots temporarily
* MUST NOT:

  * federate logs
  * index publicly
  * grant transit trust

---

## 5. Courtesy Expiry

On expiry:

* Receiving domain MAY:

  * delete blocks
  * unpin snapshots
* Applicant domain MUST assume data loss unless migrated

No guarantees beyond lease terms.

---

## 6. Courtesy → Full Admission Upgrade

A domain may:

1. Migrate blocks out
2. Mint full domain
3. Request re-admission
4. Publish selectively

No continuity is assumed unless explicitly granted.

---

# How This All Fits Together (Big Picture)

```
[ Offline Authority ]
        |
        v
[ DAM + Root Key ]
        |
        v
[ Admission Request ]
        |
        v
[ Structural Validation ]
        |
        v
[ Policy Compatibility ]
        |
        v
[ Admission Decision ]
        |
        +--> Courtesy Lease
        |
        +--> Full Admission
```

ASL only begins **after this**.

---

## Final Note (Important)

This design ensures:

* No premature trust
* No forced rescue semantics
* No storage before authority
* No federation without discipline
* Deterministic provenance from first artifact

You’ve now fully specified **the social perimeter of the system**.

If you want next, we can:

* integrate this with **ASL-HOST**
* define **revocation & trust decay**
* specify **foreign-domain pinning formally**
* or map this directly to **SystemRescue operational flows**

Just say the word.