diff --git a/architecture/openbmc-systemd.md b/architecture/openbmc-systemd.md
index c7123d9..f31d1af 100644
--- a/architecture/openbmc-systemd.md
+++ b/architecture/openbmc-systemd.md
@@ -28,9 +28,9 @@
 ## Initial Power
 When an OpenBMC system first has power applied, it starts the "default.target"
 unless an alternate target is specified on the kernel command line.  In
-Phosphor OpenBMC, there is a link from default.target to multi-user.target.
+Phosphor OpenBMC, there is a link from `default.target` to `multi-user.target`.
 
-You'll find all the phosphor services associated with multi-user.target.
+You'll find all the phosphor services associated with `multi-user.target`.
 
 ## Server Power On
 When OpenBMC is used within a server, the [obmc-host-start@.target](https://github.com/openbmc/phosphor-state-manager/blob/master/target_files/obmc-host-start%40.target)
@@ -84,18 +84,18 @@
 
 ## Server Power Off (Soft)
 The soft server power off function is encapsulated in the
-obmc-host-shutdown@.target.  This target is soft in that it notifies the host
+`obmc-host-shutdown@.target`.  This target is soft in that it notifies the host
 of the power off request and gives it a certain amount of time to shut itself
 down.
 
 ## Server Power Off (Hard)
 The hard server power off is encapsulated in the
-obmc-chassis-hard-poweroff@.target. This target will force the stopping
+`obmc-chassis-hard-poweroff@.target`. This target will force the stopping
 of the soft power off service if running, and immediately cut power to the
 system.
 
 ## Server Reboot
-The reboot of the server is encapsulated in the obmc-host-reboot@.target.
+The reboot of the server is encapsulated in the `obmc-host-reboot@.target`.
 This target will utilize the soft power off target and then, once that
 completes, start the host power on target.
 
@@ -170,30 +170,30 @@
 
 Targets which are not host related, will need special thought in regards to
 their error handling.  For example, the target responsible for applying chassis
-power, obmc-chassis-poweron@0.target, will have a
-"OnFailure=obmc-chassis-poweroff@%i.target" error path.  That is, if the
+power, `obmc-chassis-poweron@0.target`, will have a
+`OnFailure=obmc-chassis-poweroff@%i.target` error path.  That is, if the
 chassis power on target fails then power off the chassis.
 
 The above info sets up some general **guidelines** for our host related
 targets and services:
 
-- All targets should have an "OnFailure=obmc-quiesce-host@.target"
+- All targets should have a `OnFailure=obmc-quiesce-host@.target`
 - All services which are required for a target to achieve its function should
 be RequiredBy that target (not WantedBy)
 - All services should first try to be "Type=oneshot" so that we can just rely on
 the target failure path
 - If a service can not be "Type=oneshot", then it needs to have a
-"OnFailure=obmc-quiesce-host@.target" and ideally set "RemainAfterExit=no"
+`OnFailure=obmc-quiesce-host@.target` and ideally set "RemainAfterExit=no"
 (but see caveats on this below)
 - If a service can not be any of these then it's up to the service application
-to call systemd with the obmc-quiesce-host@.target on failures
+to call systemd with the `obmc-quiesce-host@.target` on failures
 
 ### RemainAfterExit
 This is set to "yes" for most OpenBMC services to handle the situation where
 someone starts the same target twice.   If the associated service with that
 target is not running (i.e. RemainAfterExit=no), then the service will be
 executed again.  Think about someone accidentally running the
-obmc-chassis-poweron@.target twice.  If you execute it when the operating system
+`obmc-chassis-poweron@.target` twice.  If you execute it when the operating system
 is up and running, and the service which toggles the pgood pin is re-executed,
 you're going to crash your system.  Given this info, the goal should always be
 to write "oneshot" services that have RemainAfterExit set to yes.