sessions migration guide + images

docs/api/migration-guides/sessions.mdx

@@ -12,17 +12,17 @@ Utility-scale workloads can take many hours to complete, so it is important that
 
 Workloads can be run as single jobs, sessions, or in a batch:
 
-- Use **session** mode for iterative workloads, or if you need dedicated access to the system
-- Use **batch** mode to submit multiple primitive jobs simultaneously to shorten processing time
-- Use **job** mode to submit a single primitive request for quick testing
+- Use **session** mode for iterative workloads, or if you need dedicated access to the QPU (quantum processing unit).
+- Use **batch** mode to submit multiple primitive jobs simultaneously to shorten processing time.
+- Use **job** mode to submit a single primitive request for quick testing.
 
 The following table summarizes the differences:
 
 |     Mode     |                  Usage                  |                                                                                                        Benefit                                                                                                        |
 |:------------:|:---------------------------------------:|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|
 | Job mode     | Quantum computation only.               | Easiest to use when running a small experiment. Might run sooner than batch mode.                                                                                                                                     |
 | Batch mode   | Quantum computation only.               | The entire batch of jobs is scheduled together and there is no additional queuing time for each. Jobs in a batch are usually run close together.                                                                     |
-| Session mode | Both classical and quantum computation. | Dedicated and exclusive access to the system during the session active window, and no other users’ or system jobs can run. This is particularly useful for workloads that don’t have all inputs ready at the outset.  |
+| Session mode | Both classical and quantum computation. | Dedicated and exclusive access to the QPU during the session active window, and no other users’ or QPU jobs can run. This is particularly useful for workloads that don’t have all inputs ready at the outset.  |
 
 ## Best practices
 
@@ -40,7 +40,7 @@ The above are general guidelines, and you should tune your workload to find the
 
 ## Sessions
 
-Sessions are designed for iterative workloads to avoid queuing delays between each iteration. All sessions now run in *dedicated* mode, so that when running a session, you have exclusive access to the backend.  Because of this, you are now charged for the total wall clock time that the system is reserved for your use. Additionally, sessions are now thread safe. That is, you can run multiple workloads within a session.
+Sessions are designed for iterative workloads to avoid queuing delays between each iteration. All sessions now run in *dedicated* mode, so that when running a session, you have exclusive access to the backend.  Because of this, you are now charged for the total wall clock time that the QPU is reserved for your use. Additionally, sessions are now thread safe. That is, you can run multiple workloads within a session.
 
 <Admonition type="note">
 Session execution mode is not supported in the Open Plan. Jobs will run in job mode instead.
@@ -88,10 +88,10 @@ with Batch(backend):
 
 ## Sessions versus batch usage
 
-Usage is a measurement of the amount of time the system is locked for your workload.
+Usage is a measurement of the amount of time the QPU is locked for your workload.
 
 * Session usage is the time from when the first job starts until the session goes inactive, is closed, or when its last job completes, whichever happens **last**.
 * Batch usage is the sum of quantum time of all jobs in the batch.
 * Single job usage is the quantum time the job uses in processing.
 
-![This image shows multiple sets of jobs.  One set is being run in session mode and the other is being run in batch mode.  For session mode, between each job is the interactive TTL (time to live).  The active window starts when the first job starts and ends after the last job is completed. After the final job of the first set of jobs completes, the active window ends and the session is paused (but not closed).  Another set of jobs then starts and jobs continue in a similar manner. The system is reserved for your use during the entire session.  For batch mode, the classical computation part of each job happens simultaneously, then all jobs are sent to the system.  The system is locked for your use from the time the first job reaches the system until the last job is done processing on the system.  There is no gap between jobs where the system is idle.](/images/guides/execution-modes/SessionVsBatch.svg 'Sessions compared to batch')
+![This image shows multiple sets of jobs.  One set is being run in session mode and the other is being run in batch mode.  For session mode, between each job is the interactive TTL (time to live).  The active window starts when the first job starts and ends after the last job is completed. After the final job of the first set of jobs completes, the active window ends and the session is paused (but not closed).  Another set of jobs then starts and jobs continue in a similar manner. The QPU is reserved for your use during the entire session.  For batch mode, the classical computation part of each job happens simultaneously, then all jobs are sent to the QPU.  The QPU is locked for your use from the time the first job reaches the QPU until the last job is done processing on the QPU.  There is no gap between jobs where the QPU is idle.](/images/guides/execution-modes/SessionVsBatch.svg 'Sessions compared to batch')