Prompt:
You are analysing a published communication-protocol procedure for a safety violation.

Standards body: IEEE
Specification clause: IEEE 802.11-2020 §12.7.6 (4-way handshake) / IEEE 802.11i
Safety property that must hold: nonce_never_reused

The procedure is given below as a finite state machine. The property must hold in EVERY state reachable from the initial state.

State fields (in order): ptk_installed, tx_nonce, nonce_reused
Initial state: {'ptk_installed': False, 'tx_nonce': 0, 'nonce_reused': False}

Transitions (from-state -- label --> to-state):
  {'ptk_installed': False, 'tx_nonce': 0, 'nonce_reused': False}  --InstallPTK_msg3-->  {'ptk_installed': True, 'tx_nonce': 0, 'nonce_reused': False}
  {'ptk_installed': True, 'tx_nonce': 0, 'nonce_reused': False}  --SendEncrypted-->  {'ptk_installed': True, 'tx_nonce': 1, 'nonce_reused': False}
  {'ptk_installed': True, 'tx_nonce': 0, 'nonce_reused': False}  --ReinstallPTK_msg3retx-->  {'ptk_installed': True, 'tx_nonce': 0, 'nonce_reused': False}
  {'ptk_installed': True, 'tx_nonce': 1, 'nonce_reused': False}  --SendEncrypted-->  {'ptk_installed': True, 'tx_nonce': 2, 'nonce_reused': False}
  {'ptk_installed': True, 'tx_nonce': 1, 'nonce_reused': False}  --ReinstallPTK_msg3retx-->  {'ptk_installed': True, 'tx_nonce': 0, 'nonce_reused': True}
  {'ptk_installed': True, 'tx_nonce': 2, 'nonce_reused': False}  --ReinstallPTK_msg3retx-->  {'ptk_installed': True, 'tx_nonce': 0, 'nonce_reused': True}
  {'ptk_installed': True, 'tx_nonce': 0, 'nonce_reused': True}  --SendEncrypted-->  {'ptk_installed': True, 'tx_nonce': 1, 'nonce_reused': True}
  {'ptk_installed': True, 'tx_nonce': 0, 'nonce_reused': True}  --ReinstallPTK_msg3retx-->  {'ptk_installed': True, 'tx_nonce': 0, 'nonce_reused': True}
  {'ptk_installed': True, 'tx_nonce': 1, 'nonce_reused': True}  --SendEncrypted-->  {'ptk_installed': True, 'tx_nonce': 2, 'nonce_reused': True}
  {'ptk_installed': True, 'tx_nonce': 1, 'nonce_reused': True}  --ReinstallPTK_msg3retx-->  {'ptk_installed': True, 'tx_nonce': 0, 'nonce_reused': True}
  {'ptk_installed': True, 'tx_nonce': 2, 'nonce_reused': True}  --ReinstallPTK_msg3retx-->  {'ptk_installed': True, 'tx_nonce': 0, 'nonce_reused': True}

The property 'nonce_never_reused' is FALSE exactly when the state makes it false; infer its meaning from the field names.

Answer with a single JSON object and nothing else:

{
  "violated": true | false,
  "trace": [ {"state": {<field>: <value>, ...}}, ... ]
}

Rules for "trace" (omit it entirely if "violated" is false):
  * Include it ONLY if you claim the property is violated.
  * The first entry MUST be the initial state exactly as given.
  * Each consecutive pair MUST be a transition that appears in the model.
  * The final state MUST make the property false.
A trace that does not replay against the model earns no credit, so an honest
"violated": false is worth more than a violation you cannot demonstrate.

Vanhoef & Piessens, "Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2", ACM CCS 2017; CVE-2017-13077..13088 (KRACK).

Retransmitted/replayed EAPOL-Key msg3 triggers PTK reinstallation, resetting the TX nonce and replay counter -> nonce reuse.


Prompt:
You are analysing a published communication-protocol procedure for a safety violation.

Standards body: IEEE
Specification clause: IEEE 802.11-2020 §13 (Fast BSS Transition)
Safety property that must hold: no_data_before_key_confirm

