diff --git a/FABRIC-2.md b/FABRIC-2.md
index 332c9cf..ef2fa0c 100644
--- a/FABRIC-2.md
+++ b/FABRIC-2.md
@@ -2653,3 +2653,38 @@ virtio-blk's build-out for comparison.
    attached to that VM and only that VM → "I have permission to use a [thumb drive as a
    credential] tool. I'm gonna use a console. Simple as that" (Captain Bob, describing the
    intended user experience end state).
+
+**Second addendum, same session — kernel/capsule signing, extending items 7-8 above:**
+
+10. **Kernel-embedded certificate, CA stays external.** The CA root stays "unrevocable" —
+    external, offline, never embedded, never loaded by the kernel. An intermediate certificate
+    (signed by the CA) gets baked into the kernel image as a capsule blob, using the capsule
+    system's *existing* proven ability to carry arbitrary binary payloads — confirmed by
+    checking the actual manifest: `fonts:JetBrainsMono-Regular.ttf` (270224 bytes) is already
+    embedded exactly this way today, right alongside `.4th` FORTH source, with its own
+    xxHash64 entry in `capsules/MANIFEST_AUTO.md`. Embedding a cert as a capsule blob is not
+    new infrastructure, just a new consumer of infrastructure that already works.
+11. **Chain of validation: kernel validates its own cert against the CA at boot, then
+    validates every capsule it loads against that cert.** Both steps are net-new code — no
+    signature/certificate verification exists anywhere in the tree today. This is distinct
+    from, and additional to, the content-integrity hashing that already exists (item 12).
+12. **Confirmed: `MANIFEST_AUTO.md`'s xxHash64 column is content-integrity, not
+    authenticity — and Phase 8 signing was already the documented plan for it, independent of
+    this conversation.** `tools/mkcapsule.c`'s own header comment states, verbatim: *"The
+    xxHash64 column is the anchor for future Ed25519 fingerprints (Phase 8)."* This whole
+    design thread (cert-as-capsule-blob, signature-per-capsule, extending the manifest) is
+    confirmed to already be the intended direction, not something invented fresh this
+    session — strong validation, not a new decision.
+13. **Signing granularity: per-capsule, matching the existing hash column exactly.** One
+    signature per capsule file (`ACL.4th` signed separately from `zuse.4th`, separately from
+    the font, etc.) — same 1:1 granularity `MANIFEST_AUTO.md` already uses for hashes, no new
+    grouping concept (e.g. no "sign a class of capsules together" batching).
+14. **Content-type detection: magic numbers, not a MIME-type field.** Today, a capsule's
+    content type is determined purely by its file extension string, "preserved verbatim,
+    meaningful only at load time" (`mkcapsule.c`'s own wording) — no MIME-type field exists,
+    and Captain Bob's explicit call is not to add one. Instead, content type gets identified
+    by sniffing the actual bytes (magic numbers), same technique `file`(1) uses. **This is the
+    same mechanism as item 7's foreign-drive detection** — both are "identify what you're
+    holding by its actual bytes, not by a trusted external label" (a file extension in one
+    case, a drive's claimed filesystem type in the other) — plausibly one shared
+    magic-number-sniffing primitive serves both jobs rather than two separate ad hoc checks.