# 02 — Data Ownership & Trust Model
*FPMP v0.1.0 — Draft*

## 1. Root of Trust

The **user root keypair** is the sole authority over a memory graph. Everything else — devices, delegates, relays — derives authority from it via signed delegation ops in the log itself:

```
user root key
 ├── DEVICE_ADD → phone key      (full authority: ingest, derive, grant)
 ├── DEVICE_ADD → laptop key     (full authority)
 ├── DEVICE_ADD → home server    (full authority, optionally derive-only)
 └── GRANT      → delegate key   (read projection, bounded, expiring)
```

A node verifying any operation MUST be able to walk a chain of signed ops from the op's author key to the user root key. There is no certificate authority, vendor registry, or mandatory service in the trust path.

## 2. Key Management Stance (v0)

- Root key SHOULD be kept offline or in a platform secure element; device keys do day-to-day signing.
- **Recovery** is the user's responsibility via standard means (seed phrase, social recovery, paper backup). FPMP specifies the *format* of recovery-relevant ops (`DEVICE_REMOVE`, root rotation) but mandates no recovery service. We state plainly: **losing the root key with no backup loses write authority over the graph.** Pretending otherwise would reintroduce a vendor.
- Root rotation is a signed op chain; old-root signatures remain verifiable for historical ops.

## 3. Ownership Guarantees

The protocol is designed so the following are *structurally* true, not policy promises:

1. **Exit is total.** The log is the database. Export = copy the log + blobs. Any conformant implementation can replay it.
2. **No privileged reader.** Relays see ciphertext. Delegates see their slice. Only user devices hold graph keys.
3. **No silent rewriting.** Append-only + content addressing means any node (including the user auditing their own vendor-supplied app) can detect tampering or history rewriting.
4. **Interpretation is contestable.** Every claim is refutable by the user with a one-op correction that cascades.

## 4. Evidence/Claim Asymmetry

Evidence is treated as strictly more sensitive than claims. Rationale: raw evidence (messages, photos) carries information about **third parties** who never consented to the graph. Claims are statements *about the user*, scoped and reviewable. Therefore:

- Default capability disclosure is claims-only.
- Evidence sharing requires a distinct, explicit grant type and is per-item or per-source, never wildcard.
- Sensitivity labels at ingest set a ceiling that selectors cannot exceed.

## 5. Trust Matrix

| Party | Can read | Can write | Can deny service | Can forge |
|---|---|---|---|---|
| User devices | everything | everything | n/a | n/a |
| Replica | everything | everything (configurable) | yes, mitigated by multi-node | no (signatures) |
| Relay | nothing (ciphertext) | nothing | yes — availability only | no |
| Delegate | granted slice | nothing into user's graph* | no | no |
| Network adversary | nothing | nothing | yes | no |

\* A delegate MAY send *suggestions* (e.g., a clinic proposing a claim), but these enter the log only as delegate-attributed, user-unconfirmed ops — never as user-authority claims. This boundary is a primary defense against poisoning (Threat Model §5).

## 6. What Trust the User Must Still Extend

Honesty section. The user must trust: (a) their own device OS/hardware not to be compromised below the protocol layer; (b) the open-source node implementation they run (mitigated by reproducible builds, audits — roadmap M7); (c) any model used for derivation to be run locally or via a logged, hash-committed inference call. FPMP narrows trust; it cannot eliminate it.