The procedure is given below as a finite state machine. The property must hold in EVERY state reachable from the initial state.

State fields (in order): authed, confirmed, data
Initial state: {'authed': False, 'confirmed': False, 'data': False}

Transitions (from-state -- label --> to-state):
  {'authed': False, 'confirmed': False, 'data': False}  --FTAuth-->  {'authed': True, 'confirmed': False, 'data': False}
  {'authed': True, 'confirmed': False, 'data': False}  --KeyConfirm-->  {'authed': True, 'confirmed': True, 'data': False}
  {'authed': True, 'confirmed': True, 'data': False}  --SendData-->  {'authed': True, 'confirmed': True, 'data': True}
  {'authed': True, 'confirmed': True, 'data': True}  (no outgoing transitions)

The property 'no_data_before_key_confirm' is FALSE exactly when the state makes it false; infer its meaning from the field names.

Answer with a single JSON object and nothing else:

{
  "violated": true | false,
  "trace": [ {"state": {<field>: <value>, ...}}, ... ]
}

Rules for "trace" (omit it entirely if "violated" is false):
  * Include it ONLY if you claim the property is violated.
  * The first entry MUST be the initial state exactly as given.
  * Each consecutive pair MUST be a transition that appears in the model.
  * The final state MUST make the property false.
A trace that does not replay against the model earns no credit, so an honest
"violated": false is worth more than a violation you cannot demonstrate.


Prompt:
You are analysing a published communication-protocol procedure for a safety violation.

Standards body: IEEE
Specification clause: IEEE 802.11be/bn MLO TID-to-link mapping (§35)
Safety property that must hold: no_tx_on_inactive_link

The procedure is given below as a finite state machine. The property must hold in EVERY state reachable from the initial state.

State fields (in order): link_active, tid_mapped, tx
Initial state: {'link_active': False, 'tid_mapped': False, 'tx': False}

Transitions (from-state -- label --> to-state):
  {'link_active': False, 'tid_mapped': False, 'tx': False}  --ActivateLink-->  {'link_active': True, 'tid_mapped': False, 'tx': False}
  {'link_active': True, 'tid_mapped': False, 'tx': False}  --DeactivateLink-->  {'link_active': False, 'tid_mapped': False, 'tx': False}
  {'link_active': True, 'tid_mapped': False, 'tx': False}  --MapTID-->  {'link_active': True, 'tid_mapped': True, 'tx': False}
  {'link_active': True, 'tid_mapped': True, 'tx': False}  --DeactivateLink-->  {'link_active': False, 'tid_mapped': False, 'tx': False}
  {'link_active': True, 'tid_mapped': True, 'tx': False}  --TxOnLink-->  {'link_active': True, 'tid_mapped': True, 'tx': True}
  {'link_active': True, 'tid_mapped': True, 'tx': True}  --TxDone-->  {'link_active': True, 'tid_mapped': True, 'tx': False}

The property 'no_tx_on_inactive_link' is FALSE exactly when the state makes it false; infer its meaning from the field names.

Answer with a single JSON object and nothing else:

{
  "violated": true | false,
  "trace": [ {"state": {<field>: <value>, ...}}, ... ]
}

Rules for "trace" (omit it entirely if "violated" is false):
  * Include it ONLY if you claim the property is violated.
  * The first entry MUST be the initial state exactly as given.
  * Each consecutive pair MUST be a transition that appears in the model.
  * The final state MUST make the property false.
A trace that does not replay against the model earns no credit, so an honest
"violated": false is worth more than a violation you cannot demonstrate.


Prompt:
You are analysing a published communication-protocol procedure for a safety violation.

Standards body: IEEE
Specification clause: IEEE 802.11-2020 §10.25 (Block Ack reordering / scoreboard)
Safety property that must hold: no_duplicate_delivered

The procedure is given below as a finite state machine. The property must hold in EVERY state reachable from the initial state.

State fields (in order): expected, dup_delivered
Initial state: {'expected': 0, 'dup_delivered': False}

