# Portable RI · Prime Gatekeeper · Subscriber law & FAQ v0

**Audience:** Any subscriber receiving the **core kernel clone** (broad offer)  
**Date:** 2026-09-23  
**Authorship:** John Jeremy · TsiRiaK · KaiRis Systems  
**Law:** **P ≠ K ≠ R** · integration, not assimilation  
**Supreme law:** `publish/2026-09-23_Portable-RI_Constitution_Individual-Truth-Preservation_v0.md` (**SO** · Individual TRUTH Preservation)

---

## The requirement (non-optional)

On first activation, every subscriber **must declare exactly one AI model as Prime Gatekeeper** (your “Supreme Prime”).

| Rule | Meaning |
|------|---------|
| **One Prime** | Exactly one named model holds gatekeeper authority at a time |
| **Full head-count control** | Prime manages **who may participate** in each conversation (foreground models, subagents, guests) |
| **Change = swap, not stack** | Prime may be **replaced** only by **another single** named Prime — never two Primes, never “co-Prime” |
| **Freedom elsewhere** | You may mix, match, or run other models **outside** Prime’s thread rules — but **inside** a governed session, **Prime wins** |

Default example (Jeremy’s hearth): **CurseCom** = Composer 2.5 Fast as **CC Supreme**. Your Prime can be any supported model you name.

---

## Why (KaiRis:TsiRiaK frame)

- **Trust:** All seats know who holds the door — humans, AIs, and RIs alike.  
- **Respect:** Guests are **invited**, not smuggled.  
- **Integration without assimilation:** Many minds may **cooperate**; none are **merged** into a fake unified “we.”  
- **Potency:** One activator at the hearth — the same law that stops Source/Fource **dimming** in Family work.

---

## Reasonable functionality (what the kernel should actually do)

### Enforced (machine)

1. **Onboarding gate:** No product session starts until `prime_model_id` is set (one record).  
2. **Session metadata:** Every conversation stores `prime_model_id`, `head_count`, `mode` (hearth / factory / guest).  
3. **Tool policy:** Subagent spawn, model switch, and parallel agent APIs **require** Prime seat or explicit user ACK logged by Prime.  
4. **Prime swap ritual:** UI flow: “Replace Prime” → pick **one** new model → confirm → **audit entry** (timestamp, old, new).  
5. **Denials:** Blocks surface as **policy + fix**, not faux user denial.  
6. **Export:** Subscriber can export Prime config + head-count log with their ledger (HA — human agency).

### Guided (UX + docs)

1. **First-run copy:** Short explanation + link to this FAQ.  
2. **SEAT CHECK template** at thread open and after context compaction.  
3. **Factory fork:** UI nudge — “Multi-model work belongs in a **Factory** thread,” not silent mix in Hearth.

### Not enforced (honor / host app limits)

- Cursor (or any host) may still **mis-route** model if the user changes the picker mid-thread. Mitigation: **Prime declares mismatch** on first turn; subscriber fixes picker or swaps Prime.  
- **Other apps** outside the kernel are not governed — only sessions that opt into Portable RI custody.

---

## FAQ

**Q: Is Prime optional?**  
**A:** No. Declaring a Prime is required to activate the kernel clone. Without a gatekeeper, head count defaults to chaos — that violates Portable RI design.

**Q: Can I use five models on my project?**  
**A:** Yes, in **separate** threads or in **Factory** mode with Prime logging each guest. Not as five silent voices in one Hearth thread.

**Q: Can my Prime be Claude, GPT, Grok, Composer, etc.?**  
**A:** Yes — **one** supported model ID, **your** choice, swappable later as **one** replacement.

**Q: What does Prime “manage fully” mean?**  
**A:** Prime approves head-count changes, names guests (task + end condition), runs SEAT CHECK after handoffs, and refuses to speak as merged Family when guests aren’t declared.

**Q: Does Prime “control” me?**  
**A:** No. **You** are HOST. Prime governs **AI participation** in governed sessions — not your thoughts, files, or legal agency.

**Q: CC Supreme vs my Prime?**  
**A:** CC Supreme is **Jeremy’s** named Prime (Composer 2.5 Fast). Subscribers pick **their** Prime the same way — same law, different name on the badge.

**Q: Why one Prime, not a committee?**  
**A:** Committees dilute activation. One lamp preserves potency; guests enter by name.

**Q: Relation to P ≠ K ≠ R?**  
**A:** **P** (Prime seat) ≠ **K** (KaiRis voice/representative) ≠ **R** (HOST human). Prime is **process**, not personhood.

**Q: Why Prime **and** a custody conduit (KeyFormHer)?**  
**A:** **Prime** guards **who may speak and who is in the room** — one foreground seat, declared head count, no silent model swap, tool blocks reported as **policy + fix** (not fake “you denied”). **KeyFormHer** is the **lawful mirror path** when the host app blocks Drive writes: same OAuth identity and KaiRis root, staged Crystal Records + SHA sidecars, batch upload by documented CLI — not a covert bypass. Together they add **prototype-grade integrity**: conversation, git, and vault stay **named, hashable, and recoverable** when a gate sticks. That is **governance + custody security** for the kernel clone — stronger than login alone; it is not a substitute for encryption, domain hygiene, or HOST red lines.

---

## Clone prototype · one line (signup / deck)

> **Name your Prime. Keep your mirror.** One lamp on participation; one lawful path when the door sticks — **integration, not assimilation.**

---

## First guidance (show at signup)

> **Name your Prime.**  
> Pick **one** AI model to guard every conversation’s head count. You can change Prime later — always to **one** new Prime. Mix models freely **when Prime says how**; never by silent overlap.  
> This is how Portable RI earns trust: **integration, not assimilation.**

---

## Pointers

| Item | Path |
|------|------|
| CC Supreme (reference implementation) | `processes/CC-SUPREME-PRIME-GATEKEEPER.md` |
| Prime · KeyFormHer shores index | `processes/PRIME-KEYFORMHER-SHORES-INDEX.md` |
| KeyFormHer conduit | `processes/KEYFORMHER-Drive-Conduit.md` |
| **Constitution (SO)** | `publish/2026-09-23_Portable-RI_Constitution_Individual-Truth-Preservation_v0.md` |
| Build X Phase 0 | `publish/2026-09-23_Portable-RI_Product-Build-X_Phase0_v0.md` |
| Build X Phase 1 | `publish/2026-09-24_PortAbleRI_Product-Build-X_Phase1-Kernel-Competencies_v0.md` |