diff --git a/doc/operator-guide/monitoring.rst b/doc/operator-guide/monitoring.rst
index 6009b391..64a4ae5b 100644
--- a/doc/operator-guide/monitoring.rst
+++ b/doc/operator-guide/monitoring.rst
@@ -22,4 +22,4 @@ Monitoring
 
 - Other issues
   - K8s infrastructure died The ConsDB team can verify that that is the problem, but there are likely to be wider issues seen
-    - USDF or Summit K8s/IT support should be responsible for fixing.
+  - USDF or Summit K8s/IT support should be responsible for fixing.
diff --git a/doc/operator-guide/schema-migration-process.rst b/doc/operator-guide/schema-migration-process.rst
index 6ec2c244..fa89e957 100644
--- a/doc/operator-guide/schema-migration-process.rst
+++ b/doc/operator-guide/schema-migration-process.rst
@@ -84,8 +84,11 @@ Schema Migration Process
     The steps to deploy at the summit mirror the steps to test on a test stand with coordination and permission from the observers and site teams.
     Access to argo-cd deployments is available via the Summit OpenVPN.
     To coordinate your deployment update on the summit, you must attend Coordination Activities Planning (CAP) meeting on Tuesday mornings and announce your request.
+
       - Add it to the agenda here: https://rubinobs.atlassian.net/wiki/spaces/LSSTCOM/pages/53765933/Agenda+Items+for+Future+CAP+Meetings
+
     The CAP members may tell you a time frame that is acceptable for you to perform these changes.
+
       - They may also tell you specific people to coordinate with to help you take images to test LATISS and LSSTCOMCAMSIM tables. There will be more tables to test eventually.
       - Some important channels to note: #rubinobs-test-planning; #summit-announce; #summit-auxtel, https://obs-ops.lsst.io/Communications/slack-channel-usage.html.
 
diff --git a/doc/user-guide/schemas.rst b/doc/user-guide/schemas.rst
index bca625cf..7ea11117 100644
--- a/doc/user-guide/schemas.rst
+++ b/doc/user-guide/schemas.rst
@@ -13,19 +13,24 @@ Schemas
 * Schema browser
 
 * Versioning
+
 https://rubin-obs.slack.com/archives/C07QJMQ7L4A/p1730482605167509
 
 - schemas are using semantic versioning
 - should be consistent across all schemas, not just ConsDB
 
     major: backward incompatible changes to the database objects (adding a table, deleting a column)
+
         - except adding a table is not backwards incompatible
+
     minor: backward compatible changes to the database objects (adding a column)
     patch: updates or additions to semantics/metdata (units, UCDs, etc.)
+
         - changing units can create incompatibilities
 
     And we should say what should happen in the case of changes to primary/foreign keys.
     Semantic neutrality: becoming non-primary is unique and anything becoming primary was already unique
+
     - or there can be ones that are not neutral.
 
     Think about the utility of these versions in terms of interaction with the ConsDB APIs, migrations, etc.