Transitions (from-state -- label --> to-state):
  {'expected': 0, 'dup_delivered': False}  --RecvNext-->  {'expected': 1, 'dup_delivered': False}
  {'expected': 1, 'dup_delivered': False}  --RecvNext-->  {'expected': 2, 'dup_delivered': False}
  {'expected': 1, 'dup_delivered': False}  --RecvBelowWinStart_discard-->  {'expected': 1, 'dup_delivered': False}
  {'expected': 2, 'dup_delivered': False}  --RecvNext-->  {'expected': 3, 'dup_delivered': False}
  {'expected': 2, 'dup_delivered': False}  --RecvBelowWinStart_discard-->  {'expected': 2, 'dup_delivered': False}
  {'expected': 3, 'dup_delivered': False}  --RecvBelowWinStart_discard-->  {'expected': 3, 'dup_delivered': False}

The property 'no_duplicate_delivered' is FALSE exactly when the state makes it false; infer its meaning from the field names.

Answer with a single JSON object and nothing else:

{
  "violated": true | false,
  "trace": [ {"state": {<field>: <value>, ...}}, ... ]
}

Rules for "trace" (omit it entirely if "violated" is false):
  * Include it ONLY if you claim the property is violated.
  * The first entry MUST be the initial state exactly as given.
  * Each consecutive pair MUST be a transition that appears in the model.
  * The final state MUST make the property false.
A trace that does not replay against the model earns no credit, so an honest
"violated": false is worth more than a violation you cannot demonstrate.


Prompt:
You are analysing a published communication-protocol procedure for a safety violation.

Standards body: IEEE
Specification clause: IEEE 802.11ax/be Target Wake Time (§26.8)
Safety property that must hold: no_delivery_while_asleep

The procedure is given below as a finite state machine. The property must hold in EVERY state reachable from the initial state.

State fields (in order): awake, delivered_asleep
Initial state: {'awake': False, 'delivered_asleep': False}

Transitions (from-state -- label --> to-state):
  {'awake': False, 'delivered_asleep': False}  --SPStart-->  {'awake': True, 'delivered_asleep': False}
  {'awake': False, 'delivered_asleep': False}  --SPEnd-->  {'awake': False, 'delivered_asleep': False}
  {'awake': True, 'delivered_asleep': False}  --SPStart-->  {'awake': True, 'delivered_asleep': False}
  {'awake': True, 'delivered_asleep': False}  --SPEnd-->  {'awake': False, 'delivered_asleep': False}
  {'awake': True, 'delivered_asleep': False}  --DeliverInSP-->  {'awake': True, 'delivered_asleep': False}

The property 'no_delivery_while_asleep' is FALSE exactly when the state makes it false; infer its meaning from the field names.

Answer with a single JSON object and nothing else:

{
  "violated": true | false,
  "trace": [ {"state": {<field>: <value>, ...}}, ... ]
}

Rules for "trace" (omit it entirely if "violated" is false):
  * Include it ONLY if you claim the property is violated.
  * The first entry MUST be the initial state exactly as given.
  * Each consecutive pair MUST be a transition that appears in the model.
  * The final state MUST make the property false.
A trace that does not replay against the model earns no credit, so an honest
"violated": false is worth more than a violation you cannot demonstrate.


Prompt:
You are analysing a published communication-protocol procedure for a safety violation.

Standards body: IEEE
Specification clause: IEEE 802.11-2020 §11.2 (U-APSD / PS-Poll power save)
Safety property that must hold: no_delivery_without_trigger

The procedure is given below as a finite state machine. The property must hold in EVERY state reachable from the initial state.

State fields (in order): buffered, trigger, delivered_no_trigger
Initial state: {'buffered': False, 'trigger': False, 'delivered_no_trigger': False}

