diff --git a/wiki/OpsHubBootstrapRunbook.md b/wiki/OpsHubBootstrapRunbook.md
index d8292a7..1c540f9 100644
--- a/wiki/OpsHubBootstrapRunbook.md
+++ b/wiki/OpsHubBootstrapRunbook.md
@@ -29,7 +29,15 @@ VSM classification is stored in the manifest capability description for now:
 - `vsm_function`: `OPS`
 - `vsm_system`: `S1`
 
-Inter-Hub does not yet have first-class hub metadata columns for these values.
+Newer Inter-Hub schemas have first-class hub metadata columns for these values.
+The SQL fallback sets those columns when present and still carries the same
+classification in the manifest description for older deployments.
+
+As of the 2026-05-19 access check, the workstation kubeconfig only points at
+CoulombCore (`92.205.130.254`) and does not include the Railiance01
+(`92.205.62.239`) cluster where `hub.coulomb.social` resolves. SSH key access
+to `root`, `worsch`, and `ubuntu` on Railiance01 was denied, so the SQL fallback
+must be run from a host/session that already has Railiance01 cluster access.
 
 ## UI Path
 
@@ -61,6 +69,31 @@ Inter-Hub does not yet have first-class hub metadata columns for these values.
 11. Seed the widgets from `wiki/ops-hub-widgets.seed.json` through the UI or
     migration fallback.
 
+## SQL Fallback Path
+
+From a shell with Railiance01 Kubernetes access, run:
+
+```bash
+kubectl exec -i -n databases net-kingdom-pg-1 -- \
+  psql -U postgres -d interhub \
+  < /home/worsch/helix-forge/wiki/ops-hub-bootstrap.sql
+```
+
+If using the HostEurope kubeconfig from the workstation, first restore
+`~/.kube/config-hosteurope` as documented by `railiance-cluster`, then run:
+
+```bash
+KUBECONFIG=~/.kube/config-hosteurope \
+kubectl exec -i -n databases net-kingdom-pg-1 -- \
+  psql -U postgres -d interhub \
+  < /home/worsch/helix-forge/wiki/ops-hub-bootstrap.sql
+```
+
+The SQL fallback creates the hub, active manifest, registry entries, API
+consumer row, and seed widgets. It does not create the one-time visible static
+API key; generate that in the authenticated Inter-Hub UI and store it outside
+Git.
+
 ## Validation
 
 After manifest activation:
diff --git a/wiki/ops-hub-bootstrap.sql b/wiki/ops-hub-bootstrap.sql
index ff70b73..40c406c 100644
--- a/wiki/ops-hub-bootstrap.sql
+++ b/wiki/ops-hub-bootstrap.sql
@@ -23,6 +23,25 @@ SET name = EXCLUDED.name,
     domain = EXCLUDED.domain,
     hub_kind = EXCLUDED.hub_kind;
 
+-- Newer inter-hub schemas have first-class VSM metadata columns. Keep this
+-- block conditional so the bootstrap still works against an older deployment
+-- where the metadata is only carried by the manifest description.
+DO $$
+BEGIN
+    IF EXISTS (
+        SELECT 1
+        FROM information_schema.columns
+        WHERE table_name = 'hubs'
+          AND column_name = 'hub_family'
+    ) THEN
+        UPDATE hubs
+        SET hub_family = 'vsm',
+            vsm_function = 'OPS',
+            vsm_system = '1'
+        WHERE slug = 'ops-hub';
+    END IF;
+END $$;
+
 WITH hub AS (
     SELECT id FROM hubs WHERE slug = 'ops-hub'
 )
diff --git a/workplans/HF-WP-0001-establish-ops-hub-first-extension.md b/workplans/HF-WP-0001-establish-ops-hub-first-extension.md
index 6d4c98e..1d2d2ff 100644
--- a/workplans/HF-WP-0001-establish-ops-hub-first-extension.md
+++ b/workplans/HF-WP-0001-establish-ops-hub-first-extension.md
@@ -152,10 +152,10 @@ Decision:
   possible, with a migration-backed fallback when a repeatable bootstrap is
   needed before the public API is hardened.
 - Treat Pattern A, API Consumer Hub, as the first implementation pattern.
-- Store VSM classification in the manifest capability description for now,
-  because the current `hubs` table only has `slug`, `name`, `domain`, and
-  `hub_kind`; there are no first-class `hub_family`, `vsm_function`, or
-  `vsm_system` columns yet.
+- Store VSM classification in first-class hub metadata where the target
+  Inter-Hub schema has `hub_family`, `vsm_function`, and `vsm_system`; keep the
+  same values in the manifest capability description for compatibility with
+  older deployments and API consumers.
 - Use `hub_kind = domain` for `ops-hub`.
 - Record missing first-class VSM metadata fields and create endpoints as
   Inter-Hub hardening work under T10.
@@ -690,6 +690,38 @@ This workplan is complete when:
 9. The bootstrap path is reusable enough that `syn-hub` can be created next
    without rediscovering the whole process.
 
+## Implementation Log
+
+### 2026-05-19 — Live bootstrap access check
+
+Attempted to execute the prepared bootstrap path.
+
+Findings:
+
+- `hub.coulomb.social` resolves to Railiance01 (`92.205.62.239`).
+- The current workstation kubeconfig has only the `default` context and points
+  at CoulombCore (`92.205.130.254`).
+- `~/.kube/config-hosteurope` is missing, so the documented Railiance01
+  kubeconfig path is not available locally.
+- `kubectl` against the current context has no `inter-hub` deployment because
+  it is the CoulombCore cluster.
+- SSH key auth to `root@92.205.62.239`, `worsch@92.205.62.239`, and
+  `ubuntu@92.205.62.239` was denied.
+
+Result:
+
+- Live `ops-hub` bootstrap was not applied from this session.
+- `wiki/ops-hub-bootstrap.sql` was strengthened to set first-class VSM hub
+  metadata when the target Inter-Hub schema supports it.
+- `wiki/OpsHubBootstrapRunbook.md` now records the exact SQL fallback command
+  to run from a Railiance01-capable session.
+
+Next required operator action:
+
+- Restore/provide Railiance01 Kubernetes access, or run
+  `wiki/ops-hub-bootstrap.sql` from a host that already has access to the
+  `net-kingdom-pg-1` pod in the `databases` namespace.
+
 ## Notes
 
 `ops-hub` should complement State Hub during the transition: