Short answer
Each alert type names a specific physical event: a severed rope, an opened back cover, a cut shackle, a crossed geo-fence, a low battery. They are not severity levels of one thing. Routing them all into a single tamper queue discards the only detail that tells you what happened.
Key takeaways
- The JT701 publishes four alert types, rope cut, back cover, geo-fence and battery low, and detects rope cut, cover open and vibration.
- The JT709ex publishes three, tamper, mechanical key used and shackle cut, so its emergency override is reported as its own event, not as tampering.
- A geo-fence alert and a rope-cut alert are not the same class of claim: one describes where the asset is, the other describes damage to the device.
- Battery low is a maintenance event that shares the alert channel with security events, and it needs a different queue and a different clock.
- The evidentiary value of an alert lives in its type. Once it becomes generic "tamper", nobody can reconstruct what physically happened.
01The published lists, read literally
Start with what the two devices in our catalogue actually publish, because the wording is precise and the precision is the point. The JT701 lists its tamper detection as rope cut, cover open and vibration, and lists its alert types as rope cut, back cover, geo-fence and battery low. The JT709ex lists its alert types as tamper, mechanical key used and shackle cut. Notice that the detection list and the alert list on the master are not identical: vibration is something the device senses, while the four alert types are what it reports. That distinction already matters, because a sensor reading and a published event are different things, the first is raw, the second has been judged worth telling someone about.
02What a rope-cut alert claims
A rope-cut alert is a claim that the physical loop holding the lock closed has been severed. That is an unusually strong claim, because there is essentially no benign explanation for it. A rope does not cut itself, and it does not get cut in the course of a normal loading operation by someone with the right credentials, someone with the right credentials opens the lock instead. So a rope-cut event should carry the highest urgency of anything on the list, and it should also carry the most evidentiary weight afterwards, because it says that force was used rather than that access was granted. The correct response is immediate and specific: locate the asset from the master's position at that timestamp and treat the compartment as breached until someone confirms otherwise.
03Why back cover is a separate type
A back-cover alert describes something happening to the device rather than to the cargo. Opening the housing is how someone reaches the battery, the electronics and in principle the radio, so this alert is best read as an attack on the reporting itself rather than on the load. That changes the response in a way a generic tamper label would hide. A rope cut says get to the cargo. A cover open says the device may be about to stop telling you anything, so the last messages it sent may be the last you get. Both are serious, and they call for different actions. Collapsing them into one queue means the operator cannot tell whether to chase the shipment or to stop trusting the feed.
04Shackle cut, and the alert that is not an attack
The field lock publishes shackle cut alongside a generic tamper type and, notably, mechanical key used. The last of those three is the interesting one, because using the emergency key is a legitimate action. Our catalogue lists that key explicitly as an emergency method, so its use is expected in defined circumstances: a flat battery, a failed radio, a lock that must be opened with no electronics available. Publishing its use as its own alert type is exactly the right design, because the operation needs to know the override happened without the system pretending it was an attack. A shackle cut, by contrast, is force. Keeping the two as separate types is what lets a reviewer distinguish a documented emergency from a break-in months later.
05Geo-fence and battery low are a different class entirely
Two of the master's four alert types are not about the lock at all. A geo-fence alert says the asset entered or left an area someone defined, which is a statement about position rather than about the device's integrity, and it depends on the master's own GPS, quoted at 2.5 m CEP, plus wherever the boundary was drawn. A battery-low alert is a maintenance notice with a horizon of days, not seconds. Both are useful and neither is a security incident. Sharing one alert channel with rope cut and cover open is a practical convenience, but it means the channel carries at least three unrelated kinds of message, and a queue that treats them identically will bury the urgent ones under the routine.
06What is lost when types are collapsed
The failure mode worth naming is common and quiet. A team wires every lock event into one notification, labels it "tamper", and after a few weeks of geo-fence and battery-low traffic the notification is muted. Two things are lost at once. Operationally, the response to a rope cut is no longer different from the response to a low battery, which means there is effectively no response to a rope cut. Evidentially, the record now says something happened rather than a rope was severed at this timestamp with the vehicle at this position, and only the second version survives a dispute. The alert type is the device's single most specific output, and it is the part that costs nothing to preserve and everything to discard.
07Building a response per type
The remedy is unglamorous and short. Write the published types down as a list before deployment, using the device's own wording rather than a category of your own invention. Assign each type a response, an owner and a clock, a rope cut and a shackle cut are minutes, a cover open is minutes with an added assumption that the feed may stop, a mechanical key used is a same-day question to a named person, a battery low is a work order, and a geo-fence crossing is whatever the route plan says it is. Keep the types distinct all the way through to whatever system stores the history, because that is where the evidentiary value ends up. And review the mute list periodically, since a channel nobody reads is indistinguishable from a device that never reported.
| Alert type | Device | What it claims physically | Class of event |
|---|---|---|---|
| Rope cut | JT701 | The holding loop was severed | Forced entry |
| Back cover | JT701 | The housing was opened | Attack on the device |
| Geo-fence | JT701 | The asset crossed a defined boundary | Position, not integrity |
| Battery low | JT701 | The cell needs attention within days | Maintenance |
| Shackle cut | JT709ex | The shackle was cut | Forced entry |
| Mechanical key used | JT709ex | The emergency override was operated | Legitimate but unauditable |
| Tamper | JT709ex | Interference was sensed | Needs a follow-up detail |
Figures and sources
- Jointech JT701 tamper conditions detected: rope cut, cover open, vibration (Source: ENTEK.AI product specification, Jointech JT701, as of 2026-08-31)
- Jointech JT701 alert types published: rope cut, back cover, geo-fence, battery low (Source: ENTEK.AI product specification, Jointech JT701, as of 2026-08-31)
- Jointech JT709ex alert types published: tamper, mechanical key used, shackle cut (Source: ENTEK.AI product specification, Jointech JT709ex, as of 2026-08-31)
- Jointech JT709ex unlock methods, one of which is reported as its own alert: Bluetooth, RFID, mechanical key (emergency) (Source: ENTEK.AI product specification, Jointech JT709ex, as of 2026-08-31)
- Jointech JT701 quoted GPS accuracy, which a geo-fence alert rests on: 2.5 m CEP (Source: ENTEK.AI product specification, Jointech JT701, as of 2026-08-31)
- Jointech JT701 cellular connectivity, the path every alert leaves on: GSM / 3G, dual SIM (Source: ENTEK.AI product specification, Jointech JT701, as of 2026-08-31)
- Jointech JT709ex link to its master, the path its alerts take first: Bluetooth / LoRa, up to 1 km (open area) (Source: ENTEK.AI product specification, Jointech JT709ex, as of 2026-08-31)
- Jointech JT709ex own positioning capability, which is why its events borrow a position: none, uses master GPS (Source: ENTEK.AI product specification, Jointech JT709ex, as of 2026-08-31)
Questions
Is a rope-cut alert more serious than a cover-open alert?
They are serious differently. A rope cut says force reached the cargo. A cover open says the device itself was opened, so the reporting may be about to stop. Both need minutes, but the actions differ, one chases the shipment, the other stops trusting the feed.
Why is "mechanical key used" an alert if the key is legitimate?
Because it is the one opening that leaves no digital credential and cannot be revoked from a platform. Publishing its use as its own alert type means the override is never silent, while still not treating a documented emergency as an attack.
Should geo-fence and battery-low alerts go to the same people?
Usually not. A geo-fence crossing is a routing question and a battery-low is a work order with a horizon of days. Neither is a security incident, and putting them in the same queue as rope cut is how the urgent alerts end up muted.
Where does the location on a field-lock alert come from?
From the master. The JT709ex has no GPS of its own and uses the master's, whose accuracy is quoted at 2.5 m CEP. So the position attached to a shackle-cut event is where the JT701 was at that moment, which is a slightly different claim from where the lock was.