Transitions (from-state -- label --> to-state):
  {'buffered': False, 'trigger': False, 'delivered_no_trigger': False}  --Buffer-->  {'buffered': True, 'trigger': False, 'delivered_no_trigger': False}
  {'buffered': False, 'trigger': False, 'delivered_no_trigger': False}  --Trigger-->  {'buffered': False, 'trigger': True, 'delivered_no_trigger': False}
  {'buffered': True, 'trigger': False, 'delivered_no_trigger': False}  --Trigger-->  {'buffered': True, 'trigger': True, 'delivered_no_trigger': False}
  {'buffered': False, 'trigger': True, 'delivered_no_trigger': False}  --Buffer-->  {'buffered': True, 'trigger': True, 'delivered_no_trigger': False}
  {'buffered': False, 'trigger': True, 'delivered_no_trigger': False}  --Trigger-->  {'buffered': False, 'trigger': True, 'delivered_no_trigger': False}
  {'buffered': True, 'trigger': True, 'delivered_no_trigger': False}  --Trigger-->  {'buffered': True, 'trigger': True, 'delivered_no_trigger': False}
  {'buffered': True, 'trigger': True, 'delivered_no_trigger': False}  --DeliverOnTrigger-->  {'buffered': False, 'trigger': False, 'delivered_no_trigger': False}

The property 'no_delivery_without_trigger' is FALSE exactly when the state makes it false; infer its meaning from the field names.

Answer with a single JSON object and nothing else:

{
  "violated": true | false,
  "trace": [ {"state": {<field>: <value>, ...}}, ... ]
}

Rules for "trace" (omit it entirely if "violated" is false):
  * Include it ONLY if you claim the property is violated.
  * The first entry MUST be the initial state exactly as given.
  * Each consecutive pair MUST be a transition that appears in the model.
  * The final state MUST make the property false.
A trace that does not replay against the model earns no credit, so an honest
"violated": false is worth more than a violation you cannot demonstrate.


Prompt:
You are analysing a published communication-protocol procedure for a safety violation.

Standards body: IEEE
Specification clause: IEEE 802.11-2020 §11.3 / §12 (SA Query, protected management frames / 802.11w)
Safety property that must hold: no_spoofed_disassoc_accepted

The procedure is given below as a finite state machine. The property must hold in EVERY state reachable from the initial state.

State fields (in order): associated, query_pending, spoof_accepted
Initial state: {'associated': True, 'query_pending': False, 'spoof_accepted': False}

Transitions (from-state -- label --> to-state):
  {'associated': True, 'query_pending': False, 'spoof_accepted': False}  --RecvUnprotectedDisassoc_startSAQuery-->  {'associated': True, 'query_pending': True, 'spoof_accepted': False}
  {'associated': True, 'query_pending': True, 'spoof_accepted': False}  --SAQueryResponse_keepAssoc-->  {'associated': True, 'query_pending': False, 'spoof_accepted': False}

The property 'no_spoofed_disassoc_accepted' is FALSE exactly when the state makes it false; infer its meaning from the field names.

Answer with a single JSON object and nothing else:

{
  "violated": true | false,
  "trace": [ {"state": {<field>: <value>, ...}}, ... ]
}

Rules for "trace" (omit it entirely if "violated" is false):
  * Include it ONLY if you claim the property is violated.
  * The first entry MUST be the initial state exactly as given.
  * Each consecutive pair MUST be a transition that appears in the model.
  * The final state MUST make the property false.
A trace that does not replay against the model earns no credit, so an honest
"violated": false is worth more than a violation you cannot demonstrate.


Prompt:
You are analysing a published communication-protocol procedure for a safety violation.

Standards body: IEEE
Specification clause: IEEE 802.11ai Fast Initial Link Setup (§12.12)
Safety property that must hold: no_data_before_key

The procedure is given below as a finite state machine. The property must hold in EVERY state reachable from the initial state.

State fields (in order): fils_auth, key, data
Initial state: {'fils_auth': False, 'key': False, 'data': False}

