Article summary
Sudan introduced the +249 933 mobile range in December 2024. Learn how to update validation rules, recover false rejects and rerun only the affected WhatsApp list segment.
If a Sudan phone validator was built before December 2024, it may have rejected valid +249 933 records simply because the prefix did not yet exist in its rule set. That is not a change in WhatsApp registration. It is a numbering-plan change colliding with stale validation logic. The right response is to identify the affected rejects, release a versioned rule update, and rerun a controlled delta.
The specific change: 933 entered the mobile numbering plan
In a communication dated 3 December 2024, Sudan’s Telecommunications and Post Regulatory Authority announced a new NDC assignment. Prefix 933 was introduced for digital mobile telephony, assigned to MTN Sudan, with an introduction date of 1 December 2024. The notice appears in ITU Operational Bulletin No. 1307.
A validator can therefore recognize country code +249 yet still fail at the next layer. A static allow-list created before the allocation will treat 933 as an unknown NDC. The resulting “invalid” label describes the software’s outdated knowledge, not the current status of the number.
Number validation asks whether a value fits the current numbering plan. A WhatsApp check asks a different platform question. If the first gate is stale, the second may never be reached reliably.
Measure the blast radius before changing production
Search historical import and rejection logs for explicit +249933 values, national-looking 0933 values, and Sudan rows previously labelled unknown_prefix or invalid_ndc. Group them by first-seen month and source system. This reveals whether the issue is confined to a recent lead source or has accumulated across several pipelines.
Then remove false candidates from the impact set. An extra trunk zero, a duplicated country code, scientific notation damage, or a South Sudan +211 record incorrectly tagged as Sudan does not become valid merely because 933 was allocated. The change is narrow; the repair should be equally precise.
Release the numbering rule like production code
An in-place regular-expression edit erases the explanation for past results. A controlled release keeps the evidence:
- Create a new rule version. Attach the TPRA/ITU notice, allocation purpose and effective date.
- Build positive and negative tests. Include valid-shaped +249 933 candidates, national 0933 candidates, truncated values, duplicate +249 prefixes and +211 counterexamples.
- Shadow-calculate past rejects. Compare old and new classifications without immediately changing CRM records.
- Review the delta. Confirm that newly accepted rows changed because of the allocation, not because the expression became too permissive.
- Publish with rollback evidence. Retain the old result, old rule and migration timestamp.
The TPRA numbering page says the national plan is updated to accommodate growth and new services, and that changes are notified to the ITU. Prefix maintenance should therefore be an ongoing feed of evidence, not a one-time 933 patch.
Rerun the list in three waves
Wave one contains only historical rejects that now clearly fit +249 933. It tests the rule correction. Wave two reviews other Sudan exceptions from the same source systems to discover broader import defects. Wave three considers the remaining historical population only where the business purpose and permission are still current.
Give each wave its own batch_id. If an unexpected result appears, the team can separate a numbering-rule problem from a source-data problem or a task problem. Combining years of records into one rerun would turn those causes into an uninterpretable hit rate.
Make the old-versus-new rule diff explicit
| Record pattern | Old version | New version | Enter the task? |
|---|---|---|---|
| Well-formed +249 933 candidate | unknown_ndc | ready | Yes, in wave one |
| National 0933 notation with reliable provenance | unknown_ndc | ready-after-transform | Yes, with a transformation log |
| +249 933 with a missing digit | invalid_length | invalid_length | No; a new range does not repair truncation |
| +211 phone incorrectly tagged as Sudan | country_conflict | country_conflict | No; return to provenance review |
Only classifications affected by the 933 allocation should change. Length, country and data-damage problems remain exceptions, preventing a range update from becoming a general relaxation.
Preserve the first result during the rerun
One row can legitimately hold old_validation, new_validation and platform_observation. Together they show that the old rule blocked it, the official allocation later admitted it, and a platform observation was made on a specific date. Keeping only the final cell erases why the historical result changed.
Wave-one recovery measures the validator repair; it is not the WhatsApp registration rate, activity rate or profile-field coverage. Give every rate its own denominator so exceptions that never entered the task are not counted as “not registered.”
Choose Full Format only when the decision needs it
If the business question is simply whether the recovered 933 phones are registered on WhatsApp, a WS Registration task is narrower. Select WS Full Format only when activity, avatar, profile, business-account and mapping observations are all necessary for a defined workflow.
The AppShai WS Full Format export can include phone, activity time, active days, gender, age, avatar, skin tone, avatar type, business status and mapped WhatsApp phone. Activity requires a check timestamp. Profile and avatar values may be missing or change. A mapping difference needs review. None of those observations proves that a 933 phone belongs to a particular person.
A successful repair is explainable, not merely larger
Do not define success as a higher acceptance rate. The report should show how many 933 records the old rule rejected, how many the current allocation supports, how many remain exceptions because of length or provenance, how many recovered records completed the intended check, and whether the new rule incorrectly passed any negative test.
When every Excel row can be traced to the source record, validator version and ITU change notice, the rerun is auditable. The same change-response process will also handle the next +249 allocation without forcing the team to reclean its entire Sudan database.
