That sentence — **“any node can become a system”** — is actually the *right mental hook* for what you’re building. You’re just applying it at the **PEL + TGK semantic layer**, not the SystemRescue layer. That’s an important shift, and it exposes exactly the missing piece you’re feeling: **identity, authority, and certification**.

Let’s align the layers cleanly and then answer your question about **users, ownership, and whether ZFS helps**.

---

## 1. Re-anchoring “any node can become a system”

In your architecture, a **system** is *not* a machine and *not* a filesystem.
A system is:

> **A domain that can produce, seal, snapshot, and attest to deterministic artifacts and executions.**

So:

* A laptop
* A rescue USB
* A build farm node
* A CI runner
* A forensics machine

…can *all* “become a system” **if** they can:

1. Produce artifacts/PERs
2. Seal them
3. Attach provenance
4. Publish them under a domain identity

SystemRescue gives you *capability*.
PEL + TGK give you *meaning*.
What’s missing is **authority**.

---

## 2. What ZFS can and cannot do here

### What ZFS *can* help with

ZFS gives you:

* Snapshot identity (strong, immutable)
* Retention pins
* Integrity guarantees
* A natural “domain-local root of persistence”

This makes ZFS an excellent **substrate for authority anchoring**.

### What ZFS cannot do

ZFS does **not** provide:

* Users
* Identities
* Ownership semantics
* Certification
* Trust relationships

ZFS can *host* trust anchors — it cannot *define* them.

---

## 3. Users are not UNIX users (important)

If you try to map this to:

* `/etc/passwd`
* UID/GID
* POSIX permissions

You will break your own model.

In your system:

> **Users are cryptographic principals, not OS accounts.**

That’s the key.

---

## 4. The missing layer: Domain Identity & Authority (DIA)

You are missing a small but crucial layer that sits **above ASL/PEL/TGK and below federation**.

Let’s call it (name optional):

> **Domain Identity & Authority (DIA)**

This layer defines:

* Who may *assert* artifacts
* Who may *seal* snapshots
* Who may *publish* state
* Who may *certify* execution receipts

---

## 5. What a “user” actually is in your system

A **user** is:

> A keypair that is authorized to act *for a domain* under specific roles.

Not a login. Not a shell. Not a UID.

### Example roles

* `producer` — may generate artifacts
* `executor` — may emit PERs
* `publisher` — may publish snapshots
* `auditor` — may verify, not write

Roles are **semantic**, not filesystem permissions.

---

## 6. Where identity lives (and yes, ZFS helps here)

### Domain identity root (per domain)

```
/asl/domain/
├── domain.id
├── domain.pubkey
├── authorities/
│   ├── root.pub
│   ├── ci.pub
│   └── rescue.pub
├── policies/
│   └── publish.policy
└── attestations/
```

This lives:

* On ZFS
* Inside a snapshot
* Pinned
* Immutable once sealed

This is your **domain root of trust**.

---

## 7. Certification: what gets certified?

Not machines. Not users. Not files.

You certify **statements**.

Examples:

* “This snapshot represents `/home` as of logseq X”
* “This PER was executed from these inputs”
* “This artifact corresponds to this path”

These certifications are **artifacts themselves**.

That’s the big insight.

---

## 8. Execution receipt certification (PEL + TGK)

A PER becomes authoritative only when:

1. Inputs are snapshot-bound
2. Execution is deterministic
3. PER is signed by an authorized key
4. Signature is stored as an artifact
5. TGK edge links PER → signature → snapshot

This gives you:

* Non-repudiation
* Replayable verification
* Cross-domain trust

No mutable ACLs. No global PKI required.

---

## 9. Ownership is about *who can publish*

Ownership in your system is:

> The right to publish artifacts into a domain’s visible state.

That’s it.

* Anyone can *produce* internally
* Only authorized keys can *publish*
* Federation only sees *published* state

This matches your federation spec perfectly.

---

## 10. What SystemRescue becomes in this model

SystemRescue is just:

> A transient node that can temporarily act under a domain identity.

It may:

* Import a domain key (hardware token, USB)
* Produce recovery artifacts
* Emit PERs
* Publish a recovery snapshot

Then disappear.

The authority lives in the domain, not the machine.

---

## 11. Why this completes “any node can become a system”

Because now:

* A node + tools + a key = a system
* Without a key, it’s just a reader
* With a key, it can assert truth
* ZFS ensures what was asserted cannot be silently altered

That’s the closure you were missing.

---

## 12. The minimal thing you need to add (not a big system)

You do **not** need:

* LDAP
* OAuth
* POSIX ACLs
* Distributed consensus

You need:

* Domain keypairs
* Signed artifacts
* Snapshot-pinned authority state
* Simple role policies

That’s it.

---

## 13. One-sentence takeaway

> **ZFS gives you immutability; ASL gives you determinism; PEL gives you meaning; TGK gives you structure — but only cryptographic domain identity turns a node into a system.**

If you want, next we can:

* Specify a minimal **Domain Authority Manifest**
* Define the PER signature format
* Walk through “archived home directory” as a certified execution
* Show how federation validates authority without trusting nodes

This is the missing keystone — and you were already circling it.