Typically with SCORM 2004 you can use the imss:sequencing, and imss:limitConditions. Example:
<imsss:sequencing>
<!-- Optional: Limit attempts (managed by LMS), and or attemptAbsoluteDurationLimit equates to cmi.max_time_allowed -->
<imsss:limitConditions attemptLimit="1" />
<imsss:objectives>
<imsss:primaryObjective satisfiedByMeasure="true">
<!-- equates to cmi.scaled_passing_score of 60% -->
<imsss:minNormalizedMeasure>0.6</imsss:minNormalizedMeasure>
</imsss:primaryObjective>
</imsss:objectives>
</imsss:sequencing>
If the LMS doesn't support this, you would have to either place the data within the student attempt, but this gets dicy too.
Here is why-
If the student, or sco ever sets the 'cmi.exit' to '', 'normal', 'logout' or 'timeout' that is effectively the end of the attempt. In SCORM 2004 the LMS has a responsibility to create a new attempt and your current student data will be reset. Meaning, you either have to set a cookie or local storage value in order to keep track of this reliably. But, thats not even going to reliably work due to the student using another device. So in a way this is as I stated 'dicy'.
In SCORM 1.2 this got handeled differently by LMS Vendors. The spec didn't make it extremely clear how the LMS would manage modes and statuses so many run in a combination of ways which makes figuring out how to react to being in 'review' mode for example harder to rely on if the LMS lets you keep setting values after you've been graded. Most LMS vendors will tell you to manage your own attempts and may even keep you in an eternal attempt. I could go on about this for pages, but if you need anything more detailed here let me know.