nemo_voice_agent.evaluation.tools.tau2_telecom_predicates
nemo_voice_agent.evaluation.tools.tau2_telecom_predicates
Telecom DB-state predicate ports for the db_state_assertions framework.
Six predicates total — four user-side and two agent-side. Each one is
registered under domain="tau2_telecom" via the flat (domain, func_name)
predicate registry; the runner dispatches by func_name only (predicates
are side-agnostic, the caller picks the right DB).
User-side predicates (read shared_state["db"] on the user bot):
assert_mobile_data_status(db, expected_status)— single derived bool summarizing whether mobile data is functional. Combines 6 device fields via_get_mobile_data_working.assert_internet_speed(db, expected_speed, expected_desc=None)— runs a deterministic simulated speed test against device + surroundings state; checkssimulated_speed >= expected_speed(and optionally that the speed-category label matches).assert_service_status(db, expected_status)— direct check ondevice.network_connection_status.assert_can_send_mms(db, expected_status)— multi-field check (mobile data + network tech + MMSC config + messaging-app permissions).
Agent-side predicates (read shared_state["db"] on the agent bot):
assert_data_refueling_amount(db, customer_id, line_id, expected_amount)— checks the line’sdata_refueling_gbfield against an expected value (within float tolerance).assert_no_overdue_bill(db, overdue_bill_id)— true if the named bill is either absent from the DB or marked PAID.
Each predicate returns bool and never raises (the dispatcher catches,
but we don’t rely on that — upstream’s semantics for these is “false on
unexpected conditions”). The matching assert_value in the upstream
task JSON is what determines pass/fail; the predicate just produces the
underlying signal.
Module Contents
Functions
API
Mirror of upstream’s TelecomUserTools._can_send_mms.
MMS sending requires all of:
- mobile data working (delegates to
_get_mobile_data_working) - network technology is 3G or higher (NOT 2G)
- WiFi-calling-with-MMS-over-WiFi is OFF (carrier limitation)
- MMSC URL is configured (non-None)
- The
messagingapp exists in app_statuses and has bothstorageandsmspermissions
Iterate db["bills"] looking for bill_id. Returns None if not found.
Upstream raises ValueError here; we return None because
assert_no_overdue_bill treats “bill not found” as success and the
None-check is simpler than try/except for that semantic.
Iterate db["customers"] looking for customer_id. Returns
None if not found (upstream raises). Same rationale as
_get_bill_by_id — caller decides the missing-customer semantic.
Iterate db["lines"] looking for line_id.
Return True if mobile data is currently functional, False otherwise.
Mirrors upstream’s TelecomUserTools._get_mobile_data_working. Mobile
data is NOT working when any of the following are true (early-return
short-circuit, in this order):
- Airplane mode is on
- Network signal strength is NONE
- Network connection status is NO_SERVICE
- User is abroad AND (roaming not enabled on device OR roaming not allowed by location)
- Master data switch is off
- Surroundings flag says data usage exceeded
Lookup a line scoped to a customer.
Mirrors upstream’s _get_target_line: verifies line_id is in
customer.line_ids before returning the line. Returns None if
either the customer or the line isn’t found, or if the line isn’t
associated with the customer.
Simulate a deterministic speed test against current device state.
Mirrors upstream’s TelecomUserTools._run_speed_test. Returns
(speed_mbps, description) where:
speed_mbpsisNonewhen mobile data isn’t working (description = “No Connection” in that case).- Otherwise speed is computed as
(min + max) / 2 * signal_factor * base_speed_factorwith:(min, max)from the network-technology speed-range tablesignal_factorfrom the signal-strength multiplier tablebase_speed_factorreduced by VPN-with-poor-performance (×0.1) and data-saver-mode (×0.2)
descriptionis a verbal label (“Very Poor” / “Poor” / “Fair” / “Good” / “Excellent”) bucketed from the computed speed.
Assert that the messaging-app MMS-send capability matches expected_status.
Assert that the named line’s data_refueling_gb matches expected_amount.
Float-tolerance compare (abs(diff) < 1e-6). Returns False if the
line cannot be located (vs upstream which raises) — predicate-as-bool
semantics are simpler for the dispatcher.
Assert that the simulated speed meets a minimum threshold.
Parameters:
Minimum acceptable Mbps. The simulated speed must be
>= expected_speed for the assertion to pass. When the
speed test fails entirely (mobile data not working), the speed
is treated as 0.0 — assertion passes only if expected_speed
is also <= 0.
Optional verbal-bucket constraint. When provided,
the simulated speed’s category label (case-insensitive) must
equal this value AND the numeric threshold must also be met.
Common values from upstream tasks: "excellent", "good".
Assert that mobile data working status matches expected_status.
Assert that overdue_bill_id is either absent or paid.
Mirrors upstream: returns True when (a) the bill isn’t in the DB
at all (missing means “no longer overdue”), or (b) the bill exists
and its status is PAID. Returns False otherwise (e.g. still
overdue, draft, awaiting payment, disputed).
Assert that device.network_connection_status matches expected_status.
expected_status is the string value of a NetworkStatus enum
(e.g. "connected", "no_service").