diff --git a/ARCHITECTURE.md b/ARCHITECTURE.md
index 7ff26b4ef74..34f2afa2d5a 100644
--- a/ARCHITECTURE.md
+++ b/ARCHITECTURE.md
@@ -504,6 +504,8 @@ shape is an explicit transition, not a flag day:
   never spans communities. Serving leases use the same application admission.
   Startup and deletion catalog validation tolerate the universal fence objects
   being absent; inventories still record live fences for older executors.
+  Desired-state bootstraps install only explicitly declared legacy fences.
+  New tenant-owned tables rely on application admission, without a fence trigger.
 - **Replica floor (transition foundation):** runtime now provides a shared
   replica-floor lock helper for compliant channel-event writers, and the writer
   probe handshake takes the exclusive counterpart before sampling `S`, scanning
diff --git a/crates/buzz-db/src/runtime/migration.rs b/crates/buzz-db/src/runtime/migration.rs
index af877332529..66cc1092d5d 100644
--- a/crates/buzz-db/src/runtime/migration.rs
+++ b/crates/buzz-db/src/runtime/migration.rs
@@ -14,6 +14,10 @@ use crate::Result;
 
 static MIGRATOR: sqlx::migrate::Migrator = sqlx::migrate!("../../migrations");
 
+#[cfg(test)]
+#[path = "tests/schema_fence_bootstrap_postgres_tests.rs"]
+mod schema_fence_bootstrap_postgres_tests;
+
 /// Run all pending Buzz database migrations.
 ///
 /// The entire run holds the exclusive [`SCHEMA_DESTRUCTION_LOCK_KEY`] session
diff --git a/crates/buzz-db/src/runtime/tests/schema_fence_bootstrap_postgres_tests.rs b/crates/buzz-db/src/runtime/tests/schema_fence_bootstrap_postgres_tests.rs
new file mode 100644
index 00000000000..67eb9a9a990
--- /dev/null
+++ b/crates/buzz-db/src/runtime/tests/schema_fence_bootstrap_postgres_tests.rs
@@ -0,0 +1,39 @@
+use sqlx::PgPool;
+
+/// A fresh bootstrap keeps the declared backstops but never discovers new
+/// community tables and silently attaches a trigger to them.
+#[tokio::test]
+#[ignore = "requires Postgres"]
+async fn migration_schema_bootstrap_keeps_only_explicit_legacy_fences() {
+    let pool = PgPool::connect(&crate::test_support::database_url())
+        .await
+        .unwrap();
+    sqlx::raw_sql("CREATE TABLE new_tenant_probe (community_id UUID NOT NULL)")
+        .execute(&pool)
+        .await
+        .unwrap();
+    // Only checked-in schema files contribute SQL to this test bootstrap.
+    sqlx::raw_sql(sqlx::AssertSqlSafe(
+        crate::test_support::desired_state_schema_sql(),
+    ))
+    .execute(&pool)
+    .await
+    .unwrap();
+
+    for (table, expected) in [
+        ("new_tenant_probe", false),
+        ("events", true),
+        ("users", true),
+    ] {
+        let fenced: bool = sqlx::query_scalar(
+            "SELECT EXISTS (SELECT 1 FROM pg_trigger \
+             WHERE tgrelid = $1::regclass \
+               AND tgfoid = 'enforce_community_write_fence()'::regprocedure)",
+        )
+        .bind(table)
+        .fetch_one(&pool)
+        .await
+        .unwrap();
+        assert_eq!(fenced, expected, "unexpected fence on {table}");
+    }
+}
diff --git a/docs/database.md b/docs/database.md
index 78ad9486dd4..0a3c9b58e70 100644
--- a/docs/database.md
+++ b/docs/database.md
@@ -100,7 +100,7 @@ writer of a fenced table already goes through admission. The remaining
 fence-retirement work drops the fence triggers and functions, and MUST also
 update ARCHITECTURE.md § *Dual enforcement*.
 
-**Today this blocks new tenant-owned tables.** Startup and deletion validation
+**New tenant-owned tables use application admission.** Startup and deletion validation
 no longer require a fence on any table; they pass with every universal fence
 object dropped (`migration_schema_fence_objects_are_optional_for_serving_and_deletion`
 in `crates/buzz-db/src/store/deletion.rs`). Two things still matter:
