From 57a2506585db42d353b556d424cc6e5fd80174ea Mon Sep 17 00:00:00 2001
From: Haoming Meng <41393704+haoming29@users.noreply.github.com>
Date: Thu, 30 Nov 2023 15:58:29 -0600
Subject: [PATCH] Update client-usage.mdx

---
 docs/pages/client-usage.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/pages/client-usage.mdx b/docs/pages/client-usage.mdx
index 45cb3c6b9..7b56429cc 100644
--- a/docs/pages/client-usage.mdx
+++ b/docs/pages/client-usage.mdx
@@ -4,7 +4,7 @@ The Pelican client currently only supports *fetching* objects from Pelican feder
 
 One thing to note is that Pelican should be thought of as a tool that works with federated *objects* as opposed to *files*. The reason for this is that calling something a file carries with it the connotation that the file is mutable, ie its contents can change without requiring a new name. Objects in a Pelican federation, however, should be treated as immutable, especially in any case where objects are pulled through a cache (which will be the case for almost all files in the OSDF). This is because the underlying cache mechanism, powered by XRootD, will deliver whatever object it already has access to; if an object name changes at the origin, the cache will remain unaware and continue to deliver the old object. In the worst case, when the cache only has a partial object, it may attempt to combine its stale version with whatever exists at the origin. Use object names wisely!
 
-##Before Starting
+## Before Starting
 
 ### Assumptions