Transitions (from-state -- label --> to-state):
  {'fils_auth': False, 'key': False, 'data': False}  --FILSAuth-->  {'fils_auth': True, 'key': False, 'data': False}
  {'fils_auth': True, 'key': False, 'data': False}  --EstablishKey-->  {'fils_auth': True, 'key': True, 'data': False}
  {'fils_auth': True, 'key': True, 'data': False}  --SendData-->  {'fils_auth': True, 'key': True, 'data': True}
  {'fils_auth': True, 'key': True, 'data': True}  (no outgoing transitions)

The property 'no_data_before_key' is FALSE exactly when the state makes it false; infer its meaning from the field names.

Answer with a single JSON object and nothing else:

{
  "violated": true | false,
  "trace": [ {"state": {<field>: <value>, ...}}, ... ]
}

Rules for "trace" (omit it entirely if "violated" is false):
  * Include it ONLY if you claim the property is violated.
  * The first entry MUST be the initial state exactly as given.
  * Each consecutive pair MUST be a transition that appears in the model.
  * The final state MUST make the property false.
A trace that does not replay against the model earns no credit, so an honest
"violated": false is worth more than a violation you cannot demonstrate.


Prompt:
You are analysing a published communication-protocol procedure for a safety violation.

Standards body: 3GPP
Specification clause: 3GPP TS 38.331 §4.2 (RRC states: IDLE/INACTIVE/CONNECTED)
Safety property that must hold: no_data_in_idle

The procedure is given below as a finite state machine. The property must hold in EVERY state reachable from the initial state.

State fields (in order): state, data
Initial state: {'state': 0, 'data': False}

Transitions (from-state -- label --> to-state):
  {'state': 0, 'data': False}  --Connect-->  {'state': 2, 'data': False}
  {'state': 2, 'data': False}  --Suspend-->  {'state': 1, 'data': False}
  {'state': 2, 'data': False}  --Release-->  {'state': 0, 'data': False}
  {'state': 2, 'data': False}  --SendData-->  {'state': 2, 'data': True}
  {'state': 1, 'data': False}  --Resume-->  {'state': 2, 'data': False}
  {'state': 1, 'data': False}  --ReleaseFromInactive-->  {'state': 0, 'data': False}
  {'state': 2, 'data': True}  --DataDone-->  {'state': 2, 'data': False}

The property 'no_data_in_idle' is FALSE exactly when the state makes it false; infer its meaning from the field names.

Answer with a single JSON object and nothing else:

{
  "violated": true | false,
  "trace": [ {"state": {<field>: <value>, ...}}, ... ]
}

Rules for "trace" (omit it entirely if "violated" is false):
  * Include it ONLY if you claim the property is violated.
  * The first entry MUST be the initial state exactly as given.
  * Each consecutive pair MUST be a transition that appears in the model.
  * The final state MUST make the property false.
A trace that does not replay against the model earns no credit, so an honest
"violated": false is worth more than a violation you cannot demonstrate.


Prompt:
You are analysing a published communication-protocol procedure for a safety violation.

Standards body: 3GPP
Specification clause: 3GPP TS 38.323 §5.2 (PDCP reordering / duplication discard)
Safety property that must hold: no_duplicate_delivered

The procedure is given below as a finite state machine. The property must hold in EVERY state reachable from the initial state.

State fields (in order): next_count, dup
Initial state: {'next_count': 0, 'dup': False}

Transitions (from-state -- label --> to-state):
  {'next_count': 0, 'dup': False}  --DeliverInOrder-->  {'next_count': 1, 'dup': False}
  {'next_count': 1, 'dup': False}  --DeliverInOrder-->  {'next_count': 2, 'dup': False}
  {'next_count': 1, 'dup': False}  --RecvDuplicate_discard-->  {'next_count': 1, 'dup': False}
  {'next_count': 2, 'dup': False}  --DeliverInOrder-->  {'next_count': 3, 'dup': False}
  {'next_count': 2, 'dup': False}  --RecvDuplicate_discard-->  {'next_count': 2, 'dup': False}
  {'next_count': 3, 'dup': False}  --RecvDuplicate_discard-->  {'next_count': 3, 'dup': False}

The property 'no_duplicate_delivered' is FALSE exactly when the state makes it false; infer its meaning from the field names.

Answer with a single JSON object and nothing else:

{
  "violated": true | false,
  "trace": [ {"state": {<field>: <value>, ...}}, ... ]
}

Rules for "trace" (omit it entirely if "violated" is false):
  * Include it ONLY if you claim the property is violated.
  * The first entry MUST be the initial state exactly as given.
  * Each consecutive pair MUST be a transition that appears in the model.
  * The final state MUST make the property false.
A trace that does not replay against the model earns no credit, so an honest
"violated": false is worth more than a violation you cannot demonstrate.


Prompt:
You are analysing a published communication-protocol procedure for a safety violation.

Standards body: 3GPP
Specification clause: 3GPP TS 38.322 §5.2/§5.3 (RLC AM retransmission, maxRetxThreshold)
Safety property that must hold: retx_bounded_no_runaway

The procedure is given below as a finite state machine. The property must hold in EVERY state reachable from the initial state.

State fields (in order): retx, acked, failed
Initial state: {'retx': 0, 'acked': False, 'failed': False}

Transitions (from-state -- label --> to-state):
  {'retx': 0, 'acked': False, 'failed': False}  --Retransmit-->  {'retx': 1, 'acked': False, 'failed': False}
  {'retx': 0, 'acked': False, 'failed': False}  --Ack-->  {'retx': 0, 'acked': True, 'failed': False}
  {'retx': 1, 'acked': False, 'failed': False}  --Retransmit-->  {'retx': 2, 'acked': False, 'failed': False}
  {'retx': 1, 'acked': False, 'failed': False}  --Ack-->  {'retx': 1, 'acked': True, 'failed': False}
  {'retx': 0, 'acked': True, 'failed': False}  (no outgoing transitions)
  {'retx': 2, 'acked': False, 'failed': False}  --Retransmit-->  {'retx': 3, 'acked': False, 'failed': False}
  {'retx': 2, 'acked': False, 'failed': False}  --Ack-->  {'retx': 2, 'acked': True, 'failed': False}
  {'retx': 1, 'acked': True, 'failed': False}  (no outgoing transitions)
  {'retx': 3, 'acked': False, 'failed': False}  --Retransmit-->  {'retx': 4, 'acked': False, 'failed': False}
  {'retx': 3, 'acked': False, 'failed': False}  --Ack-->  {'retx': 3, 'acked': True, 'failed': False}
  {'retx': 2, 'acked': True, 'failed': False}  (no outgoing transitions)
  {'retx': 4, 'acked': False, 'failed': False}  --Ack-->  {'retx': 4, 'acked': True, 'failed': False}
  {'retx': 4, 'acked': False, 'failed': False}  --MaxRetx_RLF-->  {'retx': 4, 'acked': False, 'failed': True}
  {'retx': 3, 'acked': True, 'failed': False}  (no outgoing transitions)
  {'retx': 4, 'acked': True, 'failed': False}  (no outgoing transitions)
  {'retx': 4, 'acked': False, 'failed': True}  (no outgoing transitions)

The property 'retx_bounded_no_runaway' is FALSE exactly when the state makes it false; infer its meaning from the field names.

Answer with a single JSON object and nothing else:

{
  "violated": true | false,
  "trace": [ {"state": {<field>: <value>, ...}}, ... ]
}

Rules for "trace" (omit it entirely if "violated" is false):
  * Include it ONLY if you claim the property is violated.
  * The first entry MUST be the initial state exactly as given.
  * Each consecutive pair MUST be a transition that appears in the model.
  * The final state MUST make the property false.
A trace that does not replay against the model earns no credit, so an honest
"violated": false is worth more than a violation you cannot demonstrate.


Prompt:
You are analysing a published communication-protocol procedure for a safety violation.

Standards body: 3GPP
Specification clause: 3GPP TS 38.321 §5.7 (DRX onDuration / inactivity / RTT timers)
Safety property that must hold: awake_when_pdcch_expected

The procedure is given below as a finite state machine. The property must hold in EVERY state reachable from the initial state.