@@ -110,21 +110,19 @@ in `crates/buzz-db/src/store/deletion.rs`). Two things still matter:
   (`community deletion catalog drift (missing=…, unknown=…)`), and deletion
   fails closed for every community, not only the new table's. Listing the
   table is enough to pass.
-- Desired-state bootstraps run `schema/community_write_fence.sql`, which
-  attaches a fence trigger to every `community_id` table not excluded by
-  `community_write_fence_excluded_table`. A fresh desired-state database would
-  put a trigger on the new table and a migrated one would not, so the two
-  schema paths would diverge.
-
-So before a feature can add a tenant-owned `community_id` table, the
-desired-state bootstrap must stop attaching fence triggers. That change belongs
-to the fence-retirement work. Land it before the feature, or as the feature's
-first PR. Do not work around it with a trigger, or with an entry in
+- Desired-state bootstraps install only the legacy fences explicitly listed
+  under `schema/triggers/`. They do not discover and fence new tables.
+  Keep those existing backstops until their own retirement is verified;
+  new tables receive no fence in either schema path.
+
+The blanket desired-state fence attachment has been removed. A feature may
+add a tenant-owned `community_id` table when it follows the checklist below.
+Do not add a trigger, or an entry in
 `community_write_fence_excluded_table` for a table the community owns.
 
 #### Checklist: adding a tenant-owned `community_id` table
 
-After the desired-state change above has landed, all in the same PR:
+All in the same PR:
 
 - [ ] Every writer of the table goes through community admission
       (`begin_community_write_transaction` or another constructor that returns
diff --git a/schema/community_write_fence.sql b/schema/community_write_fence.sql
deleted file mode 100644
index 2ebc9fd1f98..00000000000
--- a/schema/community_write_fence.sql
+++ /dev/null
@@ -1,31 +0,0 @@
--- Attach the universal fence to every existing table carrying community_id,
--- including deployment-private sidecars whose community_id is provenance.
---
--- Desired-state schema application does not replay migration history, so the
--- explicit `SELECT attach_community_write_fence('<table>')` calls in
--- `triggers/<table>.sql` stay as first-class catalog declarations. They also
--- make the fence contract visible to migration linting instead of hiding it
--- only in this dynamic bootstrap loop. This loop runs last, so it fences every
--- desired-state table regardless: a fenced desired state does not prove the
--- migration path attaches the fence. Keep the explicit calls.
-DO $$
-DECLARE
-    target REGCLASS;
-BEGIN
-    FOR target IN
-        SELECT c.oid::REGCLASS
-          FROM pg_class c
-          JOIN pg_namespace n ON n.oid = c.relnamespace
-          JOIN pg_attribute a ON a.attrelid = c.oid
-         WHERE n.nspname = current_schema()
-           AND c.relkind IN ('r', 'p')
-           AND NOT c.relispartition
-           AND a.attname = 'community_id'
-           AND NOT a.attisdropped
-           AND NOT community_write_fence_excluded_table(c.relname)
-         ORDER BY c.oid::REGCLASS::TEXT
-    LOOP
-        PERFORM attach_community_write_fence(target);
-    END LOOP;
-END
-$$;
diff --git a/schema/schema.sql b/schema/schema.sql
index d252cbdb7ea..68f09de3262 100644
--- a/schema/schema.sql
+++ b/schema/schema.sql
@@ -7,9 +7,9 @@
 --
 -- Everything SchemaBot cannot apply lives in this directory's other
 -- subdirectories: `types/`, `functions/`, `partitions/`, `triggers/` (including
--- write-fence attachment), `seeds/`, and the `community_write_fence.sql`
--- bootstrap. This file composes all of them into one fresh database, in load
--- order: types → functions → tables → partitions → triggers → seeds → fence.
+-- explicit legacy write-fence attachment), and `seeds/`. This file composes
+-- them into one fresh database, in load order:
+-- types → functions → tables → partitions → triggers → seeds.
 --
 -- `./bin/pgschema apply --file schema/schema.sql` resolves the `\i` includes
 -- relative to this file (it refuses `..`). `pgschema` skips INSERTs and some
@@ -209,4 +209,3 @@ CREATE EXTENSION IF NOT EXISTS pgcrypto;
 \i seeds/storage_accounting_snapshots.sql
 
 -- Fence any community-scoped table that lacks an explicit attach.
-\i community_write_fence.sql