diff --git a/FABRIC-2.md b/FABRIC-2.md
index 918b961..4f2b5d4 100644
--- a/FABRIC-2.md
+++ b/FABRIC-2.md
@@ -2738,6 +2738,38 @@ virtio-blk's build-out for comparison.
   QEMU-vs-real-hardware conditional rather than uniformly strict everywhere, which is plausibly
   *why* item 15's assumption was worth stating up front.
 
+**Fourth addendum — user-role tiers, and the snakeoil-cert answer to Milestone 7's
+bootstrapping question, 2026-08-22:**
+
+19. **Three distinct user-role tiers, not just "core" vs. "contrib."** (a) Builder+dev —
+    builds the kernel/toolchain itself and develops capsules (Captain Bob's own role). (b)
+    Dev — uses only the FORTH SDK (`capsules/sdk.4th`) to author capsules, doesn't build the
+    kernel. (c) A user with no SDK at all — presumably runs pre-built capsules only, no
+    authoring capability. This refines the trust-tier question from item 17/spitball above:
+    it's not a single core/contrib boundary, it's at least three capability levels.
+20. **Snakeoil cert, embedded per-build — this resolves Milestone 7's open bootstrapping
+    question, at least for dev/test builds.** Every capsule and named blob gets signed with a
+    "snakeoil" cert (the standard term for a self-signed, non-production dev/test
+    certificate) that is itself embedded directly into each build — not loaded as a capsule
+    at runtime, not verified against an external CA at boot, part of the trusted build
+    process itself. This sidesteps the "how does the CA public key get into the kernel
+    without being just another unverifiable capsule" problem Milestone 7 raised, for the
+    dev/test case specifically: there's no runtime verification-against-external-root step at
+    all for snakeoil-signed content, because trust is established at build time, not boot
+    time. The real external-CA chain from Section U items 10-14 presumably still applies for
+    genuinely distributed/production builds; snakeoil is the dev/test answer, not a
+    replacement for it.
+21. **Two paths into a build, nothing else.** A capsule or named blob makes it into a build
+    only by (a) being signed with the build's own snakeoil cert, or (b) going through code
+    review and inclusion in either the build or the single source repo. This substantially
+    simplifies Milestone 8's still-open trust-tier decision (item 17's spitballed
+    directions) — "in the reviewed source repo" is itself the trust signal for
+    production-track content, rather than needing a separate signature-authority-tier scheme
+    layered on top. Worth revisiting Milestone 8's punch-list items against this before
+    picking one of the four originally-spitballed directions; at least one of them
+    (signature-authority tiers) may now be redundant with "repo inclusion already is the
+    review gate."
+
 ---
 
 ## V. Gap analysis — Artemis home-blocks/thumbdrive/PKI subsystem, 2026-08-22