一套WhatsApp筛号系统不应只有“有效/无效”两格。电信空号、WA/WS平台开通和平台活动是三个由不同来源、不同时间窗口回答的问题。把它们压成一个status，会让未知变成否定、旧活动覆盖新许可，也让故障无法回滚。
先画出三条独立数据流
| 数据层 | 回答 | 典型来源 | 有效期 |
|---|---|---|---|
| 电信层 | 号码结构或网络可达性 | 号码规则/经批准检测 | 随网络与号码变化 |
| 平台注册层 | 是否返回WhatsApp开通观察 | WS筛开通 | 绑定checked_at |
| 活动层 | 活动时间/天数观察 | WS筛活跃 | 业务定义的短窗口 |
输入区只负责保存证据
raw_contacts保存phone_raw、source、collected_at和country_evidence；normalization_run生成phone_normalized、rule_version与format_exception。不要在原字段上直接替换，也不要因格式错误就把客户标为“空号”。
任务队列决定先跑什么
队列项写明business_question、cohort、task_type、owner、purpose、expiry和stop_rule。若只需要WhatsApp注册观察，就不运行活动或全格式。电信状态只有在业务确实需要且存在合适处理依据时单独取得。
建立TXT/Excel批次协议
导出TXT时每行一个号码，并生成不可上传的crosswalk：batch_id、row_key、contact_id、phone_normalized。计算TXT哈希并冻结输入计数。爱普筛返回Excel后，先验证文件属于哪个batch、schema是否对应任务，再做数据解析。
暂存区是系统的保险丝
任何Excel都不直接更新contacts。staging记录原始单元格、解析结果、错误代码和行号；只有通过schema、类型、唯一性与回连检查的数据才进入观察表。批次失败可整体撤销，而不是在生产库中逐行猜。
任务字段分别落表
| 任务 | 核心导出 | 建议目标表 |
|---|---|---|
| WS筛开通 | 手机号、是否开通 | platform_registration_observation |
| WS筛活跃 | 手机号、活跃时间、活跃天数、映射手机号 | platform_activity_observation |
| 电信检测 | 依实际来源定义 | telecom_observation |
| 许可 | 渠道、用途、退出、有效期 | contact_permission |
用五态代替布尔值
每层至少支持observed_yes、observed_no、unknown、input_error、system_error，并保留原始返回。unknown不会自动转成no；系统故障只触发受控重试；输入错误回到标准化队列。状态名包含“observed”，提醒使用者它不是永久真值。
映射手机号建立边，不覆盖节点
WS活动返回的映射手机号记录在identity_edge，带来源批次、置信状态与观察日期。若同一输入对应多个返回，或一个返回连接多个contact_id，边进入quarantine。人工确认前，CRM主号码保持不变。
下游名单由查询生成
不要导出一张永久的“好号码表”。下游视图在运行时组合所需层，并让permission、opt_out、frequency_cap和legal_hold拥有否决权。注册与活动只能贡献技术或排序条件，不能生成许可。
重试、过期和回滚
system_error使用指数退避与最大次数；input_error修复后形成新batch而不是改旧文件；活动到expiry后降为stale；发现schema错误时按batch_id撤销导入。每个动作写审计日志并保留操作者。
上线前做故障演练
故意测试重复号码、乱序Excel、缺列、额外列、空行、格式异常、映射冲突与中途失败。验证系统能拒绝错误文件、恢复队列、避免重复写入，并解释每条记录当前状态。只测“成功案例”无法证明系统可运营。
架构完成的标志
任意一条下游记录都能追溯到原始来源、规范化规则、TXT批次、任务、Excel行、观察时间和许可决定；删除某个过期观察不会破坏客户档案；整批导入可以撤销。达到这三点，才是一套筛号系统，而不是几个会流转的Excel。
