diff --git a/docs/gemdoc/.gitkeep b/docs/gemdoc/.gitkeep
new file mode 100644
index 0000000000000000000000000000000000000000..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
diff --git a/docs/gemdoc/daq_guide.md b/docs/gemdoc/daq_guide.md
new file mode 100644
index 0000000000000000000000000000000000000000..2af607aeda142805f0ba4fdfb62a27e27b392aea
--- /dev/null
+++ b/docs/gemdoc/daq_guide.md
@@ -0,0 +1,149 @@
+# A GEM DOC's DAQ Guide 
+
+This guide is to help walk new docs through basic procedures at p5 concerning the DAQ. 
+
+## Calibration Scans 
+
+For scans, you must be in local DAQ -- you coordinate with the Shift Leader when this is possible. And when you return to global, you must **DESTROY** the GEM/local or minidaq session. Instructions on how to take the scans are already given here : (link) .
+
+General information about the daily scans : 
+
+1. **Calibration Pulse Scan** – determines how many dead channels we have 
+	* uses GEM Local so can be taken without MiniDAQ
+    * this scan takes only a few seconds 
+
+
+2. **SBit** - determines the level of noise (Need STANDBY & INDUCTION OFF)
+	* uses GEM Local so can be taken without MiniDAQ
+    * this scan takes around 5 minutes per iteration. It is common to set iterations = 1. 
+
+
+3. **Low Threshold Run (Local Run)** — helps to keep track of noisy channels ? 
+	* uses MiniDAQ 
+    * Usually have this running ~20-30min  before stopping the run 
+
+For all scans (except SBit), it does not matter what the HV condition is (unless a specific request demands a certain configuration) -- just make sure to document it. HV can be standby or ON, but *LV must be on*. 
+
+**If LV is OFF -- you can't read anything out!!**
+
+> Laurent's Request : If you encounter something out of the ordiniary in the DAQ like say a scan didn't run as usual and had to be retaken -- you open an e-log under the Subsystems > GEM > P5 > DAQ category with the type *Problem Report*. This is to be done even if you are able to find a way around the problem -- we need to keep track of all the small glitches to make sure we don't miss anything major. 
+
+--- 
+
+## Taking Scans during InterFill 
+
+It is possible to complete all scans during a standard interfill. Here are a few tips to take these scans efficiently.
+
+**Beam Dump**
+You can have an agreement with the shift leader to immediently place you in local DAQ and DCS after beam dump (and call you after it has been done). This saves you a couple of minutes as you have given your consent beforehand but you must be ready on your end. 
+
+1. Take the Calibration Scan (do not analyze until later) 
+2. Prepare the system for the Sbit Scan and take it 
+
+These two scans fit nicely in the time it takes for **Ramp Down**. 
+
+3. Return the system to HV Stanby (after the sbit) 
+
+4. By **No Beam, SetUp**, you should be taking the low threshold Run. (HV at standby or ON depending on request)
+
+
+At **Injection Probe Beam, Injection Setup Beam**, the LHC Protection should fire and if you aren't in Standby, it will apply Standby for you. You should have enough statistics (~20min) to return to global DAQ and central DCS before Injection Setup Beam ends-- making sure to destroy the minidaq before you do so!! 
+
+
+---
+
+## Output of Runs 
+
+To check the status of the runs and make sure everything was applied correctly : 
+
+1. To check a Low Thr Run :
+    
+        ssh username@cmsusr 
+        ssh gem-daq01 
+        cd /gemdata/runs/minidaq/<run_number>
+        ##open any of the fed config info json files to double check thr=1 has been applied 
+
+    You'll be able to open the output config files of these runs immediately following the start of the run, but recall that the data is sent to Tier0. 
+
+    Additionally, you can check the monitoring page : [XDAQ](http://srv-s2g18-33-01.cms:20300/urn:xdaq-application:lid=61468 ) 
+    >L1A Rate should NOT be 0  
+
+
+2. To check a Calibration Scan (Sbit, CalPulse, etc.) : 
+        
+        ssh username@cmsusr
+        ssh gem-daq01
+        cd /gemdata/log/
+        ls -lrth
+
+        ## pick out the most recent log (it should be 20400 or 20200 not the 20300 …) 
+        tail -n 50 gem-daq01-20400-2022-06-12T18:33:32.723500Z-4258.log 
+        ## the other option is to use the grep command to search the file for ‘scan done’
+
+        ## the location of the scan outputs are: 
+        /gemdata/runs/local/run#
+
+A scan will be DONE when all 13 AMC Slots show DONE (6 for GE+1/1 and GE-1/1 and 1 for GE21 demo)
+
+--- 
+
+## Analyze the Calibration Pulse Scan 
+(to be done in /gemdata directory)
+        
+        sudo -u gemdoc -i 
+        ssh gemvm-control 
+        gem-find-dead-channel -r <RUNNUMBER>
+
+After above is complete, open [Grafana : Dead Channels Trends](https://cmsgemonline-monitoring.app.cern.ch/d/Trh6MZd4k/dead-channels-trends?orgId=1&from=now-7d&to=now) and refresh page. Look through and see if any SC had a spike in # of dead channels. (Can also check the nice overview at the top of the page before scrolling through all SC). 
+It is also recommended to have a range of at least 7 days. 
+
+Note that some spikes are not taken as seriously as others : 
+
+* some SC fluctuate from all OK to all VFAT channels (128) DEAD 
+* Sometimes datapoints are not reported for a SC 
+* Sometimes you have a small fluctuation (≤ 2 dead channels) being recovered or discovered 
+> e.g. GE11-P-36 Ly2 fluctuates a lot 
+
+In all cases, make sure to document in your elog.
+
+
+**Reporting Scans** 
+Like mentioned in the overview guide, you must write an elog for the calibration scans taken and also update the google doc with the local run taken. 
+
+--- 
+
+## Issues and Fixes 
+There are some known issues that central shifters may call you about. Time is of the essence, but it is better to understand 100% the problem before hanging up to accurately report information. 
+
+Here is how to handle known situations : 
+
+### FEDs stuck in WARNING 
+> The error : GEM FED #### is stuck in TTS WARNING 
+    
+Central Trigger shifter will have instructions, but just in case : 
+
+“As of July 18, there is an issue where the GEM FEDs get stuck in global. Tell the Shift leader to issue a *“TTC resync”* and see if this fixes the problem before doing red or green recycling. A TTC Resync takes about ~5 seconds. 
+
+Please note that “red recycle” and “green recycle” are simply ‘quick’ fixes to be used with care. If there are no collisions and it is during normal working hours, please call the DAQ expert in case of an error in global to allow them to investigate.”
+
+If the error is : 
+>TTS BLOCKED 
+
+Most likely, the AMC13 needs to be rebooted. **CALL DAQ EXPERT** 
+
+
+### Too Few OHs are ON 
+If you receive a notification or call that too few OHs are ON, this implies too few chambers have LV ON. We will be seen in Central DCS as “Not Ready”. 
+
+Simply request for a GR when next possible if GEM is in global. 
+
+* This can be in the shadow of another detector if stable beams are ongoing. Do NOT have central crew reconfigure us as this will cause deadtime to be assigned to us. It takes ~ 35 seconds to configure GEMs. 
+
+If GEM is in local, re-configure in either GEM-local or MiniDAQ. (It is assumed that if we are in local, there are no stable beams.)
+
+
+
+### GE21 Demonstrator (FED 1469)
+If anything is reported to you concerning the GE21 demonstrator during stable beams, you must request to take the FED out of the Fill. 
+> In the past there were instances of *High Rates of Deadtime* which can be solved by a GR but this is a quick fix and it is not guaranteed that the issue will not occur again.  
+
diff --git a/docs/gemdoc/dcs_guide.md b/docs/gemdoc/dcs_guide.md
new file mode 100644
index 0000000000000000000000000000000000000000..4ca74ed41c587829e27d7d0f2eda6fa123aec699
--- /dev/null
+++ b/docs/gemdoc/dcs_guide.md
@@ -0,0 +1,130 @@
+# A GEM DOC's DCS Guide 
+
+This guide is to help walk new docs through basic procedures at p5 concerning the DCS. 
+
+## Taking Control of the FSM 
+Make sure you are logged in to the DCS before you ask the technical shifter to take local control of the FSM 
+
+**Reasons for taking control of the FSM** : You need to interact with
+
+1. the upper left grey box on the DCS 
+
+2. the tree panel on the left 
+
+**Example situations include**  
+
+1. Including/Excluding a SC 
+2. Turning ON/OFF/HV to Standby a specific chamber, select chambers, or entire endcap through the FSM 
+    - When taking local control from central, wait a good 10 seconds before taking it (it will blink yellow ``` "NOBODY controls the system" ```) 
+  
+
+**Manually Recovering HV for a Chamber (while in Local)**
+
+When a chamber trips, and is unable to automatically recover due to exceeding its max. recovery times per day, it is up to the doc to manually recover the chamber. 
+If you take control or have control of the FSM, this is the safer method of recovering a chamber because you do not have to play around with the I0. 
+
+
+1. Clear Alarms 
+    - click on CLR ALARMS (at the top)
+    - click on clear all HV alarms in mainframe 
+2. Find the chamber in the leftmost part of the DCS underneath your login (``` CMS_GEM -> GEM_Logical -> GEM_ENDCAP_* ```) 
+    Right click on : ```GE11/*/*``` and choose "Show in new tab"; Here you can apply the usual FSM commands to 1 layer or both 
+3. Go To STANDBY HV ON for chamber(s) with trips in the case that you have multi-channel trips. If you only have 1 channel that trips, just go straight to 4 
+4. Power ON HV for chamber(s) with trip(s)
+        - watch the ramp up 
+5. If everything goes well, and the ramp up is successful, the FSM will restore the I0 back 
+
+---
+
+## Evidence of a short or HV anomaly 
+If Imon goes up (past 20uA) and thus trips again during ramp up, it is necessary to change the recipe settings for the specific chamber, channel.
+
+**To distinguish between a short or HV anomaly :** 
+
+* Short : Vmon / Imon = 10.0
+* HV anomaly : Vmon / Imon < 10.0 
+
+**To change the recipe settings :** 
+
+1. Click on Recipe Settings located at the top menu in the DCS 
+2. Choose the chamber you want 
+3. Select a higher I0 value for the ramp up (iSafeLimit) and for after a ramp up (iSetOn and iSetStb). Usually iSetStb = iSetOn. You will have to fill out the I0 values for all channels, not just the one that tripped. 
+4. Double check that the new Recipe Limits have been applied by clicking "...." 
+5. Switch HV back on through the FSM 
+6. Make sure to write an elog and notify! 
+
+--- 
+## Manually Recovering Chamber(s) without the FSM 
+
+One can also recover a tripped chamber without the FSM. However, only do this if you are knowledgeable about the procedure. *Follow the general rule that anytime a channel is ramped up, I0 = ISafeLimit + 10*. This procedure is therefore slightly more complicated for SC with short(s)/hv anomaly(ies).
+
+1. Clear Alarms 
+    - click on CLR ALARMS (at the top) 
+    - click on clear all HV alarms in mainframe 
+2. Click on the SC that tripped (Ly1 or Ly2 NOT the HV board) 
+3. If one electrode tripped, keep in FREE Mode. If more than one tripped, switch to GEM mode; apply settings 
+4. Set ISafeLimit + 10 to the SC (just a simple 20.0uA for all healthy SC) and apply settings. 
+    - watch the ramp up carefully (especially Imon) 
+5. If everything goes well, and the ramp up is successful, restore I0 to iSetOn (for healthy SC I0 = 10.0uA) 
+
+
+**Again**, I note that ramping up a SC through the FSM is the safer, more common practice -- especially for SC with shorts and or hv anomalies. FSM recipe automatically applies the correct I0 values for both ramp up and after. 
+
+---
+
+## Turning OFF the Induction Gap (G3Bot) 
+
+This configuration is used when taking sbit scans. If you aren't already in local FSM, ask for control from the technical shifter. 
+
+1. Select Settings 
+2. Select Chamber LV/HV settings
+3. Select all Chambers (you will have to repeat for the other endcap and GE21)
+4. Switch ALL ON 
+5. Click on the tick box above V column 
+6. Turn OFF the Induction Gap (G3Bot)
+7. Apply HV settings 
+8. Wait for ramp down 
+9. Check that the induction gap is off in the overview panel in the lower left corner and clicking on the GE21 Demonstrator Layers to view the quick HV status. 
+10. When ready to turn G3Bot back on, simply use the FSM and apply GO_To_STANDBY, then HV ON.
+
+---
+## GEM Magnet Operations 
+
+Whenever there is a change in the CMS magnetic field, the magnet protection should be triggered 
+After Magnet Field is stable (at **T or at 0T ) it is necessary to do HV training : 
+
+1. ONLY G1Top @ 420V (1hr)
+2. ONLY G2Top @ 420V (1hr) 
+3. ONLY G3Top @ 380V – lower for protection of electronics (1hr)
+
+4. All Foils (Tops) ON @ above values (1hr) 
+5. HV Standby – to check stability of the system (~ 30min) 
+6. HV ON & rejoin global 
+
+    * check beforehand what exact procedure to follow due to time concerns 
+    * Make sure to turn OFF whatever was ON before proceeding to the next step (i.e. G1Top ON, G1Top OFF & then G2Top ON) 
+
+This procedure is done using Chamber LV/HV settings.  
+
+---
+## Turning ON/OFF PConv 
+
+For times like 'January' Mode when LV, HV needs to be OFF & racks in UXC need to be OFF during the night, follow below steps. 
+    LV, HV can be turned OFF through the FSM. However, for the racks in UXC : 
+
+1. Go to Settings, CAEN Settings 
+2. To turn ON : *Double Click* on Channel1 [2,4,6,8] then turn ON Channel0 
+3. Next, turn on Channel 1 and 0 for [1,3,5,7] 
+    - sometimes one of the two won't turn on. Just try the other channel in the same PConv and they both will turn on 
+
+Just think when turning ON : First fix BLUE and then the one in ERROR/RED will go to BLUE 
+
+4. To turn OFF : go in opposite direction of turning ON 
+5. Turn OFF Channel0 [1,3,5,7] & then Channel1 should go off - just check that it is off 
+6. Turn OFF Channel0 [2,4,6,8] & then Channel1 (LV should go RED in [1,3,5,7])
+
+The IMPORTANT thing is to turn OFF Channel1 for [2,4,6,8] at the END 
+
+> **Turn OFF Example** : PConv1 Channel0, Channel1; then PConv2 Channel0, Channel1 -> at this point, PConv1 Channel0,1 will turn RED. (repeat for other PConv)
+
+        
diff --git a/docs/gemdoc/overview.md b/docs/gemdoc/overview.md
new file mode 100644
index 0000000000000000000000000000000000000000..a5938538040d8f4c2aed739e97a9f868d86a1225
--- /dev/null
+++ b/docs/gemdoc/overview.md
@@ -0,0 +1,74 @@
+# Overview of GEM DOC Responsibilities 
+
+## Monitor the status of CMS and the LHC 
+
+As DOC, it is important to keep an eye on these pages in addition to monitoring GE1/1 and the GE2/1 Demonstrator.  
+
+1. [LHC status](https://op-webtools.web.cern.ch/vistar/vistars.php)  : What is the beam status? 
+    * the comment box is also useful to see when the next stable beams will occur, how many bunches, etc. 
+
+
+2. [Central DCS](https://cmsonline.cern.ch/webcenter/portal/cmsonline/pages_common/dcs) : Is GEM in central DCS? Are we “Ready for Physics”?
+
+3. [DAQ](https://cmsonline.cern.ch/webcenter/portal/cmsonline/pages_common/daq) : Is GEM in global DAQ? What’s the current Run #? How long has the current run been going? 
+
+4. [Online DQM](https://cmsweb.cern.ch/dqm/online) : keep an eye on the summary plot. Does our data quality look good? ( <  6 chambers in error per endcap)
+
+
+5. [OMS](https://cmsoms.cern.ch/) : monitoring tool for Run Summary. Clicking the Run Range will show you useful info about the run (time, beam mode, which components are out) 
+    * it's helpful to keep track of CSC because we depend on them for trigger readout. 
+
+    * Also important! Keep an eye on the time - is it UTC or local? (to change to local, unclick the checkbox at the bottom labeled UTC time) 
+
+--- 
+## Reporting in Google Docs 
+
+1. [Run List 2023](https://docs.google.com/spreadsheets/d/1b5fQP5SsYUW0XheOydHnG1Yory3QIrJMMTwz4-rMkmc/edit#gid=179158703)  : this is where you report the global runs (> 1hr) with info you find using the OMS page + **any useful info about GE11 and GE21** (this is mainly to report on the LV and HV status).  
+    *  Runs are separated by month. There is a separate page to report local runs. 
+
+2. [ToBeDone](https://docs.google.com/spreadsheets/u/1/d/1m_OqvUmCpz6ge8rljOpFvAVRUmRCXPSGtEvBphsajBo/htmlview?pli=1#) : Important here is a) the list of HV anomalies and Shorts and b) the Equivalent divider current to HV values
+    * When there is a change in HV anomalies and/or shorts, this must be updated. 
+
+--- 
+
+## Communication Responsibilities
+
+1. [Elogs](https://cmsonline.cern.ch/webcenter/portal/cmsonline/pages_common/elog?_afrMFO=0&_afrMFR=192&_afrMFS=0&_afrWindowMode=0&_afrMFG=0&_afrMFCI=0&_afrMFH=685&_afrMFM=0&_afrMFDH=900&_afrMFC=10&_afrMT=screen&_afrLoop=14167596648366733&_afrFS=16&_afrMFW=1440&Adf-Window-Id=ia1u8l0gr&_afrMFDW=1440&__adfpwp_action_portlet=683379043&__adfpwp_backurl=https://cmsonline.cern.ch:443/webcenter/portal/cmsonline/pages_common/elog?_afrMFO=0&_afrMFR=192&_afrMFS=0&_afrWindowMode=0&_afrMFG=0&_afrMFCI=0&_afrMFH=685&_afrMFM=0&_afrMFDH=900&_afrMFC=10&_afrMT=screen&_afrLoop=14167596648366733&_afrFS=16&_afrMFW=1440&Adf-Window-Id=ia1u8l0gr&_afrMFDW=1440&__adfpwp_mode.683379043=1&_piref683379043.strutsAction=/viewSubcatMessages.do?catId=1691&subId=1715&page=1)  : this is for official reporting (usually the doc writes elogs in the section  GEM/P5/Commissioning)
+
+2. [Run Coordination Meeting](https://schwick.web.cern.ch/schwick/rctools/) : This is where you fill out minutes for the daily RC meeting at 9:30. Write your report by clicking the pencil under DOC reports. Also review the full report by clicking on the orange figure reading under Daily Report. It is recommended to fill out this report at least 30 minutes before the meeting begins.  
+
+3. [Mattermost](https://mattermost.web.cern.ch/cms-gem-ops/channels/gem-weekly-operations) : Primary source of communication between DOC and experts; usually in the Weekly Operations channel, sometimes in DCS or Commissioning. However, if there is a question that needs to be **IMMEDIATELY** answered, better to call the relevant expert. 
+
+4. In general, the DOC is the link between GEM Experts and the Central Shifters. You need to be aware of the plans for GEM and how that fits in with the schedule for CMS and report to both sides. 
+
+
+    ### Common Elogs 
+
+    **LHC Fill** 
+
+    Go to the [Overview](https://cmsgemonline-monitoring.app.cern.ch/d/vH594Q2Vz/overview?orgId=1&refresh=30s) page in grafana and looking at how many VFATs Enabled. 
+    A long straight vertical line is indication of the system being reconfigured
+    Unstable GBT == loss of vfats is expected 
+
+    Report in an elog % of VFATs enabled throughout the entire fill 
+    
+    * FED 1467 : # / 1728
+
+	* FED 1468 : # / 1728 
+
+	* FED 1469 : # / 48 
+
+    Include only the longest couple of runs within a fill along with the corresponding summary plots from the Online DQM page.
+    >Example elog : [LHC Fill Elog](http://cmsonline.cern.ch/cms-elog/1182556)
+
+
+    **Calibration Scans** 
+
+    DOCs are asked to take daily calibration scans to monitor the GE1/1 detector. (More information about these scans in the DAQ Guide)
+    >Example elog : [Calibration Scan Elog](http://cmsonline.cern.ch/cms-elog/1187322) 
+
+
+    **Other** 
+
+    Anytime something is changed in the DCS, or a problem occurs, an elog must be written to keep accurate records of operations at P5. 
+
diff --git a/mkdocs.yml b/mkdocs.yml
index 279a1a4c43f2e7181ce9ce5c11eba84af89b2472..46d03879bd57b6cc5d9be65816e3b850e238ee1c 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -74,6 +74,10 @@ nav:
     - P5 operations:
       - expert/p5-operations/index.md
       - expert/p5-operations/installation-maintenance.md
+  - GEM DOC guide:
+      - gemdoc/overview.md
+      - gemdoc/dcs_guide.md
+      - gemdoc/daq_guide.md
   - FAQ:
     - faq/index.md
   - References: