本体登记表
知识库
全库 1033 个构件(2026-08-17 按说明书 v2 全量重抽),按纲要六类构件组织,规则=函数·规则型。(二期数据接地:对象 8/89 · 属性 83/273 · 关系 1/108,在详情页维护)
确认进度894/1033· 已确认=锁定,改前先解锁
这里不做判断,只记录结论:PM / 风控 / 后端把口径定下来之后,在对应条目上记一笔「定了什么、谁定的」。冲突记完可以顺手把说法错了的那条构件标成「待改」,提醒回去改。
X-003冲突U01 开通与授信
开户段的反欺诈引擎是一次调用还是两次
说法一(02§引擎矩阵、R2)
激活反欺诈引擎(CFMC)是在授信开户之后调用。
说法二(R10§5)
开户初审走的是 MIDAFS 反欺诈引擎(接口 88100019)。
矛盾开户段反欺诈到底是「开户后激活」还是「开户初审」,时点与身份是否同一个引擎不明,目前分别登记为 F-20 与 F-54 两个函数,待风控确认是否合并。
涉及:F-20 激活反欺诈(CFMC,ICRC-MIDAFS)F-54 开户反欺诈初审(ICRC-MIDAFS 88100019)出处:02§引擎矩阵·R10§5
登记原文
02§引擎矩阵/R2（CFMC 激活反欺诈=授信开户后调用）/R10§5（MIDAFS 开户初审走 88100019）: 开户段反欺诈引擎的时点/身份是否同一（开户后激活 vs 开户初审）不明，分别立 F-20 与 F-54，待风控确认是否合并✓ 已收口 · 新说法两次,各管一段:开户初审时调 MIDAFS(88100019,对应 F-54 开户反欺诈初审),账户激活时另调 CFMC(对应 F-20 激活反欺诈)。原两句说法描述的是不同时点,不构成矛盾,两个函数壳都保留Leo · 2026-09-08待改:F-54 开户反欺诈初审（ICRC-MIDAFS 88100019） · F-20 激活反欺诈（CFMC，ICRC-MIDAFS）
X-004冲突U02 支付消费
支付结果是否回传商户、失败后能否重试
说法一(02§关键字段与门槛)
支付成功→进通用结果页并触发外部回调;失败→错误提示,可重试。
说法二(02§D.3/D.4、02§用户旅程)
支付结果不回传商户;失败后不可在页内重试。
矛盾同一篇内对「是否外部回调」和「失败能否重试」表述相反;D 节是逐行查代码得出的,速览段疑为旧口径残留。
涉及:N015 消费支付交易A-04 受理支付交易出处:02§关键字段与门槛 vs 02§D.3
登记原文
02§关键字段与门槛（'成功→COMMON_RESULT 页+外部回调；失败→错误提示可重试'）/02§D.3/D.4 与 02§用户旅程（'结果回传商户=无'、'失败不可页内重试'）: 同篇内对'外部回调'与'失败可重试'表述相反；D 节为代码逐行查实，速览段疑为旧口径残留✓ 已收口 · 说法二对SDK 不回传支付结果:三个结果页的关闭按钮均无参,商户须自行经收单侧查单接口或入站回调确认;失败页无重试按钮,唯一按钮回宿主,客户须从商户侧重新发起(与 L027、L028 一致)Leo · 2026-09-08
X-005冲突U02 支付消费
付款页展示的费率到底是头息率还是月费率
说法一(02§D.2)
付款页每一档展示的是 UPFRONT_ADMIN_FEE 这个字段的百分比,页面上标为 admin fee。
说法二(R4§3 出参对照、02§业务规则速览)
UPFRONT_ADMIN_FEE 对应的是头息(service fee),真正的 admin fee 对应月费率(MONTH_INST_HANDLE_FEE_RATE);速览段又说付款页只展示 admin fee%,service fee 不单独列示。
矛盾如果 D.2 的字段名准确,付款页展示的其实是 service fee 而不是 admin fee,与速览段和 R4 的命名对照相反。
涉及:N015 消费支付交易P036 费率口径常量组出处:02§D.2 vs R4§3·02§业务规则速览
登记原文
02§D.2（付款页每档展示 UPFRONT_ADMIN_FEE% 标为 admin fee）/R4§3 出参（UPFRONT_ADMIN_FEE=头息/service fee；admin fee=MONTH_INST_HANDLE_FEE_RATE）+ 02§业务规则速览（付款页仅展示 admin fee%，service fee 不单独列示）: 付款页实际渲染的字段究竟是头息率还是月费率——若 D.2 字段名准确，则付款页展示的是 service fee 而非 admin fee，与速览段及 R4 命名对照矛盾✓ 已收口 · 说法二对付款页每一档展示的是月费率(MONTH_INST_HANDLE_FEE_RATE,前端字段名 adminFee);UPFRONT_ADMIN_FEE 是首月一次性收取的头息/service fee,不在付款页单列、由 RIPLAY 合同披露Leo · 2026-09-08
X-006冲突U02 支付消费
产品库的「Merchant CPM」是否就是付款码被扫
说法一(02§消费渠道,产品口径)
Merchant CPM = 付款码被扫。
说法二(R10§4、02§后端事实增补)
系统里 CPM 的语义已证实为被扫,但「产品库里的 Merchant CPM 模块名是否就指这个」仍需 PM 确认。
矛盾不是结论相反,而是同一名词在产品模块与系统语义上是否指同一对象尚未闭合,待 PM 一句话确认。
涉及:N079 QRIS 付款码(CPM 被扫)出处:02§后端事实增补
登记原文
02§消费渠道 Merchant CPM=付款码被扫（产品口径）/R10§4·02 / 02§后端事实增补（CPM 系统语义已证=被扫，但'产品库 Merchant CPM 模块名是否即指此仍需 PM 确认'）: 同一名词的产品模块与系统语义是否同一对象未闭合，登记待 PM 一句话确认（非结论矛盾，属口径未对齐）✓ 已收口 · 说法一对产品库的「Merchant CPM」就是 QRIS 付款码被扫(客户出示码、商户扫码),两者同指;已加为 N079 的别名,便于按产品库术语检索Leo · 2026-09-08待改:N079 QRIS 付款码（CPM 被扫）
X-008冲突U03 取现 Instant Cash
取现头息率现网是 6% 还是 3%
说法一(R4§1、L237)
取现放款时一次性扣除的砍头息为 6%。
说法二(03§用券后 RIPLAY,《RIPLAY 更新优化 0507》)
RIPLAY 展示折后 admin fee 的示例为 upfront fee 3% = Rp30,000。
矛盾头息率 6% 与示例 3% 不一致;示例可能只是举例值但没有标注,需 PM 确认现网头息率。
涉及:L237 规则:取现放款一次性扣砍头息P036 费率口径常量组出处:R4§1·R4§2②·03§用券后 RIPLAY
登记原文
L237/R4§1 取现砍头息=6%/03§用券后 RIPLAY 显示折后 admin fee 示例:upfront fee 3%=Rp30,000(《RIPLAY 更新优化 0507》): 头息率 6% vs 示例 3%;示例可能仅为举例值但未标注,需 PM 确认现网头息率✓ 已收口 · 说法一对取现砍头息现网为 6%;RIPLAY 合同中的「upfront fee 3% = Rp30,000」是文档示例数字,不代表现网费率,不得据此建模或对外引用Leo · 2026-09-08待改:P036 费率常量组
X-013冲突U04 账单与账期、常规还款
账单到期日每月 10 号,是否只对 2025 年前开户成立
说法一(04§账期规则,PM 2026-08-13)
2025 年后开户的账户,最后还款日为次月 3 号(L251)。
说法二(05§提前还款费率,《RIPLAY PayLater - New 2025-05》)
账单到期日为每月 10 日。
矛盾RIPLAY 对全体用户写每月 10 日,而 PM 两代规则下 2025 年后开户是次月 3 号;RIPLAY 的口径是否只对 2025 年前开户成立待确认。
涉及:L251 规则:2025 年后开户的账期(25 号出账/3 号还款)P133 账期参数组出处:04§账期规则·05§提前还款费率
登记原文
L251 / 04§账期规则（PM 2026-08-13：2025 年后开户次月 3 号还款）/05§提前还款费率《RIPLAY PayLater - New 2025-05》：账单到期日为每月 10 日: 范围重叠结论不同：RIPLAY 对全体写每月 10 日，PM 两代规则下 2025 年后开户为次月 3 号；RIPLAY 是否只对 2025 前开户成立待确认✓ 已收口 · 说法一对到期日不是全局常量,按账户 billingCycle 派生:billingCycle=1 → 到期 10 日(RIPLAY"每月 10 日"仅对这一代成立),billingCycle=25 → 次月 3 日;billingCycle 在首借 S31015 持久化(1-28),多账单日并存IT 知识库 riplay-contract-dynamic-fields.md §3.1(UAT 2026-07 样本:BILLING_CYCLE=25→DUE_DATE_DAY=03 ×6,=1→10 ×4)、lifecycle §5(PM 两代口径)、icps-billing-cycle-and-future-schedule-query.md(WeFi-NY/knowledge-base@0d93e0f)trista · 2026-09-08待改:L251 2025 年后开户的账户:出账日与最后还款日由产 · P133 账单日
X-014冲突U04 账单与账期、常规还款
核销门槛是 121 天以上还是 180 天以上
说法一(05§E.6)
核销准入门槛为账龄档 AGE_CD>4,即 121-180 天的账户也可通过。
说法二(05§E.6 引述、催收框架口径)
产品侧惯称「180+ 核销」。
矛盾核销准入门槛 AGE_CD>4 与 DPD≥181 两个口径不一致。
涉及:L269 规则:呆账核销人工上传流程P132 账龄档出处:05§E.6
登记原文
L269 / 05§E.6（核销门槛 AGE_CD>4，121-180 天可过）/产品侧惯称'180+核销'（05§E.6 引述、催收框架口径）: 口径矛盾：核销准入门槛 AGE_CD>4 vs DPD≥181✓ 已收口 · 新说法两个口径是两道不同闸门:业务准入 = DPD(TM_LOAN.DUE_DAYS)≥181(自动核销候选);系统安全准入 = AGE_CD > AGE_XFR_START_AGECD(UAT=4),人工与自动共用后置检查;人工上传路径本身无 181 天硬门槛,故 121-180 天在人工路径可过IT 知识库 icps-manual-writeoff-flow.md §3.4/§6.3(② icps26.06.24 + UAT 2026-07-22)、7_prd_tech_specs/icps/2026-07-24-auto-batch-writeoff README、loan-batch-data-lifecycle-governance.md §3.6(WeFi-NY/knowledge-base@0d93e0f)trista · 2026-09-08待改:L269 呆账核销无自动扫描：须运营人工整理文件→上传→双 · P132 账龄档
X-015冲突U04 账单与账期、常规还款
对客所说的「利息」与后端账目并不对应
说法一(05§E.1)
现金贷产品(801002)的利息桶恒为 0,对客所谓「息费」实际由罚息、分期手续费、违约金组成。
说法二(对客话术、前端字段)
字段 minimumRepayInterestFee、LOAN_PAID_OUT_INT_AMT 都称为「利息」。
矛盾对客口径里的「利息」与后端记账桶实际不符,对客话术可能误导用户。
涉及:N005 借据(IOU)N018 还款交易出处:05§E.1·05§关键字段
登记原文
05§E.1（现金贷 801002 利息桶恒为 0，'息费'实为罚息+分期手续费+违约金）/对客话术/前端字段 minimumRepayInterestFee、LOAN_PAID_OUT_INT_AMT 称'利息': 口径矛盾：对客'利息'与后端桶实际不符，对客话术会误导✓ 已收口 · 新说法两者都对,是命名误导不是数据矛盾:后端现金贷产品的利息桶恒为 0 属实,字段名叫 interest 也属实。统一口径——凡名为 interest 的字段(minimumRepayInterestFee、LOAN_PAID_OUT_INT_AMT 等),实际由罚息、分期手续费与提前结清违约金构成;建模、取数与对外披露时不得按「利息」理解或计算,已在结清构成组与最低还款字段组的备注写明Leo · 2026-09-08待改:P033 结清构成组 · P029 最低还款字段组
X-016冲突U04 账单与账期、常规还款
提前还款违约金 8%/10% 的「待统一」标记已过时
说法一(R4§6 待确认表)
提前还款违约金 8% 与 10% 两个值需 PM 统一。
说法二(03§、_待确认清单 PM 15 条,2026-08-13)
PM 已确认两个值的差异是有意为之。
矛盾数值本身不冲突,只是 R4 仍挂着陈旧的「待统一」标记未同步。
涉及:P036 费率口径常量组出处:R4§6·03§·_待确认清单
登记原文
R4§6 待确认表（提前还款违约金 8%/10% 需 PM 统一）/03§/_待确认清单 PM 15 条（2026-08-13 确认差异有意为之）: 陈旧待确认标记未同步：值不冲突，但 R4 仍标待统一✓ 已收口 · 说法二对提前还款违约金消费 8% / 取现 10% 是有意差异,不需统一:两产品的风险与成本不同(PM 2026-08-13 确认,已写入 L065 与 P036),原「待统一」标记作废Leo · 2026-09-08
X-021冲突U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)
核销准入实际门槛比「180+ 核销」更宽
说法一(05§E.6)
核销准入真实门槛为账龄档 AGE_CD>4,即 AGE_CD=5/6(121-180 天)也能通过。
说法二(产品侧惯称)
「180+ 核销」。
矛盾核销准入口径存在偏差;核销动作本身归其他单元处理,此处只记录口径差异。
涉及:P132 账龄档出处:05§E.6
登记原文
05§E.6 核销准入真实门槛 AGE_CD>4(AGE_CD=5/6 即 121-180 天也能过)/产品侧惯称『180+ 核销』: 核销准入口径偏差(本单元仅登记,核销动作归其他单元)✓ 已收口 · 说法一对人工核销路径的系统准入确为 AGE_CD>4,比"180+"宽;"180+"是自动核销与产品口径的 DPD 门槛,二者不是同一闸门。WRITEOFF_BY_DUE_DAYS 列存在但人工上传未赋值,旧路径 recourseMinDueDays=181 在新 IQ/CT 路径未调用IT 知识库 icps-manual-writeoff-flow.md §3.4/§5/§6.3(2026-07-24 复核)(WeFi-NY/knowledge-base@0d93e0f);与 X-014 同源合并处理trista · 2026-09-08待改:P132 账龄档
X-028冲突U07 会员与营销
低价权益能否与利率类优惠券叠加
说法一(L060,02§低价权益)
低价权益与利率券可叠加,例如 3%×0.7=2.1%。
说法二(L357,11§券叠加规则,PM 2026-08-13)
低价权益与 Admin Fee 利率类券互斥,只能生效一个。
矛盾适用范围重叠但结论相反;R4§4 仍写「叠加规则待 PM」属于陈旧口径。
涉及:L060 规则:低价权益与利率券叠加L357 规则:低价权益与利率类券互斥N048 营销权益券(EQUITY)出处:02§低价权益·11§券叠加规则·R4§4
登记原文
L060 / 02§低价权益(低价权益与利率券可叠加,3%×0.7=2.1%)/L357 / 11§券叠加规则(低价权益×Admin Fee 利率类券互斥,PM 2026-08-13): 范围重叠(低价权益×利率类券)结论相反;R4§4 仍写'叠加规则待 PM'为陈旧口径✓ 已收口 · 说法二对互斥:低价权益与利率类优惠券(Admin Fee 券)同属利率类优惠,只能生效一个(PM 2026-08-13);L060 里「可叠加、利率券基于低价后价格计算 3%×0.7=2.1%」的表述已删除,以 L357 为准Leo · 2026-09-08待改:L060 低价权益已解耦为额度属性:全支付场景自动生效、支
X-029冲突U07 会员与营销
支付立减券列表排序,PRD 与代码不同
说法一(源 PRD《PL coupon 列表展示支付立减劵 0812》)
按发放日期倒序。
说法二(11§、代码)
排序模式为最近到期优先(sortMode=20151002),券商店里按面值降序。
矛盾SMP 券排序口径 PRD 与代码不同;知识库已注明「以代码为准」,此处仅记录差异。
涉及:N049 SMP 支付立减券N029 优惠券使用选择出处:11§优惠券(PL coupon 列表)
登记原文
源 PRD《PL coupon 列表展示支付立减劵 0812》按发放日期倒序/11§/代码 sortMode=20151002 最近到期 + store 面值降序: SMP 券排序口径 PRD 与代码不同;KB 已注'以代码为准',仍登记不改写✓ 已收口 · 说法二对以代码现网实现为准:支付页券列表按 sortMode=20151002「最近到期优先」排序;券商店里另按面值降序。PRD 里「按发放日期倒序」的说法已过时Leo · 2026-09-08待改:L158 SMP 券在锁额页的弹窗只展示按最近到期排序拉取
X-043冲突U09 参考层字典(横切属性与枚举正本)
账单逾期判定「每月 10 日」只对 2025 年前开户成立
说法一(L063)
账单到期(每月 10 日)未还清 → 状态由 N 转 O(逾期)。
说法二(_待确认清单-风控后端SA-20260813 后端 5 条)
账期分两代——2025 年后开户 25 号出账、次月 3 号还款,宽限期 10 天。
矛盾「每月 10 日」只对 2025 年前开户成立;L063 需按开户代际写全适用范围。
涉及:L063 规则:账单最后还款日与逾期转态N045 账单P133 账期参数组出处:registry L063·_待确认清单-风控后端SA-20260813
登记原文
L063『到期(每月 10 日)未还清→N→O』/_待确认清单 后端 5 条:账期两代规则(2025 年后开户=25 号出账·次月 3 号还款;宽限期 10 天): 口径矛盾:『每月 10 日』仅对 2025 年前开户成立;L063 需按开户代际写全适用范围(U04 处理)✓ 已收口 · 新说法逾期转态以账户级 PMT_DUE_DATE(由 billingCycle 派生:1→10 日,25→次月 3 日)为界,过期未清 IS_OVERDUE=Y、OVERDUE_DAYS/TIMES 递增;上 A 码再加 graceDate 条件;"每月 10 日"只是 billingCycle=1 代的实例。L063 的"O"状态值在核心侧未见(观测为 U/N/F)IT 知识库 riplay-contract-dynamic-fields.md §3.1(UAT 2026-07)、lifecycle §1/§5(PROD 2026-06-29/30 观测)、icps-block-codes-core.md §4(WeFi-NY/knowledge-base@0d93e0f)trista · 2026-09-08待改:L063 账单到最后还款日(由账户的账单日对应的产品参数定 · N045 账单
X-044冲突U09 参考层字典(横切属性与枚举正本)
前一账期状态是否存在 O(逾期)值
说法一(R5§⑧)
账单状态 CURR_STMT_STATUS 后端只观测到 U/N/F 三个值。
说法二(R3§①)
前端 currentState 取值为 U/N/F/O。
矛盾取值集不同——O 是否存在于前一账期状态;后端字典未确认。
涉及:P198 前一账期账单状态出处:R5§⑧·R3§①
登记原文
R5§⑧ CURR_STMT_STATUS 后端仅观测到 U/N/F/R3§① currentState 取值 U/N/F/O: 取值集差异(O 是否存在于前一账期状态);后端字典未确认✓ 已收口 · 说法二对按前端枚举登 U/N/F/O 四个值,其中 O(已逾期)注明「后端未观测到,待确认」;前端枚举代表实际可能出现的取值,后端只是当时没采到该值Leo · 2026-09-08待改:P198 前一账期账单状态
G-005缺口U01 开通与授信
引擎建议额度对应的输出字段名不明
缺什么:P072 引擎建议额度 在引擎输出里对应哪个字段名没有找到。
为什么缺/线索:后端系统地图只写到引擎会给建议额度,未见字段名(R10§5)。
涉及:P072 引擎建议额度出处:R10§5
登记原文
P072 引擎建议额度: 引擎输出字段名未见✓ 已收口 · 已补齐引擎建议额度的字段名 = SUG_LMT(系统建议额度),落 TM_MID_APS_RESULT / TM_APP_MAIN;同表并列 APP_LMT 申请额度、ACC_LMT 核准额度、CREDIT_LIMIT 授信额度,四者的区别正是「报价 vs 核定」:引擎出 SUG_LMT,裁决核定 ACC_LMT。出处:IT 知识库 code_full.db db_columns(ICRC-icrc-tcs TM_MID_APS_RESULT / icrc-midaps TM_APP_MAIN)Leo · 2026-09-08待改:P072 引擎建议额度
G-006缺口U01 开通与授信
钱包账户中级户对应的等级码不明
缺什么:P076 钱包账户等级 里"中级户"对应的取值(mpcLevel)没有找到,目前只见到 01=初级户、03=Prime。
为什么缺/线索:出处只出现了 01 和 03 两个字面值(01§D.3、01§D.5)。
涉及:P076 钱包账户等级出处:01§D.3·01§D.5
登记原文
P076 钱包账户等级: 中级户 mpcLevel 取值字面未见（仅见 01 初级/03 Prime）✓ 已收口 · 已补齐中级户 mpcLevel=02(实名 / Allo Pay Plus);全集 01 初级/02 中级/03 Prime;01、02 台账在 idwlt,03 权威在 idp(idwlt 只转发);03→02 为 Prime 降级IT 知识库 2_code_graph/api_catalog/snapshots/2026-07-21/groups/032-group-32.md L205、006-group-6.md L236、membership-and-ledger-routing.md §1、pojk-account-status-change-notification.md §1(WeFi-NY/knowledge-base@0d93e0f)trista · 2026-09-08待改:P076 钱包账户等级
G-017缺口U01 开通与授信
开户段三个引擎的输出字段不明
缺什么:F-20 激活反欺诈、F-53 人脸比对与名单库查询、F-54 开户反欺诈初审 三个引擎的输出字段没有登记,目前只有名字没有内容。
为什么缺/线索:引擎矩阵和后端地图只列了引擎名和调用点(02§引擎矩阵、R10§4.01)。
涉及:F-20 激活反欺诈F-53 人脸比对与名单库查询F-54 开户反欺诈初审出处:02§引擎矩阵·R10§4.01
登记原文
F-20 激活反欺诈 / F-53 人脸比对 / F-54 开户初审: outputs 字段未见（壳）✓ 已收口 · 已补齐三张表分工明确:结论落 TM_AFS_CASE.ACTION_TYPE(放行/挑战/拒绝),反欺诈中台逐次调用明细落 TM_MID_AFS_RESULT,活体与三方核身流水落 TM_THIRDPARTY_LIVENESS_FLOW。F-20/F-54 取结论表+明细表,F-53 取核身流水表 [2026-09-08 修正:收口时把三张表名直接填进了 F-20/F-53/F-54 的 outputs,位置不对——纲要 1.4 规定一期不接触数据字段,outputs 的字段义是「产物落到哪(P/N 号)」。已新立 P246 开户反欺诈裁决(宿主 N013,writer F-20·F-54·F-53)承载业务侧结论,outputs 改指 P246;三张表名降为 P246 note 里的二期接地线索,知识不丢。]Leo · 2026-09-08待改:F-20 激活反欺诈（CFMC，ICRC-MIDAFS） · F-53 人脸比对与名单库查询（IKYC 88400008 + IBG 三库 + 公安比对） · F-54 开户反欺诈初审（ICRC-MIDAFS 88100019）
G-024缺口U02 支付消费
商户订单三个单号如何对应、商户写入字段无归属
缺什么:N077 商户订单 上有三个标识(order_no、mpcOrderNo、MER_BIZ_NO),彼此的对应关系没有说明;由商户侧写入的字段(订单总额 totalAmt、商品清单 goodsList)写入方是外部商户系统,本体里没有对应的写入方类型可挂。
为什么缺/线索:出处只见字段名(02§D.1)。
涉及:N077 商户订单出处:02§D.1
登记原文
N077 商户订单: order_no / mpcOrderNo / MER_BIZ_NO 三个标识的对应关系未明；商户侧写入字段（totalAmt/goodsList）无本体写入方类型（写入方=商户系统）✓ 已收口 · 已补齐三个单号共存于组合支付的同一行:order_no 平台订单号 / external_order_no 商户外部订单号 / mpc_order_no 钱包订单号,另有 biz_seq_no·pay_biz_seq_no 支付流水号;商户写入字段落点 totalAmt→total_amount·order_amount、goodsList→goods_details、商户身份→merchant_id·merchant_name。出处:IT 知识库 2_code_graph/code_full.db db_columns(repo=ihybrid-servicedcn, table=order_info / payment_info)Leo · 2026-09-08待改:N077 商户订单 · P100 订单总额 · P101 商品清单
G-025缺口U02 支付消费
取现风控挑战没有独立单号,结果写入方未建档
缺什么:N078 风控挑战(取现挑战码 1212)没有独立单号,缺唯一标识;P109 挑战结果 的写入方——人脸比对(IKYC)或 OTP 平台——没有建档为函数构件。
为什么缺/线索:出处只见挑战码和结果字段(02§D.3、R3§⑥)。
涉及:N078 风控挑战P109 挑战结果出处:02§D.3·R3§⑥
登记原文
N078 风控挑战（取现 1212）: 取现挑战无独立单号，身份标识缺；挑战结果 P109 写入方（IKYC 人脸比对/OTP 平台）未建档为函数✓ 已收口 · 已补齐挑战工单有真正主键:IKYC TM_CASE.FACE_ID(唯一键 TRANS_REF_NBR+ORG_SYS_ID),N078 身份标识已改为它;faceScanAppNo 降为支付侧引用外键。结果写入方定位到 ikyc-nyservice(8056)/RCS-OTP·IUMS-OTP,已记入 P109,是否另建函数构件另议Leo · 2026-09-08待改:N078 风控挑战 · P109 挑战结果
G-027缺口U02 支付消费
支付引擎入参场景码值和裁决结果字典缺失
缺什么:P104 支付场景标识 传给引擎的场景枚举真实码值没有;P106 放款反欺诈引擎决策-消费 及相邻引擎决策字段(P108)的输出裁决字典(放行/挑战/拒绝各是什么码)也没有;风险码字典与策略包版本同样缺。
为什么缺/线索:IT 知识库查不到(R4§3、R10§6)。
涉及:P104 支付场景标识P106 放款反欺诈引擎决策-消费出处:R4§3·R10§6
登记原文
P104 支付场景标识 / P106·8 引擎决策: 引擎入参场景枚举真实码值与引擎输出裁决字典（放行/挑战/拒绝码）未见；RiskCode 字典与策略包版本 IT KB 查不到✓ 已收口 · 已补齐原判「IT KB 查不到」不成立,契约是全的:入参 payMethod 六值(ALLO_BANK_APP/ALLO_BANK_WEB/ALLO_QRIS_MPM/ALLO_QRIS_CPM/ALLO_QRIS_CASHOUT/ALLO_QRIS_CASHOUT_STORE);裁决 actionType 六值(1 通过/2 拒绝/7 刷脸/101 线上问题核身/102 人工审核/103 拒绝后异步核身),随行 ruleVersionNo(即缺口问的策略包版本)/ruleCode/riskLevel/blockCode/controlPeriod。P106 已按真实码值改登,P104/P108 补对应与差异。⚠ 该契约属 IGK-AFS 88200042-01(bizType=PAY),非登记的 CLPY(ICRC-MIDAFS),两实例是否共用同一字典待后端确认——引用时须注明实例来源Leo · 2026-09-08待改:P104 支付场景标识 · P106 放款反欺诈引擎决策-消费 · P108 挑战类型
G-028缺口U02 支付消费
QRIS 主扫两种形态只有 PM 口述,缺书面来源
缺什么:P105 QRIS 码形态 里"主扫有两种形态"的说法目前只有 PM 口述(2026-07-16),没有书面 PRD 依据。
为什么缺/线索:三篇 QRIS 源 PRD 都没有明写主扫两形态,待归档补源(02§QRIS 主扫的两种形态)。
涉及:P105 QRIS 码形态出处:02§QRIS 主扫的两种形态
登记原文
P105 QRIS 码形态: PM 口述口径（2026-07-16），源 PRD 三篇 QRIS 文档未显式记载主扫两形态，待归档补源✓ 已收口 · 已补齐已有书面来源:IT 知识库 5_domain_knowledge/wallet-open-upgrade-qris-transfer.md:31,33 明写「MPM 主扫(普通 QRIS·用户扫商户静/动态码付款,最常见消费)」并附生产量级 ~560 万次/3h,不再是仅 PM 口述。已补进 P105 与 L221 的出处,口径未变Leo · 2026-09-08待改:P105 QRIS 码形态 · L221 QRIS 主扫动态码（商户按订单生成）支付金额随
G-029缺口U02 支付消费
虚拟卡属性写入方未建档,自动补足规则待 PM
缺什么:N011 VDC 虚拟借记卡 的几个属性——P111 VDC 卡限额、P114 VDC 最近一次支付时间、卡号后四位——写入方是卡系统/支付枢纽,但没有建档;自动补足(Auto top-up)从信贷额度还是钱包补、触发阈值是多少也没有定。
为什么缺/线索:补足来源与阈值在 03 篇标为待 PM(02§VDC Auto top-up、03§待确认)。
涉及:N011 VDC 虚拟借记卡P111 VDC 卡限额P114 VDC 最近一次支付时间出处:02§VDC Auto top-up·03§待确认
登记原文
N011 VDC 属性写入方: VDC limit（P111）、最近支付时间（P114）、卡号后四位写入方=卡系统/支付枢纽，未建档；Auto top-up 补足来源（额度 vs 钱包）与触发阈值 03 篇标待 PM✓ 已收口 · 已补齐虚拟卡属性的落库字段与写入方已查实:卡限额=virtual_card_info.card_limit(接口 dailyAmtLmt,由 88200106-UPDATE_CARD_VELOCITY_LIMIT 写)、最近支付时间=virtual_card_transaction_latest_record、PL 补足开关=paylater_top_up_switch(ON/OFF/INACTIVE,由 88200106-SWITCH_PL_TOPUP 写);写入方统一为 VDC 发卡子系统 ihybrid-virtualcard(88200106)——也印证卡号后四位当初填 A-22 授信裁决是错的。自动补足的触发阈值另登 G-205。出处:IT 知识库 code_full.db db_columns(repo=ihybrid-virtualcard) + api_catalog 2026-07-21 groups/007:155,161,286Leo · 2026-09-08待改:P111 VDC 卡限额 · P114 VDC 最近一次支付时间 · P115 卡号后四位
G-034缺口U02 支付消费
付款码只对 Prime 钱包开放,但档位判据未建档
缺什么:L220 规则(付款码出码仅 Prime 钱包档放行)依赖的钱包档位属性(mpcLevel/Prime)没有单独建档,目前引用时以 N003 Allo Wallet 钱包账户 代替;"什么算 Prime 档"的具体判据也没有。
为什么缺/线索:档位判据待 U01/钱包侧给出(R10§4·02)。
涉及:L220 规则:付款码出码仅 Prime 档N003 Allo Wallet 钱包账户出处:R10§4·02
登记原文
L220 CPM 出码 Prime 档: 钱包档位属性（mpcLevel/Prime）未在本单元建档，refs 以 N003 代；具体档位判据待 U01/钱包侧✓ 已收口 · 已补齐钱包档位字段 = mpcLevel,字典 01 初级 / 02 中级(实名) / 03 高级;「Prime 档」即 mpcLevel=03(ADVANCED = Allo Prime),为 L220「CPM 出码仅 Prime 钱包档放行」的判据。已补进 P076 取值。出处:IT 知识库 api_catalog groups/032:205 + 5_domain_knowledge/deposit-hold-freeze-codes.md:97Leo · 2026-09-08待改:P076 钱包账户等级 · L220 CPM 付款码出码仅对 Prime 钱包档用户放
G-041缺口U03 取现 Instant Cash
引擎判断首借还是复借的依据字段不明
缺什么:L023 规则(首支走首账前审批)和 P122 曾借款标记 背后,引擎判断一笔取现算首借还是复借的判据存在数据库里,具体字段名和表没有登记。
为什么缺/线索:需要业务方确认(03§口径补充、R10§5)。
涉及:L023 规则:首支走首账前审批P122 曾借款标记出处:03§口径补充·R10§5
登记原文
L023 / P122: 引擎侧首借/复借切换判据存 DB,字段名与表未见(需业务方确认)✓ 已收口 · 已补齐首借/复借的引擎侧判据字段:icps.TM_AUTH_LOAN.FIRST_FLAG(标识首笔借款,首借时 setFirstFlag(Y))与反欺诈入参 icrc-midafs.TM_DATA_PAY_TRADE.IS_FIRST_LOAN(是否首次借贷);与前端 cashState 是两套,不一致时以引擎侧为准。已写入 L023 备注。出处:IT 知识库 code_full.db db_columns(icps.TM_AUTH_LOAN / icrc-midafs.TM_DATA_PAY_TRADE) + 1_scv_summaries/icps/STATE_MACHINE.md:41Leo · 2026-09-08待改:L023 取现无成功放款记录的客户按首支走首账前借款审批引
G-056缺口U04 账单与账期、常规还款
还款宽限期 10 天从哪天起算
缺什么:宽限期 10 天的起算点没有说清——是「出账日到最后还款日」之间的缓冲(两代账期表面上是 9-10 天),还是「最后还款日之后到被标记逾期/上 A 锁定码」之间的缓冲。
为什么缺/线索:04§账期规则只写了 10 天但没写起点;R1§Block code 写的是「过了宽限日就上 A 码」,两者的关系待 PM/后端确认。
涉及:L255 规则:还款宽限期 10 天出处:04§账期规则·R1§Block code
登记原文
L255 宽限期 10 天: 起算点未明：是出账日→最后还款日的缓冲（两代表面上为 9-10 天），还是最后还款日后至标记逾期/上 A 码的缓冲；与 R1'过宽限日→上 A'的关系待 PM/后端确认✓ 已收口 · 已补齐宽限期起算点是最后还款日 PMT_DUE_DATE,终点是 graceDate(借据级 GRACE_DATE);过 graceDate 仍有未还转入本利罚才上 A 码;"出账日→还款日"9-10 天是账期间隔,不是宽限期。10 天数值仍是 PM 口径,现网 graceDays 参数待核IT 知识库 icps-block-codes-core.md §4(pmtDueDayCalcStrategy=G 须过 graceDate)、icps-billing-cycle-and-future-schedule-query.md 字段表(2026-08-31)、paylater-billing-statement-lifecycle.md §5(WeFi-NY/knowledge-base@0d93e0f)trista · 2026-09-08待改:L255 还款宽限期是产品参数,本条不写天数;宽限、出账归 · L063 账单到最后还款日(由账户的账单日对应的产品参数定
G-057缺口U04 账单与账期、常规还款
10 天 cutoff 规则和灵活码第 31 位是一回事吗
缺什么:灵活码第 31 位「按 cutoff day 出账/无 cutoff day」是否就是 04 篇说的 10 天 cutoff 归属规则,没有对上;另外借新还旧的新借据「默认跟随最近账单日」到底是什么意思,也没有说清。
为什么缺/线索:R1 对第 31 位只有一句位段说明,04§账期规则只讲 10 天规则,两边没互相引用。
涉及:L252 规则:cutoff day 10 天出账归属L253 规则:借新还旧新借据跟随最近账单日P002 灵活码出处:R1 第 31 位·04§账期规则
登记原文
L252 / L253 cutoff day 与 Flex 第 31 位: R1 第 31 位'按 cutoff day 出账/无 cutoffday'是否即 04 篇的 10 天 cutoff 规则；借新还旧新借据默认 follow 最近账单日的准确含义✓ 已收口 · 已补齐是同一机制:cutoff 归属规则由账户级 TM_ACCOUNT.cutOffDay 承载;灵活码第 31 位是"本笔新借据是否跳过 cutoff、直接跟随最近账单日"的资格位(0=按 cutoff / 1=follow,默认 1),经报文字段 CUT_OFF_DAY_STRATEGY 传核心;L253"跟随最近账单日"= 首期账单日取最近账单日而非按 cutoff 顺延IT 知识库 ifes-flexcode-management.md §2C/§5(2025-12-25 spec 示例)、lifecycle §5、icps SUMMARY TM_ACCOUNT(cutOffDay/billingCycle)、zcnc-cindy-define-replace-semantics.md(WeFi-NY/knowledge-base@0d93e0f)trista · 2026-09-08待改:L252 出账归属截止日是产品参数,含义是「月内截止日」, · L253 借新还旧新借据 Flex 第 31 位=1（默认 · P002 灵活码
G-058缺口U04 账单与账期、常规还款
退款是什么情况触发、退到哪里、能不能撤
缺什么:退款动作的触发条件(是客户多还/溢缴退款,还是商户发起退款,两种含义未分)、到账路径(退到钱包还是原路退回)、能否撤销、有什么前置条件,全部没有登记。
为什么缺/线索:04§待确认与「待确认清单·后端 3」都挂着这个问题;目前只知道两个技术锚点(ICPS 222111 退款接口、QRIS 的 refund-qris-payment 与 reversal),待后端补齐。
[2026-08-27 SEG2 核验补充具体问题:退款(A-36)与 VDC 撤销(A-58)写入不对称——A-58 写借据冲销与额度恢复,A-36 两者都不写,积分腿与钱包腿的返还写入方也空缺。请后端一次答清四条腿(PL/钱包/积分/立减)各自的回退路径与写入方。]
涉及:A-36 退款N053 退款单出处:04§待确认·_待确认清单 后端 3
登记原文
A-36 退款: 触发条件（多还/溢缴 vs 商户退款两义）、到账路径（钱包 or 原路）、可逆性、前置条件全缺；已知锚点 ICPS 222111 / QRIS refund-qris-payment+reversal✓ 已收口 · 已补齐四条腿逐腿落库:PL=refunded_loan_amount、钱包=refunded_cash_amount、积分=refunded_bonus_points、券/立减=refunded_coupon_amount(另有 refunded_amount 合计、refunded_fee、refunded_times);退款接口 88200082-payment-refund,支持部分退款可多次;撤销与退款是并列终态。订正:ICPS 222111 不是退款接口而是「还款/退款记录查询」。出处:IT 知识库 code_full.db db_columns(ihybrid-servicedcn payment_info) + api_catalog groups/028:87-120、groups/026:886 + 1_scv_summaries/icps/SERVICE_MAP.md:114Leo · 2026-09-08待改:A-36 退款
G-062缺口U04 账单与账期、常规还款
账龄档 1-9 各对应多少天、挂在账户还是借据上
缺什么:账龄档(AGE_CD)1-9 的完整取值与对应天数区间没有登记;它是账户级还是借据级的属性也不清楚。
为什么缺/线索:05§E.1、05§E.6、R1 里只零散用到个别值(如 >4 用于核销门槛),没有完整字典。
涉及:P132 账龄档出处:05§E.1·05§E.6·R1
登记原文
P132 AGE_CD: 完整 1-9 取值与天数映射；宿主级别（账户 vs 借据）✓ 已收口 · 已补齐AGE_CD 1-9 为 30 天一档(1=1-30 … 9=241+ 天),账户级 tm_account.AGE_CD(伴 AGE_HIST 24 期、LAST_AGING_DATE)与借据级 AGE_CD 两级并存,账户级为主档;档位按自然月推进,是近似区间不是 DPD 硬换算IT 知识库 5_domain_knowledge/ifes-blockcode.md §2、icps-block-codes-core.md §1/§3(2026-07-18 ②③④ 交叉)、icps-manual-writeoff-flow.md §6.3(UAT 2026-07-22 快照)(WeFi-NY/knowledge-base@0d93e0f)trista · 2026-09-08待改:P132 账龄档
G-064缺口U04 账单与账期、常规还款
交易流水收支方向:查实客户层无方向字段,须由交易类型推导
缺什么:交易流水的金额方向(哪些是收、哪些是支,正负号怎么定)没有定义;会员费交易显示的商户名要后端确认;流水记录和消费支付、还款这些业务事件是不是「同一件事的两个视角」、实例怎么对应,还没有建模决定。
为什么缺/线索:R7§2.3 只列了流水字段,方向与映射留白。
涉及:N037 交易流水(记录)N018 还款交易N015 消费支付交易出处:R7§2.3
登记原文
N037 交易流水: 金额方向（收/支符号）无定义；会员交易商户名待后端；N037 与 N018/N015 等业务事件的实例对应关系（同一事实两视角）待建模决定✓ 已收口 · 已补齐确定的否定答案:借贷方向标志 DB_CR_IND 只在 GL 会计层存在,不下发到客户可见流水层。故客户侧收支方向须由交易类型(P037)推导,登记表不应再期待一个方向字段。与业务事件的对应关系随 P037 的取值语义承载。Leo · 2026-09-08待改:P037 交易类型 · N037 交易流水（记录）
G-066缺口U04 账单与账期、常规还款
账期参数是谁在哪配置的
缺什么:账期参数组(出账日、还款日、宽限期等)的写入方——是哪个后台配置项或参数表在维护——没有建档。
为什么缺/线索:04§账期规则只写了规则值,没写来源系统。
涉及:P133 账期参数组出处:04§账期规则
登记原文
P133 账期参数组: 写入方（后台配置项/参数表）未建档✓ 已收口 · 已补齐账期参数两层:账户级 TM_ACCOUNT.billingCycle/cutOffDay/nextStmtDate 由正式首借 S31015 在 firstPurchaseDate 为空时计算并持久化(试算 222117 不落库);产品级出账/宽限/Z 阈值在 inycpsdb.tm_prm_object(ProductCredit/StmtRule XML)由 DML 发版维护,无运营后台改写入口IT 知识库 icps-billing-cycle-and-future-schedule-query.md(② 2026-08-31)、icps-payment-allocation-hierarchy.md §1(UAT 2026-08-11 双 DCN 直查)、icps-core FILE_INDEX(CoreStmtRule/CoreComputeGraceAndStmtDay)(WeFi-NY/knowledge-base@0d93e0f)trista · 2026-09-08待改:P133 账单日
G-147缺口U09 参考层字典(横切属性与枚举正本)
钱包状态由谁改写、钱包等级全部码值未知
缺什么:P199 钱包账户状态的锁定/冻结/解锁/销户动作没有建档,写入方未登记;P076 钱包账户等级的中级户码值未见,03=Prime 只是推断,全部取值待后端。
为什么缺/线索:出处 R5§⑧、功能说明/01。
涉及:P199 钱包账户状态P076 钱包账户等级出处:R5§⑧·功能说明/01
登记原文
P199 mpcStatus / P076 mpcLevel: 钱包锁定/冻结/解锁/销户动作未建档(writer=null);mpcLevel 中级户码值、03=Prime 为推断,全值待后端✓ 已收口 · 已补齐mpc_status 7 值(00/01/02/10/20/30/99);写入方五类(RCSDBCORE 运营台人工、igk-afs 反欺诈 101001011、WEBOS 案件、ihybrid PRM 8265/8264、IMED_CS POJK 06:15 批量)经 88200084 FREEZE_MEMBER→idwlt-memidadcn 88200087 落 mem_info.mpc_status + mem_status_log.originate_sys;锁定 20 由 T+1 memberUnlockTasklet 自动解,冻结 30 无到期仅 RCS 人工解;PROD 2026-07 司法 hold 100% 人工IT 知识库 deposit-hold-freeze-codes.md §0/§5/§7(2026-07-18 ②③④)、pojk-account-status-change-notification.md §2(2026-07-25)(WeFi-NY/knowledge-base@0d93e0f);写入动作本次新立(见 audit create)trista · 2026-09-08待改:P199 钱包账户状态
G-155缺口U09 参考层字典(横切属性与枚举正本)
借据订单/协议状态适用哪些交易、由谁写入
缺什么:P202 借据订单/协议状态(INBS AgreementStatus)适用于哪些交易(取现、借新还旧、账单分期是否都走 INBS 订单)、由哪个动作写入,没有登记;它挂在 N005 借据上只是推断。
为什么缺/线索:出处 R5§⑧、功能说明/05§E.5。
涉及:P202 借据订单/协议状态(INBS)N005 借据(IOU)出处:R5§⑧·功能说明/05§E.5
登记原文
P202 AgreementStatus: 适用交易范围(取现/借新还旧/账单分期是否都走 INBS 订单)与写入动作;host 取 N005 为推断✓ 已收口 · 已补齐定义源=INBS nbs-nanyang-comm-def(构造器带 desc/isFinalState/isCanCancel);写入方=INBS 联机状态机;适用于 INBS 放款类交易:取现 160101、消费 160102、JXHJ 族含账单分期——host=N005 借据由推断转为已证,借新还旧走 INBS 订单同时得证。附带修正:原 note 的「INBS 200xxx 交易」与 KB 的 160101/160102 不符,以 KB 为准待后端复核Leo · 2026-09-08待改:P202 借据订单/协议状态(INBS) · N005 借据
G-165缺口finalize
取现借款审批决策的取值字典未登记
缺什么:P127 取现借款审批决策的枚举取值字典没有登记。
为什么缺/线索:出处 03§业务规则速览、02§引擎矩阵、R10§4.03、03§口径补充;文档中未见。
涉及:P127 取现借款审批决策出处:03§业务规则速览·02§引擎矩阵·R10§4.03·03§口径补充
登记原文
P127: 枚举取值字典未载(文档未见)✓ 已收口 · merged与 G-038 是同一个缺口(P127 取现借款审批决策取值字典缺失),合并;结论以 G-038 为准Leo/claude · 2026-08-27
IF-03接口候选U02 支付消费
三类支用事件共用同一套准入闸门,可归并为「可支用」
建议:把消费支付交易(N015)、渠道侧支付(N016)、取现支用(N017)归并为一个「可支用」接口。
理由:三者共用邮箱未验证拦截(L015)、五级准入检查(L016)、PIN 必验(L017)、引擎串行过闸(L021/L022)以及下发风控挑战(A-27),同一句规则已在受理支付交易(A-04)与受理取现申请(A-05)各写一遍(出处 02§支用决策引擎矩阵、02§关键字段与门槛)。
涉及:N015 消费支付交易N016 渠道侧支付N017 取现支用A-04 受理支付交易A-05 受理取现申请A-27 下发风控挑战L015 规则:邮箱未验证拦截支用L016 规则:支用五级准入检查L017 规则:提交前必验 PIN出处:02§支用决策引擎矩阵·02§关键字段与门槛
登记原文
此处或可归并接口「可支用」：消费支付 N015 / 渠道侧支付 N016 / 取现 N017 共用邮箱验证拦截 L015、五级准入 L016、PIN 必验 L017、引擎串行过闸（L021/L022）与挑战下发 A-27——同句已在 A-04 与 A-05 各写一遍 候选:N015·N016·N017✓ 已收口 · 不立接口先不立接口:共用闸门已由多宿主规则(L016/L017/L021 等)表达,实现者属性槽位未对齐;按 2.6「归并优先合并属性」,留三期归并阶段统一处理Leo · 2026-09-08
IF-04接口候选U02 支付消费
凡需试算的场景共用定价引擎规则,可归并为「可试算」
建议:把消费支付(N015)、取现(N017)、月最低还款(N019)、账单分期(N020)、逾期重组(N021)、转分期(N022)以及 VDC 激活弹窗归并为一个「可试算」接口。
理由:这些场景共享「凡向用户展示试算结果必调定价引擎」(L192)与「试算档默认选中」(L052)两条规则(出处 R4§3)。
涉及:N015 消费支付交易N017 取现支用N019 月最低还款申请N020 账单分期申请N021 逾期重组申请N022 转分期(展期)申请L192 规则:展示试算结果必调定价引擎L052 规则:试算档默认选中出处:R4§3
登记原文
此处或可归并接口「可试算」：消费支付/取现/最低还款/账单分期/转分期/逾期重组/VDC 激活弹窗共享 L192（必调定价引擎）与 L052（默认选中） 候选:N015·N017·N019·N020·N021·N022✓ 已收口 · 不立接口先不立接口:共用约束已由 L192(凡展示试算必实时调引擎、禁本地价格表)一条管全部场景,本身即批发效果,再立接口是重复;留三期归并阶段Leo · 2026-09-08
IF-05接口候选U03 取现 Instant Cash
取现/支付/还款受理共用三道门,可归并为「可受理」
建议:把取现支用(N017)、消费支付交易(N015)、还款交易(N018)的受理动作(A-04/A-05/A-06)归并为「可受理」接口。
理由:三者共享邮箱门(L015)、五级检查(L016)、PIN 门(L017),同一句规则要抄多遍(出处 03§D.1、索引 L015/L016/L017)。
涉及:N017 取现支用N015 消费支付交易N018 还款交易A-04 受理支付交易A-05 受理取现申请A-06 受理还款L015 规则:邮箱未验证拦截支用L016 规则:支用五级准入检查L017 规则:提交前必验 PIN出处:03§D.1·索引 L015/L016/L017
登记原文
此处或可归并接口'可受理':取现/支付/还款受理动作 A-04/A-05/A-06 共享邮箱门(L015)、五级检查(L016)、PIN 门(L017)同一句要抄多遍 候选:N017·N015·N018✓ 已收口 · 不立接口先不立接口:按纲要 v3.0 的 2.6「归并优先合并属性,绑定只是折中」,三类受理动作的门虽同形但属性槽位尚未对齐,且共用规则 L017 已用多宿主表达;留待三期归并阶段统一处理Leo · 2026-09-08
IF-06接口候选U03 取现 Instant Cash
产生新借据的申请共用签约门,可归并「可签约」
建议:把取现支用(N017)、月最低还款(N019)、账单分期(N020)、逾期重组(N021)、转分期(N022)这类会产生新借据的申请归并为「新借据类/可签约」接口。
理由:「勾选已阅读同意 RIPLAY 且合同加载完成」这道提交门(L049)在受理取现(A-05)、受理账单分期(A-09)、受理逾期重组(A-10)、受理转分期(A-11)里抄了四遍(出处 03§D.4、索引 L049)。
涉及:N017 取现支用N019 月最低还款申请N020 账单分期申请N021 逾期重组申请N022 转分期(展期)申请L049 规则:RIPLAY 勾选与合同加载门A-05 受理取现申请A-09 受理账单分期申请A-10 受理逾期重组申请A-11 受理转分期(展期)申请出处:03§D.4·索引 L049
登记原文
此处或可归并接口'新借据类/可签约':RIPLAY 勾选∧加载完成门(L049)在 A-05/A-09/A-10/A-11 抄四遍 候选:N017·N019·N020·N021·N022✓ 已收口 · 不立接口先不立接口:合同门已由 L049 多宿主(A-05·A-09·A-10·A-11)表达;留三期归并阶段——届时若把 RIPLAY 合同下发要素组 P128 合成共享属性,本条最具备立接口条件Leo · 2026-09-08
IF-07接口候选U04 账单与账期、常规还款
会落交易流水的事件可归并为「可入流水」接口
建议:把消费支付(N015)、渠道侧支付(N016)、取现(N017)、还款(N018)、退款单(N053)、转分期申请(N022)以及质押代偿归并为「可入流水」接口,统一落入交易流水(N037)。
理由:它们都以交易类型(TRANSACTION_TYPE)一行落入流水,且同一条 180 天/分页规则、同一详情分发规则要写多遍(出处 R7§2.1-2.2)。
涉及:N015 消费支付交易N016 渠道侧支付N017 取现支用N018 还款交易N053 退款单N022 转分期(展期)申请N037 交易流水(记录)出处:R7§2.1-2.2
登记原文
此处或可归并接口「可入流水」：支付 N015 / 渠道侧支付 N016 / 取现 N017 / 还款 N018 / 退款 N053 / 展期申请 N022 / 质押代偿 都以 TRANSACTION_TYPE 行落入 N037，且同一条 180 天/分页规则、同一详情分发规则要写多遍 候选:N015·N016·N017·N018·N053·N022·N037✓ 已收口 · 不立接口先不立接口:流水字段组 P040 与交易状态码 P038 已作为共享属性挂在各交易事件上,共性已表达;留三期归并阶段(届时可直接用这两个 P 号作 shape.properties)Leo · 2026-09-08
IF-08接口候选U04 账单与账期、常规还款
借据与账单共享「足额到账即结清」规则,可归入「可核销」
建议:借据(N005)是核销/结清对象;账单(N045)与借据共享「足额到账→F/结清」这条同形规则(L074、L270),可一并归入手册已有的「可核销」接口。
理由:两者结清判定形状相同,分别写会重复(出处 R5§③、R5§⑧)。
涉及:N005 借据(IOU)N045 账单L074 规则:账单足额到账结清L270 规则:借据结清与可用额度推导出处:R5§③·R5§⑧
登记原文
「可核销」（手册已知接口）：借据 N005 为核销/结清对象；账单 N045 与借据 N005 共享'足额到账→F/结清'同形规则（L074 / L270） 候选:N005·N045✓ 已收口 · 不立接口先不立接口:说明书虽把「可核销」列为已知接口,但借据状态 P031 与账单状态 P025 仍是两套枚举,按 2.6「归并优先合并属性」应先合属性再立接口;留三期归并阶段Leo · 2026-09-08
IF-12接口候选U06 质押与额度成长(LimitUp 专属)
三类可质押资产共用杠杆门控,可归并为「可质押」
建议:把定存存单(N006)、钱包现金(代建 TD,N003)、积分账户(N004)三类资产归并为「可质押」接口。
理由:三者共用杠杆率门控与释放调度规则(出处 09§核心能力、09§后端事实增补)。
涉及:N006 定存存单N003 Allo Wallet 钱包账户N004 积分账户出处:09§核心能力·09§后端事实增补
登记原文
此处或可归并接口:可质押——定存存单/钱包现金(代建 TD)/积分三类资产共用杠杆率门控与释放调度 候选:N006·N003·N004✓ 已收口 · 不立接口先不立接口:质押主体在场景⑨(流动性定存与质押),不是支付段的主体;留三期归并阶段,建议核⑨时与该段一并定Leo · 2026-09-08
IF-13接口候选U07 会员与营销
权益券与支付立减券共享同一状态机,可归并为券族接口
建议:把营销权益券(N048)与 SMP 支付立减券(N049)归并为「可发放/可核销券族」接口。
理由:两者共享「发放→可用→使用/作废/过期」状态机,以及发放/作废权益券(A-37)、角标计数、锁定码展示门等同一句规则(出处 11§优惠券、R3§④)。
涉及:N048 营销权益券(EQUITY)N049 SMP 支付立减券A-37 发放/作废权益券出处:11§优惠券·R3§④
登记原文
此处或可归并接口:可发放/可核销券族——N048 权益券与 N049 SMP 券共享'发放→可用→使用/作废/过期'状态机与 A-37 发放/作废、角标计数、blockCode 展示门等同句规则 候选:N048·N049✓ 已收口 · 不立接口先不立接口:两类券的状态枚举与属性尚未合并(权益券 N048 与立减券 N049 各有一套,后者还带实例字段组 P173),按 2.6 应先合属性;留三期归并阶段(主责在场景⑦会员与营销)Leo · 2026-09-08
IF-16接口候选U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)
八类受理动作前都要验 PIN,可归并为「可验密」接口
建议:把消费支付(N015)、取现(N017)、还款(N018)、转分期(N022)、质押(N025)、解押(N026)、会员购买(N028)、重新授信(N024)归并为「可验密(PIN-gated)」接口。
理由:「提交前必验 PIN」(L017)这同一句规则挂在 8 类受理动作前面,目前是挂在 PIN 校验(A-49)上作为族级门(出处 功能说明/12 §A)。
[2026-09-08 Leo 决定:立「可验密」接口。但落地受阻两点,已转为待办——① 平台侧接口表未启用(data/registry 下无 interfaces.yaml,schema 与 registry 也无接口类型),需 trista 补;② 按 2.6「归并优先合并属性」自查:八类受理动作共用的是一条前置条件规则(L017,现用多宿主表达),实现者身上没有共同的属性槽位,shape.properties 暂时填不出——需在归并时先确认是否存在可合并的共享属性(如「验密状态/验密时点」),或按 shape.actions 单列(动作签名 A-49 PIN 校验 + 八类受理动作)。拟定实现者:消费支付交易 N015、取现支用 N017、还款交易 N018、转分期 N022、质押记录、会员购买 N028、授信申请 N013。]
涉及:N015 消费支付交易N017 取现支用N018 还款交易N022 转分期(展期)申请N025 质押申请N026 解押申请N028 会员购买/续费N024 重新授信申请(reapply)A-49 PIN 校验L017 规则:提交前必验 PIN出处:功能说明/12-支撑流程(账户安全·引导·结果页).md§A
登记原文
此处或可归并接口「可验密（PIN-gated）」：L017 同一句规则挂在 8 类受理动作（支付/取现/还款/转分期/质押/解押/购会员/reapply）前，现挂 A-49 作族级门 候选:N015·N017·N018·N022·N025·N026·N028·N024✓ 已收口 · 立接口已立为 IF-16 可验密,登在 data/registry/interfaces.yaml。shape.properties 暂空(八类实现者身上没有共同属性槽位,验密状态/验密时点均未登记为属性),先以 shape.actions=A-49 单列;是否应立「验密状态」共享属性另开 G-209。Leo · 2026-09-08
IF-19接口候选U09 参考层字典(横切属性与枚举正本)
支用/还款类事件的状态枚举同形,可归并为「可受理」
建议:把消费支付(N015)、取现(N017)、还款(N018)、月最低还款(N019)、账单分期(N020)、逾期重组(N021)、转分期(N022)归并为「可受理」接口。
理由:各自的状态枚举(SPENDING_STATUS/CASH_LOAN_STATUS/REPAY_STATUS/extensionStatus/jxhjOrderStatus)共用 P/S/C(+F)三四态形状,且「同步受理≠终态」(L385)这条规则要对整族生效(出处 R3§⑥、R5§④⑧、R7§2.3)。
涉及:N015 消费支付交易N017 取现支用N018 还款交易N019 月最低还款申请N020 账单分期申请N021 逾期重组申请N022 转分期(展期)申请L385 规则:跨系统同步受理+异步回执出处:R3§⑥·R5§④⑧·R7§2.3
登记原文
此处或可归并接口『可受理』:N015/N017/N018/N019/N020/N021/N022 各自的状态枚举(SPENDING_STATUS/CASH_LOAN_STATUS/REPAY_STATUS/extensionStatus/jxhjOrderStatus)共用 P/S/C(+F)三四态形状,且『同步受理≠终态』(L385)要对全族生效。 候选:N015·N017·N018·N019·N020·N021·N022✓ 已收口 · 不立接口先不立接口:各事件的状态属性仍各登各的(取现订单状态 P211、借据状态 P031、还款状态 P208 等),枚举未合并;留三期归并阶段,届时与 IF-05(同名「可受理」,归的是门)一并落地,注意别登成两条Leo · 2026-09-08
IF-20接口候选U09 参考层字典(横切属性与枚举正本)
锁定码对支用拦截、对还款放行的规则可归并为「可锁定/可管控」
建议:把消费支付(N015)、取现(N017)、还款(N018)归并为「可锁定/可管控」接口。
理由:锁定码(blockCode)各字符对支付/取现的拦截、对还款不拦截(L381)这套规则在受理支付(A-04)、受理取现(A-05)、受理还款(A-06)各处重复引用(出处 R1§五、R5§②)。
涉及:N015 消费支付交易N017 取现支用N018 还款交易P005 冻结/拦截码(锁定码)L381 规则:还款方向不受锁定码拦截A-04 受理支付交易A-05 受理取现申请A-06 受理还款出处:R1§五·R5§②
登记原文
此处或可归并接口『可锁定/可管控』:blockCode 各字符对支付/取现的拦截、对还款的不拦截(L381)在 A-04/A-05/A-06 各处重复引用。 候选:N015·N017·N018✓ 已收口 · 不立接口先不立接口:锁定码只挂在信贷账户一个宿主上,实现者不足三个,不满足 2.6「三个以上对象同形」的立接口条件;共用约束已由 L376–L379 与 L381 表达Leo · 2026-09-08
G-167缺口finalize
积分账户有没有自己的账号,还是只是一个余额属性
缺什么:N004 积分账户 的身份标识没有登记——原来填的 mpc_uid 是客户(N001)的标识,一个标识符只能属于一个对象,不能借用。
为什么缺/线索:知识库只见查积分余额接口(amsCardpointQueryPointBal 返回 avlScoreAmount),没有出现积分账户自己的编号(02§D.2)。需要 PM/后端确认:积分账户是独立对象(有自己的账号和生命周期),还是钱包/客户身上的一个「积分余额」属性;若是后者,N004 应降为属性。
涉及:N004 积分账户N001 客户N003 钱包账户出处:02§D.2·纲要 2.1
登记原文
N004 积分账户:身份标识未见;原登 mpc_uid 为客户标识,不可借用✓ 已收口 · 已补齐积分账户是独立对象,有自己的账户号(字段名待后端补)Leo · 2026-08-17
G-168缺口finalize
N078 风控挑战 与 N082 风控挑战记录 是否同一对象
缺什么:两个对象共用同一身份标识 faceScanAppNo(刷脸挑战单号),疑为不同抽取单元各建一次的重复对象。
为什么缺/线索:一个标识符只揭示一个对象(纲要 2.1);若确为同一物应合并为一个(保留一号,另一号并入并在 note 记录),其属性/规则宿主随之归位。
涉及:N078 风控挑战N082 风控挑战记录出处:02§D.3·03§D.4
登记原文
N078 风控挑战 与 N082 风控挑战记录 是否同一对象✓ 已收口 · 已补齐已合并(见对象复核记录)Leo · 2026-08-18
G-169缺口finalize
N023 协商方案确认 与 N051 协商还款方案 是否需要两个对象
缺什么:两者身份标识都是 promiseCode+version(+term),「方案」与「对方案的确认」是否有各自独立的生命周期未说清。
为什么缺/线索:若确认只是方案上的一个状态迁移(未确认→已确认),N023 应降为 N051 的属性/动作产物;若确认是一次独立事件(可多次、可撤回),保留两个但标识应加上确认时间等区分要素。
涉及:N023 协商方案确认N051 协商还款方案出处:05§协商还款·R3
登记原文
N023 协商方案确认 与 N051 协商还款方案 是否需要两个对象✓ 已收口 · 已补齐已合并(见对象复核记录)Leo · 2026-08-18
G-170缺口finalize
客户的 MPC 用户 ID 与钱包账户的 MPC 账户 ID 是不是同一个字段
缺什么:N001 客户 标识写 MpcID/mpc_uid,N003 钱包账户 标识写 mpcId,字面几乎相同;文档未明确二者是同一字段还是两个字段。
为什么缺/线索:纲要示例明确 mpc_uid=人的标识、acct_no=账户的标识;若钱包账户实际用的也是 mpc_uid,则钱包与客户 1:1 绑定、钱包账户可能没有独立主键——待后端确认字段名。
涉及:N001 客户N003 钱包账户出处:01§D.1·R5§⑧·纲要 2.1
登记原文
客户的 MPC 用户 ID 与钱包账户的 MPC 账户 ID 是不是同一个字段✓ 已收口 · 已补齐不是同一个字段:mpcUid=会员编号(人的标识,≤19);钱包账户自己的账号=acctNo(≤16),按 acctType 区分 00 积分户/01 个人钱包/02 公司钱包/03 核心账号。出处:IT 知识库 api_catalog 2026-07-21 groups/032:184,213-219(接口 88300032-QUERY_MEM_BALANCE)Leo · 2026-09-08待改:N001 客户 · N003 钱包账户
G-171缺口finalize
商户除了名称,唯一标识 ID 是什么
缺什么:N009 商户 的身份标识目前只有商户名(MERCHANT_NAME),同名商户无法区分;商户 ID(收单侧 merchant ID / MID)没有登记。
为什么缺/线索:知识库全文只出现 MERCHANT_NAME(交易流水行标题)和 MER_BIZ_NO(商户业务号,是订单的标识不是商户的);商户接入契约「由收单侧提供」(02§后端事实增补),PayLater 侧文档不含商户主档。待后端/收单方(IPG/IHYBRID)给出商户唯一 ID 字段名及其在流水/订单里的落点。
涉及:N009 商户N077 商户订单N037 交易流水(记录)出处:02§D.1·R3§流水字段·R7§行标题
登记原文
N009 商户:唯一标识只有 MERCHANT_NAME,商户 ID 未见✓ 已收口 · 已补齐商户有唯一 ID:收单侧接口回传并已落库,作为 N009 身份标识;具体字段名与在流水/订单里的落点待补登Leo · 2026-08-20
G-172缺口finalize
决策引擎/规则包为什么算对象
缺什么:N012 决策引擎/规则包 登为对象,但它是跑函数的系统,不是业务世界里的实体或事件(纲要 2.1);U09 已把 8 个规则包登为计算型函数,并明确 R10 其余后端系统「不入本体」——决策引擎应同样处理。
为什么缺/线索:三个动作(A-04/A-05/A-27)和三条规则(L021/L022/L023)在 refs 里顺带列了 N012,执行者信息本已在 executor 文本和 F 号里;P065 引擎归属口径组是函数元数据。
涉及:N012 决策引擎/规则包P065 引擎归属口径组A-04 受理支付交易A-05 受理取现申请A-27 下发风控挑战出处:纲要 2.1·R10§5
登记原文
N012 决策引擎/规则包 不应为对象✓ 已收口 · 已补齐N012 退役:引擎是执行系统不是业务对象,知识由计算型函数(F-06/07/08/17/18/19/20/21/25/26)与动作 executor 承载;P065 引擎归属口径组同步退役并入各函数 noteLeo · 2026-08-18
G-173缺口finalize
对象表复核:6 个系统配置/字典类退役
N067 埋点事件定义、N070 后台配置包、N066 运营位、N064/N065 落地页配置、N063 名单——都是程序字典/系统参数/UI 槽/圈人结果,不是业务世界的实体或事件;其属性已迁到相应业务对象(N041/N042/N040/N002/N011/N061/N030/N001)。
涉及:N067 埋点事件定义N070 功能开关配置N066 运营位N064 App 内营销落地页配置N065 留资 H5 落地页配置N063 名单出处:纲要 2.1 对象判据复核
登记原文
对象表复核:6 个系统配置/字典类退役✓ 已收口 · 已补齐对象表复核:6 个系统配置/字典类退役Leo · 2026-08-18
G-174缺口finalize
对象表复核:5 个视图/瞬时/技术对象退役
N046 试算方案(引擎瞬时输出,并入 F-08 与借据属性)、N037 交易流水(各交易事件的展示视图)、N043 UI 展示记录(前端本地留痕→客户属性)、N029 优惠券使用选择(支付/取现的参数)、N073 开户流程实例(技术编排→并入 N013 授信申请)。
涉及:N046 试算方案N037 交易流水N043 UI 展示记录N029 优惠券使用选择N073 开户流程实例出处:纲要 2.1 对象判据复核
登记原文
对象表复核:5 个视图/瞬时/技术对象退役✓ 已收口 · 已补齐对象表复核:5 个视图/瞬时/技术对象退役Leo · 2026-08-18
G-175缺口finalize
对象表复核:两对重复对象合并
N082 风控挑战记录 并入 N078 风控挑战(同 faceScanAppNo);N023 协商方案确认 并入 N051 协商还款方案(确认=方案状态迁移)。G-168/G-169 随之收口。
涉及:N078 风控挑战N082 风控挑战记录N051 协商还款方案N023 协商方案确认出处:纲要 2.1 对象判据复核
登记原文
对象表复核:两对重复对象合并✓ 已收口 · 已补齐对象表复核:两对重复对象合并Leo · 2026-08-18
G-176缺口finalize
支用场景深审:结构/对象/属性 17 处修正
缺什么:①取现/渠道侧支付缺「生成借据」关系(R010 扩端点);②R009 商户→支付方向错(退役);③N077 商户订单改实体;④A-05 product 改 none(借据由 A-26 产出);⑤F-07/F-18/F-19/F-08 outputs 去掉客户事件对象与业务码;⑥N036 开关操作退役并入 N011/P110/A-17;⑦N068 通知改为 A-39 产物事件;⑧试算档 P034/P035/P116/P117 宿主改交易/申请(报价 vs 核定);⑨12 个属性补/改 writer;⑩P215→P125、P210→P038 合并;⑪账单金额/账单日/账单月/还款日 6 属性宿主 N002→N045。
为什么缺/线索:v3 各单元并行抽取,跨单元口径未对齐;依据知识库 03§放款链路(ICPS 建借据)、02§发起(商户带订单调起、客户发起支付)、纲要易混边界 11(建议值 vs 核定值)。
涉及:N015 消费支付交易N016 渠道侧支付N017 取现支用N005 借据N077 商户订单N036 Auto top-up 开关操作N068 通知A-05 受理取现申请A-26 放款F-07F-08F-18F-19P034P116P117出处:纲要 2.1/2.2/2.4/2.5 · 03§放款链路
登记原文
支用场景(SEG2/SEG3)深审收口✓ 已收口 · 已补齐已按纲要修正 17 处Leo · 2026-08-19
G-177缺口finalize
支用场景第二轮:规则多宿主、例外号换号、借据双来源、叙事残留
缺什么:①7 条被多个动作当条件的规则只挂单宿主(L015/L016/L017/L020/L237/L058/L060)→改多宿主;②L017e/L045e 仍带 e 号→换独立号 L394/L395;③N005 借据 product_of 单值→A-04·A-26(消费由受理产出、取现由放款产出);④补登消费分期档位规则 L396;⑤L030 补业务语义;⑥SEG2/SEG3 叙事清掉 R009/N036 残留、P125 重复、借据来源误述、26 个账户属性堆砌行。
为什么缺/线索:纲要 5.6「每个动作 conditions 每条是已建档 F 号且挂在本动作」;速览 23 条业务规则逐项对照,22 条已覆盖、消费期数范围缺。
涉及:L015L016L017L020L237L058L060N005 借据L396出处:纲要 5.6 · 02/03§业务规则速览
登记原文
支用场景第二轮深审✓ 已收口 · 已补齐已修 10 处Leo · 2026-08-19
G-179缺口finalize
A-51「展示引导」下 62 条规则分流,14 条超长规则改写
缺什么:A-51 被当作前端展示逻辑的垃圾桶(62 条规则),展示不改业务状态不是纲要意义的动作。
处理:23 条去掉前端细节后剩业务口径→改挂属性/函数/动作(conditions 同步);37 条纯 UI 交互→保留在 A-51 但标 owl_status=建模约定不进 OWL,列表显示 UI 标;2 条退役并入;另 14 条超长规则压成 ≤120 字业务断言,接口名/字段/行号/文案移入 note。
涉及:A-51 展示引导与弹窗记录出处:纲要 2.4/2.5/5.3
登记原文
第三轮:A-51 展示规则分流 + 长规则改写✓ 已收口 · 已补齐rehost 23 / keep-ui 37 / retire 2 / rewrite 14Leo · 2026-08-19
X-046冲突finalize
纲要说 product_of 只给事件,但借据/账户/券这些实体也是动作产出的
说法一(纲要 2.1 存储表)
product_of 是哪个动作的产物(事件专用)
说法二(纲要 2.1 ❸ · 2.4)
动作可产出新对象(分案→案件、重组→新借据),产物对象 product_of 与动作 product 互指——案件/借据是实体
矛盾实体能否填 product_of 两处条文不一致;登记表 4 个实体按事实填了
涉及:N002 信贷账户N005 借据N048 营销权益券N049 SMP 支付立减券出处:纲要 2.1 · 2.4 ❸
登记原文
纲要 2.1 product_of「事件专用」vs 实体也是动作产物✓ 已收口 · 已补齐放宽措辞,不另立字段:product_of=产出该对象的动作号,实体、事件都可填,可多值,与动作卡 product 互指的要求不变。2.4 的干预痕迹审查语义只落在事件对象上(事件 product_of 非空=机构干预痕迹,进模型特征前须显式审查);实体的 product_of 只是来源溯源,不带审查义务。纲要 2.1 存储表、2.1 动作产物标记段、2.4 落点段已同步改写;合规检查「事件专用」warn 撤除,保留指向活跃动作+互指两条校验。现有 10 个带 product_of 的活跃实体按新口径合规。trista · 2026-08-25
G-181缺口finalize
账单与还款场景按 SOP 核验:属性重复退役、宿主归位、动作卡补全
处理:①N018 还款交易 product_of 清空(客户事件),系统发起还款是否拆对象登缺口;②P013 欠款金额组/P016 日期组 退役并入单值属性 P223-P231/P239·P241·P243(同字段双登);③逾期天数/次数/距还款日 改双宿主 N002·N045;④P133 账期参数 writer=A-22;⑤补规则 L401 产品分型独立日利率;⑥A-43/A-60/A-61 空腔补齐。机器审计 0 error;04 篇 7 个知识点覆盖全。
涉及:N018 还款交易N045 账单P013P016P233P234P238P133L401出处:场景核验 SOP
登记原文
SEG4 账单与还款核验收口✓ 已收口 · 已补齐按 SOP 六步核完Leo · 2026-08-19
G-182缺口audit-2026-08-20
渠道侧支付缺交易状态/撤销状态属性
缺什么:N016 渠道侧支付 身上只有支付场景标识(P104)与 QRIS 码形态(P105),没有交易状态/撤销状态属性——A-58 撤销 VDC PL 支付对它的状态改写无属性可挂(提交结果码 P041 已补挂,但撤销态不属于提交结果)。
为什么缺/线索:02§VDC 只见撤销结果(成功/失败)返回,未见渠道侧支付自身的状态字段;待后端给出渠道侧支付的状态字段名与取值。
涉及:N016 渠道侧支付A-58 撤销 VDC PL 支付出处:02§VDC·纲要 2.4
登记原文
N016 渠道侧支付:缺交易状态/撤销状态属性,A-58 撤销写入无处挂;待后端补字段名✓ 已收口 · 确认无随 X-053 自动消解:渠道侧支付已并入消费支付交易,交易状态本就在 N015 上(P038),无需为它单建状态属性Leo · 2026-09-08
X-049冲突audit-seg1
钱包初级户刷脸成功后:先升中级还是直接升高级
说法一
两条是串行两步(刷脸后升中级→提交时再升高级)
说法二
两条是互斥分支,条件须补触发时点
涉及:L009L010A-25N003出处:SEG1 核验 2026-08-27
登记原文
钱包初级户刷脸成功后:先升中级还是直接升高级✓ 已收口 · 说法一对串行两步:刷脸子步完成时先把初级户升为中级(L009);之后在 KYC 完成、授信表单提交时,若该客户可开高级户再升高级(L010)。两条不是互斥分支,触发时点已分别写进条件Leo · 2026-09-08待改:L009 初级户（mpcLevel='01'）刷脸成功后须 · L010 表单提交时非 Prime（mpcLevel≠'0
G-184缺口audit-seg1
开户段采集类事件缺记录主键
缺什么:N038 GPS 定位记录 与 N039 App List 采集记录 都是按次追加的真实观测事件,但没有记录主键——数不清、指不准单条。
为什么缺/线索:R8§12.3 只写 amsGpsReportEvents 回传 gpsInfo+bizType+channel;R10§109 写 appListData 落 t_user_app_list_report(单行整串 JSON)。待后端给出两张上报表的行主键字段名。
涉及:N038 GPS 定位记录N039 App List 采集记录A-50 上报事件出处:SEG1 核验 2026-08-27
登记原文
开户段采集类事件缺记录主键✓ 已收口 · 已补齐App List 采集记录的主键查到:ifes-vibe-coding.t_user_app_list_report.id,另带 biz_seq_no 业务流水号。同时修正一处范围错误:该表 trans_code 实证含 OPEN_ACCT 与 CASH_LOAN,取现也在上送,不止开户段。GPS 记录(N038)仍缺——TM_CUST_GPS_INFO 只有客户号无记录级主键,留 G-018。Leo · 2026-09-08待改:N039 App List 采集记录
G-185缺口audit-seg1
Video Banking 面签记录缺场次号
缺什么:N075 是由 VB 面签方执行、有四态结果并驱动账户状态的真实业务事件,但没有身份标识——同一申请多次面签无法区分。
为什么缺/线索:01§D.5 分支表与 R5§19 状态机只写结果经 amsAccountSubmitVbResult(VB_NOTIFY) 回传。待 VB/COMMON_VIDEO 侧给出面签场次号。
涉及:N075 Video Banking 面签记录A-52 执行 Video Banking 面签出处:SEG1 核验 2026-08-27
登记原文
Video Banking 面签记录缺场次号✓ 已收口 · 已补齐场次号定为 CASE_NO 面签工单号,落 ICVS/IB-icvs.TM_QQ_VIDEO_EVENT。SEQUENCE 虽名为序列号但其注释明写「标识一次推流活动」,一次面签会产生推流/断流/录制/截图多条消息,属消息级不可作身份;VOIP_CALL_KEY 房间号记为技术线索。待确认:一个工单是否可能有多次面签重试。Leo · 2026-09-08待改:N075 Video Banking 面签记录
G-188缺口audit-seg1
邮箱验证与 OTP 验证动作未建档
缺什么:KYC 能力表里的通用 OTP 验证(COMMON_OTP)与邮箱验证(COMMON_EMAIL_VERIFY)两项能力在登记表里没有动作卡;P237 需邮箱验证 只有下发方(A-01),「客户完成验证后由谁改写这个标记」没有构件承载。
为什么缺/线索:01§B 实名认证/KYC 能力表列了这两项;全表 grep COMMON_OTP 零命中。参照已有的 G-007(钱包动作未建档)。
涉及:P237 需邮箱验证A-01 受理开通申请N013 授信申请出处:SEG1 核验 2026-08-27
登记原文
邮箱验证与 OTP 验证动作未建档✓ 已收口 · 已补齐「客户完成验证后由谁改写标记」已有答案:ifes-ams(88300019)持有并回写 emailVerified(00 未验证/01 已验证);rcs-notice /email/validate 只负责发信与回调,不持业务状态。P237 的 writer 保持 A-01(该标记 A-01 置位、ifes-ams 复位,writer 轴只能填登记表内的动作构件,回写方记在备注)。决定不另建 COMMON_EMAIL_VERIFY / COMMON_OTP 动作卡——回写属接口侧状态同步而非业务动作,二期接地后若发现独立业务语义再补Leo · 2026-09-08待改:P237 需邮箱验证
G-189缺口audit-seg1
开通拒绝码只登了 B 系,D/S 两族取值缺失
缺什么:P087 开通拒绝码 的完整码族是 8147+Bxxx/Dxxx/Sxxx,但取值字典只登了 81470000 与 10 个 B 系码,D 系、S 系一个取值都没有。
为什么缺/线索:01§D.2 只给了 B 系后台语义表,D/S 两族仅在括注里提及。待后端补两族取值表。(与 G-003 不同:G-003 问的是产出引擎与命中规则,不覆盖取值缺失)
涉及:P087 开通拒绝码F-21 KYC 预筛决策F-54 开户反欺诈初审出处:SEG1 核验 2026-08-27
登记原文
开通拒绝码只登了 B 系,D/S 两族取值缺失✓ 已收口 · 已补齐D/S 两族取值与语义全部查到并登记:S001-S008 参数校验类、S901-S905 状态机运行类、S999 兜底、D997/D999 RMB 消息中间件(D 系仅两码)。并得出一个分界:B 系=业务拒绝(不可重试),D/S 系=系统故障(可重试),已分标进每个取值与定义。注:B 系产出引擎归属(F-21/F-54)仍待风控,属另一条线(writer 保持空)Leo · 2026-09-08待改:P087 开通拒绝码
G-190缺口audit-seg1
渠道标识:appId 四值已补,身份与字典的角色已界定
缺什么:N010 接入渠道 的身份标识是 app_id,而 P096 渠道标识 的口径就是「调起 SDK 的渠道 app_id」,同一列登了两处。
为什么缺/线索:纲要 2.1 身份标识记在对象上;但 P096 被 7 条规则当 refs 引用(L003/L004/L011/L170/L171/L193/L213),直接退役会造成断头引用。需定:把这些 refs 改指 N010 后退役 P096,还是保留 P096 作为可引用的字段登记。
涉及:P096 渠道标识N010 接入渠道出处:SEG1 核验 2026-08-27
登记原文
渠道标识既是对象身份又登了一条同名属性✓ 已收口 · 已补齐appId 实证取值补齐(Allo 5000210000/IM3 50002IM301/BIMA 50002BMA01/H5 50002LPT01)。「既是身份又是属性」判为不是重复:N010.identity=app_id 登记的是「渠道靠 app_id 逐个指认」,P096 登记的是该标识的取值字典与各渠道语义,并作为七条分流规则的挂载点;identity 是字符串字段装不下取值表,两者职责不同。P096 定义已改写以消除歧义,不退役。Leo · 2026-09-08待改:P096 渠道标识 · N010 接入渠道
X-050冲突audit-seg1
钱包账户借用客户的 mpcId 作身份标识
说法一
钱包账户是独立对象,须向后端要它自己的账号标识
说法二
钱包账户不是独立对象,mpcLevel/mpc_status 改判为客户属性后退役
涉及:N003 钱包账户N001 客户P199 钱包账户状态P076 钱包账户等级出处:SEG1 核验 2026-08-27
登记原文
钱包账户借用客户的 mpcId 作身份标识✓ 已收口 · 说法一对钱包账户是独立对象(自有等级、状态、余额与生命周期),但不能借客户的 mpcId 作身份标识;身份标识置空,向后端索取钱包自己的账号字段名(已登 G-203)Leo · 2026-09-08待改:N003 钱包账户
X-052冲突audit-seg1
开户授信链路的服务编号两处对不上
说法一
88200102 是同一引擎的另一跳编号,登记表可沿用
说法二
88200102 是取现复借专号,开户段应改为 88100024/10106,F-07 函数名须改
涉及:F-07 贷前/首账前借款审批引擎A-56 受理授信提交并送审出处:SEG1 核验 2026-08-27
登记原文
开户授信链路的服务编号两处对不上⏸ 搁置 · 搁置挂起待后端确认:两份都是技术口径,业务侧判不了;确认前 F-07 的函数名沿用现状,但不得据此对外引用服务号Leo · 2026-09-08
G-195缺口audit-seg2
商户订单没有状态属性
缺什么:N077 商户订单 的定义自陈「有订单号与生命周期(待支付→已支付→退款)」,但名下只有订单总额(P100)与商品清单(P101),状态字段与取值一条没有。
为什么缺/线索:02§D.1 入口契约与 D.5 交易详情均未给出订单状态字段名。待收单/商户侧补。(现有 G-024 只覆盖三个单号的对应关系,不含状态)
涉及:N077 商户订单P100 订单总额A-04 受理支付交易出处:SEG2 核验 2026-08-27
登记原文
商户订单没有状态属性✓ 已收口 · 确认无确认无:商户订单的生命周期由商户侧维护,本平台只保留下单快照,不落订单状态;本方状态是消费支付交易自身的状态(P038)与支付记录终态 resultStatus。已把该口径补进 N077 定义Leo · 2026-09-08待改:N077 商户订单
G-196缺口audit-seg2
四个对象的身份标识待补(通知/收单机构/Biller/RIPLAY 合同)
缺什么:本轮核验按纲要 2.1 清空了四个自造或借用的身份标识,均待补真实标识——
· 通知(N068):KB 只登触发时机/渠道/文案键,无触达流水号
· 收单机构(N080):原借用了 GL 内部户科目(P119),那是科目的标识不是机构的
· 账单出票方 Biller(N081):KB 唯一出处是定价引擎入参的场景字符串(大小写不敏感),不能当身份;若后端确认它只有场景字符串、无主档,应改判为属性(宿主 N015,与支付场景标识 P104 并列)后退役本对象
· RIPLAY 合同(N047):原填「合同版本」是模版键,数出来是版本数不是合同份数
为什么缺/线索:四者都是真对象(有生命周期、是业务实体或事件),缺的只是标识。
涉及:N068 通知N080 收单机构N081 账单出票方N047 RIPLAY 合同出处:SEG2 核验 2026-08-27
登记原文
四个对象的身份标识待补(通知/收单机构/Biller/RIPLAY 合同)✓ 已收口 · 已补齐四者中三者标识已补:N080=payment_info.order_acquirer;N081=payment_info.biller(保留对象——R066 为 N:1 属对象行为,「无主档」只是本行无主表,Biller 是真实外部交易对手方);N047=借据号+CONTRACT_NAME+CONTRACT_VERSION(保留对象——R021 为 1:1,属借据的弱实体,沿用父对象主键合于纲要 2.1;KB 查实无独立份数级 ID 列,但不等于不可逐份识别)。N068 通知的账本定位到 RCS-INFOS infos_messages,但触达流水号列名 KB 未见,标识仍缺,分出 G-208。附带发现:清算科目按 BILLER_<biller>_<acquirer>_* 展开,Biller 与收单机构联合决定科目Leo · 2026-09-08待改:N080 收单机构 · N081 账单出票方（Biller） · N047 RIPLAY 合同 · N068 通知（参数化）
G-197缺口audit-seg2
积分账户的账户号字段名仍未拿到
缺什么:G-167 已定结论「积分账户是独立对象,有自己的账户号」,但字段名至今没拿到,身份标识仍写着「字段名待补」。
为什么缺/线索:KB 只见查积分余额接口返回可用余额,未见账户号。待后端补。
涉及:N004 积分账户G-167出处:SEG2 核验 2026-08-27
登记原文
积分账户的账户号字段名仍未拿到✓ 已收口 · 已补齐积分账户的账号字段名 = lytAcctNo(积分账号);配套 balancePoints(可用积分余额)、totalPoints(总积分),账户类型 acctType=00 积分户。已写入 N004 身份标识。出处:IT 知识库 api_catalog 2026-07-21 groups/032:220-222(接口 88300032-QUERY_MEM_BALANCE)Leo · 2026-09-08待改:N004 积分账户
X-053冲突audit-seg2
渠道侧支付要不要并进消费支付交易
说法一
并入 N015(承载差异不构成两个实体)
说法二
保留两个对象(需说清业务边界并补状态属性)
涉及:N015 消费支付交易N016 渠道侧支付P104 支付场景标识R065 经…收单R066 代付给(Biller)G-182出处:SEG2 核验 2026-08-27
登记原文
渠道侧支付要不要并进消费支付交易✓ 已收口 · 说法一对并入 N015:两者共用同一身份空间与记账口径,唯一分界「是否由本前端 SDK 承载」是系统承载差异不是业务实体差异;承载方式由支付场景标识 P104 与 QRIS 码形态 P105 表达Leo · 2026-09-08待改:P041 支用提交结果码(风控挑战码) · P104 支付场景标识 · P105 QRIS 码形态 · R010 生成（借据） · R020 核销于 · R062 承载(消费支付) · R063 触发（风控挑战） · R065 收单方为 · R066 代付给（Biller） · A-04 受理支付交易（参数化：SDK 组合支付/QRIS MPM/CPM/Billpayment/Indomaret）
X-054冲突audit-seg2
组合支付守恒式到底含几条腿
说法一
守恒式四项(现状,含钱包/PL/积分/立减)
说法二
守恒式五项(补定存腿 depositAmt)
涉及:L019 组合支付守恒L345 券金额服务端重算P102 组合支付金额构成出处:SEG2 核验 2026-08-27
登记原文
组合支付守恒式到底含几条腿✓ 已收口 · 说法一对守恒式四项(钱包+PayLater+积分+立减=应付)。定存不能直接付款:定存质押的作用是转成信用额度,付款时实际走的是 PL 腿(paylaterAmt),所以 depositAmt 不是本场景的资金腿。R10§02 写的「资金腿三选一含 depositAmt」描述的是支付枢纽通用接口的路由能力,不等于 PayLater 消费支付走这条腿(Leo 2026-09-08 确认)Leo · 2026-09-08待改:P102 组合支付金额构成 · L345 组合支付金额守恒由服务端硬约束:钱包、PayLa
G-198缺口audit-seg2
风控挑战通过后怎么回到原流程没写清
缺什么:下发风控挑战(A-27)的副作用里原写着「客户完成 OTP/刷脸后续查(路径未详)」——挑战通过之后系统怎么接回原来的支付/取现流程、由谁发起续查、失败几次算终止,都没有构件承载。
为什么缺/线索:02§D.3 只写「刷脸成功后续回轮询、失败进失败页」,取现侧 03§D.4 同样一笔带过。待前端/后端补链路。
涉及:A-27 下发风控挑战P109 挑战结果P041 支用提交结果码出处:SEG2 核验 2026-08-27
登记原文
风控挑战通过后怎么回到原流程没写清✓ 已收口 · 已补齐续查链路已成文:OTP 腿带 otp 调 88200049 online-payment-verify(重发 payment-resend-otp);刷脸腿按 paymentBizSeqNo 轮询 inquiry-payment-result(81520004 待刷脸/81520003 处理中),轮询到终态即接回原流程。失败码族 81521403/404/406 对应 OTP 第 3/4/5 次失败,B403=超最大尝试次数,据此推得上限为 5 次——数值本身属策略配置,另开 G-206 请风控确认Leo · 2026-09-08待改:A-27 下发风控挑战 · P109 挑战结果 · P041 支用提交结果码(风控挑战码)
G-199缺口audit-seg2
退款的触发条件与可逆性都没有口径
缺什么:退款(A-36)是本段唯一一张前置条件为空的动作卡,而退款不可能无条件——至少要有:原交易已成功入账、退款金额不超过原交易金额(部分退可多次但累计不超)、账期窗口、原交易未被撤销(与 A-58 互斥)。这四条登记表里一条都没有。另外卡面原写「不可逆」而 note 写「可逆性待后端」,自相矛盾,现已改为显式待确认。
为什么缺/线索:04§待确认明写「退款(多还/溢缴)的触发条件与到账路径待后端补」。与 G-058 是同一批问题的不同侧面。
涉及:A-36 退款N053 退款单P121 退款类型G-058出处:SEG2 核验 2026-08-27
登记原文
退款的触发条件与可逆性都没有口径✓ 已收口 · 已补齐前置条件以返回码成文(七条):原交易存在 80530127、订单匹配 80530102、金额不超 80530168/82640005、账期窗口 80530167、与撤销互斥 80530015、不重复全额退 80532800、交易类型支持 80530117;可逆性=带条件可逆(已退款不可撤销,部分退款可多次)。已写入 A-36。出处:IT 知识库 api_catalog groups/028:113(88200082-payment-refund 返回码块)Leo · 2026-09-08待改:A-36 退款
G-200缺口audit-seg2
两个反欺诈函数的输出落点未见
缺什么:激活反欺诈(F-20)与 KYC 预筛决策(F-21)的产物落到哪个字段没有登记,outputs 此前是空串(纲要 2.5 规定计算型第一阶段的最低义务就是 id+名+outputs),现已改为显式 none 并指向本缺口。
为什么缺/线索:两者的 note 都自陈「输出留白」。待风控给出决策字段名。
涉及:F-20 激活反欺诈F-21 KYC 预筛决策出处:SEG2 核验 2026-08-27
登记原文
两个反欺诈函数的输出落点未见✓ 已收口 · 已补齐F-20 已随 G-017 定为 TM_AFS_CASE.ACTION_TYPE(明细 TM_MID_AFS_RESULT);F-21 落 TM_TRANS_RULE_ENGINE_DTL.actionType,=="1" 才继续公安比对(F-53)否则 E007;F-21 为 IKYC 进程内嵌 Experian CFNC 规则包,非独立服务 [2026-09-08 修正:同 G-017,F-21 的 outputs 原填 TM_TRANS_RULE_ENGINE_DTL.actionType,已新立 P247 KYC 预筛裁决(宿主 N013,writer F-21)并改指之;库表列名降为二期接地线索。]Leo · 2026-09-08待改:F-20 激活反欺诈（CFMC，ICRC-MIDAFS） · F-21 KYC 预筛决策（CFNC，IKYC）
X-055冲突audit-seg2
虚拟卡支付的 300 万上限到底是单笔还是日累计
说法一
300 万=每日限额的可调上限(L038 冗余,应退役并入 L037)
说法二
300 万=单笔硬上限(L038 应改写为「单笔不得超过 Rp3.000.000,独立于每日限额」)
涉及:L037 差额超每日剩余上限失败L038 PL 部分超 3M 失败L039 每日限额默认与上限P112·P113出处:SEG2 核验 2026-08-27
登记原文
虚拟卡支付的 300 万上限到底是单笔还是日累计✓ 已收口 · 说法一对300 万是每日 PL 支付限额的可调上限(默认 200 万、客户可调但不得超卡限额、绝对上限 300 万,见 L039),不是独立的单笔硬上限;因此 L038「PL 部分超 300 万失败」被 L037「差额超每日剩余上限失败」完全吸收,已退役并入Leo · 2026-09-08待改:L037 已激活 Auto top-up 时，差额（订单金 · L038 VDC 支付中 PL 需支付部分>3M→支付失败
X-056冲突audit-seg2
展示类规则挂在动作上时,四道门都套不上
说法一
owl_status=建模约定不进 OWL 的规则 gate 可留空,合规检查豁免
说法二
为展示类规则新增第五道门(如「展示门」),纲要相应放宽
涉及:L031L032L035L052L028A-51 展示引导与弹窗记录出处:SEG2 核验 2026-08-27
登记原文
展示类规则挂在动作上时,四道门都套不上✓ 已收口 · 说法一对标了 owl_status=建模约定不进 OWL 的展示类规则可不填门类,合规检查豁免:四道门本为动作准入设计,展示约定既不参与推理也不拦截动作,硬套成「状态门」反而误导。合规检查已同步放行Leo · 2026-09-08待改:L028 消费支付失败页无重试按钮，唯一按钮回宿主，用户须 · L031 QRIS 支付选钱包时,账户持有 0 利率权益则 · L032 QRIS 支付选 PayLater 时期数默认只 · L035 CPM 支付的 PayLater 期数选项按由小 · L052 试算档默认选中:消费支付取后端返回的首档(前端不 · L054 低价支用主页:仅有一个可用低价利率时自动选中;多 · L059 确认页:低价价格券无券名时不展示券名行与总节省行 · L061 客户从取现金额页或低价档页返回离开且额度动用不足 · L071 账单卡仅在该账单存在退款金额时显示退款入口。 · L079 常规还款页输入金额不低于最低还款额且不等于账单全 · L126 重新授信被拒时,结果页引导客户走质押提额;剩余可 · L131 还款成功后短暂轮询等待杠杆奖励发放结果;超时只显 · L132 剩余可领取杠杆额度大于 0 时才显示奖励项与加仓 · L133 还款后显示的本次提额金额取自当日提额记录(还款任 · L135 V1 任务页的提额模块与还款奖励模块分别受对应后 · L150 SDK 内展示的提额比例优先取营销活动配置值,无 · L156 质押成功后的支付引导页促销横幅最多 3 个,超出 · L168 App 登录手机号命中 7 天内在 Indoma · L173 开户事件按 amsEventReportConf · L175 LimitUp 客户首次进入首页且未看过引导时: · L176 新首页欢迎与引导每位客户只展示一次:设备本地记录 · L194 白名单校验返回异常码 80430228 时展示专 · L214 授信成功后,Y001 客群进 LimitUp 结 · L241 一期口径:账户持有可用低价价格券即在主页展示低利 · L243 取现受理成功结果页主按钮:IM3、BIMA 渠道 · L245 低价支用页不展示特价文案与划线原价;底部统一按钮 · L246 取现确认页须摊开披露到账额、借款额、服务费(券后 · L247 RIPLAY 合同内容由后端下发、前端不组装;前 · L264 还款页分流:Y001 客群或提前结清进基础还款页 · L265 账单页只分当期与下期两个页签,切换按月重查;下期 · L289 重组结果页四态:成功(含重组前后账单对比)、处理 · L320 质押或解押处于在途状态时,页面展示在途态。 · L321 质押流程首步退出时弹窗挽留说明好处;解押时整页挽 · L322 质押输入金额页固定展示 10 万/30 万/50 · L337 QRIS 主扫支付页对 LimitUp 非会员客 · L338 会员入口:非有效期内显示提额文案、图标置灰,点击 · L340 锁额页存在最高面值折扣券时顶部展示券提示条(面值 · L342 配置了多次核销的券,卡券角标展示当前剩余可用次数 · L355 促销主页置顶我的卡券入口并显示当前生效券数量,点 · L364 LimitUp 引导只按设备本地记录判定一次性展 · L405 组合支付轮询按 2 秒间隔最多 10 次,结果码
X-057冲突audit-seg2
等本等费分摊该不该单独立一个函数
说法一
退役 F-34,算法并入 F-08 口径
说法二
保留 F-34,为逐期还款计划单建属性作其产物
涉及:F-34 等本等费分摊F-08 定价引擎试算P034 试算方案字段组出处:SEG2 核验 2026-08-27
登记原文
等本等费分摊该不该单独立一个函数✓ 已收口 · 说法一对退役 F-34,等本等费分摊的算法口径并入 F-08:逐期计划是定价引擎返回的字段(P034 子字段 SCHEDULE_LIST),分摊公式属引擎内部实现,纲要规定内部实现不进知识库;拆独立属性又与「结构组须整组登记」冲突Leo · 2026-09-08待改:P034 试算方案字段组 · L229 管理费按月收取,每期金额=原始本金×月费率,各期 · F-08 定价引擎试算（CtPrice / coreTransTryLoan，INBS）
G-203缺口audit-seg2
钱包账户自己的账号字段名是什么
缺什么:X-050 定结论「钱包是独立对象但不能借客户的 mpcId 作身份」后,N003 的身份标识已置空,需要后端给出钱包账户自身的账号字段名(不是客户的 MPC 用户 ID)。
为什么缺/线索:知识库里 mpcLevel / mpc_status 都是按人查的,未见钱包账号本身;与积分账户 G-197 是同一类问题,可一并问后端。
涉及:N003 钱包账户N001 客户P199 钱包账户状态P076 钱包账户等级出处:X-050 收口 2026-09-08
登记原文
钱包账户自有账号字段名待后端补✓ 已收口 · 已补齐钱包账户的账号字段 = acctNo(最大长度 16,acctType=01 个人钱包),已写入 N003 身份标识;与客户级 mpcUid 是两个不同字段。出处:IT 知识库 api_catalog 2026-07-21 groups/032:184,213-219(接口 88300032-QUERY_MEM_BALANCE)Leo · 2026-09-08待改:N003 钱包账户
G-204缺口audit-seg2
接口层已在本地建好(interfaces.yaml + 类型 + 表单),待 trista 合并发布
缺什么:说明书 2.6 定义了接口表 interfaces.yaml(shape.properties / shape.actions / implementers 带 bindings / verify),v3.0 又重定义了字段;但 data/registry 下没有该文件,lib/repo 的 schema 与 registry 也没有接口类型,平台读不到、页面也没有入口。
为什么缺/线索:Leo 2026-09-08 在核 SEG2 时决定立「可验密」接口(IF-16),发现无处落地。需 trista 在平台侧补接口表与 schema(含 6.3.5「挂接口的规则编译时展开到每个实现者」);补齐前,已拍板要立的接口只能记在缺口表里。
涉及:IF-16 可验密出处:SEG2 核验 2026-09-08
登记原文
接口表未启用,接口候选无处落地✓ 已收口 · 已补齐本地已补齐:①新建 data/registry/interfaces.yaml(注释头+JSON 数组,与各表同格式);②lib/repo/registry.ts 增 RegInterface / IfShapeProperty / IfImplementer 三个类型,readRegistry 读入 interfaces 并纳入 nameOf / aliasIndex / aliasOf(IF 号可正常渲染中文名);③lib/repo/registrySchema.ts 增 interfaces 类型定义,编辑表单与新建入口可用。IF-16 可验密 已按 2.6 格式登进表内(8 个实现者,shape.actions=A-49,properties 暂空并说明原因)。next build 通过,合规无新增违规。仍需 trista 做的:页面入口与图谱渲染(接口用虚线框),以及 6.3.5「挂接口的规则编译时展开到每个实现者」的编译逻辑——这两项属平台侧改造。Leo · 2026-09-08待改:IF-16 可验密
G-213缺口U04 账单与账期、常规还款
还款链路无对外事件上报,经营侧拿不到还款成功的数据出口
缺什么:还款全链路既无 GPS 上报、也无对外归因事件上报——与取现链路形成对比(取现验密成功即上报定位、开户成功有 PAYLATER_APPROVED/LIMITUP 等对外事件)。后果:经营侧若要做「还款成功」的外部触达或归因(如向广告平台回传转化),目前没有数据出口。
这是一条负向事实(缺少能力),不是字段缺失——需产品定是否要建这个出口、数据侧定回传口径。
为什么缺/线索:功能说明 05「经营与体验关注点」明写此事,登记表未承载。
涉及:A-06 受理还款A-59 还款入账冲抵A-50 上报事件(开户段参数化)出处:六段核验 2026-09-08
登记原文
还款链路无对外事件上报✓ 已收口 · 已补齐确认负向事实:还款链路只有内部 200031→CRC10501 风险标签报送,无 AppsFlyer/Firebase/GPS 类对外归因事件(现有契约仅 PAYLATER_APPROVED/LIMITUP/LOAN_ACC_OPENED 三类获批事件);若要建出口,天然挂点是 INBS I200031 臂或 ICPS RepayPostedNoticeNbsHandlerIT 知识库 marketing-attribution-event-contract.md §2/§3/§7(2026-08-13)、current/inbs/repayment-success-semantics.md(2026-09-01 code_verified)(WeFi-NY/knowledge-base@0d93e0f)trista · 2026-09-08待改:A-50 上报事件（开户段参数：CNC/GPS/App List/对外归因/开户成功+防重） · A-59 还款入账冲抵
数据源:PayLater 产品知识库 2026-08-13 版 × 本体知识库说明书 v2 · 2026-08-17 全量重抽(9 单元并行判定+合并校验)· 冲突只登记不判断 · 「缺口」为按纲要三态纪律显式暴露的待补项;冲突登记不改写,结论在「缺口·冲突」页收口