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

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

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.