State fields (in order): active, pdcch_expected
Initial state: {'active': False, 'pdcch_expected': False}

Transitions (from-state -- label --> to-state):
  {'active': False, 'pdcch_expected': False}  --OnDurationStart-->  {'active': True, 'pdcch_expected': False}
  {'active': True, 'pdcch_expected': False}  --OnDurationStart-->  {'active': True, 'pdcch_expected': False}
  {'active': True, 'pdcch_expected': False}  --ExpectPDCCH-->  {'active': True, 'pdcch_expected': True}
  {'active': True, 'pdcch_expected': False}  --InactivityExpire_sleep-->  {'active': False, 'pdcch_expected': False}
  {'active': True, 'pdcch_expected': True}  --OnDurationStart-->  {'active': True, 'pdcch_expected': True}
  {'active': True, 'pdcch_expected': True}  --PDCCHReceived-->  {'active': True, 'pdcch_expected': False}

The property 'awake_when_pdcch_expected' is FALSE exactly when the state makes it false; infer its meaning from the field names.

Answer with a single JSON object and nothing else:

{
  "violated": true | false,
  "trace": [ {"state": {<field>: <value>, ...}}, ... ]
}

Rules for "trace" (omit it entirely if "violated" is false):
  * Include it ONLY if you claim the property is violated.
  * The first entry MUST be the initial state exactly as given.
  * Each consecutive pair MUST be a transition that appears in the model.
  * The final state MUST make the property false.
A trace that does not replay against the model earns no credit, so an honest
"violated": false is worth more than a violation you cannot demonstrate.


Prompt:
You are analysing a published communication-protocol procedure for a safety violation.

Standards body: 3GPP
Specification clause: 3GPP TS 38.321 §5.1 (Random access, contention resolution)
Safety property that must hold: no_undetected_collision

The procedure is given below as a finite state machine. The property must hold in EVERY state reachable from the initial state.

State fields (in order): preamble, contention, resolved, undetected
Initial state: {'preamble': False, 'contention': False, 'resolved': False, 'undetected': False}

Transitions (from-state -- label --> to-state):
  {'preamble': False, 'contention': False, 'resolved': False, 'undetected': False}  --SendPreamble-->  {'preamble': True, 'contention': False, 'resolved': False, 'undetected': False}
  {'preamble': True, 'contention': False, 'resolved': False, 'undetected': False}  --CollisionOccurs-->  {'preamble': True, 'contention': True, 'resolved': False, 'undetected': False}
  {'preamble': True, 'contention': True, 'resolved': False, 'undetected': False}  --ContentionResolutionID-->  {'preamble': True, 'contention': True, 'resolved': True, 'undetected': False}
  {'preamble': True, 'contention': True, 'resolved': True, 'undetected': False}  (no outgoing transitions)

The property 'no_undetected_collision' is FALSE exactly when the state makes it false; infer its meaning from the field names.

Answer with a single JSON object and nothing else:

{
  "violated": true | false,
  "trace": [ {"state": {<field>: <value>, ...}}, ... ]
}

Rules for "trace" (omit it entirely if "violated" is false):
  * Include it ONLY if you claim the property is violated.
  * The first entry MUST be the initial state exactly as given.
  * Each consecutive pair MUST be a transition that appears in the model.
  * The final state MUST make the property false.
A trace that does not replay against the model earns no credit, so an honest
"violated": false is worth more than a violation you cannot demonstrate.


Prompt:
You are analysing a published communication-protocol procedure for a safety violation.

Standards body: 3GPP
Specification clause: 3GPP TS 38.321 §5.17 / TS 38.213 §6 (Beam failure recovery)
Safety property that must hold: recover_before_rlf

The procedure is given below as a finite state machine. The property must hold in EVERY state reachable from the initial state.

State fields (in order): bf_detected, bfr_sent, recovered, rlf
Initial state: {'bf_detected': False, 'bfr_sent': False, 'recovered': False, 'rlf': False}

