diff --git a/FABRIC-2.md b/FABRIC-2.md
index ef2fa0c..fa25611 100644
--- a/FABRIC-2.md
+++ b/FABRIC-2.md
@@ -2688,3 +2688,52 @@ virtio-blk's build-out for comparison.
     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.
+
+**Third addendum, same session — contributor capsule directory, and sequencing:**
+
+15. **Assumption: contributors develop in QEMU, not on real hardware.** Stated as the working
+    assumption for whatever comes next in this thread, not yet acted on.
+16. **`capsules/contrib/` — fits the existing subdirectory convention, no new mechanism
+    needed just to have the directory.** Confirmed: `capsules/artemis/`, `capsules/common/`,
+    `capsules/fonts/`, `capsules/hermes/` are all real, existing subdirectories today, baked
+    with `:` as the path separator (`artemis:init.4th` in the manifest) — `contrib/` would be
+    one more of the same, structurally.
+17. **What *is* new: no provenance/trust-tier distinction exists in the capsule system at
+    all today.** Confirmed against `tools/mkcapsule.c`: every capsule that isn't Mama's own
+    bare `init.4th` gets the identical `FLAG_PRODUCTION | FLAG_EXPERIMENT` unconditionally —
+    there is no per-capsule notion of "who wrote this" or "how much do we trust it" anywhere
+    in the flag system. A contrib directory implies contributor capsules need to be treated
+    differently from core ones; that distinction has to be invented, not just enabled by a
+    folder.
+18. **Sequencing, explicit:** ACL/PKI/thumbdrive work (Sections U items 1-14) closes first,
+    then this contrib-directory/trust-tier work, then networking — "we're gonna start working
+    on networking" is explicitly the thing *after* this, not concurrent with it. Downloadable
+    capsules (as opposed to today's offline/bundled-at-build-time capsules) are named as a
+    networking-era concern, not scoped further than the name.
+
+**Spitballed, unvetted, explicitly requested as free brainstorm — none of this is decided:**
+
+- A new `FLAG_CONTRIB` bit, mechanically trivial given the flag system already exists
+  (`FLAG_PRODUCTION`/`FLAG_EXPERIMENT`/`FLAG_MAMA_INIT`) — same pattern as how bare `init.4th`
+  already gets `FLAG_MAMA_INIT` by filename match; a capsule under `contrib/` could get
+  `FLAG_CONTRIB` by path match, at `mkcapsule` build time, no new infrastructure.
+- Signature authority tiers, hanging off items 10-13's cert chain: core capsules signed by
+  the project's own intermediate cert; contrib capsules signed by a *separate* intermediate
+  (per-contributor, or one shared lower-privilege "contrib" cert) — the kernel's chain
+  validation at load time (item 11) would then know not just "is this signed" but "signed by
+  whom," and could apply different behavior accordingly (e.g. contrib capsules load but
+  default to a more restrictive ACL posture, or require an explicit accept at boot).
+  Structurally the same shape as the console/VM key-match idea (item 9) — a signature is just
+  another kind of key/lock check.
+- Block-namespace sandboxing for contrib capsules specifically. Collision risk
+  (`BLOCK_MAP.md`'s whole reason for existing) goes up sharply once third parties are writing
+  capsules — `mkcapsule` could refuse to build if a `contrib/`-path capsule claims any block
+  outside a reserved sandbox range (the existing "4000+ user-defined capsules" range,
+  `.claude/CLAUDE.md`, is already close to this shape), rather than relying on manual
+  conflict review the way core capsules do today.
+- Dev-mode relaxation tied directly to item 15's QEMU assumption: unsigned or
+  wrong-authority contrib capsules could still be allowed to load under QEMU/dev conditions
+  (so contributors can iterate without needing a minted cert for every test run) while being
+  refused unconditionally on a real bare-metal boot — i.e. signature enforcement could be
+  QEMU-vs-real-hardware conditional rather than uniformly strict everywhere, which is plausibly
+  *why* item 15's assumption was worth stating up front.