diff --git a/data/docs/cms-guide-for-education/cms-guide-for-education.md b/data/docs/cms-guide-for-education/cms-guide-for-education.md
index 83d4523984..0a5fbdfcd9 100644
--- a/data/docs/cms-guide-for-education/cms-guide-for-education.md
+++ b/data/docs/cms-guide-for-education/cms-guide-for-education.md
@@ -56,6 +56,7 @@ If you want a more detailed understanding of particle physics or an introduction
 For example:
 
 * [Particle Physics Playground](/record/52) provides you with further hands-on activities with open data from CMS and other experiments.
+* [Particle Discovery Lab](/record/49) is a 6-hour computational exercise for intermediate university students that reinforces physics course concepts like relativistic energy-momentum conservation and provides a platform for teaching analysis of histograms and propagation of uncertainties.
 * [Computing Methods in High-Energy Physics](/record/61) is an introductory course on computing in high-energy physics.
 * [CMS HEP Tutorial](/record/50) is a one-week course with a basic introduction to fundamental concepts of data analysis in HEP experiments using CMS Open Data.
 
diff --git a/data/docs/cms-guide-trigger-system/cms-guide-trigger-system.json b/data/docs/cms-guide-trigger-system/cms-guide-trigger-system.json
index bdb7dca990..421330138c 100644
--- a/data/docs/cms-guide-trigger-system/cms-guide-trigger-system.json
+++ b/data/docs/cms-guide-trigger-system/cms-guide-trigger-system.json
@@ -8,7 +8,7 @@
       "CMS"
     ],
     "short_description": {
-      "content": "Physically, an event is the result of a single readout of the detector electronics and the signals that will (in general) have been generated by particles, tracks, energy deposits, present in a number of bunch crossings. The task of the online Trigger and Data Acquisition System (TriDAS) is to select,..."
+      "content": "An event is the result of a single reading of the detector electronics capturing signals generated by particles from several bunch crossings. The online Trigger and Data Acquisition System (TriDAS) is tasked with selecting..."
     },
     "slug": "cms-guide-trigger-system",
     "tags": [
diff --git a/data/docs/cms-guide-trigger-system/cms-guide-trigger-system.md b/data/docs/cms-guide-trigger-system/cms-guide-trigger-system.md
index 1deb953aec..52ebb3462a 100644
--- a/data/docs/cms-guide-trigger-system/cms-guide-trigger-system.md
+++ b/data/docs/cms-guide-trigger-system/cms-guide-trigger-system.md
@@ -1,8 +1,8 @@
-Physically, an event is the result of a single readout of the detector electronics and the signals that will (in general) have been generated by particles, tracks, energy deposits, present in a number of bunch crossings. The task of the online Trigger and Data Acquisition System (TriDAS) is to select, out of the millions of events recorded in the detector, the most interesting 100 or so per second, and then store them for further analysis. An event has to pass two independent sets of tests, or Trigger Levels, in order to qualify. The tests range from simple and of short duration (Level-1) to sophisticated ones requiring significantly more time to run (High Levels 2 and 3, called HLT). In the end, the HLT system creates RAW data events containing:
+An event is the result of a single reading of the detector electronics capturing signals generated by particles from several bunch crossings. The online Trigger and Data Acquisition System (TriDAS) is tasked with selecting and storing the most interesting events (around 1000 events per second) from the millions of detected events. An event has to pass two independent sets of tests, or Trigger Levels, in order to qualify. These tests range from quick and simple (Level 1, called L1) to more complex and time-consuming (Levels 2 and 3, called the "high-level trigger", or HLT). Ultimately, the HLT system produces RAW data events containing:
 
 - the detector data,
-- the level 1 trigger result
-- the result of the HLT selections (HLT trigger bits)
+- the L1 trigger result
+- the HLT selection result (HLT trigger bits)
 - and some of the higher-level objects created during HLT processing.
 
 Original Source: [TriggerSystem](https://twiki.cern.ch/twiki/bin/view/CMSPublic/WorkBookCMSSWFramework#TriggerSystem "TriggerSystem")
@@ -10,88 +10,112 @@ Original Source: [TriggerSystem](https://twiki.cern.ch/twiki/bin/view/CMSPublic/
 
 ### The HLT
 
-The HLT contains many trigger paths, each corresponding to a dedicated trigger (such as a prescaled single-electron trigger or a 3-jets-with-MET trigger). A path consists of several steps (software modules), each module performing a well-defined task such as unpacking (raw to digi), reconstruction of physics objects (electrons, muons, jets, MET, etc.), making intermediate decisions triggering more refined reconstructions in subsequent modules, or calculating the final decision for a trigger path. The CMSSW Framework/EDM ensures that if an intermediate filter decision on a trigger path is negative, the rest of the path is not executed (skipped) and the specific trigger is regarded as rejecting the event. In order to save CPU time, each reconstruction step is followed by a filter in order to avoid running time-consuming reco code if it is already clear it will not be needed.
+The HLT contains many trigger paths, each corresponding to a dedicated trigger (such as a prescaled single-electron trigger or a 3-jets-with-MET trigger). A path consists of several steps (software modules). Each module performs a well-defined task such as unpacking (raw to digi), reconstruction of physics objects (electrons, muons, jets, MET, etc.), making intermediate decisions that trigger more refined reconstructions in subsequent modules, and calculating the final decision for a trigger path. The CMSSW Framework/EDM ensures that if an intermediate filter decision on a trigger path is negative, the rest of the path is skipped, and this specific trigger is regarded as rejecting the event. In order to save computation time, each reconstruction step is followed by a filter to skip unnecessary time-consuming reco code.
 
-In general it is expected that all HLT trigger paths are run, even if the event is already accepted by a path. In case this turns out to be too time-consuming, a truncated mode of HLT operations should be foreseen where the HLT short-circuits after the first accept (and after the triggers needed to classify the event for a primary data set and output stream are computed) and does not run the rest of the triggers. Presumably, the triggers not run online could be run in the offline reconstruction step to compute all trigger bits (for events written out) in order to get a complete trigger picture allowing trigger efficiency studies.
+In general it is expected that all HLT trigger paths are run, even if the event is already accepted by a path. In case this turns out to be too time-consuming, a truncated mode of HLT operations should be expected. In the truncated mode, the HLT short-circuits after the first acceptance, once the necessary triggers for classifying the event for a primary data set and output stream are computed. The subsequent triggers would not be executed. Presumably, the triggers not run online could be run in the offline reconstruction to compute all trigger bits for events written out, so that we can get a complete trigger picture that allows trigger efficiency studies.
 
-Each HLT trigger path must be seeded by one or more L1 trigger bit seeds: the first filter module in each HLT path is looking for a suitable L1 seed (consisting of L1 bit[s] and L1 object[s]) as a starting point for that specific HLT trigger.
+Each HLT trigger path must be seeded by one or more L1 trigger bit seeds: the first filter module in each HLT path looks for a suitable L1 seed (consisting of L1 bit(s) and L1 object(s)) as a starting point for that specific HLT trigger.
 
 Original Source: [SWGuideHighLevelTrigger](https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideHighLevelTrigger#How_it_works "SWGuideHighLevelTrigger")
 
 ### Persistent Trigger Results Objects and Available Software
 
-Two persistent HLT products are available:
+#### <b>AOD (2010-2012)</b>
 
-- `TriggerResults`: (subclassed from `HLTGlobalStatus` object), containing
-all the usual decision bits.
+  Two persistent HLT products are available:
 
-    The `TriggerResults` product (available for events written to output)
-allows access to the configuration and trigger decisions, i.e.,
-all the usual "trigger bits", including:
+  1. `TriggerResults`: Contains all the usual decision bits. It is subclassed from `HLTGlobalStatus` object.
 
-    1. Final decision of individual path and of full trigger table
-    2. Which triggers were run (some triggers may not run due to lack of a corresponding L1 seed or HLT running in truncated mode)
-    3. For each trigger rejecting the event, (the index of) which intermediate or final module instances on the path rejected the event
-    4. For each trigger encountering an error condition, (the index of) which module instances on the path encountered un-recoverable errors.
+     The `TriggerResults` product is available for events written to output. It provides access to both configuration information and trigger decisions, i.e., all the usual "trigger bits", including:
 
-    The corresponding code can be found in [DataFormats/Common/interface/TriggerResults.h](https://github.com/cms-sw/cmssw/blob/CMSSW_5_3_X/DataFormats/Common/interface/TriggerResults.h "TriggerResults.h") and [DataFormats/Common/interface/HLTGlobalStatus.h](https://github.com/cms-sw/cmssw/blob/CMSSW_5_3_X/DataFormats/Common/interface/HLTGlobalStatus.h "HLTGlobalStatus.h")
+     - Final decision of individual path and of full trigger table
+     - Which triggers were run (some triggers may not run due to lack of a corresponding L1 seed or HLT running in truncated mode)
+     - The index of the intermediate or final module instances on the path that rejected the event (for each trigger rejecting the event)
+     - The index of the module instances on the path that encountered un-recoverable errors (for each trigger encountering an error condition)
 
-- `TriggerEvent`: summarising the "L3" trigger collections and "L3" filter decisions.
+     The corresponding code can be found in [DataFormats/Common/interface/TriggerResults.h](https://github.com/cms-sw/cmssw/blob/CMSSW_5_3_X/DataFormats/Common/interface/TriggerResults.h "TriggerResults.h") and [DataFormats/Common/interface/HLTGlobalStatus.h](https://github.com/cms-sw/cmssw/blob/CMSSW_5_3_X/DataFormats/Common/interface/HLTGlobalStatus.h "HLTGlobalStatus.h")
 
-    The corresponding code can be found in [DataFormats/HLTReco/interface/TriggerEvent.h](https://github.com/cms-sw/cmssw/blob/CMSSW_5_3_X/DataFormats/HLTReco/interface/TriggerEvent.h "TriggerEvent.h")
+  2. `TriggerEvent`: Summarises the "L3" trigger collections and "L3" filter decisions.
 
-Additionally, the package [HLTrigger/HLTcore](htts://github.com/cms-sw/cmssw/tree/CMSSW_5_3_X/HLTrigger/HLTcore "HLTrigger/HLTcore") contains several
-analyzers pulling out the trigger information.
-You can use the corresponding analyzers directly - see their `cfi` files in
-the python subdirectory - or copy relevant code pieces into your modules.
+     The corresponding code can be found in [DataFormats/HLTReco/interface/TriggerEvent.h](https://github.com/cms-sw/cmssw/blob/CMSSW_5_3_X/DataFormats/HLTReco/interface/TriggerEvent.h "TriggerEvent.h")
 
-- `TriggerSummaryAnalyzerAOD`: analyser printing the content of the `TriggerEvent` product
-- `HLTEventAnalyzerAOD`: analyser combining the information from TriggerResults and TriggerEvent products
+     Additionally, the package [HLTrigger/HLTcore](htts://github.com/cms-sw/cmssw/tree/CMSSW_5_3_X/HLTrigger/HLTcore "HLTrigger/HLTcore") contains several analyzers that pull out the trigger information. You can use the corresponding analyzers directly - see their `cfi` files in the python subdirectory - or copy relevant code pieces into your modules. The `TriggerSummaryAnalyzerAOD` analyser prints the content of the `TriggerEvent` product. The `HLTEventAnalyzerAOD` analyser combines the information from `TriggerResults` and `TriggerEvent` products.
 
-The `HLTEventAnalyzer` plugin make use of the helper class [HLTConfigProvider](https://github.com/cms-sw/cmssw/blob/CMSSW_5_3_X/HLTrigger/HLTcore/interface/HLTConfigProvider.h "HLTConfigProvider") (also in [HLTrigger/HLTcore](https://github.com/cms-sw/cmssw/tree/CMSSW_5_3_X/HLTrigger/HLTcore "HLTrigger/HLTcore")), which extracts the HLT configuration (paths, modules) from the provenance.
+     The `HLTEventAnalyzer` plugin makes use of the helper class [HLTConfigProvider](https://github.com/cms-sw/cmssw/blob/CMSSW_5_3_X/HLTrigger/HLTcore/interface/HLTConfigProvider.h "HLTConfigProvider") (also in [HLTrigger/HLTcore](https://github.com/cms-sw/cmssw/tree/CMSSW_5_3_X/HLTrigger/HLTcore "HLTrigger/HLTcore")), which extracts the HLT configuration (paths and modules) from the provenance.
 
-Note: this helper class must be initialised calling it's `init(...)`
-from the `beginRun()` method of your plugin using this helper class. The reason
-that it has to be (re-)initialised in `beginRun()` is that the HLT
-configuration can (only) change at the boundary between runs.
+     Note: This helper class must be initialised by calling it's `init(...)` from the `beginRun()` method of your plugin. The helper class has to be (re-)initialised in `beginRun()`, because the HLT configuration can only change between runs.
 
-Original Source: [Persistent Trigger Results Objects](https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideHighLevelTrigger#Persistent_Trigger_Results_Objec "Persistent Trigger Results Objects")
+  Original Source: [Persistent Trigger Results Objects](https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideHighLevelTrigger#Persistent_Trigger_Results_Objec "Persistent Trigger Results Objects")
 
-Find the software and usage instructions in
+  Find more software and usage instructions in
 
-- [Analysis code for extracting the trigger information from the CMS 2010 data](/record/5003)
-- [Analysis code for extracting the trigger information from the CMS 2011 data](/record/5004)
+  - [Analysis code for extracting the trigger information from the CMS 2010 data](/record/5003)
+  - [Analysis code for extracting the trigger information from the CMS 2011 data](/record/5004)
+  - [Physics object extractor tool for the CMS 2012 data](/record/12501)
 
-and in TriggerAnalyzer and TriggerObjectAnalyzer packages in
+<br>
 
-- [Physics object extractor tool for the CMS 2012 data](/record/12501)
-- [Physics object extractor tool for the CMS 2015 data](/record/12502).
+#### <b>MiniAOD (2015 and beyond)</b>
+
+  MiniAOD contains:
+
+  - trigger bits associated to all paths
+  - all the trigger objects that have contributed to firing at least one filter within the trigger
+  - all objects reconstructed
+  - L1 global trigger summary
+  - the prescale values of all triggers
+
+  <b>Trigger bits for each path</b> are stored as `edm::TriggerResults`, as standard in CMSSW.
+
+  In order to access paths by trigger name, you can get an `edm::TriggerNames` instance from the Event, which translates indices in names. The mapping is the same in all events sharing the same trigger configuration, which is defined by the `parameterSetID()` method of the trigger results object.
+
+  <b>Trigger objects</b> associated to filters in the HLT are saved as instances of `pat::TriggerObjectStandAlone`, so that they can be used for e.g. trigger matching and measurements of trigger efficiency with the tag-and-probe method. The trigger names stored in the objects are packed, but they can be unpacked by passing an `edm::TriggerNames` instance.
+
+  <b>Trigger prescale</b> are encoded for each path into an `pat::PackedTriggerPrescales`, which can be unpacked with an `edm::TriggerNames` if access by path name is needed.
+
+  For tips and examples on accessing the trigger information, check the [MiniAOD Analysis Documentation](https://twiki.cern.ch/twiki/bin/view/CMSPublic/WorkBookMiniAOD2015), which contains both example CMSSW code and example python code.
+
+  Find examples for accessing trigger information using POET (physics object extractor tool) in:
+
+  - [Physics object extractor tool for the CMS 2015 data](/record/12502).
+  - [CMS Open Data Workshops](https://cms-opendata-guide.web.cern.ch/cmsOpenData/workshops/), particularly from 2022 and 2023.
+
+  Note: POET is not available for the CMS 2016 MiniAOD data, but the trigger information can still be accessed using EDAnalyzers similar to those available for 2015 MiniAOD.
+
+#### <b>NanoAOD (2016 and beyond)</b>
+
+  In NanoAOD, trigger bit information is available for all trigger paths in the input files. The bits that are not available in some events are filled with zeros. Trigger objects are stored in NanoAOD for some filters as defined [here](https://github.com/cms-sw/cmssw/blob/master/PhysicsTools/NanoAOD/python/triggerObjects_cff.py#L53). Trigger prescales are not stored in NanoAOD, but this information can be found using the `brilcalc` command line tool, as described in the last two sections of the [CMS luminosity calculation guide](/docs/cms-guide-luminosity-calculation).
+
+ Trigger information is stored in the following collections of branches:
+
+  - `L1_*`: Trigger bit for each L1 path.
+  - `L1PreFiringWeight_*`: L1 pre-firing event correction weight. Prefiring of L1 triggers represents a problem in their combined effect with the CMS trigger rules. It causes inefficiency in recording potentially interesting events. See the [CMS Open Data Guide](https://cms-opendata-guide.web.cern.ch/analysis/selection/triggers/) for more details.
+  - `HLT_*`: Trigger bit for each HLT path.
 
 
 ### HLT Trigger Path definitions
 
-For each dataset, the possible HLT trigger paths are listed in the dataset record. Each HLT path is composed of different algorithms and they are defined in the data-taking configuration files, which are given in
+For each dataset, the possible HLT trigger paths are listed in the dataset record. Each HLT path is composed of different algorithms defined in the data-taking configuration files, which are given in:
 
 - [High-Level Trigger information for 2010 CMS open data](/record/1699)
 - [High-Level Trigger information for 2011 CMS open data](/record/1700)
 - [High-Level Trigger information for 2012 CMS open data](/record/1701)
 - [High-Level Trigger information for 2013 CMS open data](/record/1702)
 - [High-Level Trigger information for 2015 CMS open data](/record/23900)
+- [High-Level Trigger information for 2016 CMS open data](/record/30300)
 
-The exact parameters (such as pT or eta cuts, or else) for each component of the HLT path can be found in the data-taking configuration file.
+The exact parameters (such as pT or eta cuts) for each component of the HLT path can be found in the data-taking configuration file.
 
-As an example, if you are looking for information about `HLT_Dimuon10_Jpsi` trigger, look for a string `process.HLT_Dimuon10_Jpsi`
-in the data-taking configuration file corresponding to the event range of your interest.
-You will find the corresponding CMSSW path, which consists of all the modules (i.e., specifically python-configured CMSSW code)
-and/or sequences (groups of modules) that make up that trigger path.
-You can then look for each of these modules or sequences in the same configuration file until your find
-the parameters with which they are configured.
-As an example, you will find one of the modules of this path, `hltDimuon10JpsiL3Filtered`, by searching for
-`process.hltDimuon10JpsiL3Filtered` and you will see that it is an instantiation of class `HLTMuonDimuonL3Filter`:
+For an example, if you are looking for information about the `HLT_Dimuon10_Jpsi` trigger, look for a string `process.HLT_Dimuon10_Jpsi` in the data-taking configuration file corresponding to the event range of your interest.
+You will find the corresponding CMSSW path, which consists of all the modules (i.e., specifically python-configured CMSSW code) and/or sequences (groups of modules) that make up that trigger path.
+You can then look for each of these modules or sequences in the same configuration file until you find the parameters with which they are configured.
+
+As an example, you will find one of the modules of this path, `hltDimuon10JpsiL3Filtered`, by searching for `process.hltDimuon10JpsiL3Filtered`. You will see that it is an instantiation of class `HLTMuonDimuonL3Filter`:
 
 `process.hltDimuon10JpsiL3Filtered = cms.EDFilter( "HLTMuonDimuonL3Filter",`
 
 followed by the values of different parameters for this algorithm.
+
 All HLT algorithm classes and definitions of the parameters therein can be found in
-[HLTrigger](https://github.com/cms-sw/cmssw/tree/CMSSW_5_3_X/HLTrigger "HLTrigger"), the example class above in
-[HLTMuonDimuonL3Filter.h](https://github.com/cms-sw/cmssw/blob/CMSSW_5_3_X/HLTrigger/Muon/interface/HLTMuonDimuonL3Filter.h "HLTMuonDimuonL3Filter.h").
+[HLTrigger](https://github.com/cms-sw/cmssw/tree/CMSSW_5_3_X/HLTrigger "HLTrigger"). The example class above can be found in
+[HLTMuonDimuonL3Filter.h](https://github.com/cms-sw/cmssw/blob/CMSSW_5_3_X/HLTrigger/Muon/interface/HLTMuonDimuonL3Filter.h "HLTMuonDimuonL3Filter.h"). These two links lead to the code for CMSSW_5_3_X. Switch to the correct CMSSW version using the tab on the upper left of the pages.
diff --git a/data/records/cms-learning-resources.json b/data/records/cms-learning-resources.json
index c25026a59a..686dc724ba 100644
--- a/data/records/cms-learning-resources.json
+++ b/data/records/cms-learning-resources.json
@@ -162,6 +162,51 @@
       ]
     }
   },
+  {
+    "abstract": {
+      "description": "<p>The Particle Discovery Lab uses CMS dimuon data from 2016 published via the CERN Open Data Portal. This intermediate-level lab exercise is designed to accompany an undergraduate course covering 20th century physics, including relativity and elementary particles.</p><p>Data from the Compact Muon Solenoid (CMS) experiment is provided in a format that can be quickly processed by students using either MATLAB or Python. No dedicated CMS Open Data software is required! Their task will be to “discover” a heavy particle that decays to two muons by reverse-engineering the properties of the short-lived particle from the observed muons. Students will build proficiency with: relativistic kinematics and energy conservation, Poisson-distributed data events, analysis using histograms, indistinguishable signal and background events, fitting and background subtraction, uncertainty propagation, and array-based programming and plotting</p><p>Instructor code is also provided in the \"instructors\" branch of the source repository, and includes instructions to build a new input dataset using the CMS Open Data software platforms.</p>"
+    },
+    "accelerator": "CERN-LHC",
+    "authors": [
+      {
+        "name": "Hogan, Julie",
+        "orcid": "0000-0002-8604-3452"
+      }
+    ],
+    "collections": [
+      "CMS-Learning-Resources"
+    ],
+    "date_published": "2024",
+    "experiment": [
+      "CMS"
+    ],
+    "keywords": [
+      "external resource",
+      "education"
+    ],
+    "license": {
+      "attribution": "MIT Open Source License"
+    },
+    "links": [
+      {
+        "description": "Source code repository",
+        "url": "https://github.com/bethel-physics/ParticleDiscoveryLab"
+      },
+      {
+        "description": "Visit the student site!",
+        "url": "https://bethel-physics.github.io/ParticleDiscoveryLab/"
+      }
+    ],
+    "publisher": "CERN Open Data Portal",
+    "recid": "49",
+    "title": "Particle Discovery Lab",
+    "type": {
+      "primary": "Documentation",
+      "secondary": [
+        "Activities"
+      ]
+    }
+  },
   {
     "abstract": {
       "description": "Every year, thousands of high-school students all over the world become particle physicists for a day, and visit nearby CMS institutes and universities to perform real analyses using public CMS data. The CMS Masterclass exercise is developed by QuarkNet and conducted under the aegis of the International Particle Physics Outreach Group."
diff --git a/docker-compose-override.yml b/docker-compose-override.yml
index 28b72fe8ef..ac09e461d5 100644
--- a/docker-compose-override.yml
+++ b/docker-compose-override.yml
@@ -30,7 +30,7 @@ services:
       - TEMPLATES_AUTO_RELOAD=True
     command: bash -c "/content/scripts/start-server-debug.sh"
     restart: "unless-stopped"
-    image: registry.cern.ch/cernopendata/cernopendata-portal:latest
+    image: registry.cern.ch/cernopendata/cernopendata-portal:0.1.11
     volumes:
       - ../opendata.cern.ch:/content
       - ./cernopendata:/code/cernopendata