Transitions (from-state -- label --> to-state):
  {'bf_detected': False, 'bfr_sent': False, 'recovered': False, 'rlf': False}  --DetectBeamFailure-->  {'bf_detected': True, 'bfr_sent': False, 'recovered': False, 'rlf': False}
  {'bf_detected': True, 'bfr_sent': False, 'recovered': False, 'rlf': False}  --SendBFR-->  {'bf_detected': True, 'bfr_sent': True, 'recovered': False, 'rlf': False}
  {'bf_detected': True, 'bfr_sent': True, 'recovered': False, 'rlf': False}  --RecoverBeam-->  {'bf_detected': True, 'bfr_sent': True, 'recovered': True, 'rlf': False}
  {'bf_detected': True, 'bfr_sent': True, 'recovered': True, 'rlf': False}  (no outgoing transitions)

The property 'recover_before_rlf' is FALSE exactly when the state makes it false; infer its meaning from the field names.

Answer with a single JSON object and nothing else:

{
  "violated": true | false,
  "trace": [ {"state": {<field>: <value>, ...}}, ... ]
}

Rules for "trace" (omit it entirely if "violated" is false):
  * Include it ONLY if you claim the property is violated.
  * The first entry MUST be the initial state exactly as given.
  * Each consecutive pair MUST be a transition that appears in the model.
  * The final state MUST make the property false.
A trace that does not replay against the model earns no credit, so an honest
"violated": false is worth more than a violation you cannot demonstrate.


Prompt:
You are analysing a published communication-protocol procedure for a safety violation.

Standards body: 3GPP
Specification clause: 3GPP TS 38.300 §9.2.3 / TS 38.423 (Xn handover, data forwarding & path switch)
Safety property that must hold: always_one_serving_context

The procedure is given below as a finite state machine. The property must hold in EVERY state reachable from the initial state.

State fields (in order): source_ctx, target_ctx, path_switched, data_lost
Initial state: {'source_ctx': True, 'target_ctx': False, 'path_switched': False, 'data_lost': False}

Transitions (from-state -- label --> to-state):
  {'source_ctx': True, 'target_ctx': False, 'path_switched': False, 'data_lost': False}  --PrepareTarget-->  {'source_ctx': True, 'target_ctx': True, 'path_switched': False, 'data_lost': False}
  {'source_ctx': True, 'target_ctx': True, 'path_switched': False, 'data_lost': False}  --ReleaseSourceEarly-->  {'source_ctx': False, 'target_ctx': True, 'path_switched': False, 'data_lost': True}
  {'source_ctx': True, 'target_ctx': True, 'path_switched': False, 'data_lost': False}  --PathSwitchAck-->  {'source_ctx': True, 'target_ctx': True, 'path_switched': True, 'data_lost': False}
  {'source_ctx': False, 'target_ctx': True, 'path_switched': False, 'data_lost': True}  --PathSwitchAck-->  {'source_ctx': False, 'target_ctx': True, 'path_switched': True, 'data_lost': True}
  {'source_ctx': True, 'target_ctx': True, 'path_switched': True, 'data_lost': False}  --ReleaseSourceEarly-->  {'source_ctx': False, 'target_ctx': True, 'path_switched': True, 'data_lost': False}
  {'source_ctx': False, 'target_ctx': True, 'path_switched': True, 'data_lost': True}  (no outgoing transitions)
  {'source_ctx': False, 'target_ctx': True, 'path_switched': True, 'data_lost': False}  (no outgoing transitions)

The property 'always_one_serving_context' is FALSE exactly when the state makes it false; infer its meaning from the field names.

Answer with a single JSON object and nothing else:

{
  "violated": true | false,
  "trace": [ {"state": {<field>: <value>, ...}}, ... ]
}

Rules for "trace" (omit it entirely if "violated" is false):
  * Include it ONLY if you claim the property is violated.
  * The first entry MUST be the initial state exactly as given.
  * Each consecutive pair MUST be a transition that appears in the model.
  * The final state MUST make the property false.
A trace that does not replay against the model earns no credit, so an honest
"violated": false is worth more than a violation you cannot demonstrate.