本体协作平台
trista · 本体管理员
本体登记表

知识库

全库 1033 个构件(2026-08-17 按说明书 v2 全量重抽),按纲要六类构件组织,规则=函数·规则型。(二期数据接地:对象 8/89 · 属性 83/273 · 关系 1/108,在详情页维护)

确认进度894/1033· 已确认=锁定,改前先解锁
⬇ 下载本体包
变更记录别名索引字段索引
全部 299冲突 57缺口 222接口候选 20│○ 待收口 218✓ 已收口 81收口进度81/299

这里不做判断,只记录结论:PM / 风控 / 后端把口径定下来之后,在对应条目上记一笔「定了什么、谁定的」。冲突记完可以顺手把说法错了的那条构件标成「待改」,提醒回去改。

X-001冲突U01 开通与授信

客群分段码是否真的下发到了 SDK

说法一(R1§三)
P003 客群分段码(segCode)共 40 位,由审批引擎在开户后输出并返回给 SDK。
说法二(R3§①、R3§待确认清单)
前端代码全仓检索,没有见到任何读取 segCode/SEG_CODE 的字段。
矛盾客群分段码究竟有没有下发到 SDK、接口里是否真的存在这个字段,两边说法对不上,待后端确认。
涉及:P003 客群分段码出处:R1§三·R3§①
登记原文P003 / R1§三（segCode 40 位，开户后审批引擎输出并返回 SDK）/R3§①·R3§待确认清单（前端代码全仓未见 segCode/SEG_CODE 字段）: 口径矛盾：segCode 是否真的下发到 SDK/接口存在；仅登记不裁决
○ 待收口
X-002冲突U01 开通与授信

哪些开通状态可以进入开户申请落地页

说法一(旧登记 L012)
受理开户申请必须处于开通状态 T211(初始态)。
说法二(01§D.6)
代码查实,T211/T017/T022/T023 四个状态都统一进入申请落地页。
矛盾旧规则只允许 T211,代码实际放行四个状态,范围不同;L012 已按 01 篇改写为四态并记为口径变化,请复核旧登记的来源。
涉及:L012 规则:开户申请受理的状态前提P006 开通/KYC 状态出处:01§D.6·R5§①
登记原文L012 现有登记（受理开户须 OPEN_STATUS=T211 初始态）/01§D.6（T211/T017/T022/T023 统一进申请落地页）: 范围不同：旧规则只允许 T211，代码查实四态均可进入；本文件已按 01 篇改写 L012 并登记为口径变化，请复核旧登记来源
○ 待收口
X-007冲突U03 取现 Instant Cash

每月还款日是固定 10 号,还是按开户年份分两代

说法一(03§RIPLAY 试算字段,《RIPLAY Instant Cash May 2025》)
P129 RIPLAY 披露每月还款日为每月 10 日。
说法二(_待确认清单-风控后端SA-20260813 后端第 5 条)
2025 年前开户的账户 1 号出账、10 号还款;2025 年后开户的 25 号出账、次月 3 号还款;试算的账期(billingCycle)由引擎按账户下发。
矛盾RIPLAY 对客披露固定 10 日,后端实际是两代账期规则(3 号/10 号)并由引擎按账户下发,两者口径不一致。
涉及:P129 RIPLAY 披露内容字段组P133 账期参数组出处:03§RIPLAY 试算字段·_待确认清单-风控后端SA-20260813
登记原文P129 RIPLAY 每月还款日=每月 10 日(《RIPLAY Instant Cash May 2025》)/_待确认清单 后端5条:2025 年前开户 1 号出账·10 号还款,2025 年后开户 25 号出账·次月 3 号还款;试算 billingCycle 由引擎下发: 口径矛盾:RIPLAY 披露固定 10 日,后端为两代账期规则(3 号/10 号)且引擎按账户下发
○ 待收口
X-009冲突U03 取现 Instant Cash

低价/特殊取现的最小金额是 500K 还是 2K

说法一(索引 L120,09 篇)
特殊取现页若免息额度小于最小取现金额(500K,后台字段)则该档不可选。
说法二(L053/L057/L047)
低价可用额度小于 Rp2,000 才算「额度已用完」,每档最小金额 = max(档位下限, 2000),500K 只是推荐金额档而不是门槛。
矛盾适用范围有重叠但结论不同——低价/特殊取现的最小金额到底是 500K 还是 2K。
涉及:L120 规则:特殊取现页免息额度门槛L053 规则:低价取现额度用完判定L057 规则:低价档最小金额展示态L047 规则:常规取现统一最低金额N017 取现支用出处:03§最低取现金额门槛·03§取现入口门槛·索引 L120
登记原文L120(索引,09 篇):特殊取现页免息额度<最小取现金额(500K 后台字段)则不可选/L053/L057/L047:低价可用额度<2K 才'额度已用完',档 minLimit=max(档位下限,2000),500K 为推荐金额档非门槛: 范围重叠结论不同:低价/特殊取现最小金额 500K vs 2K
○ 待收口
X-010冲突U03 取现 Instant Cash

支用态可取的枚举值有几个

说法一(R5§⑦)
P010 支用态(cashState)有 5 个取值(W/AC/OPC/REPAY_FIRST_CREDIT/NOT_AVILABLE_CREDIT)。
说法二(R3§①状态类)
cashState 取值「同 ACCOUNT_STATE」,即 9 个取值(W/AC/NAC/RFC/OPC/NU/HN/HF/HO)。
矛盾枚举全集不一致——支用态能否取 NU/HN/HF/HO;两处引用的代码行号也不一致(R5 140-158 vs R3 124-142)。
涉及:P010 支用态(派生)P009 综合账户态(派生)出处:R5§⑦·R3§①
登记原文P010 cashState 取值 R5§⑦(5 值 W/AC/OPC/REPAY_FIRST_CREDIT/NOT_AVILABLE_CREDIT)/R3§①状态类 cashState 取值'同 ACCOUNT_STATE'(9 值 W/AC/NAC/RFC/OPC/NU/HN/HF/HO): 枚举全集不一致(cashState 是否可取 NU/HN/HF/HO);行号亦不一致(R5 140-158 vs R3 124-142)
○ 待收口
X-011冲突U03 取现 Instant Cash

额占率超上限时,主页还展不展示低价引导

说法一(L241,一期口径)
用户持有 DJ 低价权益即展示主页低价引导标记。
说法二(L056,二期口径)
须同时满足持有 DJ 权益且额占率低于第一价格区间上限才展示。
矛盾额占率≥上限时是否展示结论相反;二期是收紧版,但前端是否已承载该判定未查实,现网生效的是哪个版本待确认。
涉及:L241 规则:主页低价权益引导(一期口径)L056 规则:主页低价引导条件(二期收紧)出处:03§主页低价权益引导标记
登记原文L241 一期:持 DJ 权益即展示低价引导/L056 二期:持 DJ ∧ 额占率<第一价格区间上限才展示: 范围重叠结论不同(额占率≥上限时展示与否);二期为收紧版但前端承载与否未查实,现网生效版本待确认
○ 待收口
X-012冲突U03 取现 Instant Cash

取现「四引擎串行」实际单笔只过三道

说法一(03§业务规则速览)
决策引擎为「四引擎串行」。
说法二(03§用户旅程5)
反欺诈→刷脸→首借/复借,虽称四个引擎,但首借与复借二选一,单笔实际只过三个。
矛盾「四引擎」指的是引擎矩阵里的四个实例,单笔取现实际串行三道闸(首借/复借二选一),表述容易被误读。
涉及:N017 取现支用N012 决策引擎/规则包出处:03§用户旅程5·03§业务规则速览
登记原文03§业务规则速览 决策引擎:'四引擎串行'/03§用户旅程5:'反欺诈→刷脸→首借/复借'称四个引擎但按首支/复支二选一实际单笔过三个: 表述口径:'四引擎'指矩阵四个实例,单笔实际串行三闸(首支/复支二选一),易误读
○ 待收口
X-017冲突U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

月最低还款本金占比在灵活码的哪几位

说法一(05§E.3,后端公式)
月最低还款本金 = 本金 × 比例,比例取灵活码(FlexCode)第 4-6 位。
说法二(R1§二)
灵活码第 5-6 位为月最低还款本金占比,第 4 位是「按月重置最低还款配置」标志。
矛盾同一个比例的位段编号不一致(4-6 vs 5-6);R1 是 PM 权威口径,E.3 是代码实证,尚未裁决。
涉及:P002 灵活码N019 月最低还款申请出处:05§E.3·R1§二
登记原文05§E.3 后端公式『本金×比例(FlexCode 第 4-6 位)』/R1§二 Flex 第 5-6 位=月最低还款本金占比(第 4 位=reset monthly repayment config): 同一比例的位段编号不一致(4-6 vs 5-6);R1 为 PM 权威、E.3 为代码实证,未裁决
○ 待收口
X-018冲突U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

预付页「剩余总金额」是剩余本金还是本息费合计

说法一(R3§②预付字段表)
预付介绍页的 Remaining total amount 取账户剩余本金(accountInfo.accountPrinAmt / ACCOUNT_PRIN_AMT)。
说法二(05§K-S-2607③、预付门槛节)
该字段已改为 ACCT_SUM_PAID_OUT,即本金+利息+罚息+费用合计。
矛盾R3 仍写修正前口径,与 05 修正后的口径不一致(试算的 AMOUNT 仍用剩余本金,两处一致)。
涉及:N052 预付门槛任务A-62 核销预付门槛出处:R3§②·05§K-S-2607③
登记原文R3§②预付字段表:Remaining total amount=accountInfo.accountPrinAmt(ACCOUNT_PRIN_AMT)/05§K-S-2607③/预付门槛节:PrepayIntro Remaining total amount 已改为 ACCT_SUM_PAID_OUT(本金+利息+罚息+费用): R3 仍写修正前口径,与 05 修正后不一致(试算 AMOUNT 仍用剩余本金两处一致)
○ 待收口
X-019冲突U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

月最低还款新借据的期数由灵活码哪组位段约束

说法一(05§月最低还款 0119)
新借据的期数由灵活码第 13-14/15-16 位判断。
说法二(R1§二)
第 13-16 位是新借据最大/最小期数,第 24-27 位是借新还旧新借据可选最小/最大期数;05 正文又称前端不读这些位,档位由引擎返回。
矛盾「新借据(13-16 位)」与「借新还旧新借据(24-27 位)」两组期数位并存,到底哪组约束月最低还款生成的新借据未写明。
涉及:P002 灵活码N019 月最低还款申请出处:05§月最低还款·R1§二
登记原文05§月最低还款(0119):新借据期数由 Flex 第 13-14/15-16 位判断/R1§二:第 13-16 位=新借据最大/最小期数、第 24-27 位=借新还旧新借据可选最小/最大期数;05 正文称前端不读、档位由引擎返回: 『新借据(13-16)』与『借新还旧新借据(24-27)』两组期数位并存,哪组约束月最低还款新借据未写明
○ 待收口
X-020冲突U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

重组「≥2 笔、≤10 笔」门槛是否只对多借据分支适用

说法一(05§业务规则速览)
重组门槛为借据 ≥2 笔且 ≤10 笔。
说法二(05§D.4)
逾期重组直入分支(OVERDUE_RESTRUCTURE)不选借据,借据列表为空。
矛盾速览段没有限定分支;L093 已写成仅多借据分支(MULTI_SETTLE)适用,速览的表述范围过宽,请审核确认。
涉及:L093 规则:多借据选择分支(MULTI_SETTLE)N021 逾期重组申请A-10 受理逾期重组申请出处:05§业务规则速览·05§D.4
登记原文05§业务规则速览『重组门槛 ≥2 笔、≤10 笔』/05§D.4 OVERDUE_RESTRUCTURE 直入分支 LOAN_LIST=null(不选据): 速览未限定分支;已在 L093 写成仅 MULTI_SETTLE 适用,速览表述范围过宽,请审核确认
○ 待收口
X-022冲突U06 质押与额度成长(LimitUp 专属)

重新授信入口的准入条件,PRD 与代码不一致

说法一(L122,07§重新风险授信流程 PRD 版)
首页展示重新申请入口需满足未逾期、在押本金≤50K、距授信拒绝日期>30 天等条件。
说法二(L123,07§额度成长来源/R6 代码版)
代码不含在押条件,改为营销码第 14/19 位不在 {1,3} 内,且按「距上次核额日(creditDate)」超过 reapplyCreditIntervalMinDays 判断;R6 里 reapplyCreditDataConfirmDays 也按「上次核额起」而非「拒绝日」计算。
矛盾适用范围重叠但准入条件不同——PRD 有在押本金条件且从拒绝日起算,代码无在押条件且从上次核额日起算。
涉及:L122 规则:重新授信入口条件(PRD 版)L123 规则:重新授信入口条件(代码版)N024 重新授信申请(reapply)P001 营销码出处:07§重新风险授信流程·07§额度成长来源·R6
登记原文L122(07§重新风险授信流程 PRD 版)/L123(07§额度成长来源/R6 代码版): 范围重叠结论不同:PRD 门槛含'在押本金≤50K'与'距授信拒绝日期>30 天',代码版无在押条件、改为 marketCode 第14/19位∉{1,3}且按'距上次核额日 creditDate'>reapplyCreditIntervalMinDays;R6 reapplyCreditDataConfirmDays 亦按'上次核额起'而非'拒绝日'
○ 待收口
X-023冲突U06 质押与额度成长(LimitUp 专属)

质押杠杆率 1.55 倍是含本金还是纯增量

说法一(09§产品定位与额度口径)
常规杠杆率(regularLeverageRatio)是本金的倍数,含本金。
说法二(09§核心能力、07 示例)
质押 Rp100K@1.55x = 新增 Rp155K 额度。
矛盾若 1.55 是含本金倍数,新增额度应为 +55K,示例却是 +155K(不含本金的纯增量);与「新增额度 = min(质押额×总杠杆率, …)」公式如何对应待裁定。
涉及:P017 质押杠杆信息组N025 质押申请L112 规则:定存质押新增额度公式出处:09§核心能力·09§产品定位与额度口径·07§后端事实增补
登记原文09§产品定位与额度口径(regularLeverageRatio=本金的倍数,含本金)/09§核心能力/07 示例(质押 Rp100K@1.55x=+Rp155K 额度): 口径矛盾:若 1.55 为含本金倍数,新增应为 +55K;示例却为 +155K(不含本金的纯增量);与 min 公式的'质押额×总杠杆率'如何对应待裁
○ 待收口
X-024冲突U06 质押与额度成长(LimitUp 专属)

前端兜底会误禁营销码首位为 0 的合法质押比例档

说法一(R1§一,PM 2026-08-13)
营销码第 5-7 位为质押比例,首位为 0 的取值(如 030=30%)是合法值。
说法二(L103,前端兜底)
首位非 1 或全 000 视为无有效杠杆率,禁止质押。
矛盾设计与实现不一致——按 R1 首位 0 的比例档合法,前端按旧字典会误禁;现网只下发首位 1 暂不出错。
涉及:P001 营销码L103 规则:前端质押杠杆率兜底判定出处:R1§一·09§待确认/风险
登记原文R1§一 第5-7位(030=30% 合法值,PM 2026-08-13)/L103 前端兜底(首位非 1/全 000 禁押): 口径矛盾(设计 vs 实现):按 R1 首位 0 的比例档合法,前端兜底按旧字典会误禁;现网仅下发首位 1 暂不致错
○ 待收口
X-025冲突U06 质押与额度成长(LimitUp 专属)

Y001→Y001_R1 升级用的产品调整枚举是哪个

说法一(07§实时提升杠杆率、10§杠杆率实时更新)
更新风险码用的产品调整类型枚举为 801002_09。
说法二(07§示例、R2§三)
触发 Y001→Y001_R1 升级的枚举为 801001_09(10 篇两者并列)。
矛盾同一次升级在不同段落写成两个不同枚举值,是否按产品码分两个枚举待核。
涉及:P004 风险码(风险标签集)A-31 执行调额出处:07§实时提升杠杆率·10§杠杆率实时更新·R2§三
登记原文07§实时提升杠杆率/10§(801002_09 更新 RiskCode)/07§示例·R2§三(801001_09 触发 Y001→Y001_R1): 同一 Y001→Y001_R1 升级在不同段落分别写为 ProductCdAdjTypeList 枚举 801002_09 与 801001_09(10 篇两者并列),是否按产品码分两枚举待核
○ 待收口
X-026冲突U06 质押与额度成长(LimitUp 专属)

定存清单是否只对 Prime 会员开放

说法一(L301,09§后端事实增补,IT KB 实证)
定存清单只对 Prime(Premium)会员可取。
说法二(09§质押流程,PRD)
展示用户持有的符合条件的存单,没有会员前提。
矛盾适用范围重叠但结论不同;且「Prime」指的是钱包档位还是 LimitUp Premium 会员也不明确。
涉及:L301 规则:定存清单仅 Prime 会员可取N006 定存存单N025 质押申请出处:09§后端事实增补·09§质押流程
登记原文L301(09§后端事实增补:定存清单只对 Prime(Premium)会员可取)/09§质押流程(展示用户持有的符合条件存单,无会员条件): 范围重叠结论不同:IT KB 实证称定存清单仅 Prime 会员可取,PRD 流程未设会员前提;且'Prime'指钱包档位还是 LimitUp Premium 未明
○ 待收口
X-027冲突U07 会员与营销

会员还款提额比例是 3% 还是 6%

说法一(10§会员权益表,二期 0609;R1 取值 03)
会员有效期内还款提额比例为 3%。
说法二(10§还款提额率)
现网营销码第 3-4 位为 06,即 6%(数据源 A 亦为 06)。
矛盾PRD 值 3% 与现网 6% 不一致;L147/L149 已各按出处分别登记。
涉及:L147 规则:会籍 ACTIVE 时提额奖励参数L149 规则:还款提额比例读取P001 营销码P052 会员套餐/权益组出处:10§会员权益·10§还款提额率
登记原文10§会员权益 表(二期 0609 还款提额 3%;R1 03=3%)/10§还款提额率(现网 marketCode 3-4 位=06→6%;数据源 A 06): 会员有效期内还款提额比例 PRD 值 3% 与现网 6% 不一致(registry X-2);L147/L149 各按出处登记
○ 待收口
X-030冲突U07 会员与营销

营销码 3-4 位示例值 99 与位段口径不符

说法一(《QRIS 支付页展示会员提额比例 1105》)
示例为 06=6%、99=99%。
说法二(R1§一 第 3-4 位)
该位段直读为整数百分比,99 不是合法值。
矛盾PRD 示例值 99 与位段口径不符;知识库以 R1 为准。
涉及:P001 营销码出处:10§还款提额率·R1§一
登记原文《QRIS 支付页展示会员提额比例 1105》'06=6%,99=99%'/R1§一 第 3-4 位(99 非合法值,直读整数): PRD 示例值 99 与位段口径不符;KB 以 R1 为准
○ 待收口
X-031冲突U07 会员与营销

会员费交易的商户名由谁决定

说法一(10§App/页面改造,0515)
钱包交易列表中会员交易的商户名由 Limit up Member 改为 Pay to limit up premium。
说法二(R7§2.3)
前端代码未见专用的会员交易商户名常量,商户名由后端 MERCHANT_NAME 决定。
矛盾PRD 口径与前端代码踪迹不一致(可能是后端下发),待后端确认。
涉及:N037 交易流水(记录)N028 会员购买/续费出处:10§App/页面改造·R7§2.3
登记原文10§App/页面改造(钱包交易列表商户名 Limit up Member→Pay to limit up premium,0515)/R7§2.3(代码未见专用会员交易商户名常量,商户名由后端 MERCHANT_NAME 决定,待后端): PRD 口径与前端代码踪迹不一致(可能后端下发),待后端确认
○ 待收口
X-032冲突U07 会员与营销

PRD 承诺的会员调额补偿机制在系统里没找到入口

说法一(10§购买月会员流程)
接口失败/超时时记录到补偿表,后续手动补偿。
说法二(R10§4-10)
会员购买记录表(t_limit_up_member_record)四种状态分列,DAO 只有插入和主键查询,没有补偿扫描入口。
矛盾PRD 承诺的补偿机制在 IT KB 中未见落地入口;不算直接矛盾,但需人工核实补偿表实体。
涉及:N058 调额补偿记录A-45 会员调额人工补偿P176 会员购买记录字段组出处:10§杠杆率实时更新·R10§4-10
登记原文10§购买月会员流程(接口失败/超时记录到补偿表后续手动补偿)/R10§4-10(t_limit_up_member_record 四状态分列,DAO 只有插入+主键查,无补偿扫描入口): PRD 承诺的补偿机制在 IT KB 未见落地入口;非直接矛盾但需人工核实补偿表实体
○ 待收口
X-033冲突U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

埋点目录里 creditline 分区计数前后不一致

说法一(参考/R8-埋点事件目录 §0 文件总览)
creditline.js 分区数为 36。
说法二(参考/R8-埋点事件目录 §1 表格)
逐行实列 38 个顶层分区。
矛盾同一文件内计数不一致(表格 38 vs 总览 36)。
涉及:N041 内部埋点事件记录出处:参考/R8-埋点事件目录.md
登记原文参考/R8-埋点事件目录.md§0 文件总览 creditline.js 分区数=36/参考/R8-埋点事件目录.md§1 表格实列 38 个顶层分区: 同一文内计数不一致（表格逐行 38 vs 总览 36）
○ 待收口
X-034冲突U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

埋点目录 deposit-liquidity 分区计数不一致

说法一(参考/R8-埋点事件目录 §0)
deposit-liquidity.js 分区数为 14。
说法二(参考/R8-埋点事件目录 §5)
表格 13 行,并注「实含 13 个」。
矛盾计数不一致,14 vs 13。
涉及:N041 内部埋点事件记录出处:参考/R8-埋点事件目录.md
登记原文参考/R8-埋点事件目录.md§0 deposit-liquidity.js 分区数=14/参考/R8-埋点事件目录.md§5 表格 13 行 + 注「实含 13 个」: 计数不一致 14 vs 13
○ 待收口
X-035冲突U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

埋点目录里 allo-pay-upgrade 分区计数不一致

说法一(参考/R8-埋点事件目录 §0)
allo-pay-upgrade.js 分区数为 7。
说法二(参考/R8-埋点事件目录 §6)
表格 6 行,并注「实含 6 个」。
矛盾计数不一致,7 vs 6。
涉及:N041 内部埋点事件记录出处:参考/R8-埋点事件目录.md
登记原文参考/R8-埋点事件目录.md§0 allo-pay-upgrade.js 分区数=7/参考/R8-埋点事件目录.md§6 表格 6 行 + 注「实含 6 个」: 计数不一致 7 vs 6
○ 待收口
X-036冲突U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

开户成功事件上报的分流,由前端还是后端决定

说法一(旧登记 L172)
前端按风险码和额度分支上报——风险码含 Y002 且额度≠0 时上报 PAYLATER_APPROVED+LOAN_ACC_OPENED,Y001 走另一路。
说法二(参考/R7 §1.1/§1.5、功能说明/13 §后端事实增补)
事件名由后端 eventNameList 下发;PAYLATER_APPROVED 与 LIMITUP 不得混报。
矛盾开户上报分流的判定主体不同(前端按风险码/额度分支 vs 后端配置下发);现行正文未见前端分支,旧口径存疑,尚未裁决。
涉及:L172 规则:开户成功事件上报分支N042 对外归因上报事件P068 对外上报事件名P004 风险码(风险标签集)出处:参考/R7-通知触达与交易流水.md·功能说明/13-埋点与监控.md
登记原文旧登记 L172（Y002∧limit≠0→PAYLATER_APPROVED+LOAN_ACC_OPENED；Y001→…）/参考/R7-通知触达与交易流水.md§1.1/§1.5 + 功能说明/13-埋点与监控.md§后端事实增补（事件名由后端 eventNameList 下发；PAYLATER_APPROVED 与 LIMITUP 不得混报）: 开户上报分流的判定主体不同（前端按 riskCode/limit 分支 vs 后端配置下发）；现行正文未见前端分支，旧口径存疑，未裁决
○ 待收口
X-037冲突U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

PIN 态的来源该记为「构造」还是「事实」

说法一(注册表原登记)
P024 PIN 态(密码状态)的来源标为构造。
说法二(功能说明/12 §A、§后端事实增补)
passwordStatus 是后端下发的状态枚举。
矛盾来源轴口径不同;本次已改为「事实」(凭证状态是对世界原样记录),请复核。
涉及:P024 PIN 态(密码状态)出处:功能说明/12-支撑流程(账户安全·引导·结果页).md
登记原文registry P024 origin=构造/功能说明/12-支撑流程(账户安全·引导·结果页).md§A/§后端事实增补 passwordStatus 为后端状态枚举: 来源轴口径：本次改为事实（凭证状态为世界原样记录），请复核
○ 待收口
X-038冲突U09 参考层字典(横切属性与枚举正本)

质押比例位段设计与前端兜底不一致(与 X-024 同题)

说法一(L103,前端兜底)
营销码质押位首位非 1 或全 000 = 无有效杠杆率,禁止质押。
说法二(R1§一 5-7 位 PM 口径、L393)
三位数×0.01,030=30% 为合法值。
矛盾适用范围重叠但结论不同——首位 0 的合法比例档(如 030)会被前端兜底误禁;现网只下发首位 1 暂不出错,R1 已标注「配置首位 0 档位前必须先修前端」。
涉及:P001 营销码L103 规则:前端质押杠杆率兜底判定L393 规则:营销码 5-7 位质押比例读法出处:R1§一·_待确认清单(挂起技术项 09/R1)
登记原文L103(前端兜底:首位非 1/全 000=无有效杠杆率禁质押)/R1§一 5-7 位 PM 口径(×0.01,030=30% 为合法值)/L393: 范围重叠结论不同:首位 0 的合法比例档(如 030)会被前端兜底误禁;现网只下发首位 1 暂不致错,R1 已标『配首位 0 档位前必须先修前端』,登记不裁决
○ 待收口
X-039冲突U09 参考层字典(横切属性与枚举正本)

营销码 3-4 位取值 00 是 0% 还是 2%

说法一(R1§一 第 3-4 位)
取值「00 = 2%(默认)」。
说法二(R3§⑦ getMemberPremiumPercent)
00 或缺失读为 0。
矛盾说法三(L149):非会员/过期一律按 2% 兜底。
涉及:P001 营销码L149 规则:还款提额比例读取出处:R1§一·R3§⑦·registry L149
登记原文R1§一 第 3-4 位取值『00=2%(默认)』/R3§⑦ getMemberPremiumPercent『00/缺失→0』/ L149『非会员/过期一律 2% 兜底』: 口径矛盾:00 读为 0% 还是 2%——疑 R1 把非会员兜底 2% 写进了位段取值;需 PM 明确 00 的位段含义
○ 待收口
X-040冲突U09 参考层字典(横切属性与枚举正本)

R1 引用纪律把营销码与灵活码的 3-4 位写混了

说法一(R1 引用纪律第 6 条)
灵活码第 3-4 位为直读整数百分比(非枚举映射)。
说法二(R1§一/§二)
营销码第 3-4 位才是直读比例;灵活码第 3-4 位是月最低可用性/重置标志(布尔位)。
矛盾属文内笔误——直读百分比是营销码 3-4 位,灵活码 3-4 位是布尔位;引用者易错。
涉及:P001 营销码P002 灵活码出处:R1 引用纪律·R1§一§二
登记原文R1 引用纪律第 6 条『Flex 第 3-4 位为直读整数百分比(非枚举映射)』/R1§一/§二(Market 3-4 位=直读比例;Flex 3-4 位=月最低可用性/重置标志): 文内笔误:直读百分比是 Market code 3-4 位,Flex 3-4 位是布尔位;引用者易错
○ 待收口
X-041冲突U09 参考层字典(横切属性与枚举正本)

营销码 5-7 位叫「杠杆率」还是「质押比例」

说法一(R2§二 营销码行)
第 5-7 位为质押杠杆率。
说法二(R1§一,2026-08-13)
第 5-7 位为定存质押比例(×0.01)。
矛盾术语未同步——R2 仍称「杠杆率」,R1 已改为「质押比例」;建议 R2 回改。
涉及:P001 营销码出处:R2§二·R1§一
登记原文R2§二 marketCode 行『质押杠杆率(5-7)』/R1§一 5-7 位『定存质押比例×0.01』(2026-08-13): 术语未同步:R2 仍称『杠杆率』,R1 已改『质押比例』;建议 R2 回改
○ 待收口
X-042冲突U09 参考层字典(横切属性与枚举正本)

质押提额的计算口径,PRD 版与实现版是否等价

说法一(L112,PRD 版)
质押提额 = 本金 × 杠杆率(代码倍数口径),或按比例 0-100%+最大值,或按存单金额区间给固定金额(二选一)。
说法二(R1§一、R10§4,07/09 篇实现事实版)
新增额度 = min(质押额×总杠杆率, 质押额+剩余杠杆额度)。
矛盾同一计算口径有两种表述,是否等价需 PM/后端确认。
涉及:L112 规则:定存质押新增额度公式N025 质押申请P017 质押杠杆信息组出处:registry L112·R1§一·R10§4
登记原文L112 质押提额=本金×杠杆率(代码倍数口径)/比例 0-100%+最大值 或 按存单金额区间固定金额(二选一)/R1§一/R10§4(07/09) 额度公式 新增额度=min(质押额×总杠杆率, 质押额+剩余杠杆额度): 同一计算口径两种表述(PRD 版 vs 实现事实版),是否等价需 PM/后端确认;登记不改写
○ 待收口
X-045冲突U09 参考层字典(横切属性与枚举正本)

质押划转状态,前端与后端值集对不上

说法一(R3§⑥)
P057 质押划转状态(TRANSFER_STATUS)前端值集含 REVERSE_SUCC/SEND_SUCC/APPLY_SUCC/WAIT_CONDITION 等在途细分。
说法二(R5§⑧)
生产表 tm_trans_info 的状态集只有 TRAN_SUCC/TRAN_FAIL/CANCEL/TRAN_INIT。
矛盾前端定义的在途细分与 REVERSE_SUCC 在生产未见,后端的 CANCEL 前端未定义;哪一侧是正本待确认。
涉及:P057 质押划转状态N025 质押申请出处:R3§⑥·R5§⑧
登记原文P057 前端 TRANSFER_STATUS 值集(含 REVERSE_SUCC/SEND_SUCC/APPLY_SUCC/WAIT_CONDITION)/R5§⑧ tm_trans_info 生产状态集仅 TRAN_SUCC/TRAN_FAIL/CANCEL/TRAN_INIT: 前后端值集不一致:前端定义的在途细分与 REVERSE_SUCC 生产未见,后端 CANCEL 前端未定义;哪一侧为正本待确认
○ 待收口
G-001缺口U01 开通与授信

授信申请结果码 1006/1008 是什么意思

缺什么:P092 授信申请结果码 中 1006、1008 两个码的业务含义没有登记。 为什么缺/线索:IT 知识库收录的 405 个接口契约里都没有这两个码,待后端确认(01§待确认、待确认清单·问后端第 2 条)。
涉及:P092 授信申请结果码出处:01§待确认·_待确认清单§问后端2
登记原文P092 授信申请结果码: 1006/1008 语义待后端（IT KB 405 个契约无此码）
○ 待收口
G-002缺口U01 开通与授信

申请被置为待面签/待补料,是谁写入的

缺什么:P006 开通/KYC 状态 里的 T017/T022/T023(待 Video Banking 面签、待补料等中间态)由谁写入没有登记——是引擎裁决参数自动置的,还是审核人员人工操作。 为什么缺/线索:出处只列了状态值,没有写写入方(R5§①)。
涉及:P006 开通/KYC 状态出处:R5§①
登记原文P006 开通状态 T017/T022/T023: 缺写入方：谁把申请置为待 VB/待补料（引擎裁决参数还是审核人工）
○ 待收口
G-003缺口U01 开通与授信

开通拒绝码由哪个引擎产出(码族语义已补全,只差引擎归属)

缺什么:P087 开通拒绝码 中 B 开头的拒绝码由哪个引擎产出没有登记——是 F-21 KYC 预筛决策(IKYC)还是 F-54 开户反欺诈初审(MIDAFS);各码对应的反欺诈命中规则和阈值也没有。 为什么缺/线索:命中规则和阈值在风控策略包里,文档和代码都不持有(01§D.2、R10§5)。 [2026-09-08 IT 知识库核查] 码族语义已查全并随 G-189 登记(B 系=业务拒绝、D/S 系=系统故障)。剩余未决的只有「B 系各码由 F-21 KYC 预筛还是 F-54 开户初审产出」与命中规则/阈值——两者都在风控策略包里,知识库结构性不收。这也是 P087 writer=∅ 合规错误的唯一堵点。
涉及:P087 开通拒绝码F-21 KYC 预筛决策F-54 开户反欺诈初审出处:01§D.2·R10§5
登记原文P087 开通拒绝码: 缺写入方：B 系码由哪个引擎产出（IKYC F-21 / MIDAFS F-54）；各码反欺诈命中规则/阈值在风控策略包
○ 待收口
G-004缺口U01 开通与授信

预授信额度是谁算出来的

缺什么:P073 预授信额度 由谁写入、由哪个函数产出没有登记——是离线模型跑出来的,还是引擎实时算的。 为什么缺/线索:出处只写了这个字段的存在,没有写产出方(01§A、01§后端补充事实)。
涉及:P073 预授信额度出处:01§A·01§后端补充事实
登记原文P073 预授信额度: 缺写入方与产出函数（离线模型 or 引擎）
○ 待收口
G-007缺口U01 开通与授信

钱包锁定/冻结/解锁动作没有建档

缺什么:P077 钱包状态 的写入方没有建档——钱包侧的锁定、冻结、解锁等动作没有登记为动作构件。 为什么缺/线索:出处只观测到状态值,没有对应的动作(R5§⑧)。
涉及:P077 钱包状态出处:R5§⑧
登记原文P077 钱包状态: 写入方（钱包侧锁定/冻结/解锁动作）未建档
○ 待收口
G-008缺口U01 开通与授信

锁定码 U/N 含义及与账单状态的优先级不明

缺什么:P005 冻结/拦截码(锁定码) 里在用的 U、N 两个码业务含义没有给出;锁定码与账单状态(acctStmtStatus)谁优先也没有说明。 为什么缺/线索:优先级关系待 PM/后端确认(R1§五)。
涉及:P005 冻结/拦截码(锁定码)出处:R1§五
登记原文P005 blockCode: 在用码 U/N 语义未见；与 acctStmtStatus 优先级待 PM/后端
○ 待收口
G-009缺口U01 开通与授信

客群分段码第 3-40 位含义待补

缺什么:P003 客群分段码 共 40 位,第 3-40 位每一位的含义没有登记。 为什么缺/线索:待 PM 补充(R1§三)。
涉及:P003 客群分段码出处:R1§三
登记原文P003 segCode: 3-40 位含义待 PM 补充
○ 待收口
G-010缺口U01 开通与授信

风险码完整字典和 Risk Flag 具体值缺失

缺什么:P004 风险码(风险标签集) 的完整取值字典和对应的策略包版本没有;文档里"Risk Flag=XXXX"占位符的实际取值也没有。 为什么缺/线索:IT 知识库未收录风险码字典(R1§四、R10§6);Risk Flag 具体值待 PM 补。
涉及:P004 风险码(风险标签集)出处:R1§四·R10§6
登记原文P004 riskCode: 完整字典与策略包版本 IT KB 未收录；Risk Flag=XXXX 待 PM 补值
○ 待收口
G-011缺口U01 开通与授信

开户流程从申请到激活的端到端链路未闭合

缺什么:N073 开户流程实例 在开户系统(MEG)侧落哪张表、表结构如何没有;从申请→审批→落额→激活的端到端运行链路没有串起来。 为什么缺/线索:MEG 侧落表结构没进 IT 知识库(R10§3、R10§6)。
涉及:N073 开户流程实例出处:R10§3·R10§6
登记原文N073 开户流程实例: MEG 侧落表结构未入 IT KB；apply→审批→落额→激活端到端运行链未闭合
○ 待收口
G-012缺口U01 开通与授信

能否开 Prime 户的判定方和规则不明

缺什么:"能否开通 Prime 钱包账户"这个标志(P086 子字段 canOpenPrimeAcct)由谁判定、按什么规则判定没有登记。 为什么缺/线索:出处只见到该标志被使用,未见判定逻辑(01§D.5)。
涉及:P086 子字段 canOpenPrimeAcct出处:01§D.5
登记原文P086.canOpenPrimeAcct: 判定方/判定规则未见
○ 待收口
G-013缺口U01 开通与授信

落地页放行标志 withoutUaAndMpc 的含义不明

缺什么:L195 规则(落地页准入放行)依赖的标志(withoutUaAndMpc)业务含义没有登记——什么场景下会"没有 UA 和 MPC"没有写清。 为什么缺/线索:出处只有"该标志为真时直接放行、不做钱包状态阻断"这一条判断(01§D.1)。
涉及:L195 规则:落地页准入放行标志出处:01§D.1
登记原文L195 withoutUaAndMpc: 标志语义未见（何种上下文缺 UA/MPC）
○ 待收口
G-014缺口U01 开通与授信

视频面签由谁执行、面签记录如何标识不明

缺什么:A-52 执行 Video Banking 面签 由哪个系统或团队执行没有登记;面签记录也没有唯一标识字段。 为什么缺/线索:出处只写到有面签环节(01§D.5)。
涉及:A-52 执行 Video Banking 面签出处:01§D.5
登记原文A-52 执行 Video Banking 面签: 面签方（系统/团队）归属未见；VB 面签记录 identity 未见
○ 待收口
G-015缺口U01 开通与授信

额度锁定:BLOCK_CODE 字典已有,但触发与解锁路径仍缺

缺什么:A-23 锁定授信额度 有两处空白——① 触发参数(params)未见:什么条件、按什么入参判定"额度异常"没有记载;② 解锁路径未见:锁定后如何恢复(自动解除还是人工、走哪个动作)没有记载。 为什么缺/线索:R5§① 只给出状态值 ACTIVE_CREDIT_FREEZED(已开户但额度异常被锁定)与状态机位置,未描述触发与解除机制。待风控/后端补。 [2026-09-08 IT 知识库核查] BLOCK_CODE 全字典在知识库中可查;但登记表里写的 ACTIVE_CREDIT_FREEZED 在代码中零命中,A-23 锁定授信额度 的触发条件与解锁路径同样未见。两点结论:①ACTIVE_CREDIT_FREEZED 这个值的来源存疑,须核对是否为口述或早期文档遗留;②锁定/解锁的触发属风控策略,需风控给规则、后端给落库路径。
涉及:A-23 锁定授信额度N002 信贷账户P006 开通/KYC 状态出处:R5§①
登记原文A-23 锁定授信额度: 解锁动作与路径未见
○ 待收口
G-016缺口U01 开通与授信

安全问答核身的题库和判定阈值不在文档里

缺什么:F-55 安全问答核身判定 用的具体题目和判定通过的阈值没有登记。 为什么缺/线索:题库和阈值存在后台数据库/策略里,文档和代码都不持有(01§待确认)。
涉及:F-55 安全问答核身判定出处:01§待确认
登记原文F-55 安全问答核身判定: 题库具体题目与判定阈值在后台 DB/策略
○ 待收口
G-018缺口U01 开通与授信

开户段五类上报/提交记录缺唯一标识

缺什么:N031 推荐码提交、N033 协议同意、N038 GPS 定位记录、N039 App List 采集记录、N040 CNC 风控上报事件 五类记录都没有登记唯一标识字段。 为什么缺/线索:出处只见提交/上报动作,未见记录的标识列(01§D.5、01§D.7、R10§4.01)。 [2026-09-08 IT 知识库核查] 五类里已解决两类:App List 采集记录主键=t_user_app_list_report.id(见 G-184);Video Banking 面签场次号=CASE_NO(见 G-185)。GPS 定位记录仍缺:落表 ICRC-DATA.TM_CUST_GPS_INFO 已定位,但表内只有 ECIF_NO 客户号、无记录级主键列,需后端确认该表的实际主键(可能是复合键 ECIF_NO+BIZ_TYPE+CREATED_DATETIME)。埋点事件(N041)属 BI 侧事件字典,知识库结构性不收。
涉及:N031 推荐码提交N033 协议同意N038 GPS 定位记录N039 App List 采集记录N040 CNC 风控上报事件出处:01§D.5·01§D.7·R10§4.01
登记原文N031/N033/N038/N039/N040 identity: 登记未见身份标识列（推荐码提交、协议同意、GPS/App List/CNC 记录）
○ 待收口
G-019缺口U01 开通与授信

OCR SDK 版本号无法在前端证实

缺什么:F-44 OCR 证件识别 用的 SDK 版本(Advance.AI v3.0.3)只有 PRD 口径,前端代码里没有版本字符串可以证实。 为什么缺/线索:版本以 App 原生侧为准(01§待确认)。
涉及:F-44 OCR 证件识别出处:01§待确认
登记原文F-44 OCR SDK 版本: Advance v3.0.3 为 PRD 口径，前端无版本串可证，版本以原生侧为准
○ 待收口
G-020缺口U01 开通与授信

授信拒绝原因码取值表缺失

缺什么:P095 授信拒绝原因码 的全部取值和含义没有登记。 为什么缺/线索:出处只提到有这个字段(01§A)。
涉及:P095 授信拒绝原因码出处:01§A
登记原文P095 授信拒绝原因码: 取值表未见
○ 待收口
G-021缺口U01 开通与授信

OCR 提交结果状态除成功码外取值不明

缺什么:P091 OCR 提交结果状态 只见到 5000 一个取值,其余取值和含义没有登记。 为什么缺/线索:出处只出现 5000 这一个值(01§D.5)。
涉及:P091 OCR 提交结果状态出处:01§D.5
登记原文P091 OCR 提交结果状态: 除 5000 外其余取值未见
○ 待收口
G-022缺口U01 开通与授信

推荐码提交后能否撤销不明

缺什么:A-20 受理推荐码提交 后能否撤销、撤销路径是什么没有登记。 为什么缺/线索:目前卡片里写的可逆性是推断,没有出处证实(01§D.5)。
涉及:A-20 受理推荐码提交出处:01§D.5
登记原文A-20 受理推荐码提交: 可逆性（撤销路径）未见，卡内为推断
○ 待收口
G-023缺口U01 开通与授信

授信结果轮询超时后用户落到哪个页面

缺什么:A-56 受理授信提交并送审 后前端每 2 秒查一次结果、最多查 10 次(amsAccountQueryApplyResult),10 次用完仍无结果时用户落到哪个页面没有明说。 为什么缺/线索:推断是"处理中"页,但出处未写明(01§D.4)。
涉及:A-56 受理授信提交并送审出处:01§D.4
登记原文A-56 轮询超时: amsAccountQueryApplyResult 2s×10 轮询耗尽后的落点未明说（推断为 processing 页）
○ 待收口
G-026缺口U02 支付消费

QRIS 付款码身份已定,只差码有效时长

缺什么:N079 QRIS 付款码(CPM 被扫) 的码串字段、出码流水字段名和码的有效时长没有登记;PayLater 额度作为付款码资金源在生产上真实存在的证据也没有。 为什么缺/线索:IT 知识库查不到相关记录(R10§6)。 [2026-09-08 IT 知识库核查] 身份标识查到:qrCodeNo(出码流水号)+ qrCodeValue(码串),payWith 枚举给出付款方式,已补进 N079。剩余未决:付款码的有效时长(TTL)——属运行配置,知识库不收,需后端给现网值。
涉及:N079 QRIS 付款码(CPM 被扫)出处:R10§6
登记原文N079 QRIS 付款码: 码串/出码流水字段名与时效未见；PayLater 作 CPM 资金源的生产实证 IT KB 查不到
○ 待收口
G-030缺口U02 支付消费

消费费率现网值和积分兑换规则缺失

缺什么:消费的 admin fee 月费率、年利率、service fee 率在现网的实际值没有;积分兑换率和兑换上限的业务规则也没有。 为什么缺/线索:费率由引擎按账户实时计算,前端没有静态表,待 PM/后端给值(R4§6、02§待确认);积分规则待 PRD。
出处:R4§6·02§待确认
登记原文两费现网值: 消费 admin fee 月费率、年利率、消费 service fee 率现网值为引擎按账户算，前端无静态表，待 PM/后端；积分兑换率/上限业务规则待 PRD
○ 待收口
G-031缺口U02 支付消费

对外商户接入规范不在知识库(内部查单与回调契约已齐)

缺什么:外部商户正式接入的规范(查单、结果回调的契约细节)没有,目前只有 L027 规则(SDK 关闭不回传支付结果)这一条。 为什么缺/线索:接入规范不在 IT 知识库里,由收单侧提供(02§待确认)。 [2026-09-08 IT 知识库核查] 内部侧:查单与回调契约在知识库中完整,L027「SDK 关闭不回传支付结果」的技术前提可核实。对外侧:面向外部商户的接入规范(签名、回调重试约定、对账口径等)不是代码资产,知识库结构性不收,需商务/产品提供对外文档。
涉及:L027 规则:SDK 关闭不回传支付结果出处:02§待确认
登记原文L027 商户接入契约: 对外部商户正式接入 spec（查单/回调契约细节）不在 IT KB，由收单侧提供
○ 待收口
G-032缺口U02 支付消费

支付链路埋点事件 ID 待前端/数据(框架已确认存在)

缺什么:A-04 受理支付交易 从付款页拉单→试算→提交→结果全程零埋点,没有可观测的指标;另外代码里的结果轮询守卫(isUpScene 未定义、coreTransPayUnionPayLoanResult 未被调用)是死分支。 为什么缺/线索:PM 2026-08-13 确认暂不立项补埋点(02§D.4、02§经营与体验关注点)。 [2026-09-08 IT 知识库核查] 埋点框架确实存在:weboard-web-sdk。但支付链路各步的事件 ID 不在知识库里(埋点 ID 属前端常量与数据字典,知识库结构性不收)。结论:不是「没有埋点能力」,是「事件 ID 未登记」——需前端给出支付链路已埋的事件清单,数据侧给漏斗口径。
涉及:A-04 受理支付交易出处:02§D.4·02§经营与体验关注点
登记原文A-04 支付漏斗观测: payment 页拉单→试算→提交→结果全程零埋点，feedback 不可度量（PM 2026-08-13 暂不立项）；轮询守卫 isUpScene 未定义/coreTransPayUnionPayLoanResult 未调用为死分支
○ 待收口
G-033缺口U02 支付消费

各类优惠券能否叠加、谁优先没有统一规则

缺什么:低价权益、支付立减券、Admin Fee 券三者之间能否叠加、叠加时谁优先,没有统一的叠加规则。 为什么缺/线索:代码里没有统一的叠加器,PRD 也没有成文,待 PM(R4§4)。
出处:R4§4
登记原文券叠加规则: 低价权益/支付立减券/Admin Fee 券之间能否叠加与优先级无统一叠加器、PRD 未成文，待 PM
○ 待收口
G-035缺口U02 支付消费

钱包支付场景 ALLO_PAY 是否仍有效待 PM

缺什么:支付场景 ALLO_PAY(钱包支付)是否还是一个有效的业务场景没有定论。 为什么缺/线索:SDK 里对应的路由(SERVICE_PAYMENT)没有注册,跳转必然失败,对应页面文件(pages/service/Payment.vue)是无人引用的孤儿文件——待 PM 确认(02§关键字段与门槛、02§D.1)。
出处:02§关键字段与门槛·02§D.1
登记原文scene=ALLO_PAY 钱包支付: SDK 内路由 SERVICE_PAYMENT 未注册、导航必失败；pages/service/Payment.vue 为孤儿文件——ALLO_PAY 是否仍是有效业务场景待 PM
○ 待收口
G-036缺口U02 支付消费

试算方案等"构造类"对象该算实体还是事件

缺什么:N046 试算方案 在注册表里标为"构造"类型,而按手册二分法这次记成了事件,两处不一致;同一批标为构造的对象(N045 账单~N072 工单)如何映射到实体/事件也没有统一说法。 为什么缺/线索:需要审核统一口径(注册表索引 vs 手册第 2 章§2.1)。
涉及:N046 试算方案出处:registry-index vs handbook-ch2 §2.1
登记原文N046 试算方案对象类型: 注册表标 type=构造，本轮按二分记事件；需审核统一（同批 N045~N072 构造类如何映射实体/事件）
○ 待收口
G-037缺口U03 取现 Instant Cash

取现挑战记录缺标识,挑战后查放款结果流程不详

缺什么:N082 风控挑战记录 在取现侧没有唯一标识字段(现有的 RULE_CODE_LIST_PARTNER 只是挑战类型清单,不是标识);用户完成 OTP/刷脸挑战之后,如何继续查询放款结果的流程也没有写清。 为什么缺/线索:出处只写到挑战下发(03§D.4)。
涉及:N082 风控挑战记录出处:03§D.4
登记原文N082: 取现侧挑战记录标识字段未见(RULE_CODE_LIST_PARTNER 为清单);挑战完成(OTP/刷脸)后续查放款结果的流程未详
○ 待收口
G-038缺口U03 取现 Instant Cash

取现审批决策:落库字段已有,APPROVAL_RESULT/ACTION_CODE 枚举仍缺

缺什么:P127 取现借款审批决策(首借/复借审批)的取值字典和落库字段没有登记。 为什么缺/线索:风险码字典与策略包版本在 IT 知识库查不到(R10§6)。 [2026-08-27 合并 G-165 的出处:03§业务规则速览、02§引擎矩阵、R10§4.03、03§口径补充中均未见取值字典。] [2026-09-08 IT 知识库核查] 落库表与字段可查;缺的是 APPROVAL_RESULT 与 ACTION_CODE 两个枚举的取值字典——与 G-048/G-152 是同一件事的两面(那两条问的是 ACTION_CODE 的四个具体值)。需风控一并给出。
涉及:P127 取现借款审批决策出处:R10§6
登记原文P127: 首借/复借审批决策取值字典与落库字段未见(RiskCode 字典/策略包版本 IT KB 查不到)
○ 待收口
G-039缺口U03 取现 Instant Cash

刷脸反欺诈取现侧:MIDAFS 落库已统一,CLCF 绑定行未见

缺什么:F-17 刷脸反欺诈(CLCF) 在取现链路里的输出结果落到哪个字段没有登记。 为什么缺/线索:引擎矩阵只列了调用点(02§引擎矩阵)。 [2026-09-08 IT 知识库核查] MIDAFS 侧落库与开户段同族(结论 TM_AFS_CASE.ACTION_TYPE、明细 TM_MID_AFS_RESULT,见 G-017)。剩余:F-17 在 CLCF 侧具体绑定到哪一行配置未见,需后端指认。
涉及:F-17 刷脸反欺诈出处:02§引擎矩阵
登记原文F-17: 刷脸反欺诈(CLCF)取现侧输出落库字段未见
○ 待收口
G-040缺口U03 取现 Instant Cash

RIPLAY 披露内容由谁配置、流程如何未建档

缺什么:P129 RIPLAY 披露内容字段组 的写入方——合规/产品配置合同模板的动作——没有建档;合同模板的配置流程也没有。 为什么缺/线索:出处只写了披露字段内容(03§RIPLAY)。
涉及:P129 RIPLAY 披露内容字段组出处:03§RIPLAY
登记原文P129: RIPLAY 披露内容写入方(合规/产品配置合同模板动作)未建档;合同模板配置流程未见
○ 待收口
G-042缺口U03 取现 Instant Cash

放款资金入钱包的最后一跳链路未闭合

缺什么:A-26 放款 的资金最终进入 Allo Wallet 钱包(R072 放款至钱包)这最后一跳经过哪些系统没有串起来。 为什么缺/线索:IT 知识库里该链路未闭合(R10§6)。
涉及:A-26 放款R072 放款至(钱包)出处:R10§6
登记原文A-26 / R072: 放款资金落 Allo Wallet 的最后一跳链路在 IT KB 未闭合
○ 待收口
G-043缺口U03 取现 Instant Cash

高额度挽留问卷的内容和作答去向不明

缺什么:N043 UI 展示记录 中的高额度挽留问卷,问卷题目内容、用户作答提交后落到哪、作答事件如何记录都没有登记,目前只知道弹窗的触发条件和节流规则。 为什么缺/线索:出处只写了弹窗触发(03§高额度挽留问卷弹窗)。
涉及:N043 UI 展示记录出处:03§高额度挽留问卷弹窗
登记原文N043 挽留问卷: 问卷内容/提交落库/作答事件未见,只知弹窗触发与节流
○ 待收口
G-044缺口U03 取现 Instant Cash

低价档各档费率、适用人群、发券规则待 PM

缺什么:P035 低价档字段组 在现网各档的费率值(0/0.5/1.5/2.5%)、每档适用哪些人群、对应的券怎么发,都没有登记。 为什么缺/线索:这些是营销/后台配置,不在代码里,待 PM(R4§6、03§口径补充)。
涉及:P035 低价档字段组出处:R4§6·03§口径补充
登记原文P035 低价档: 现网各低价档费率值(0/0.5/1.5/2.5%)与适用人群、券发放规则为营销/后台配置,待 PM
○ 待收口
G-045缺口U03 取现 Instant Cash

低价引导二期"第一价格区间上限"具体值不明

缺什么:L056 规则(主页低价引导二期收紧条件)里"额占率低于第一个价格区间上限才展示"的那个上限值是多少没有登记。 为什么缺/线索:该值是营销配置,前端没有判定常量(03§主页低价权益引导标记、R4§6)。
涉及:L056 规则:主页低价引导二期条件出处:03§主页低价权益引导标记·R4§6
登记原文L056: 额占率二期'第一个价格区间上限值'为营销配置,前端无判定常量
○ 待收口
G-046缺口U03 取现 Instant Cash

常规与低价取现页产品号取法不同,多产品账户会否算错

缺什么:L240 规则(取现试算入参)里,常规取现页的产品号动态取账户第一个贷款计划(loanPlans[0]),低价取现页却写死为 9022;一个账户有多个产品号时两页会不会试算到不同产品,没有答案。 为什么缺/线索:待后端确认(03§待确认)。
涉及:L240 规则:取现试算入参约束出处:03§待确认
登记原文L240: 常规页 LOAN_CODE 动态取 loanPlans[0] vs 低价页硬编码 9022,多产品号账户下是否试算到不同产品待后端
○ 待收口
G-047缺口U03 取现 Instant Cash

取现授权 15 项检查的完整清单缺失

缺什么:L235 规则(取现授权须过 15 个检查点)的完整清单没有,目前只知道第一项是锁定码检查、另有两道额度检查。 为什么缺/线索:出处只给了部分(03§后端事实增补)。
涉及:L235 规则:取现授权 15 项检查出处:03§后端事实增补
登记原文L235: 取现授权 15 个检查点全清单未见(仅知锁定码第一 + 两道额度检查)
○ 待收口
G-048缺口U03 取现 Instant Cash

支用结果动作码六个值有四个含义不明

缺什么:P041 支用提交结果码(风控挑战码) 中的动作码(ACTION_CODE)共六个值,其中 LR、LA、LACLNL、LACLNH 四个的业务含义没有登记,只知道 LRCLNR/LRCLNL 表示额度受限(QUOTA_LIMIT)。 为什么缺/线索:出处只见前端对那两个值的处理(R3§⑥其它场景码)。 [2026-09-08 IT 知识库核查] ACTION_CODE 这一列在知识库中存在且可定位,但 LR / LA / LACLNL / LACLNH 四个取值全部零命中——取值语义在风控策略包里,知识库结构性不收。与 G-038 是同一件事(该列的枚举字典)。建议三条合并向风控一次性提问。
涉及:P041 支用提交结果码(风控挑战码)出处:R3§⑥其它场景码
登记原文P041 ACTION_CODE: 六值中 LR/LA/LACLNL/LACLNH 语义未见(仅知 LRCLNR/LRCLNL→QUOTA_LIMIT)
○ 待收口
G-049缺口U03 取现 Instant Cash

S08「已批已扣未放款」存量处置:两月 1,363 人待补偿,产品侧跟进中

缺什么:P124 取现订单/协议状态 中的 S08 作废单——审批通过、钱已扣、但没放款——后续怎么处理、怎么补偿没有建档为动作,系统也没有自愈机制。 为什么缺/线索:出处只观测到该状态(R5§⑧)。 [2026-09-08 六段核验·功能说明 05 E.5 补入生产实证] 这不是理论风险,是已发生的事故,且有明确规模: · 形态:客户按引导完成最低还款(收钱腿成功)后,借新还旧新贷在放款授权 31015 被 ICPS 锁定码检查拒绝→钱已扣、订单落 S08 取消终态(不可撤销、无自愈)。客户表现为「还了最低还款却还在逾期」。 · 规模:2026-06 影响 113 人;2026-07 影响 1,250 人 / 29.57 亿 IDR。两月合计约 1,363 人待补偿。 · 根因:数据鲜度错配——入口判定读 CRC-DATA 离线标签 FlexCode(会漂移),放款判定读 ICPS 实时 BLOCK_CODE,「标签允许最低还款」与「账户已挂码」同时成立。 · 拒绝码分布:L038(A/Z/z 逾期码)63.7% + V011(n 黑名单)32.3%。⚠ V011 那批客户 DPD 全为 0——只按逾期天数筛会漏掉三分之一。 · 状态:产品侧已在跟进修复(2026-08-13 确认),落地后应更新 L278 与 F-66 note 里的「无自愈/未修」表述。 与 G-193 假拒绝是同一类问题(生产缺陷造成的存量客户损害),但那条卡在重新取数(G-207),本条数字已实证。
涉及:P124 取现订单/协议状态出处:R5§⑧
登记原文P124 S08: S08 作废单(批了、扣了钱、未放款)的处理/补偿动作未建档,无自愈
○ 待收口
G-050缺口U03 取现 Instant Cash

取现用券核销:通道已定位,落哪个服务号未定

缺什么:A-38 核销优惠券 在取现侧,利率券(INT_RG)和普通券通过 MES_INFO 核销时归哪个系统负责(NBS 200002 还是 IMEG 88200056)没有登记;放款失败时券状态会不会回滚也没有。 为什么缺/线索:出处只见核销调用(03§D.4、R10§4.11)。 [2026-09-08 IT 知识库核查] 核销通道查到:INBS 走 MES_EQUITY_OPERATE;另有 CPS_COUPON_CANCEL_QUERY 撤销查询接口——这回答了缺口的后半问:「放款失败券会否退回」在技术上有撤销通道,不是无解。剩余:核销究竟落 88200070 还是 88200056 这两个服务号中的哪一个,需后端指认;以及撤销是否被业务流程实际调用(有通道不等于有调用)。
涉及:A-38 核销优惠券出处:03§D.4·R10§4.11
登记原文A-38 取现侧: INT_RG/普通券经 MES_INFO 核销的系统归属(NBS 200002/IMEG 88200056)与放款失败时券状态是否回滚未见
○ 待收口
G-051缺口U03 取现 Instant Cash

低价权益与各类券的叠加优先级待 PM(知识库结构性不收)

缺什么:L060 规则(低价权益与利率券可叠加)之外,低价权益、支付立减券、Admin Fee 券之间叠加时谁优先没有统一规则。 为什么缺/线索:代码里没有统一的叠加器,待 PM(R4§4)。 [2026-09-08 IT 知识库核查] 知识库结构性不收此类内容:叠加优先级是产品策略,不落在代码里(代码只按传入的优先级执行)。需 PM 直接给出各类券与低价权益的叠加/互斥优先级表。已确认无需再检索。
涉及:L060 规则:低价权益与利率券叠加出处:R4§4
登记原文L060: 低价权益/支付立减券/Admin Fee 券叠加优先级无统一叠加器,待 PM
○ 待收口
G-052缺口U03 取现 Instant Cash

DBDP 风险标签是怎么打上去的未建档

缺什么:P004 风险码(风险标签集) 中 DBDP 标签的打标动作和圈选规则没有建档,目前只知道这个标签会强控相关字段。 为什么缺/线索:打标逻辑在风控侧(03§业务规则速览、R1§riskCode)。
涉及:P004 风险码(风险标签集)出处:03§业务规则速览·R1§riskCode
登记原文P004 DBDP: DBDP 标签的打标动作/圈选规则在风控侧,未建档(仅知字段强控)
○ 待收口
G-053缺口U03 取现 Instant Cash

VDC 自动补足:接口落库已有,阈值与判定规则待 PM

缺什么:虚拟卡自动补足(VDC Auto top-up)的触发阈值,以及从信贷额度还是钱包补足,都没有定。 为什么缺/线索:待 PM 确认;当前前端仓库没有承载,归 U02 的 A-33 VDC 自动补足放款(03§待确认)。 [2026-09-08 IT 知识库核查] 接口与落库路径可查。剩余的触发阈值(补足到多少、低于多少触发)与资金来源判定规则属产品参数,知识库结构性不收,需 PM 给现网配置。
涉及:A-33 VDC 自动补足放款出处:03§待确认
登记原文VDC Auto top-up: 触发阈值与补足来源(额度 vs 钱包)待 PM;本仓前端无承载(归 U02 A-33)
○ 待收口
G-054缺口U03 取现 Instant Cash

试算方案没有持久标识

缺什么:N046 试算方案 没有持久化的唯一标识,只是会话内的一次报价,作为对象无法落地追溯。 为什么缺/线索:出处只见会话内试算结果(03§D.2)。
涉及:N046 试算方案出处:03§D.2
登记原文N046 试算方案: 无持久标识(会话内报价),对象接地缺口
○ 待收口
G-055缺口U03 取现 Instant Cash

取现 OTP 结果值 1/2 的含义不明

缺什么:P044 挑战/OTP 链路字段 中 OTP 结果(OTP_RESULT)取值 1 和 2 分别代表什么没有登记。 为什么缺/线索:R7§取现 WhatsApp OTP 未给出,归 U12。
涉及:P044 挑战/OTP 链路字段出处:R7§取现 WhatsApp OTP
登记原文P044 OTP_RESULT: OTP_RESULT 1/2 语义未在本篇给出(R7/U12)
○ 待收口
G-059缺口U04 账单与账期、常规还款

出账:日终 Task5 cpsJob 职责已成文,批步骤与计息规则未追到代码

缺什么:出账批量的具体步骤、计息规则、以及「当期账单状态」的后端取值字典(CURR_STMT_STATUS)都没有闭合;日终主批(cpsJob 00:00)是否就是出账批,也没有证实。 为什么缺/线索:R10§4-04、R5§⑧、05§E.7 各写了一部分,IT KB 里没有能把整条链串起来的材料。 [2026-09-08 IT 知识库核查] 日终批中 Task5 cpsJob 的职责范围在知识库中成文,可确认出账挂在日终批里。剩余:出账批的步骤序列(先算什么后写什么)与计息规则的代码实现未追到,需后端给作业编排与计息实现。
涉及:A-40 出账P198 前一账期账单状态出处:R10§4-04·R5§⑧·05§E.7
登记原文A-40 出账: 出账批量 step、计息规则、CURR_STMT_STATUS 后端字典 IT KB 未闭合；日终主批 cpsJob 00:00 是否即出账批未证实
○ 待收口
G-060缺口U04 账单与账期、常规还款

「有当期欠款才出账单」这条旧规则还成立吗

缺什么:旧登记里「有当期欠款才出账单」这句话,在现有资料里找不到再次佐证;反而前端有一个「未使用账单」判断(当期账单金额与已还金额都为 0),暗示零金额账单是可能存在的。 为什么缺/线索:R5§③;需要后端确认零额账单会不会生成,再决定旧规则去留。
涉及:L062 规则:按账单日出账出处:R5§③
登记原文L062: '有当期欠款才出'旧登记语句现语料未再证实（isUnused=CUR_STMT_AMT===0&&STMT_PAID_AMT===0 暗示零额账单可存在）
○ 待收口
G-061缺口U04 账单与账期、常规还款

自动扣款的钱从哪来、能不能撤、时点是否确定

缺什么:自动扣款的资金来源(是否就是钱包 VA)、扣款后是否会生成一笔还款交易记录、能否撤销,都没有登记;「余额低于 Rp1,000 就跳过」这条过滤规则没有实现证据;扣款时点只有三天生产实测,没有正式口径。 为什么缺/线索:05§E.7 只有观测记录,没有后端规则文档。
涉及:A-60 自动扣款N018 还款交易出处:05§E.7
登记原文A-60 自动扣款: 扣款资金来源（是否即钱包 VA）、是否落 N018 实例、可逆性；Rp1,000 低余额过滤无实现证据；时点仅三天生产实测
○ 待收口
G-063缺口U04 账单与账期、常规还款

还款状态前后端两套取值怎么对应

缺什么:还款状态在后端只有成功/失败(S/F),前端却定义了处理中/成功/完成(P/S/C,轮询时还有 PENDING),两套取值集之间的对应关系没有统一。 为什么缺/线索:05§E.2 与 R7§2.3 各写各的,待统一。
涉及:P130 还款交易要素组出处:05§E.2·R7§2.3
登记原文P130 REPAY_STATUS: 后端 S/F 与前端 REPAYMENT_STATUSES P/S/C（及轮询 PENDING）取值集对应关系待统一
○ 待收口
G-065缺口U04 账单与账期、常规还款

逾期罚息日利率现网到底是多少

缺什么:罚息日利率(PENALTY_RATE)的现网实际值没有登记,0.3%/日只是 RIPLAY 披露口径。 为什么缺/线索:R4§6 费率表里此项留空,前端不持有该值,需向后端/参数表核对。
涉及:L064 规则:逾期账单罚息 0.3%/日P133 账期参数组出处:R4§6
登记原文L064 / P133 罚息日率: PENALTY_RATE 现网值（0.3%/日为 RIPLAY 口径）
○ 待收口
G-067缺口U04 账单与账期、常规还款

综合账户态九个取值分别是什么意思

缺什么:综合账户态的九个取值(W/AC/NAC/RFC/OPC/NU/HN/HF/HO)各自的业务含义,知识库里没有给出。 为什么缺/线索:R5§③只列出了取值,没有释义。
涉及:P009 综合账户态(派生)出处:R5§③
登记原文P009 综合账户态: 九值 W/AC/NAC/RFC/OPC/NU/HN/HF/HO 各值业务含义知识库未给出
○ 待收口
G-068缺口U04 账单与账期、常规还款

还款冲抵明细的标识与落表只是推测,冲正机制未见

缺什么:还款冲抵明细(一笔还款分别冲了哪些本金/利息/费用)的唯一标识字段和落表(推测为 TM_PAYMENT_HST)都只是推断;冲正/撤销机制没有找到。 为什么缺/线索:05§E.1 与 R10§4-04 只见到表名线索,待后端证实。
涉及:N083 还款冲抵明细出处:05§E.1·R10§4-04
登记原文N083 还款冲抵明细: 身份标识与落表（TM_PAYMENT_HST）为推断；冲正机制未见
○ 待收口
G-069缺口U04 账单与账期、常规还款

商户退款与溢缴退款判为两类对象(已定),拆分动作留退款专项

缺什么:商户发起的退款(流水里 R 型记录、带商户名)与客户多还/溢缴产生的退款,是否应视为同一个「退款单」对象,没有定论。 为什么缺/线索:R7§2.2 与 04§业务视角各只描述其中一种。 [2026-09-08 IT 知识库核查] 知识库给出的事实:商户退款与溢缴退款在系统上是分开的两条链路,由不同服务承载。但「是否应建为同一个对象」是本体决策,知识库不裁决。我的建议:两者的发起方、生命周期与资金流向都不同(商户退款由收单侧发起、溢缴退款由账务侧发起),按纲要「一个对象只代表一样东西」应判为两类;N053 退款单 保留给商户退款,溢缴退款另立。但这会牵动 N053 的既有引用,建议在退款专项核验时一并处理,不在本轮动刀。 [2026-09-08 Leo 定结论] 判为两类对象,理由:发起方(商户/账务)、起因(退货撤单/客户还多了)、资金来源(商户账/本行账)、冲抵目标(那笔消费/账户余额)四项全不同,合于纲要「一个对象只代表一样东西」;P121 退款类型 这个属性的存在本身就是「用类型字段区分两种本质不同的东西」的征兆。执行方式:不在本轮动刀,另开退款专项——须逐个判定 N053 现有 12 处引用各归哪一类(R027 出自(退款)、R068 冲退(消费)、A-36 退款、A-67 冲回支付立减、F-64 账单查询、L071、L347,以及 P037/P038/P121/P131 四个属性与 N037),其中 A-36 退款 很可能本身也应拆成两张动作卡。
涉及:N053 退款单出处:R7§2.2·04§业务视角
登记原文N053 退款单: 商户退款（R 型流水带 MERCHANT_NAME）与多还/溢缴退款是否同一对象
○ 待收口
G-070缺口U04 账单与账期、常规还款

「额度变更历史」产品要做,但接口还没定义

缺什么:「额度变更历史」(top-up、解押、调额等记录的查询)产品已确认需要(2026-08-13),但页面路由和接口还没有定义。 为什么缺/线索:04§待确认、待确认清单 SA 第 6 条;待 SA 定义,并注意不要与账单历史、交易历史混为一谈。
出处:04§待确认·_待确认清单 SA 6
登记原文04§待确认 额度变更历史: '额度变更历史（top-up/解押/调额记录）'产品已确认需要（2026-08-13），路由/接口待 SA 定义；不得与账单历史/交易历史混淆
○ 待收口
G-071缺口U04 账单与账期、常规还款

还款/退款/出账等动作的观测指标待产品+数据(知识库结构性不收)

缺什么:受理还款、受理提前结清、退款、出账、标记逾期、计收罚息、结清核销这些动作,大多没有登记观测指标和回看窗口(做完之后看什么数据、看多久来判断效果);目前只有受理还款可以从还款状态推出。 为什么缺/线索:各出处均未提供这类语料。 [2026-09-08 IT 知识库核查] 知识库结构性不收观测指标与回看窗口——这是产品与数据侧的度量定义,不在代码资产里。需产品定指标口径、数据侧定回看窗口。涉及 A-06/A-07/A-36/A-40/A-41/A-42/A-43 七张动作卡的 feedback 轴。已确认无需再检索。 [2026-09-08 全库核验] 范围补两张:A-59 还款入账冲抵、A-61 呆账核销(人工) 的 feedback 同样为空,与本缺口是同一件事(账务类动作缺观测口径),一并请产品定指标、数据定回看窗口。本次核验未替产品编造指标——七张卡的 feedback 保持空白,由本缺口承载。
涉及:A-06 受理还款A-07 受理提前结清A-36 退款A-40 出账A-41 标记逾期A-42 计收罚息A-43 结清核销A-59 还款入账冲抵A-61 呆账核销(人工)出处:—
登记原文A-06/A-07/A-36/A-40~A-43 feedback: 多数动作的观测指标与回看窗口语料未给出（仅 A-06 可由 REPAY_STATUS 推）
○ 待收口
G-072缺口U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

预付门槛的读取与结算接口前端只是占位

缺什么:预付门槛任务的「读取预付状态」和「结算」两个接口在前端只是占位(未注册的开放问题 OQ-006),真实接口契约和预付金额的后端字段名(prepayAmount)待后端给出。 为什么缺/线索:05§D.4、R3§②。
涉及:N052 预付门槛任务A-62 核销预付门槛出处:05§D.4·R3§②
登记原文N052 / A-62: 预付状态读取与结算两接口在前端为占位(OQ-006 未注册),真实契约与 prepayAmount 后端字段名待后端
○ 待收口
G-073缺口U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

预付门槛开关没进后台开关清单

缺什么:重组预付门槛开关(restructurePrepaySwitch)没有收录进后台开关清单,它在哪被读取、默认值是什么都缺。 为什么缺/线索:R6§一 的开关清单里没有它,只在 05 篇的修订记录 #4 里出现过。
涉及:P062 后台开关组 子项 restructurePrepaySwitch出处:05§预付门槛判定来源同步换轨·R6§一
登记原文P062.restructurePrepaySwitch: R6 开关清单未收录该开关(仅见 05 revision #4),消费点与默认值缺
○ 待收口
G-074缺口U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

展期资格(ZQ01)是按什么条件圈的人

缺什么:展期资格 ZQ01 的圈选条件和策略在风控侧,知识库里是空白;目前只知道是定期筛选,再由人工通过 Workbench 上传。 为什么缺/线索:06§口径补充、R9§一。
涉及:F-65 ZQ01 展期资格圈选出处:06§口径补充·R9§一
登记原文F-65 ZQ01 圈选: 筛选条件/策略在风控侧留白;仅知定期筛+人工 Workbench 上传
○ 待收口
G-075缺口U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

转分期的现网费率是多少

缺什么:转分期的现网费率(日利率 DAY_INT_RATE_INSTALLMENT、手续费率 ADMIN_FEE_RATE)不掌握,它们放在 ICPS 生产参数表里,代码仓和 IT KB 都不持有。 为什么缺/线索:06§待确认、待确认清单 #1;需向后端取。
涉及:P145 转分期费用组出处:06§待确认·_待确认清单#1
登记原文P145 转分期费率: 现网 DAY_INT_RATE_INSTALLMENT/ADMIN_FEE_RATE 值(ICPS 生产参数表),代码仓与 IT KB 均不持有
○ 待收口
G-076缺口U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

逾期重组/协商方案的减免比例现网值

缺什么:逾期重组方案与协商还款方案中,本金、利息、罚息的减免比例现网实际值没有登记。 为什么缺/线索:R4§6;减免比例由风险侧上传,前端不持有。
涉及:P140 协商方案要素组P141 逾期重组方案要素组出处:R4§6
登记原文P140 / P141 减免比例: 逾期重组与协商方案的本金/利息罚息减免比例现网值(风险上传,前端不持有)
○ 待收口
G-077缺口U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

协商方案确认后怎么放款/换据,后端链路看不见

缺什么:协商还款方案下挂的状态机在后端没有闭合;客户确认方案之后的放款或换据链路,从 SDK 侧看不到。 为什么缺/线索:R10§6、05§D.5。
涉及:N051 协商还款方案A-12 受理协商方案确认出处:R10§6·05§D.5
登记原文N051 协商还款方案: 方案下挂状态机后端未闭合;A-12 确认后放款/换据链路 SDK 不可见
○ 待收口
G-078缺口U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

月最低还款通道后端是否也检查灵活码首位

缺什么:借新还旧受理闸门②要求灵活码首位为 1,但月最低还款(MINI_REPAY)通道的后端闸门是否也同样检查首位,没有写明(前端读的是第 3 位)。 为什么缺/线索:05§E.4。
涉及:L273 规则:借新还旧闸门②灵活码首位P002 灵活码出处:05§E.4
登记原文L273: MINI_REPAY 通道后端闸门是否同样查 FlexCode 首位(前端读第 3 位)未写明
○ 待收口
G-079缺口U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

「逐借据期数资格」后端用哪个字段判

缺什么:借新还旧闸门④「纳入的借据须满足期数条件」,后端具体用哪个字段判定没有登记;把它对应到灵活码第 20-23 位只是推断。 为什么缺/线索:05§E.4。
涉及:L275 规则:借新还旧闸门④逐借据期数资格P002 灵活码出处:05§E.4
登记原文L275: 『逐借据期数资格』后端具体判定字段;与 Flex 20-23 位的对应为推断
○ 待收口
G-080缺口U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

重组名单和方案通过什么工具上传

缺什么:逾期重组方案、预付名单、协商方案的上传工具和工单流程(是否走 Workbench 的 Universal List)没有写明。 为什么缺/线索:05§逾期重组(0716)、R9。
涉及:A-48 上传重组名单与方案出处:05§逾期重组(0716)·R9
登记原文A-48 上传渠道: 逾期重组方案/预付名单/协商方案的上传工具与工单流程(是否走 Workbench Universal List)未写明
○ 待收口
G-081缺口U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

试算业务场景码:权威源与四值已确认,普通取现字面量未给

缺什么:试算业务场景码(BIZ_SCENE)的完整取值集不清楚——除了前端出现过的,后端是否还有其他场景值,需后端给;它和交易码是否应归并,待审核。 为什么缺/线索:R3§待确认。 [2026-09-08 IT 知识库核查] 权威源查到:INBS 的 TM_TRANS_INFO 表,登记的四个取值经代码确认成立——这回答了「有没有前端没见过的值」的一半:全集以该表为准。剩余:普通取现场景对应的场景值字面量知识库未给出,需后端补一个值。两条缺口(G-081 与 G-149)问的是同一件事,建议合并向后端提问。
涉及:P136 试算业务场景码(BIZ_SCENE)P039 交易码出处:R3§待确认
登记原文P136 BIZ_SCENE: 全集是否还有前端未出现的场景值,需后端;与 P039 的归并关系待审核
○ 待收口
G-082缺口U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

转分期一次能不能对多笔借据

缺什么:转分期一次能否作用于多笔借据没有定论——接口参数是数组(loanReorgList),但用户旅程只描述单笔。 为什么缺/线索:06§D。
涉及:R017 作用于(改期)N022 转分期(展期)申请出处:06§D
登记原文R017: 转分期一次是否可对多笔借据(loanReorgList 为数组,旅程为单笔)
○ 待收口
G-083缺口U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

展期的最长期数、最低本金现网值

缺什么:展期后端硬门槛「新期数上限 12 期」「最低剩余本金 Rp500,000」是 UAT 参数,现网实际值待后端。 为什么缺/线索:06§后端事实增补。
涉及:L281 规则:展期后端硬门槛(期数/本金)出处:06§后端事实增补
登记原文L281/12: MAX_TERM=12 / MIN_BAL_PRIN=500000 为 UAT 参数,现网值待后端
○ 待收口
G-084缺口U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

展期入口的「白名单用户」是不是就是 ZQ01

缺什么:展期入口规则里的「白名单用户」是否就等于风险码里含 ZQ01 的用户,只是推断,源 PRD《1230》没有明写。 为什么缺/线索:05§展期入口。
涉及:L097 规则:还款模块展期入口展示条件P004 风险码出处:05§展期入口
登记原文L097 白名单: 『白名单用户』是否即 riskCode∋ZQ01(推断),PRD《1230》未明写
○ 待收口
G-085缺口U06 质押与额度成长(LimitUp 专属)

额度成长任务(Mission)后端在哪、规则值是多少

缺什么:额度成长任务的后端实现系统没有指认(IT KB 零命中,不要绑到 igame-app);任务达成条件、奖励额度、Top-up 倍数的现网值,以及任务状态由谁写入,都缺。 为什么缺/线索:08§待确认/风险、R10§4 08。
涉及:N059 额度成长任务N035 任务完成P165 任务状态出处:08§待确认/风险·R10§4 08
登记原文N059/N035/P165: Mission 后端实现系统未指认(IT KB 0 命中,勿绑 igame-app);任务达成条件/奖励额度/Top-up 倍数现网值;任务状态写入方
○ 待收口
G-086缺口U06 质押与额度成长(LimitUp 专属)

提额记录的标识字段与类型全集

缺什么:提额记录的唯一标识字段名与落表没有登记;提额记录类型的取值全集也不完整(现有取值是前端常量加 PRD 拼合出来的)。 为什么缺/线索:07§实时提升杠杆率、R3§⑥。
涉及:N057 提额记录P055 提额记录类型出处:07§实时提升杠杆率·R3§⑥
登记原文N057: 提额记录身份标识字段名与表;类型取值全集(P055 由前端常量+PRD 拼合)
○ 待收口
G-087缺口U06 质押与额度成长(LimitUp 专属)

调额补偿记录由哪个动作产生、能否撤销

缺什么:调额补偿记录是在会员购买链路落表时产生,还是在调额失败分支才产生,以及表名,都没有登记;人工补偿动作能否撤销也缺。 为什么缺/线索:07§实时提升杠杆率、10§。
涉及:N058 调额补偿记录A-45 会员调额人工补偿出处:07§实时提升杠杆率·10§
登记原文N058: 补偿记录产出动作(会员购买链路落表 vs 调额失败分支)与表名;A-45 可逆性
○ 待收口
G-088缺口U06 质押与额度成长(LimitUp 专属)

重新授信成功后新额度走哪个动作落地

缺什么:重新授信(reapply)成功后,新额度是通过「授信裁决落地」还是「执行调额」写进账户,没有证实。 为什么缺/线索:07§重新风险授信流程。
涉及:P164 reapply 引擎核定额度A-13 受理重新授信申请A-22 授信裁决落地A-31 执行调额出处:07§重新风险授信流程
登记原文P164/A-13: reapply 成功后新额度落地走哪个动作(A-22 授信裁决落地 vs A-31 调额)未证实
○ 待收口
G-089缺口U06 质押与额度成长(LimitUp 专属)

风险标签「XXXX」的具体值待补

缺什么:规则里写的 Risk Flag=XXXX 具体是什么值,还没有填上。 为什么缺/线索:R1§四;待 PM 补值。
涉及:L318 规则:特定风险标签下的处理P004 风险码出处:R1§四
登记原文L318: Risk Flag=XXXX 具体值待 PM 补
○ 待收口
G-090缺口U06 质押与额度成长(LimitUp 专属)

提额入口渠道 04~08 是什么

缺什么:提额入口渠道(EnterLimitChannel)的取值 04~08 没有见到含义。 为什么缺/线索:R3§⑦只见到部分取值。
涉及:P056 提额入口渠道出处:R3§⑦
登记原文P056: EnterLimitChannel 04~08 取值未见
○ 待收口
G-091缺口U06 质押与额度成长(LimitUp 专属)

质押本金优先字段还没上线

缺什么:风控团队拟提供的「质押本金优先」字段(pledgeBalanceAmount)尚未实现,上线计划未定。 为什么缺/线索:R3§③。
涉及:P017 质押杠杆信息组出处:R3§③
登记原文P017: pledgeBalanceAmount(risk team 拟提供的质押本金优先字段)未实现,上线计划未定
○ 待收口
G-092缺口U06 质押与额度成长(LimitUp 专属)

质押成功邮件由谁发

缺什么:质押锁定成功后给客户的邮件通知,发送方没有登记——前端没有发,待后端/营销确认。 为什么缺/线索:R7§1.5。
涉及:L308 规则:质押成功邮件通知出处:R7§1.5
登记原文L308: 质押成功邮件发送方(前端未发,待后端/营销)
○ 待收口
G-093缺口U06 质押与额度成长(LimitUp 专属)

LimitUp 名单怎么维护、范围是什么

缺什么:LimitUp 相关名单的维护流程、所在系统、能否撤销都缺;SHOPEE/BPJS 白名单与 Beta/Gamma 放量名单的具体范围需要找风控。 为什么缺/线索:07§后端事实增补。
涉及:A-66 维护 LimitUp 相关名单出处:07§后端事实增补
登记原文A-66: 名单维护流程/系统/可逆性;SHOPEE/BPJS 白名单与 Beta/Gamma 放量名单具体范围需找风控
○ 待收口
G-094缺口U06 质押与额度成长(LimitUp 专属)

「Prime 会员」指钱包档位还是 LimitUp 会员

缺什么:「定存清单只对 Prime(Premium)会员可取」里的 Prime,是指钱包账户等级里的 Prime,还是 LimitUp 的 Premium 会员,没有说清。 为什么缺/线索:09§后端事实增补。
涉及:L301 规则:定存清单仅 Prime 会员可取出处:09§后端事实增补
登记原文L301: 'Prime(Premium)会员'含义(钱包档位 Prime vs LimitUp Premium)
○ 待收口
G-095缺口U06 质押与额度成长(LimitUp 专属)

可用额度到底谁是唯一写入方

缺什么:可用额度的写入方没有定下来——支用、还款等多个动作都会改它,尚未确定单一写入方。 为什么缺/线索:07§额度构成;归 U03 核。
涉及:P147 可用额度出处:07§额度构成
登记原文P147: 可用额度单一写入方(支用/还款多写入)——本单元未定,U03 核
○ 待收口
G-096缺口U06 质押与额度成长(LimitUp 专属)

存单本金由谁写入、存单靠什么字段标识

缺什么:存单本金的写入方没有建档(存款域的购买事件未登记);定存存单的唯一标识字段名也缺。 为什么缺/线索:09§核心能力。
涉及:P160 存单本金N006 定存存单出处:09§核心能力
登记原文P160/N006: 存单本金写入方(存款域购买事件未建档);存单身份字段名
○ 待收口
G-097缺口U06 质押与额度成长(LimitUp 专属)

定存流动性价格 ID 存在哪

缺什么:定存流动性价格 ID 的字段名和落表没有登记。 为什么缺/线索:09§价格权益与额占率定价。
涉及:P153 定存流动性价格 ID出处:09§价格权益与额占率定价
登记原文P153: 定存流动性价格 ID 字段名/落表
○ 待收口
G-098缺口U06 质押与额度成长(LimitUp 专属)

质押物代偿在什么情况下触发、归谁管

缺什么:质押物代偿(RMS 代偿)的触发前提——什么样的欠款或逾期状态会触发——以及归属哪个职能域,都没有登记。 为什么缺/线索:09§后端事实增补。
涉及:A-65 执行质押物代偿出处:09§后端事实增补
登记原文A-65: RMS 代偿触发前提(何种欠款/逾期态触发)、职能域归属
○ 待收口
G-099缺口U06 质押与额度成长(LimitUp 专属)

营销码第 5-7 位现网实际取值分布

缺什么:营销码第 5-7 位(定存质押比例)在现网的实际取值分布不掌握。 为什么缺/线索:09§待确认/风险;待以现网数据/营销配置核对。
涉及:P001 营销码出处:09§待确认/风险
登记原文P001 第5-7位: 现网取值分布(待以现网/营销配置核对)
○ 待收口
G-100缺口U06 质押与额度成长(LimitUp 专属)

Y001_R1 标签是什么意思、权益差在哪

缺什么:风险码里 Y001_R1 标签的业务含义,以及它与 Y001 的权益差异,没有登记。 为什么缺/线索:07§业务代码字段、R2§三。
涉及:P004 风险码出处:07§业务代码字段·R2§三
登记原文P004 Y001_R1: Y001_R1 标签的业务含义/权益差异
○ 待收口
G-101缺口U06 质押与额度成长(LimitUp 专属)

补充资料传错了能不能重传

缺什么:补充资料上传这一动作能否撤销、能否重传,没有登记。 为什么缺/线索:07§额度成长来源。
涉及:A-19 受理补充资料上传出处:07§额度成长来源
登记原文A-19: 补充资料上传可逆性(可否重传)
○ 待收口
G-102缺口U06 质押与额度成长(LimitUp 专属)

协议同意记录存在哪张表、有哪些字段

缺什么:协议同意记录的字段名与落表没有登记(推测是 t_protocol_consent)。 为什么缺/线索:09§T&C 协议、R10§4 01。
涉及:N033 协议同意P061 协议同意记录字段组出处:09§T&C 协议·R10§4 01
登记原文N033/P061: 协议同意记录字段名与表(t_protocol_consent 推测)
○ 待收口
G-103缺口U06 质押与额度成长(LimitUp 专属)

计费类规则改挂属性后没有门控,职能域归属待定

缺什么:质押新增额度公式、解押存单提前支取 0% 结算、任务奖励额度上限等计费类规则改挂到属性后,不再有门控(gate)承载;「账务/风控运营」这个职能域只是暂定名。 为什么缺/线索:handbook-ch5;待审核归并。
涉及:L112 规则:定存质押新增额度公式L117 规则:曾质押存单提前支取 0% 结算L134 规则:任务奖励额度上限不由营销码编码出处:handbook-ch5
登记原文gate 门类: L112/L117/L134 等计费类改挂属性后无 gate;'账务/风控运营'职能域为本单元暂定,待审核归并
○ 待收口
G-104缺口U07 会员与营销

会员状态除了「有效」还有哪些值

缺什么:会员态里的 status 除了 ACTIVE 之外的取值没有登记——过期、未激活分别怎么表示。 为什么缺/线索:10§两个独立信号。 [2026-09-22] P051 会员态组已拆:status → P269 会员状态,expireTime → P270 会员有效期截止日;本缺口挂 P269。
涉及:P269 会员状态出处:10§两个独立信号
登记原文P051.status: member.status 除 ACTIVE 外的取值(过期/未激活如何表示)
○ 待收口
G-105缺口U07 会员与营销

会员购买记录的四个状态是什么

缺什么:会员购买记录表(t_limit_up_member_record)四个状态的具体取值与含义没有登记。 为什么缺/线索:R10§4-10。
涉及:P176 会员购买记录字段组出处:R10§4-10
登记原文P176 记录状态: t_limit_up_member_record 四状态具体取值与含义
○ 待收口
G-106缺口U07 会员与营销

会员费能不能退、购买能不能撤销

缺什么:会员费是否可退、会员购买是否可撤销,没有见到口径。 为什么缺/线索:10§购买月会员流程。
涉及:A-16 受理会员购买出处:10§购买月会员流程
登记原文A-16 reversibility: 会员费是否可退/购买是否可撤销,未见口径
○ 待收口
G-107缺口U07 会员与营销

会员费除了钱包支付还有别的方式吗

缺什么:会员费「默认钱包支付」之外,是否还存在其他支付方式,没有登记。 为什么缺/线索:10§购买月会员流程。
涉及:A-16 受理会员购买出处:10§购买月会员流程
登记原文A-16 支付方式: '默认钱包支付'之外是否存在其他会员费支付方式
○ 待收口
G-108缺口U07 会员与营销

会员购买成功后有没有 push/邮件/WA 通知

缺什么:会员购买后前端只有 UI 弹窗,push、邮件、WhatsApp 通知由后端/营销承担,但渠道和文案没有见到。 为什么缺/线索:R7§1.5。
涉及:A-16 受理会员购买出处:R7§1.5
登记原文会员购买通知: 前端仅 UI 弹窗,push/邮件/WA 通知由后端/营销承担,渠道与文案未见
○ 待收口
G-109缺口U07 会员与营销

会员费流水:交易类型与商户名字段已定位,展示文案未见

缺什么:会员费在交易流水里显示的商户名(Pay to limit up premium)由后端哪一方决定、对应哪种交易类型,没有登记。 为什么缺/线索:R7§2.3。 [2026-09-08 IT 知识库核查] 查到:会员购买的 BIZ_TYPE=PurchaseMembership,商户名落 MERCHANT_NAME 列——缺口问的「商户名归属与交易类型」两项都有答案了。剩余:「Pay to limit up premium」这句客户可见文案在代码中零命中,属前端文案/i18n 层,需前端确认现网实际展示什么、产品确认口径。
涉及:N037 交易流水(记录)P037 交易类型出处:R7§2.3
登记原文N037 会员费流水: 商户名 Pay to limit up premium 的后端归属与交易类型映射
○ 待收口
G-110缺口U07 会员与营销

调额补偿表叫什么、人工补偿从哪操作

缺什么:调额补偿记录的表名、字段,以及人工补偿的操作入口和流程,都没有登记。 为什么缺/线索:R10§4-10;IT KB 里没有补偿扫描入口。
涉及:N058 调额补偿记录A-45 会员调额人工补偿出处:R10§4-10
登记原文N058 / A-45: 补偿表实体名、字段、人工补偿操作入口与流程(IT KB 无扫描入口)
○ 待收口
G-111缺口U07 会员与营销

SMP 立减券的品类码、规则主键和状态全集是什么

缺什么:N085 SMP 支付立减券规则配置与 P050 立减规则组中,券品类码(如 80010004)各代表什么、券规则的唯一主键是哪个字段、SMP 券状态的全部取值,都没有登记。 为什么缺/线索:出处 11§待确认;语料里只见零星码值,完整字典未出现。
涉及:N085 SMP 支付立减券规则配置P050 立减规则组出处:11§待确认
登记原文N085 / P050: SMP 券品类码(80010004 等)含义、券规则主键、SMP 券状态全值
○ 待收口
G-112缺口U07 会员与营销

多次核销券的「剩余次数」角标由谁展示

缺什么:配置了多次核销的券,卡券左上角要显示当前剩余可用次数,但这个角标由哪一端渲染没有登记——PayLater SDK 前端仓库里没有渲染它。 为什么缺/线索:出处 11§支付立减券规则(源 PRD 有此要求,规则 L342);承载方待确认。
涉及:L342 规则:多次核销券剩余次数角标出处:11§支付立减券规则
登记原文L342: 多次核销'剩余次数角标'承载方(本仓未渲染)
○ 待收口
G-113缺口U07 会员与营销

期限券「多选多张+底部确认」交互落在哪一端

缺什么:N029 优惠券使用选择中,源 PRD 要求的按 PayLater 期限配置的券可「一次多选多张、底部确认」交互,SDK 前端仓库没有实现,不知道由哪个端承载。 为什么缺/线索:出处 11§按 PL 期限配置;归属待确认。
涉及:N029 优惠券使用选择出处:11§按 PL 期限配置
登记原文N029 期限券多选: 源 PRD'多选多张+底部确认'交互本仓未落地,归属待确认
○ 待收口
G-114缺口U07 会员与营销

优惠券权威账本归属:知识库自陈未闭合

缺什么:N048 营销权益券与 N049 SMP 支付立减券的权威账本(券的发放/使用/状态最终以谁为准)归哪个系统所有,没有定论。 为什么缺/线索:出处 R10§4-11、11§后端事实增补;已知券核销经营销服务(NBS 200002),但其下游链路未闭合,IT KB 也未裁定。 [2026-09-08 IT 知识库核查] 知识库对此明确自陈未闭合:EQUITY(N048)与 SMP 立减券(N049)分属不同系统,谁是权威账本没有代码级结论。这不是检索不足,是该结论本身尚未在技术侧形成。需产品定归口、后端确认对账关系。
涉及:N048 营销权益券(EQUITY)N049 SMP 支付立减券出处:R10§4-11·11§后端事实增补
登记原文N048/N049 权威账本: 券的权威账本 owner(NBS 200002 下游未闭合)IT KB 未裁定
○ 待收口
G-115缺口U07 会员与营销

直减预算账本的字段、额度和归属系统未知

缺什么:N086 直减预算账本(promo_budget)有哪些字段、预算额度多少、归属哪个系统,都没有登记。 为什么缺/线索:出处 11§后端事实增补;仅知这个账本存在。
涉及:N086 直减预算账本出处:11§后端事实增补
登记原文N086: promo_budget 账本字段、额度、归属系统
○ 待收口
G-116缺口U07 会员与营销

可配置化留资页是否还采集姓名

缺什么:留资校验规则从 0508 可配置化版起移除了 OTP 发送与验证,但该版本是否仍采集用户姓名、姓名如何校验,没有写明。 为什么缺/线索:出处 11§营销落地页可配置化(规则 L354);源 PRD 未提及。
涉及:L354 规则:留资校验(可配置化版)出处:11§营销落地页可配置化
登记原文L354: 0508 版留资是否仍采集姓名及其校验
○ 待收口
G-117缺口U07 会员与营销

留资 H5 的后端系统、落库表和记录标识未知

缺什么:A-18 受理留资提交后,留资数据由哪个后端系统接收、落在哪张表、N030 留资提交记录的唯一标识字段是什么,都没有登记。 为什么缺/线索:出处 11§留资类营销落地页;留资 H5 部署在 mvp.allobank.com,不在 SDK 代码仓内,无法从代码查实。
涉及:A-18 受理留资提交N030 留资提交出处:11§留资类营销落地页
登记原文A-18 / N030: 留资 H5 后端系统与落库表(mvp.allobank.com 仓外)、留资记录身份字段
○ 待收口
G-118缺口U07 会员与营销

MGM 推荐关系怎么落库、推荐提额怎么生效

缺什么:R044 推荐关系落在哪张表(推测在 MGM 系统 imgm/imgm-h5)、A-20 受理推荐码提交后 MGM 推荐提额(100K/200K)由哪个动作生效、任务(Mission)的后端系统是哪个,都没有登记。 为什么缺/线索:出处 R10§4-08、10§会员权益;IT KB 未闭合。
涉及:R044 推荐A-20 受理推荐码提交出处:R10§4-08·10§会员权益
登记原文R044 / A-20: MGM 推荐关系落库(imgm/imgm-h5)、MGM 提额 100K/200K 的生效动作、Mission 后端系统
○ 待收口
G-119缺口U07 会员与营销

营销码前两位 01→00 的批量变更规则

缺什么:用户的 P001 营销码可随时变更、支持把前两位从 01(需购买会员)批量改成 00,但批量变更的规则(谁发起、依据什么、多久一次)没有登记。 为什么缺/线索:出处 10§客群识别与会员资格(规则 L339);操作在 Emma/Cindy 侧,需向其确认。
涉及:P001 营销码L339 规则:营销码前两位批量变更出处:10§客群识别与会员资格
登记原文L339: market code 前两位 01→00 批量变更规则(Emma/Cindy 侧)
○ 待收口
G-120缺口U07 会员与营销

会员权益(返现/立减)怎么生效、由谁承载

缺什么:P052 会员套餐/权益组中,CT BU 支付 5% 返现、Indomaret 立减这两项权益的生效机制和承载系统没有登记;Allo Pay+ 与 Allo Prime 两档在营销权益上的差异也未写明。 为什么缺/线索:出处 10§会员权益、10§待确认;权益差异待 PM 确认。
涉及:P052 会员套餐/权益组出处:10§会员权益·10§待确认
登记原文P052 权益内容: CT BU 支付 5% 返现、Indomaret 立减的生效机制与承载系统;Allo Pay+ 与 Allo Prime 营销权益差异待 PM
○ 待收口
G-121缺口U07 会员与营销

运营位键名全清单和 SMP 活动 id 体系未知

缺什么:P060 运营位组各活动的运营位键(POSITION_KEY)全清单、P058 活动配置组的 SMP 活动 id 编号体系,没有登记。 为什么缺/线索:出处 11§待确认;前端只见部分键名。
涉及:P060 运营位组P058 活动配置组(increase limit)出处:11§待确认
登记原文P060 / P058: 各活动 POSITION_KEY 全清单、SMP 活动 id 体系
○ 待收口
G-122缺口U07 会员与营销

会员套餐价格变动时历史报价如何留痕

缺什么:N056 会员套餐配置的现网四档价格随后台配置可变,但历史报价如何留快照(购买当时的价格记在哪、怎么追溯)这一数据机制没有登记。 为什么缺/线索:出处 10§现网套餐价格;仅知价格可配置。
涉及:N056 会员套餐配置出处:10§现网套餐价格
登记原文N056: 现网四档价格随配置可变,历史报价须留快照(数据机制)
○ 待收口
G-123缺口U07 会员与营销

会员卡可见门控里的「人工审核」指哪一种审核

缺什么:会员卡可见性规则写「特殊用户人工审核通过后」可见,但这里的「人工审核」是指开户阶段的人工审核,还是会员资格的审核,没有说明。 为什么缺/线索:出处 10§会员卡可见性门控;原文表述模糊。
出处:10§会员卡可见性门控
登记原文10§'特殊用户人工审核通过后': '人工审核'指开户人工审核还是会员资格审核,未明
○ 待收口
G-124缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

内部埋点事件没有唯一标识,完整事件字典未整理

缺什么:N041 内部埋点事件记录没有登记唯一标识字段;完整事件字典(label/category/action 全集)也未逐事件枚举。 为什么缺/线索:出处 13-埋点与监控§待确认、R8-埋点事件目录§前言、R10§6;事件字典由 BI 从代码导出维护,IT KB 中没有 PayLater 专属字典。
涉及:N041 内部埋点事件记录出处:功能说明/13-埋点与监控.md§待确认·参考/R8-埋点事件目录.md§前言·参考/R10-后端系统与服务地图.md§6
登记原文N041: 身份标识未载；完整事件字典（label/category/action 全集）未逐事件枚举，由 BI 从代码导出维护，IT KB 无 PayLater 专属字典
○ 待收口
G-125缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

对外上报事件名 38 个只登记了约 33 个

缺什么:P068 对外上报事件名共 38 个,知识库只列出 R7/R8 中点名的约 33 个,其余几个未登记。 为什么缺/线索:出处 R7-通知触达与交易流水§1.1;事件名由后端下发,前端语料中未见全集。
涉及:P068 对外上报事件名出处:参考/R7-通知触达与交易流水.md§1.1
登记原文P068: 38 个 eventName 仅列出 R7/R8 点名的约 33 个，其余未载
○ 待收口
G-126缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

「客户回收」是什么业务动作、模板填什么

缺什么:A-55 执行工单中的「客户回收」这一类,其业务含义没有定义;P066 Workbench 上传模板字段组中客户回收模板(CUSTOMER_RECOVERY)的字段也未说明。 为什么缺/线索:出处 R9-NY-Risk-Workbench 操作手册§二;模板字段以系统模板为准。
涉及:P066 Workbench 上传模板字段组A-55 执行工单出处:参考/R9-NY-Risk-Workbench操作手册.md§二
登记原文P066 / A-55 客户回收: CUSTOMER_RECOVERY 模板字段未说明（以系统模板为准）；「客户回收」业务语义未定义
○ 待收口
G-127缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

Workbench 工单上传后能否撤销、被拒后走向何处

缺什么:A-53 上传 Universal List 文件后能否撤销、怎么撤销;A-54 审核工单被拒绝后的路径和 N072 工单拒绝态的取值;工单号字段名——都没有登记。 为什么缺/线索:出处 R9-NY-Risk-Workbench 操作手册;手册只写了正常的上传→审核→执行路径。
涉及:A-53 上传 Universal List 文件A-54 审核工单N072 工单出处:参考/R9-NY-Risk-Workbench操作手册.md
登记原文A-53 / A-54 / N072: 上传后撤销方式、审核拒绝路径与工单拒绝态取值、工单号字段名均未载
○ 待收口
G-128缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

开通问卷的奖励档算法和选项枚举未知

缺什么:F-43 开通问卷奖励档算法只有名字没有内容,P193 开通问卷奖励档的档位枚举、问卷各题的选项枚举都没有登记。 为什么缺/线索:出处 12-支撑流程§待确认;以 PRD/风控为准。
涉及:F-43 开通问卷奖励档算法P193 开通问卷奖励档出处:功能说明/12-支撑流程(账户安全·引导·结果页).md§待确认
登记原文F-43 / P193: 开通问卷奖励档算法与档位枚举（以 PRD/风控为准）；问卷选项枚举未载
○ 待收口
G-129缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

HomeV2 引导标志的受众是否已放宽到全体 Y001

缺什么:后端下发的 HomeV2 欢迎/导览标志(hv2WelcomeShownFlag/hv2TourShownFlag)的受众范围,是否已放宽为全体 Y001 用户,没有确认。 为什么缺/线索:出处 _待确认清单-风控后端SA-20260813(#4);待后端确认。
涉及:L177 规则:HomeV2 引导标志下发出处:_待确认清单-风控后端SA-20260813.md
登记原文L177: hv2 flag 受众是否已放宽为全体 Y001 待后端确认（待确认清单#4）
○ 待收口
G-130缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

LimitUp 交互引导标志由谁下发、按什么规则

缺什么:P192 LimitUp 交互引导标志(limitUpInteractiveGuidanceFlag)由哪个后端系统写入、按什么规则下发,没有登记。 为什么缺/线索:出处 12-支撑流程§B;前端只读不写。
涉及:P192 LimitUp 交互引导标志出处:功能说明/12-支撑流程(账户安全·引导·结果页).md§B
登记原文P192: limitUpInteractiveGuidanceFlag 的写入方/后端下发规则未载
○ 待收口
G-131缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

后台开关里 settingImage 字段是什么

缺什么:P062 后台开关组中,配置拉取失败时会被重置的 settingImage 字段的业务含义没有登记。 为什么缺/线索:出处 R6-后台开关与配置项§附;仅在重置逻辑里见到该字段。
涉及:P062 后台开关组出处:参考/R6-后台开关与配置项.md§附
登记原文P062 settingImage: 拉取失败时被重置的 settingImage 字段含义未载
○ 待收口
G-132缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

PIN 校验场景键:常量位置已定位(VERIFY_PIN_SCENE_MAP),取值待前端

缺什么:A-49 PIN 校验的参数中,场景映射表(VERIFY_PIN_SCENE_MAP)的全部场景键名没有逐一登记。 为什么缺/线索:出处 12-支撑流程§A;只登记了主要场景。 [2026-09-08 IT 知识库核查] 常量已定位:VERIFY_PIN_SCENE_MAP,位于 ifes-lph5 的 constants。取值清单本身是前端常量,知识库结构性不收——需前端直接导出该常量的键值对。相比原缺口「场景键名未逐一登记」,现在至少知道该去哪里取。
涉及:A-49 PIN 校验出处:功能说明/12-支撑流程(账户安全·引导·结果页).md§A
登记原文A-49 params: VERIFY_PIN_SCENE_MAP 全部场景键名未逐一载
○ 待收口
G-133缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

PIN 受理结果码的成功码和其他结果码未知

缺什么:P182 PIN 受理结果码(MED 码)中,成功码是什么、以及 B099/B271/B272 之外还有哪些结果码,没有登记。 为什么缺/线索:出处 12-支撑流程§后端事实增补;仅见这三个错误码。
涉及:P182 PIN 受理结果码出处:功能说明/12-支撑流程(账户安全·引导·结果页).md§后端事实增补
登记原文P182: PIN 链路成功码及 B099/B271/B272 以外的结果码未载
○ 待收口
G-134缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

协议同意记录的表结构和场景枚举未整理

缺什么:N033 协议同意记录的落表(t_protocol_consent)结构和字段没有进知识库;用户在哪些场景下需要同意协议的场景枚举也未整理。 为什么缺/线索:出处 R10§4.01;P061 协议同意记录字段组归 U11 处理。
涉及:N033 协议同意P061 协议同意记录字段组出处:参考/R10-后端系统与服务地图.md§4.01
登记原文N033: t_protocol_consent 表结构/字段未入 KB；协议同意场景枚举未整理（P061 归 U11）
○ 待收口
G-135缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

App List 采集因 emoji 应用名每天静默丢 2%

缺什么:N039 App List 采集记录存在数据质量缺口——应用名含 emoji 时会导致整批记录静默丢失,约占每天 2%;App 侧的采集表也没有登记。 为什么缺/线索:出处 13-埋点与监控§后端事实增补。
涉及:N039 App List 采集记录出处:功能说明/13-埋点与监控.md§后端事实增补
登记原文N039: emoji 应用名致 ~2%/天整批静默丢失——数据质量缺口；App 侧采集表未载
○ 待收口
G-136缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

观测类记录算客户事件还是 SDK 上报动作的产物

缺什么:N038 GPS 定位记录、N039 App List 采集记录、N040 CNC 风控上报事件、N041 内部埋点事件记录、N042 对外归因上报事件这五类观测记录,建模上应视为客户事件(不挂产出动作),还是视为 SDK 隐式动作 A-50 上报事件的产物(现按后者登记),没有定论。 为什么缺/线索:出处 handbook-ch5 §5.5#13 与现登记 A-50 口径不同;需审核定夺。
涉及:N038 GPS 定位记录N039 App List 采集记录N040 CNC 风控上报事件N041 内部埋点事件记录N042 对外归因上报事件A-50 上报事件出处:handbook-ch5 §5.5#13 vs 现登记 A-50
登记原文N038~N042 product_of: 观测记录是否按 5.5#13 视为客户事件（去 product_of）还是 SDK 隐式动作产物（现填 A-50），需审核定夺
○ 待收口
G-137缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

上报配置和灰度阈值要不要拆成独立对象

缺什么:N070 功能开关配置(后台配置包)中,开户事件上报配置(amsEventReportConfig OPEN_ACCT)、App List 采集灰度(APP_LIST_COLLECTION)、后台配置中心阈值,是否应各自拆成独立对象,没有定论。 为什么缺/线索:出处 R6-后台开关与配置项、R7§1.1;交审核决定。
涉及:N070 功能开关配置(后台配置包)出处:参考/R6-后台开关与配置项.md·参考/R7-通知触达与交易流水.md§1.1
登记原文N070: 是否将 amsEventReportConfig(OPEN_ACCT)/APP_LIST_COLLECTION 灰度/后台配置中心阈值拆为独立对象，交审核
○ 待收口
G-138缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

结果页族的文案和通用状态机未入库

缺什么:通用结果页族(COMMON_RESULT 等)各页文案没有登记;「处理中→成功→失败/待进一步操作」这一通用状态机也没有建为构件。 为什么缺/线索:出处 12-支撑流程§C、§待确认;文案以 PRD 为准,状态机被视为 UI 而非业务对象。
出处:功能说明/12-支撑流程(账户安全·引导·结果页).md§C·§待确认
登记原文结果页族（COMMON_RESULT 等）: 各结果页文案以 PRD 为准；通用状态机（处理中→成功→失败/待进一步操作）未建为构件（视为 UI，非业务对象）
○ 待收口
G-139缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

质押成功邮件和会员购买通知到底有没有发

缺什么:质押成功后的邮件通知、会员购买后的通知,前端都没有发送动作,是否由后端/营销触达、通过什么渠道,没有登记。 为什么缺/线索:出处 R7-通知触达与交易流水§1.5;待后端/营销确认,归 U09/U10。
出处:参考/R7-通知触达与交易流水.md§1.5
登记原文R7 §1.5 质押成功邮件 / 会员购买通知: 前端未发，待后端/营销确认是否触达（归 U09/U10）
○ 待收口
G-140缺口U09 参考层字典(横切属性与枚举正本)

客群分段码 3-40 位含义、是否真的下发未确认

缺什么:P003 客群分段码第 3-40 位逐位含义没有登记;这个码是否真的存在于接口里也不确定;写入方登记为 A-22 授信裁决落地,但只是根据 R1 描述推断。 为什么缺/线索:出处 R1§三、R3 待确认清单;前端全部代码里都找不到读取该字段(segCode/SEG_CODE)的地方;位含义待 PM 补充,是否存在待后端确认。
涉及:P003 客群分段码A-22 授信裁决落地出处:R1§三·R3 待确认清单
登记原文P003 segCode: 第 3-40 位逐位含义待 PM 补充;前端代码全仓未见 segCode/SEG_CODE 读取,是否真实存在于接口待后端确认;写入方 A-22 为 R1 描述推断
○ 待收口
G-141缺口U09 参考层字典(横切属性与枚举正本)

风险码字典、Risk Flag 值、Y001_R1 规则未知

缺什么:P004 风险码的取值全字典与对应的策略包版本;规则中「Risk Flag=XXXX」的实际值;Y001_R1 标签是否有独立的业务规则——都没有登记。 为什么缺/线索:出处 R1§四、R10§6;IT KB 明确「查不到清单」,Risk Flag 值待 PM 补。
涉及:P004 风险码(风险标签集)出处:R1§四·R10§6
登记原文P004 riskCode: 取值全字典与策略包版本(IT KB『查不到清单』);Risk Flag=XXXX 的实际值;Y001_R1 是否有独立业务规则
○ 待收口
G-142缺口U09 参考层字典(横切属性与枚举正本)

锁定码 U/N 含义、全集、优先级和加速终止触发码

缺什么:P005 冻结/拦截码(锁定码)在用的 11 个码中 U、N(大写)含义未给出;39 码全集及各自语义未登记;锁定码与账单状态等账户状态字段(acctStmtStatus)谁优先没有说明;借据状态置为 T「锁定码加速终止」由哪些码触发也不清楚。 为什么缺/线索:出处 R1§五、R5§⑧;优先级关系 R1 标注待 PM/后端。
涉及:P005 冻结/拦截码(锁定码)出处:R1§五·R5§⑧
登记原文P005 blockCode: 在用 11 码中 U、N(大写)语义未给出;39 码全集与语义;与 acctStmtStatus 等账户状态字段的优先级关系(R1 标待 PM/后端);LOAN_STATUS=T『锁定码加速终止』由哪些码触发
○ 待收口
G-143缺口U09 参考层字典(横切属性与枚举正本)

营销码 8-10 位杠杆额度上限的编码单位待确认

缺什么:P001 营销码第 8-10 位表示杠杆额度上限,其编码单位未确认(按 003=300K、010=1 mio 推断单位为 100K);第 5-7 位质押比例的现网取值分布也未核对。 为什么缺/线索:出处 R1§一、R4§6;单位待 PM 确认,取值分布待以现网/营销配置核对。
涉及:P001 营销码出处:R1§一·R4§6
登记原文P001 marketCode 8-10 位: 杠杆额度 cap 编码单位(003=300K/010=1 mio 推断单位 100K)待 PM 确认;5-7 位现网取值分布待核
○ 待收口
G-144缺口U09 参考层字典(横切属性与枚举正本)

综合账户态 NU/HN/HF/HO 四个值是什么意思

缺什么:P009 综合账户态的 NU/HN/HF/HO 四个取值的业务含义,任何一篇都没有给出。 为什么缺/线索:出处 R3§①、R5§③;现有标注疑为推断。
涉及:P009 综合账户态(派生)出处:R3§①·R5§③
登记原文P009 stmtState: NU/HN/HF/HO 四值语义未在任何篇给出(疑标注为推断)
○ 待收口
G-145缺口U09 参考层字典(横切属性与枚举正本)

开通状态数字变体与 T 码的映射、1006/1008 含义

缺什么:P006 开通/KYC 状态在表单层的数字变体(currentPlaylaterStatus 1017/1022)与 T017/T022 的对应关系只是推断;授信结果码 1006/1008 的语义未知。 为什么缺/线索:出处 R5§①、_待确认清单(问后端第 2 条)。
涉及:P006 开通/KYC 状态出处:R5§①·_待确认清单
登记原文P006 OPEN_STATUS: 表单层数字变体 currentPlaylaterStatus 1017/1022 与 T017/T022 的映射为推断;授信结果码 1006/1008 语义(问后端第 2 条)
○ 待收口
G-146缺口U09 参考层字典(横切属性与枚举正本)

前一账期账单状态 U/N/F 语义:知识库明写未确认

缺什么:P198 前一账期账单状态(CURR_STMT_STATUS)的后端字典未确认;出账批量的步骤和计息规则也没有闭合。 为什么缺/线索:出处 R5§⑧、R10§4(04)/§6;IT KB 未闭合。 [2026-09-08 IT 知识库核查] 账单状态机主线成文可用;但 U/N/F 三个取值的精确语义,知识库明确写着「未确认」——这是技术侧自陈的空白,需后端查代码或问账务系统owner。出账批量规则见 G-059。
涉及:P198 前一账期账单状态出处:R5§⑧·R10§4(04)/§6
登记原文P198 currentState: CURR_STMT_STATUS 后端字典未确认;出账批量 step 与计息规则 IT KB 未闭合
○ 待收口
G-148缺口U09 参考层字典(横切属性与枚举正本)

交易流水:写入方链路已成文,子交易类型全集未见

缺什么:P037 交易类型、P038 交易状态、P203 子交易类型这些流水字段的写入动作没有建档(登记表里没有「记流水」动作,写入方未登记);子交易类型(SUB_TRANSACTION_TYPE)全集未知;交易金额的收支方向前端没有定义;会员费交易的商户名待后端确认。 为什么缺/线索:出处 R7-通知触达与交易流水§2.3/2.4;收支方向 R7 标待补。 [2026-09-08 IT 知识库核查] 写入方链路成文可用。三问中的「收支方向」已由 G-064 给出确定答案(客户层无方向字段,须由交易类型推导)。剩余:SUB_TRANSACTION_TYPE 在代码中零命中,P203 子交易类型 的全集未见,需后端确认该字段是否仍在用。
涉及:P037 交易类型P038 交易状态P203 子交易类型出处:R7§2.3/2.4
登记原文P037/P038/P203 流水字段: 流水记录写入动作未建档(登记表无『记流水』动作,writer=null);SUB_TRANSACTION_TYPE 全集;交易金额收支方向前端无定义(R7 待补);会员交易商户名待后端
○ 待收口
G-149缺口U09 参考层字典(横切属性与枚举正本)

业务场景码:权威源已定位,普通取现场景值字面量未给

缺什么:P204 业务场景码(BIZ_SCENE)前端只见到四个值(借新还旧 JXHJ、月最低还款 MINI_REPAY、在贷重组 MULTI_SETTLE、逾期重组 OVERDUE_RESTRUCTURE),后端全集未知。 为什么缺/线索:出处 R3 待确认清单;待后端给出。 [2026-09-08 IT 知识库核查] 权威源查到:INBS 的 TM_TRANS_INFO 表,登记的四个取值经代码确认成立——这回答了「有没有前端没见过的值」的一半:全集以该表为准。剩余:普通取现场景对应的场景值字面量知识库未给出,需后端补一个值。两条缺口(G-081 与 G-149)问的是同一件事,建议合并向后端提问。
涉及:P204 业务场景码出处:R3 待确认清单
登记原文P204 BIZ_SCENE: 前端仅见 JXHJ/MINI_REPAY/MULTI_SETTLE/OVERDUE_RESTRUCTURE,后端全集待给
○ 待收口
G-150缺口U09 参考层字典(横切属性与枚举正本)

产品码 9022 与 801002 是否同一产品的两套编号

缺什么:P205 产品码的写入方未明(产品配置动作没有建档);取现试算用的 9022(LOAN_CODE)与核心系统 ICPS 的现金贷产品码 801002(PRODUCT_CD)是否是同一产品的两套编号未确认;消费产品号未登记;低价取现页硬编码 9022、常规取现页动态取值,这两条路径在多产品号账户下会怎样表现也不清楚。 为什么缺/线索:出处 R3§⑥、R1§五、_待确认清单;多产品号双路径行为列为挂起技术项。
涉及:P205 产品码出处:R3§⑥·R1§五·_待确认清单
登记原文P205 LOAN_CODE/PRODUCT_CD: 写入方未明(产品配置动作未建档,null);9022(tryLoan LOAN_CODE)与 801002(ICPS PRODUCT_CD 现金贷)是否同一产品两套编号;消费产品号;低价页硬编码 9022 与常规页动态取值双路径在多产品号账户下的行为(挂起技术项)
○ 待收口
G-151缺口U09 参考层字典(横切属性与枚举正本)

还款方式后端字段名到底叫什么(TYPE/METHOD)

缺什么:P207 还款方式的后端字段名不确定——规则 L067 写作 REPAY_TYPE=VA,但这个名字又与前端的还款类型常量(REPAYMENT_TYPES:IOURepay/BillRepay)重名,到底是 REPAY_TYPE 还是 REPAY_METHOD 待核。 为什么缺/线索:出处 R3§⑥、规则登记 L067;两处命名不一致。
涉及:P207 还款方式L067 规则:客户还款仅走钱包代扣出处:R3§⑥·registry L067
登记原文P207 REPAY_METHOD: L067 写作 REPAY_TYPE=VA,与 REPAYMENT_TYPES(IOURepay/BillRepay)重名——后端字段名到底是 REPAY_TYPE 还是 REPAY_METHOD 待核
○ 待收口
G-152缺口U09 参考层字典(横切属性与枚举正本)

取现审批动作码 LR/LA 等四个值含义未知

缺什么:P214 取现审批结果动作码(ACTION_CODE_TYPE)中,LR/LA/LACLNL/LACLNH 四个值的业务含义未知(目前只知道 LRCLNR/LRCLNL 对应额度受限 QUOTA_LIMIT);写入方按首借走 F-07 首账前借款审批引擎、复借走 F-19 借款复借审批二选一登记,但只是推断。 为什么缺/线索:出处 R3§⑥;仅从常量名和部分映射推得。 [2026-09-08 IT 知识库核查] ACTION_CODE 这一列在知识库中存在且可定位,但 LR / LA / LACLNL / LACLNH 四个取值全部零命中——取值语义在风控策略包里,知识库结构性不收。与 G-038 是同一件事(该列的枚举字典)。建议三条合并向风控一次性提问。
涉及:P214 取现审批结果动作码F-07 首账前借款审批引擎F-19 借款复借审批出处:R3§⑥
登记原文P214 ACTION_CODE_TYPE: LR/LA/LACLNL/LACLNH 四值语义(仅知 LRCLNR/LRCLNL→QUOTA_LIMIT);写入方首支 F-07/复支 F-19 二选一为推断
○ 待收口
G-153缺口U09 参考层字典(横切属性与枚举正本)

挑战类型清单:列表性质与格式已明,成员码值在策略包

缺什么:P041 支用提交结果码(风控挑战码)除已知的 0004、1212 之外还有哪些值;P216 取现挑战类型清单(RULE_CODE_LIST_PARTNER)里各成员码值是什么——都没有登记。 为什么缺/线索:出处 R3§⑥、R2§六;前端只处理了两个码。 [2026-09-08 IT 知识库核查] RULE_CODE_LIST_PARTNER 的性质查明:它是对外原因码列表,格式在知识库中可查。P041 支用提交结果码 的全集已随 G-198 大幅补齐(81520003/81520004 轮询中间态、81521403/404/406 OTP 失败族、B403 超上限)。剩余:RULE_CODE_LIST_PARTNER 的成员码值在风控策略包里,需风控给清单。
涉及:P041 支用提交结果码(风控挑战码)P216 取现挑战类型清单出处:R3§⑥·R2§六
登记原文P041/P216 挑战码: 提交结果码全集(0004/1212 之外);RULE_CODE_LIST_PARTNER 成员码值
○ 待收口
G-154缺口U09 参考层字典(横切属性与枚举正本)

质押类型九个取值待 PM 确认,是否与提额记录类型同物

缺什么:P043 质押/提额记录类型(pledgeType)的九个取值,业务含义都是根据常量名推断的,尚未经 PM 确认;它与 P055 提额记录类型是否是同一个东西、要不要合并,也没有定论。 为什么缺/线索:出处 R3§⑥、登记 P055;待 PM 确认,同物则合并。
涉及:P043 质押/提额记录类型P055 提额记录类型出处:R3§⑥·registry P055
登记原文P043 pledgeType: 九个取值的业务含义均据常量名推断,待 PM 确认;是否即『提额记录类型』P055 同物待并
○ 待收口
G-156缺口U09 参考层字典(横切属性与枚举正本)

借据处理标志:代码实证 W/WTO 两值已补,全集未见

缺什么:P201 借据处理标志(LOAN_PROCESS_FLAG)除 W=已核销之外的其他取值和含义未登记。 为什么缺/线索:出处 R5§⑧;后端观测仅见 W。 [2026-09-08 IT 知识库核查] LOAN_PROCESS_FLAG 在代码中至少出现 W、WTO 两个取值,已补登进 P201(语义仍待后端)。全集知识库未给出,需后端提供该字段的完整字典与各值含义。
涉及:P201 借据处理标志出处:R5§⑧
登记原文P201 LOAN_PROCESS_FLAG: 除 W=已核销外的取值
○ 待收口
G-157缺口U09 参考层字典(横切属性与枚举正本)

账龄码:双层挂载已确认,档位天数须以业务定义为准(PRD 否定按 DPD 换算)

缺什么:P218 账龄码(AGE_CD)1-9 各档对应的天数区间和单位没有明确(每档≈30 天是反推的);这个字段是账户级还是借据级也未确定。 为什么缺/线索:出处 R1§五。 [2026-09-08 IT 知识库核查] 两问中的一问有答案:AGE_CD 在账户级与借据级都存在——不是二选一,是两级都有。另查到 AGE_XFR_START_AGECD=4,即转档起点在第 4 档。⚠ 重要反向发现:1-9 各档的天数区间未给出,而 PRD 明确否定了「按 DPD 换算账龄档」的做法。这意味着不能用逾期天数自行推算档位,必须拿业务定义。需产品给档位定义、后端给转档实现。 [2026-09-22 数仓字典 字典明细.html] 字典对 age_cd 的释义给了完整天数区间:0=未逾期,1=1-30,2=31-60,3=61-90,4=91-120,5=121-150,6=151-180,7=181-210,8=211-240,9=241+(每档 30 天),与 9/8 记的「PRD 否定按 DPD 直接换算」冲突——要科技定:字典口径是数仓侧推断还是核心实现(参数 TM_PRM_OBJECT 里的分档表)。已按字典口径填进 P218 取值字典并标待核。另:AGE_HIST(P267,24 期账龄史)与 LAST_AGING_DATE(P268)已从 P218 拆出;字典称 LAST_AGING_DATE「可代替 DELQ DAYS 计算」,若成立影响 P233 逾期天数口径(U01 问题①)。P132 账龄档与 P218 重复,已并入。 [2026-09-23] 逾期天数按粒度拆为三条:P233 账户级 / P271 账单级 / P272 借据级(数仓 due_days,模型实读);逾期次数拆为 P234 账户级计数 / P273 账单级布尔。三条待科技核:① 起算点(最后还款日次日?)与宽限期是否计入;② 账户级取最早未清账单还是当前账单;③ P224 在贷本金的接口值 ACCOUNT_PRIN_AMT、ICPS PRINCIPAL_BAL、数仓 loan_os 是否同一口径(含不含已出账未还)。 [2026-09-23 收口(trista)] 科技 9/17 源码结论:AGE_CD = 账期月差、封顶 9(CoreComputeDueAndAgeCode),不是固定 30 日 DPD 桶——与 9/8 PRD「不能按 DPD 换算」一致;数仓字典的"每档 30 天"是数仓侧推断,P218 取值字典已标「字典口径」。仍待科技:① P233 候选落点 tm_account.OVERDUE_DAYS 与科技「S222105 无独立输出列、查询时算」相反,tm_account 到底有没有这列;② P272 借据级源列 TM_LOAN.DUE_DAYS 的 writer(哪个日终批)与起算点;③ 原三条(起算点 / 账户级取最早还是当前账单 / P224 三处口径)。
涉及:P218 账龄码P267 账龄历史(24 期)P268 上次账龄提升日期P233 逾期天数P271 账单逾期天数P272 借据逾期天数P273 账单是否逾期P234 账户逾期账单数P224 账户在贷本金出处:R1§五
登记原文P218 AGE_CD: 1-9 各档天数区间与单位(≈30 天为反推);是否账户级还是借据级
○ 待收口
G-158缺口U09 参考层字典(横切属性与枚举正本)

还款后营销码处理状态除 END 外还有哪些值

缺什么:P209 还款后营销码处理状态(MARKET_CODE_HANDLE_STATUS)除 END 之外的其他取值未登记。 为什么缺/线索:出处规则登记 L069;仅见 END 一值。
涉及:P209 还款后营销码处理状态L069 规则:还款后营销码处理出处:registry L069
登记原文P209 MARKET_CODE_HANDLE_STATUS: END 之外的取值
○ 待收口
G-159缺口U09 参考层字典(横切属性与枚举正本)

费率现网值:字段名族已确认,数值须 PM/后端导参数表

缺什么:P036 费率口径常量组的现网值整张表都缺:低价档费率与适用人群、取现/消费月费率与年利率现网档、头息现网档、replan 现网值、额占率价格区间上限、阶梯定价 X、会员月/年费价格与有效期天数、罚息日率(PENALTY_RATE)现网值、重组减免比例、转分期现网费率(生产参数表 DAY_INT_RATE_INSTALLMENT/ADMIN_FEE_RATE)。券叠加规则 PM 已收口(低价×立减可叠加、利率类互斥),但代码里没有统一的叠加器。 为什么缺/线索:出处 R4§6、_待确认清单(问后端 1);这些值多为引擎按账户计算或后台/营销配置,前端不持有,待 PM/后端。 [2026-09-08 IT 知识库核查] 字段名族经代码确认无误(P036 登记的 12 个子字段成立)。现网数值:知识库明确表态无证据——这是技术侧的明确否定,不是检索不足。费率值属运营参数,需 PM 或后端从参数表导出一张现网值对照表。
涉及:P036 费率口径常量组出处:R4§6·_待确认清单(问后端 1)
登记原文P036 费率常量组现网值: R4§6 全表:低价档费率与人群、取现/消费月费率与年利率现网档、头息现网档、replan 现网值、额占率价格区间上限、阶梯定价 X、会员月/年费价格与有效期天数、PENALTY_RATE 现网值、重组减免比例、转分期现网费率(DAY_INT_RATE_INSTALLMENT/ADMIN_FEE_RATE 生产参数表);券叠加规则已 PM 收口(低价×立减可叠、利率类互斥)但代码无统一叠加器
○ 待收口
G-160缺口U09 参考层字典(横切属性与枚举正本)

5,000 万与 2,000 万两个额度上限常量是什么关系

缺什么:两个额度上限常量的关系不明:总信用额度天花板(ALLO_MAX_CREDIT_LIMIT=50,000,000)与另一常量(TOTAL_LIMIT_MAX=20M)——后者是产品天花板还是时光轴切档参数? 为什么缺/线索:出处 R3§①、规则登记 L136/L386。
涉及:L386 规则:总额度不超产品天花板L136 规则:时光轴切档比较出处:R3§①·registry L136
登记原文L386 / L136: ALLO_MAX_CREDIT_LIMIT=50,000,000 与 TOTAL_LIMIT_MAX=20M 两常量的关系(天花板 vs 时光轴切档参数?)
○ 待收口
G-161缺口U09 参考层字典(横切属性与枚举正本)

账户总欠款口径:后端分三字段存,ACCOUNT_AMT 对应哪个待确认

缺什么:P223 账户总欠款(ACCOUNT_AMT)与本金/利息/罚息三项的合计口径未明,尤其是否包含未出账部分;写入方是核心记账,但该动作没有建档。 为什么缺/线索:出处 R3 待确认清单;口径待 PM。 [2026-09-08 IT 知识库核查] 关键事实:ICPS 用 BAL_AMT / BILL_BAL_AMT / UN_BILL_AMT 三个分开的字段——「含不含未出账」在后端不是一个口径问题,是三个不同字段。剩余:登记表用的 ACCOUNT_AMT 到底对应哪一个,或是否为合计,需后端指认。定了之后 P223 的口径描述要相应改写。
涉及:P223 账户总欠款出处:R3 待确认清单
登记原文P223 accountAmt: ACCOUNT_AMT 与本金/利息/罚息三项的合计口径(是否含未出账)待 PM;写入方=核心记账未建档
○ 待收口
G-162缺口U09 参考层字典(横切属性与枚举正本)

账户接口字段:cashLimitRate 已定位,其余三字段零命中

缺什么:账户信息接口中,账户利息额(accountIntAmt)、是否展示存款(showDeposit)、邮箱是否需验证(emailVerifyRequired)、取现额度比例(cashLimitRate)几个字段的写入方未登记;现金分期计划列表(loanPlans/LOAN_PLANS)没有单独登记——它疑似是 N002 信贷账户到 N005 借据的链接,而不是 R005 关系下的产品挂载。 为什么缺/线索:出处 R3§①、关系登记 R005;待 U03/U04 核。 [2026-09-08 IT 知识库核查] cashLimitRate 在代码中有列,且由授信审批产出——写入方问题有答案了。但 accountIntAmt / showDeposit / emailVerifyRequired 三个字段在代码中零命中,需后端确认这三个是否已下线、还是改了名——若已下线,登记表应相应退役。借款计划列表归属(N002 还是 N005)未查到,一并请后端确认。
涉及:N002 信贷账户N005 借据(IOU)出处:R3§①·registry R005
登记原文R3① 部分字段写入方: accountIntAmt/showDeposit/emailVerifyRequired/cashLimitRate 写入方未明(null);loanPlans(LOAN_PLANS 现金分期计划列表)未单登——疑为 N002→N005 链接而非 R005 的产品挂载,待 U03/U04 核
○ 待收口
G-163缺口U09 参考层字典(横切属性与枚举正本)

灵活码后端字典是否与 PM 位段口径一致

缺什么:P002 灵活码的后端字典(FLEX_CODE)是否与 R1§二 的位段口径一致未核实(五轴已复核,子字段正本由 U05 登记)。 为什么缺/线索:出处 R1§二、R3§①;R3 标注「取值表代码未见,待后端补」。
涉及:P002 灵活码出处:R1§二·R3§①
登记原文P002 flexCode: 五轴已复核;sub_fields 正本由 U05 登;R3 标『取值表代码未见,待后端补』——后端 FLEX_CODE 字典是否与 R1§二 一致待核
○ 待收口
G-164缺口U09 参考层字典(横切属性与枚举正本)

首借/复借引擎切换判据、征信源和质押本金字段待确认

缺什么:N012 决策引擎中,首借专用审批(88200227)与普通审批(88200102)的切换判据存在数据库里,需业务方确认;审批引擎(MIDAPS)的征信源 SLIK/Shopee/Toko 在观测窄窗内未见调用,但不等于停用;风控团队拟提供的质押本金优先字段(pledgeBalanceAmount)尚未上线。 为什么缺/线索:出处 R10§5、R3§③。
涉及:N012 决策引擎/规则包出处:R10§5·R3§③
登记原文N012 决策引擎: 首借专号 88200227 与普通审批 88200102 的切换判据存 DB 需业务方确认;MIDAPS 征信源 SLIK/Shopee/Toko 窄窗未见≠停用;pledgeBalanceAmount 字段(risk team 拟提供)未上线
○ 待收口
G-166缺口finalize

开通问卷奖励档的取值字典未登记

缺什么:P193 开通问卷奖励档的枚举取值字典没有登记。 为什么缺/线索:出处 12-支撑流程§C、§待确认;文档中未见。
涉及:P193 开通问卷奖励档出处:功能说明/12-支撑流程(账户安全·引导·结果页).md§C·§待确认
登记原文P193: 枚举取值字典未载(文档未见)
○ 待收口
IF-01接口候选U01 开通与授信

开户段四类受理动作可归并为「可受理」接口

建议:把授信申请(N013)、KYC 认证提交(N014)、推荐码提交(N031)三类申请事件的受理动作——受理开通申请(A-01)、受理 KYC 步骤提交(A-02)、受理推荐码提交(A-20)、受理授信提交并送审(A-56)——归并为一个「可受理」接口。 理由:这几个受理动作形状相同(都是提交时间+受理结论),且三类以上申请事件共用,分别登记等于同一规则抄多遍(出处 01§D.1、D.2、D.5)。
涉及:N013 授信申请(开户)N014 KYC 认证提交N031 推荐码提交A-01 受理开通申请A-02 受理 KYC 步骤提交A-20 受理推荐码提交A-56 受理授信提交并送审出处:01§D.1·01§D.2·01§D.5
登记原文此处或可归并接口「可受理」：受理开通申请 A-01 / 受理 KYC 步骤 A-02 / 受理推荐码 A-20 / 受理授信提交 A-56 形状相同（提交时间+受理结论），三类以上申请事件共用 候选:N013·N014·N031
○ 待收口
IF-02接口候选U01 开通与授信

KYC 子步若都要上报,可考虑「可上报」接口

建议:KYC 三个子步骤(OCR/人脸/问答)已参数化并入受理 KYC 步骤提交(A-02);如果后续各子步骤的规则要再抄一遍(例如都要做 CNC 上报、GPS 采集),可考虑把 KYC 认证提交(N014)、GPS 定位记录(N038)、CNC 风控上报事件(N040)归并为「可上报」接口。 理由:预防性建议(出处 01§D.7)——目前不重复,但一旦子步规则要复制第二遍就值得抽接口。
涉及:N014 KYC 认证提交N038 GPS 定位记录N040 CNC 风控上报事件A-02 受理 KYC 步骤提交出处:01§D.7
登记原文KYC 三子步（OCR/人脸/问答）已参数化并入 A-02，若后续各子步规则要抄第二遍（如均需 CNC 上报/GPS），可考虑「可上报」接口 候选:N014·N038·N040
○ 待收口
IF-09接口候选U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

五类还款侧申请事件同形,可归并为「可受理」

建议:把月最低还款(N019)、账单分期(N020)、逾期重组(N021)、转分期(N022)、协商方案确认(N023)五类申请事件归并为「可受理」接口。 理由:五者形状相同(提交→受理结论三态/四态、验 PIN、RIPLAY 合同随单),RIPLAY 勾选门(L049)已对 A-05/A-09/A-10/A-11 重复抄写(出处 05§D.1、05§D.3、06§D)。
涉及:N019 月最低还款申请N020 账单分期申请N021 逾期重组申请N022 转分期(展期)申请N023 协商方案确认L049 规则:RIPLAY 勾选与合同加载门出处:05§D.1·05§D.3·06§D
登记原文此处或可归并接口『可受理』:N019/N020/N021/N022/N023 五类申请事件同形(提交→受理结论三态/四态、PIN、RIPLAY 合同随单),L049(RIPLAY 勾选)已对 A-05·A-09·A-10·A-11 抄写 候选:N019·N020·N021·N022·N023
○ 待收口
IF-10接口候选U05 减压与重组(灵活还款四路:月最低还款/账单分期/逾期重组·协商/转分期)

三个借新还旧类功能是一个能力,可归并为「可借新还旧」

建议:把月最低还款(N019)、账单分期(N020)、逾期重组(N021)归并为「可借新还旧」接口。 理由:三者共用同一 INBS 工单(i200029)与四态流程状态(FLOW_STATUS),受理闸门(L272~L275)对三者同写;PM 口径为「三个功能、一个能力」(出处 05§E.4)。
涉及:N019 月最低还款申请N020 账单分期申请N021 逾期重组申请L272 规则:借新还旧闸门①无在途工单L273 规则:借新还旧闸门②灵活码首位L275 规则:借新还旧闸门④逐借据期数资格出处:05§E.4
登记原文此处或可归并接口『可借新还旧』:N019/N020/N021 三申请共用 INBS i200029 工单与 FLOW_STATUS 四态,受理闸门 L272~5 对三者同写(PM 口径『三个功能、一个能力』) 候选:N019·N020·N021
○ 待收口
IF-11接口候选U06 质押与额度成长(LimitUp 专属)

质押/解押/支取/重新授信/补料可归并「可受理」

建议:把重新授信申请(N024)、质押申请(N025)、解押申请(N026)、存单提前支取(N027)、补充资料上传(N032)归并为「可受理」接口。 理由:它们同为客户申请事件、同走受理三态,受理类规则(验 PIN、开关、在途检查)已在多处重复(出处 09§质押流程、07§重新风险授信流程)。
涉及:N024 重新授信申请(reapply)N025 质押申请N026 解押申请N027 存单提前支取N032 补充资料上传出处:09§质押流程·07§重新风险授信流程
登记原文此处或可归并接口:可受理——质押申请/解押申请/存单提前支取/重新授信申请/补充资料上传同为客户申请事件、同走受理三态,受理类规则(验 PIN、开关、在途)已在多处重复 候选:N024·N025·N026·N027·N032
○ 待收口
IF-14接口候选U07 会员与营销

会员购买/留资/推荐码提交同为申请事件,可并入「可受理」

建议:把会员购买/续费(N028)、留资提交(N030)、推荐码提交(N031)并入 IF-01 的「可受理」接口。 理由:三者均为客户申请类事件,受理动作同形(出处 10§购买月会员流程、11§留资、11§MGM)。
涉及:N028 会员购买/续费N030 留资提交N031 推荐码提交出处:10§购买月会员流程·11§留资·11§MGM
登记原文此处或可归并接口:可受理(IF01)——N028 会员购买、N030 留资提交、N031 推荐码提交均为客户申请类事件,受理动作同形 候选:N028·N030·N031
○ 待收口
IF-15接口候选U07 会员与营销

各类营销物件同由一个配置动作产出,可归并「可配置营销物」

建议:把营销活动(N061)、权益 Benefit(N062)、SMP 支付立减券规则配置(N085)、App 内营销落地页配置(N064)、留资 H5 落地页配置(N065)、运营位(N066)、会员套餐配置(N056)归并为「可配置营销物」接口。 理由:它们都由同一个参数化的配置动作——配置营销活动与权益(A-46)——产出(出处 11§SMP 活动配置、09§营销系统配置)。
涉及:N061 营销活动N062 权益 BenefitN085 SMP 支付立减券规则配置N064 App 内营销落地页配置N065 留资 H5 落地页配置N066 运营位N056 会员套餐配置A-46 配置营销活动与权益出处:11§SMP 活动配置·09§营销系统配置
登记原文此处或可归并接口:可配置营销物——N061/N062/N085/N064/N065/N066/N056 均由 A-46 参数化配置 候选:N061·N062·N085·N064·N065·N066·N056
○ 待收口
IF-17接口候选U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

五类观测记录共用同一上报动作,可归并为「可上报」

建议:把 GPS 定位记录(N038)、App List 采集记录(N039)、CNC 风控上报事件(N040)、内部埋点事件记录(N041)、对外归因上报事件(N042)归并为「可上报」接口。 理由:五者共享同一个参数化上报动作(A-50)以及只追加/防重的口径(出处 功能说明/13 §对外/风控上报、参考/R8 §12)。
涉及:N038 GPS 定位记录N039 App List 采集记录N040 CNC 风控上报事件N041 内部埋点事件记录N042 对外归因上报事件A-50 上报事件出处:功能说明/13-埋点与监控.md§对外/风控上报·参考/R8-埋点事件目录.md§12
登记原文此处或可归并接口「可上报」：N038~N042 五类观测记录共享同一参数化上报动作 A-50 与只追加/防重口径 候选:N038·N039·N040·N041·N042
○ 待收口
IF-18接口候选U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

各类「只弹一次」的引导弹窗可归并为「可一次性展示」

建议:把 welcome、tour、引导、问卷、挽留弹窗等归并为「可一次性展示」接口,统一用 UI 展示记录(N043)承载。 理由:它们共享「只弹一次」的三层记录形状(出处 功能说明/12 §B)。
涉及:N043 UI 展示记录出处:功能说明/12-支撑流程(账户安全·引导·结果页).md§B
登记原文此处或可归并接口「可一次性展示」：welcome/tour/引导/问卷/挽留弹窗共享「只弹一次」三层记录形状（N043） 候选:N043
○ 待收口
G-178缺口finalize

取现审批动作码 6 个值里 4 个含义没登记

缺什么:P214 取现审批结果动作码(ACTION_CODE) 取值 LR/LA/LRCLNR/LRCLNL/LACLNL/LACLNH,只有 LRCLNR/LRCLNL(=额度限制 QUOTA_LIMIT)有解释,其余 4 个语义未登记。 为什么缺/线索:前端只按 LRCLNR/LRCLNL 分流失败页,其余码未消费;码由借款审批引擎(F-19)返回,含义在风控侧——按字面疑为 额度有效性(L/ A)×借款策略(R/A)×新额度对比(CLNR/CLNL/CLNH)的组合,待风控确认。
涉及:P214 取现审批结果动作码F-19 借款复借审批出处:03§D.4·R3
登记原文P214 取现审批结果动作码:LR/LA/LACLNL/LACLNH 语义待补
○ 待收口
G-180缺口finalize

自动扣款和代偿产生的还款,要不要和客户主动还款分成两个对象

缺什么:N018 还款交易 定义为客户发起的事件(无 product_of);但自动扣款(A-60,ICPS 批量)和质押代偿(A-65,RMS 调度)也产生还款记录,它们是机构动作的产物(应有 product_of)。现在三者同对象记录,product_of 无法两全。 为什么缺/线索:纲要 5.5#13「客户发起的是事件、机构动作留下的是产物」是两类;同一业务事实(一笔钱冲抵账单)来源不同。待定:①拆「系统还款」事件对象(product_of=A-60·A-65),与 N018 并列;或②N018 加「发起方」属性(客户/自动扣款/代偿)区分。另 A-60 自动扣款是否真落为还款实例亦待后端确认。
涉及:N018 还款交易A-60 自动扣款A-65 执行质押物代偿出处:04§D·05§E.1·纲要 2.1/5.5#13
登记原文系统发起的还款是否拆独立事件对象
○ 待收口
X-047冲突audit-seg1

GPS 强制授权弹窗:L170 与 L362 重复登记

说法一
L170 保留强制授权半句(现状,与 note 自陈矛盾)
说法二
L170 收敛为纯基础上报,强制授权归 L362
涉及:L170L362A-50出处:SEG1 核验 2026-08-27
登记原文GPS 强制授权弹窗:L170 与 L362 重复登记
○ 待收口
X-048冲突audit-seg1

同一开通状态 T017 下,进申请落地页还是直接进面签

说法一
T017 走申请落地页(L012 现状)
说法二
T017 直接进面签(L005 现状);L012 集合应剔除 T017
涉及:L012L005A-01N013出处:SEG1 核验 2026-08-27
登记原文同一开通状态 T017 下,进申请落地页还是直接进面签
○ 待收口
G-183缺口audit-seg1

授信核准时写营销码/客群码的时点没有出处

缺什么:L210 说核准落地时写初始额度与 marketCode/segCode/riskCode、拒绝时在 marketCode 第 19 位记重授状态,但「什么时点写、由谁写」在知识库里找不到出处。 为什么缺/线索:01§D.4 只写结果码分流,R5§① 只给状态流转,R1§一只定义位段取值不给写入时点;现有依据实为登记表 F-07 的 note。待风控/后端确认写入时点。
涉及:L210 核准落地写码A-22 授信裁决落地P001 营销码P003 客群分段码出处:SEG1 核验 2026-08-27
登记原文授信核准时写营销码/客群码的时点没有出处
○ 待收口
G-186缺口audit-seg1

授信裁决记录与开通问卷提交的主键是推断的

缺什么:N074 授信裁决记录 现用「APP_NO+裁决时间」、N034 开通问卷提交 现用「客户+提交时间」,两者都是推断的复合键,知识库未给真实主键;N034 的问卷题目/答案结构也全未载,名下唯一属性还是算出来的奖励档。 为什么缺/线索:01§D.4 只有一次结果查询接口;12§51/§77 只给路由与「奖励档算法以 PRD/风控为准」。待后端/PM 补。
涉及:N074 授信裁决记录N034 开通问卷提交P193 奖励档出处:SEG1 核验 2026-08-27
登记原文授信裁决记录与开通问卷提交的主键是推断的
○ 待收口
G-187缺口audit-seg1

对外归因上报事件的身份标识不合格

缺什么:N042 现填身份标识「归因 ID = MpcID+MdcID+allo-app」,这是设备/用户级归因标识,同一客户所有上报共用,数不清单条事件;且 MpcID 已是客户(N001)的身份标识,借用违纲要 2.1。 为什么缺/线索:待后端给出单条上报记录的标识(如上报流水号),在此之前身份标识应留空。
涉及:N042 对外归因上报事件N001 客户P190 上报防重标记出处:SEG1 核验 2026-08-27
登记原文对外归因上报事件的身份标识不合格
○ 待收口
G-191缺口audit-seg1

授信申请的双主键与裁决结果码的归属

缺什么:① N013 授信申请 的身份标识并列「APP_NO + 流程实例 flowId」两个主键,flowId 又被 N014 借作身份前缀,应确定谁是主键、flowId 是否降为流程标识属性;② P092 授信申请结果码 挂在客户事件 N013 上但由机构动作 A-22 写入,按观测/干预分离更应挂在裁决记录 N074 上。 为什么缺/线索:两处都影响叙事与图谱,牵动多段,留待人工定。
涉及:N013 授信申请N014 KYC 认证提交N074 授信裁决记录P092 授信申请结果码出处:SEG1 核验 2026-08-27
登记原文授信申请的双主键与裁决结果码的归属
○ 待收口
X-051冲突audit-seg1

采集/上报类事件算不算动作的产物

说法一
保留 product_of=A-50(视为隐式上报动作的产物)
说法二
清空 product_of(视为设备/客户侧观测事件)
涉及:N038 GPS 定位记录N039 App List 采集记录N042 对外归因上报事件A-50 上报事件出处:SEG1 核验 2026-08-27
登记原文采集/上报类事件算不算动作的产物
○ 待收口
G-192缺口audit-seg1

账单日期:定为「留单值、退字段组」(已定),重构留专项

缺什么:P027 账单日期组(结构组,宿主账单)的子字段已含 STMT_DATE 账单日、PMT_DUE_DATE 最后还款日、dueMonth 账期月,而 P239 账单日、P241 本期还款日、P240 账单月份 三条单值属性登的是同一批字段、同宿主同写入方(A-40),属重复登记。 为什么缺/线索:P239/P240/P241 来自 2026-08-19 拆分 P016 日期/系统组(拆分本身对:P016 横跨账户与账单两类宿主),但拆出的账单侧三条与既有的 P027 撞车。需定:退役三条单值并入 P027,还是拆散 P027 保留单值。 同类现象全库还有 20+ 组(额度组 P012 vs P147/P220/P221/P222、账单金额组 P026 vs P028/P029 等),建议随账单段(SEG4)统一定口径。 [2026-09-08 IT 知识库核查] 知识库给出后端实际的五个字段:STMT_DATE / CURR_STMT_DATE / STMT_MONTH / PMT_DUE_DATE / CURR_PMT_DATE。其中 CURR_STMT_DATE 与 CURR_PMT_DATE 是登记表此前完全没有的——后端区分「当前账期」与「历史账期」两套日期,这是本次核查的新知识,已补入 P027 子字段。至于 P027 字段组与 P239/P240/P241 单值属性并存的重复问题:我的建议是按纲要 2.2「一条属性一个业务事实」拆为单值属性、退役字段组,但 P027 被 14 个构件引用(含 A-40/A-41/A-43 与 L062/L063/L070/L074/L250/L251),拆分需连带改写这些引用,属专项重构,不在本轮动刀。 [2026-09-08 Leo 定结论] 方向定为「留单值属性、退役 P027 字段组」,依据纲要 2.2「每条属性都应有明确的业务或技术价值,不照搬源表的列」——字段组本质是照搬源表列;且字段清单在构件弹窗里挤成一团,拆开后可读性明显改善。 专项执行清单(本轮不动刀): · 新建 4 条单值属性承载 P027 中未被 P239/P240/P241 覆盖的事实——账期起止(START_DATE/END_DATE)、还清日期(PAID_OUT_DATE)、业务日期(BUSINESS_DATE)、当前账期日期(CURR_STMT_DATE/CURR_PMT_DATE,本次新查到,后端区分「当前账期」与「历史账期」两套) · 重定 P027 的 14 处引用:A-40/A-41/A-43、F-64、P016,及 L062/L063/L070/L074/L250/L251 六条规则——每条须逐一确认它引的是哪个日期,不可批量替换 · 确认 STMT_MONTH 与 P027 中 dueMonth 是否同义(疑为同一事实的两个名字),同义则并入 P240 · 全部重定后退役 P027 [2026-09-17] 文中「额度组 P012 vs P147/P220/P221/P222」一组已处理:P012 引用逐条改指 P219-P222 后退役(见 G-218)。P147 可用额度(draft)与 P220 可用信用额度 仍是同一字段的两条登记,待并。
涉及:P027 账单日期组P239 账单日P240 账单月份P241 本期还款日P026 账单金额组出处:SEG1 核验 2026-08-27
登记原文账单日期字段结构组与单值属性重复登记
○ 待收口
G-193缺口audit-reject

假拒绝存量 1,345 笔怎么处置(数字口径存疑,须先重新统计)

缺什么:反欺诈按交易参考号防重,同键再次进入即硬编码「审批拒绝」且不回放首次结论(L249),超时重试的客户会被误判拒绝,且关联旧账单永不结清。生产存量 1,345 笔 / 1,334 客户。登记表记了机制与误判指纹,但没有任何构件承载这批存量怎么处置——谁来识别、要不要主动补偿或重放、旧账单如何结清、客户侧要不要通知,都没有动作卡。 为什么缺/线索:03§放款链路把它标为「已知生产问题」,未给处置方案。需风控 + 运营给结论:是批量重放补单、人工核销旧账单,还是仅改防重键策略防新增。识别口径已有(误判指纹=审批拒绝 + 申请号为空 + 风控侧查无审批记录)。 [2026-08-27 已出决策材料:桌面《假拒绝存量处置-风控运营.html》与 artifact 7e6abc1c,含识别指纹、四步机制、三方案对比(A 重放补单 / B 人工核销 / C 改防重键防新增)与 5 个待答问题;A 与 B 的分岔点=这批客户当初有没有实际到账,须账务先跑数。] [2026-09-08 G-193 技术半边已收口:识别口径问题查明——BE002 有三条产出路径且都不建案件(本规则的防重、RC36ADJR02 在途解质押、RC36SERR03 取现在途),响应报文完全一致,只能靠异常堆栈行号区分。现有指纹会误收后两类正常业务拒绝,方案 A 批量重放补单将给不该补的人补钱;1,345 这个数系按该口径统计,虚高可能性大。本条自此只管业务处置(A 重放补单 / B 人工核销 / C 改防重键),重新统计一事分出 G-207,处置决策须以重新统计后的数字为准。
涉及:L249 反欺诈防重假拒绝F-18 放款反欺诈-取现P126 取现反欺诈决策N005 借据N045 账单出处:SEG2/SEG3 拒绝路径核验 2026-08-27
登记原文反欺诈防重假拒绝存量 1345 笔无处置构件
○ 待收口
G-194缺口audit-reject

风控拒绝(BE002)最终落哪个失败页没登记

缺什么:取现失败类型(P125)只登了三个分流——通用失败页、在途页、额度限制页,而反欺诈拒绝(BE002)属于哪一类没有明写;派生函数 F-59 的输入里虽含结果码,但取值字典没有把 BE002 映射到具体页面。 为什么缺/线索:03§取现失败分流只列了三页,未说明风控拒绝的落点(推测走通用失败页,但知识库无明文)。待前端/PM 确认。
涉及:P125 取现失败类型F-59 取现结果分流派生P126 取现反欺诈决策出处:SEG2/SEG3 拒绝路径核验 2026-08-27
登记原文BE002 风控拒绝落哪个失败页未登记
○ 待收口
G-201缺口audit-seg2

支付段通知触发条件待产品+后端(知识库结构性不收)

缺什么:下发通知(A-39)在本段挂 0 条规则,而支付段确实有三种触达(VDC 补足失败的两套 Push、VDC 支付的 RIPLAY 邮件、取现 WhatsApp OTP)——这些触发条件目前都写在别的动作卡的副作用里,没有独立规则挂到 A-39。 为什么缺/线索:A-39 现有的三条前置条件全部来自别的业务段(会员/质押)。属覆盖缺口,不是「本来就没规则」。补登时须与 L036/L038 的既有表述去重。 [2026-09-08 IT 知识库核查] 知识库结构性不收触达触发条件。已知 A-39 下发通知 在支付段没有任何触发规则挂载,L036/L038 两条失败规则也未声明是否触发通知,P120 模版无触发条件。需产品定「什么情况下通知客户」、后端确认现网实际触发点。已确认无需再检索。
涉及:A-39 下发通知L036 VDC 未激活自动充值失败L038 PL 部分超限失败P120 VDC 支付失败 Push 模版出处:SEG2 核验 2026-08-27
登记原文通知动作在支付段没有任何触发规则
○ 待收口
G-202缺口audit-seg2

通知送达状态:状态序列已查到,只差承载列名

缺什么:下发通知(A-39)的副作用是 none(宣称不留痕),但它的观测指标写着「触达送达率/打开率」「OTP 触达→完成验证转化」——能观测就说明送达状态与触达时间落了库,却一个属性都没建档。 为什么缺/线索:R7 全篇只登触发时机、渠道与文案键,无送达状态字段。待后端补;补齐前这两个指标实际不可度量。 [2026-09-08 IT 知识库核查] 状态序列查到:CREATED→ACCEPTED→SENT→DELIVERED/FAILED/EXPIRED,回执入口 serviceId=11310026 saveBatchMessageStatus,账本 RCS-INFOS infos_messages。这已经能回答「送达率怎么算」——DELIVERED 占比。剩余:承载该状态的列名与字典未展开(知识库自陈未闭合到最终送达回执),需后端给列名;拿到后应在 N068 下立一条送达状态属性,A-39 声明的观测指标才有承载。与 G-208(触达流水号列名)是同一次向后端提问可一并解决。
涉及:A-39 下发通知N068 通知G-196出处:SEG2 核验 2026-08-27
登记原文通知的送达状态无属性,却声明要观测送达率
○ 待收口
G-205缺口audit-seg2

VDC 自动补足的触发阈值与资金来源判定规则

缺什么:自动补足(Auto top-up)什么时候触发、补多少、从信贷额度还是钱包补,这些判定规则与阈值数值没有登记。 为什么缺/线索:IT 知识库只有接口与落库(88200106-SWITCH_PL_TOPUP 开关、QUERY_PL_TOPUP_LIMIT 查限额、virtual_card_info.paylater_top_up_switch),阈值数值属后台配置/PM 口径,KB 结构性不收(自 G-029 拆出)。
涉及:A-33 VDC 自动补足放款P111 VDC 卡限额P113 每日剩余 PL 支付上限N011 虚拟借记卡出处:G-029 拆分 2026-09-08
登记原文VDC 自动补足阈值与资金来源判定待 PM
○ 待收口
G-206缺口audit-seg2

OTP 失败次数上限的确切值待风控确认

缺什么:风控挑战 OTP 腿的失败次数上限,只差一个确切数值。 已知:返回码 81521403/81521404/81521406 分别对应第 3/4/5 次校验失败,流程码 B403=超最大尝试次数,据此推得上限应为 5 次,但这是从码值映射反推的,不是明写的配置。 为什么缺/线索:次数属风控策略包配置,IT 知识库结构性不收(与 G-051 券叠加优先级、G-159 费率现网值同类)。需风控给出现网配置值,并确认是否按场景/渠道分档。
涉及:A-27 下发风控挑战P041 支用提交结果码出处:G-198 收口分出 2026-09-08
登记原文OTP 失败次数上限的确切值待风控确认
○ 待收口
G-207缺口audit-reject

假拒绝存量须按堆栈行号重新统计(现有 1,345 笔口径会误收)

缺什么:满足「BE002 + APP_NO=null + 风控侧查无审批记录」的交易里,实际混着三条不同路径:L249 防重假拒绝(该补偿)、RC36ADJR02 在途解质押拒绝、RC36SERR03 取现在途拒绝(后两类是正常业务拒绝,不该补偿)。三者响应报文完全一致,唯一区分手段是异常堆栈行号。 要做什么:请科技侧按堆栈行号拆分重新统计,给出三类各自的笔数与客户数;G-193 的处置方案(重放补单/人工核销)必须以拆分后属于 L249 的那一部分为准,现记的 1,345 笔/1,334 客户不可直接使用。 为什么缺/线索:IT 知识库给出了三路径同码的事实与区分手段,但不提供生产数据统计。
涉及:L249 反欺诈防重假拒绝P041 支用提交结果码F-18 放款反欺诈-取现出处:G-193 收口分出 2026-09-08
登记原文假拒绝存量须按堆栈行号重新统计
○ 待收口
G-208缺口audit-seg2

通知(N068)的触达流水号列名待后端给出

缺什么:通知对象的身份标识——一次触达实例的流水号字段名。 已知:通知账本在 RCS-INFOS 的 infos_messages 表(RCS 系为统一消息执行与状态中心),状态序列 CREATED→ACCEPTED→SENT→DELIVERED/FAILED/EXPIRED,回执入口 serviceId=11310026 saveBatchMessageStatus;但 infos_messages 的主键/流水号列名在 IT 知识库中未展开。 为什么缺/线索:R7 全篇只登触发时机、渠道与 i18n key,不含流水字段;需后端给出 infos_messages 的主键列名。
涉及:N068 通知(参数化)A-39 下发通知(参数化)出处:G-196 收口分出 2026-09-08
登记原文通知的触达流水号列名待后端
○ 待收口
G-209缺口audit-seg2

IF-16 可验密缺共同属性槽位:是否应立「验密状态」共享属性

缺什么:IF-16 可验密 的 shape.properties 是空的——按纲要 2.6「归并优先合并属性,绑定只是折中」,接口本应先有共同的属性槽位,但八类实现者(N015/N017/N018/N022/N024/N025/N026/N028)身上目前没有任何共同属性:验密状态、验密时点都没有登记为属性,PIN 校验的结果只存在于 A-49 的执行过程里。 要判什么:①是否应立一条共享属性「验密状态」(或「验密时点」),多宿主挂到八类实现者上,使接口有真正的形状要求;②若各实现者的验密结果口径不同,则退而用 bindings 各绑各的 P 号并登缺口待合并。 为什么缺/线索:PIN 校验结果是否落库、落在哪,登记表里没有;需后端确认 A-49 的校验结果有无持久化字段。在此之前 IF-16 只能以 shape.actions 单列成立。
涉及:IF-16 可验密A-49 PIN 校验L017 提交前必验 PIN出处:G-204 收口分出 2026-09-08
登记原文IF-16 缺共同属性槽位
○ 待收口
G-210缺口U01 开通与授信

预授信白名单未命中的取值字面量,以及三个渠道字段与前端聚合结果的关系

缺什么:①amsAccountCheckWhitelist 返回的白名单命中标记,命中为 Y 有实证,但未命中时的字面量未见(登记表原先填的「非Y」是占位不是真码值,2026-09-08 已删);②落库侧白名单标记按渠道分三个字段——TM_APP_BANK_INFO.WHITELIST_FLAG_MG(银行)、TM_APP_IM3_INFO.WHITLIST_FLAG、TM_APP_MPC_INFO.WHITLIST_FLAG(后两者列名少一个 E,原表拼写),另有策略引擎侧 TM_STRA_ENG_INPUT.WHITELISTFLAG / TM_STRA_ENG_OUTPUT.WHITELIST_FLAG;前端拿到的是聚合后的一个标记,与这三个渠道字段是什么关系(取或?按渠道二选一?)没有登记。 为什么缺/线索:IT 知识库给出了字段族但不给枚举取值;需后端确认未命中字面量与聚合口径。
涉及:P074 预授信白名单命中标记F-49 预授信白名单校验A-01 受理开通申请出处:六段核验 2026-09-08
登记原文预授信白名单未命中取值与渠道字段聚合口径
○ 待收口
G-211缺口U01 开通与授信

协议同意有无历史表;protocolType/version 两列的出处

缺什么:①N033 协议同意 按事件建模(一次同意一条),但知识库里 t_protocol_consent 是「每客户一行、两个同意标记(data_sharing/t_and_c)就地更新」的状态表,只存最新态——需后端确认是否另有历史表承载历次同意,否则「一次同意一行」在数据上不成立;②登记表 P061 里的 protocolType 与 version 两个字段在该表中不存在,出处待核(可能来自另一个系统)。 为什么缺/线索:t_protocol_consent 实际列=mpc_uid / data_sharing / t_and_c / select_time / update_time。
涉及:N033 协议同意P061 协议同意记录字段组出处:六段核验 2026-09-08
登记原文协议同意有无历史表
○ 待收口
G-212缺口audit-6seg

五个提交类事件的身份标识仍是自造组合键,需后端给真实主键

缺什么:下列五个对象的身份标识不是真实的键,是核验时自造的组合(借客户标识+时间戳,或写成表名): · N014 KYC 认证提交 —— 现填「flowId + 步骤类型(nextAction) + 提交序」,「提交序」是否存在未证 · N030 留资提交 —— 现填「手机号+提交时间(+marketingChannel)」 · N052 预付门槛任务 —— 现填「账户号 + 预付名单条目」,「名单条目」不是字段 · N071 Universal List 上传文件 —— 现填「文件类型 × 上传时间 × 上传账号」 · N087 PIN 设置/重置提交 —— 现填「客户 + 提交时间」 为什么缺/线索:2026-09-08 已在 IT 知识库检索一轮,这五个对应的表在 code_full.db 中未命中(留资侧只见 t_marketing_user_sales_relation 系,PIN 侧只见各行内系统的密码表,预付名单表 t_restructure_prepay_whitelist 在 ifes-ams 但未被索引)。需后端直接给出各自落表与主键列。 同批已解决的作参照:N034 开通问卷提交=TM_DATA_QUESTIONNAIRE.ID、N033 协议同意=mpc_uid+select_time、N039 App List=t_user_app_list_report.id、N075 VB 面签=CASE_NO。
涉及:N014 KYC 认证提交N030 留资提交N052 预付门槛任务N071 Universal List 上传文件N087 PIN 设置/重置提交出处:六段核验 2026-09-08
登记原文五个提交类事件身份标识待后端
○ 待收口
G-214缺口U05 减压与重组

转分期与账单分期对客统一包装为一个「分期」心智,登记表未体现

缺什么:PM 2026-08-13 口径——转分期(对已有借据摊期)与账单分期(对当期账单分期)**对用户统一包装为一个「分期」心智**,后台仍保持两条独立入账路径。登记表里两者是完全分开的两套构件(N020 账单分期申请 / N022 转分期申请及各自动作规则),没有任何地方记录「对客是一个心智」这件事——写 PRD 或对外沟通时容易按后台结构去讲,与产品口径不符。 要判什么:这条对客口径该以什么形式承载——是两个对象的 note、一条规则、还是一个「可分期」接口?(2.6 判据:同一句规则要抄第二遍才归并;目前没有这样的规则,故不宜直接立接口) 为什么缺/线索:功能说明 06「口径补充(PM 确认 2026-08-13)」。
涉及:N020 账单分期申请N022 转分期(展期)申请A-09 受理账单分期申请A-11 受理转分期(展期)申请出处:六段核验 2026-09-08
登记原文分期心智合并未登记
○ 待收口
G-215缺口U03 取现 Instant Cash

引擎裁决:一对一的做属性、一对多的立对象,取现侧四引擎串行是否已到升格的临界点

现状:同类的「引擎对某笔业务出裁决」在登记表里有两种登法—— · 立成对象:N074 授信裁决记录(身份 APP_NO+裁决时间,A-22 的产物,下挂 P094 裁决结论、P095 拒绝原因码) · 做成属性:P127 取现借款审批决策、P126 取现反欺诈决策、P106 消费反欺诈决策、P246 开户反欺诈裁决 判据(纲要 2.1):能逐个指认+有生命周期才立对象。N074 满足——同一申请可被多次裁决(reapply 会再裁一次),每次一条可清点;而一笔取现只有一个审批结论,做属性成立。故当前分法逻辑上站得住。 要盯的临界点:取现侧是四引擎串行(反欺诈→刷脸→首借/复借审批),已产生两条决策属性(P127 决策、P214 动作码)。若以后要追「这笔取现被哪个引擎、在什么时点、以什么理由拒的」,挂在 N017 上的几个字段记不下——那时应比照 N074 立成「取现审批裁决记录」对象。 现在够用,登记备查,不改。
涉及:P127 取现借款审批决策P214 取现审批结果动作码P126 取现反欺诈决策N017 取现支用N074 授信裁决记录出处:场景核验问答 2026-09-09
登记原文引擎裁决属性还是对象
○ 待收口
G-216缺口U02 支付消费

QRIS 付款码零属性:监管金额上限与付款方式枚举都只写在定义里,没登成属性

缺什么:N079 QRIS 付款码(CPM 被扫)有身份标识(qrCodeNo 出码流水号 + qrCodeValue 码串)、有产出动作(A-57 生成付款码)、有两条关系(扣款自资金源、成交为消费支付),但名下一条属性都没有。 而它的定义与备注里已经写着两件本该是属性的事: · 出码金额上限——定义写「出码有金额上限(监管)」,具体值见 QRIS 监管限额(单笔 Rp10jt / 单日 Rp100jt),这是码本身的约束,应登为属性并标注监管出处 · 付款方式 payWith 枚举——身份标识那一栏写着「付款方式见 payWith 枚举」,但枚举本身没有落成属性 另外码的有效时长(TTL)见 G-026,也属本对象的属性。 要做什么:确认这三项(金额上限 / payWith 枚举 / 有效时长)的字段名与取值,登为 N079 名下的属性。
涉及:N079 QRIS 付款码(CPM 被扫)A-57 生成 QRIS 付款码(CPM 出码)出处:零属性对象排查 2026-09-09
登记原文QRIS 付款码零属性
○ 待收口
G-217缺口U06 质押与额度成长(LimitUp 专属)

额度成长任务:目录与完成记录的属性挂错了宿主

现象:N035 任务完成(客户完成某个任务的一次记录)零属性,且身份标识也空(见 G-085);而三条相关属性——P053 任务类型、P165 任务状态、P166 任务奖励额度上限——全部挂在 N059 额度成长任务 上。 问题:N059 是任务**目录**(身份标识=任务类型码,四个固定任务的配置),N035 是**完成实例**。「任务类型」「奖励额度上限」属于目录没错,但「任务状态」(完成/未完成)显然是**实例**的属性——目录条目没有「状态」,只有某个客户的某次完成才有。目录与实例的属性混在了一起。 要判什么:①P165 任务状态 是否应改挂 N035;②N035 还缺哪些实例属性(完成时点、实得奖励额度、关联的支付/还款事件);③若确认 N035 只是 N059 的一个状态位、没有独立实例,则应退役 N035、把状态并回 N059——但那样「同一客户多次完成」就记不下,需先确认业务上是否只算一次。 为什么缺/线索:N035 身份标识空(后端判定系统未指认,G-085),这也是判不了的原因之一。
涉及:N035 任务完成N059 额度成长任务P165 任务状态P053 任务类型P166 任务奖励额度上限出处:零属性对象排查 2026-09-09
登记原文任务目录与完成实例属性混挂
○ 待收口
G-218缺口U09 参考层字典(横切属性与枚举正本)

结构组用宽了:一批「字段包」被当成位段编码整组登记,需拆为独立属性并退役原组

现象:活跃属性里结构组约 60 条,装着近 400 个没有自己编号的子字段(其中 80 多个还自带取值字典)。说明书 2.2 对结构组的定义是「位段编码类整组登记」(一个值内部分段,如 P002 灵活码的 50 位定长串),但多数结构组其实是把同一接口响应 / 同一张表单里的一批独立字段打成一包(如 P032 借据要素组:本金、期数、头息、费率、到账、合同……)。 问题:① 引用指不准——模型因子、规则条件只能指到整组;② 五轴标不准——一组只有一个来源 / 写入方 / 敏感级(P019 里性别随身份证号标「脱敏」);③ 没法接地与编译——科技 9/15 核验对 P012 / P032 的判语是「字段组不是单列,不能绑定成单列」,6.3 要求条件变量是有已核实词典行的 P 号,子字段没有编号;④ 拆了一半——P012、P014 的成员早已拆成单值属性(P219-P222、P233-P234),但原组没退役、引用没改指,同一字段两处登记。 已做(2026-09-17,U01 范围):P012(36 处引用)、P014(7 处引用)逐条改指后退役;P032 拆出 P256 借据本金,P019 拆出 P257 出生日期、P258 性别,P021 拆出 P259 月收入,原组子字段标 promoted_to、原组保留。改指时动作卡里的可用 / 取现额度一律写成括注说明(它们是 F-63 的推导值,动作不直接写)。 要做:① 其余约 55 个结构组逐个判:真位段(P001 营销码、P002 灵活码一类)保留,字段包按 use case 用到的先拆;G-192 已点名的同类还有账单日期组 P027、账单金额组 P026。② P147 可用额度(draft)与 P220 可用信用额度 是同一字段,待并。③ 待核:逾期天数 P233 写入方登记为「时间驱动」,结清时归零由谁写(A-43 现写成说明);新属性 P256 / P258 的写入方待 P032 / P019 拆完后补互指。④ 说明书 2.2 结构轴速判补一句判据,分清「位段」与「字段包」;机器审计加两条:结构组子字段全部有 promoted_to 而原组未退役时告警;新立属性与既有属性英文名 / 别名撞名时告警。 [2026-09-23] P133 账期参数组 → 账户级单值「账单日」(每月几号,L250 说怎么定),五个子字段退为各规则的历史样本;字段包待拆少一条。
涉及:P032 借据要素组P019 KTP OCR 字段组P021 申请补充信息组P256 借据本金P257 出生日期P258 性别P259 月收入P219 总信用额度P220 可用信用额度P221 取现额度P222 取现额度比例P233 逾期天数P234 账单逾期次数P147 可用额度P027 账单日期组P026 账单金额组出处:U01 × V3 模型包对照 2026-09-17
登记原文结构组用宽,字段包须拆为独立属性
○ 待收口
G-219缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

策略表没有生产载体;「策略」与「边界」的分界线未成文

缺什么:U01 闭环里执行点要按版本加载的「策略表」今天不存在——处置逻辑(名额、阈值、渠道 / 内容 / 话术 / 时点)全部写在模型脚本 score_s3_production.py 里,改一个渠道要改模型脚本、重新发模型。 已做(2026-09-21):脚本拆成三层,策略层落成 strategy_v1.yaml(与原脚本两批逐户等价),策略行 schema 登为 N089,策略引擎登为 F-80;红线拆成 L410 / L411。 要定:① 分界线成文——哪些字段业务在策略平台上可改(切点:名额、TAU_B、A_TOP_PCT、价值线 / 紧急线阈值、可达性天数;处置:层、强度、渠道、内容、话术、时点),哪些只能走改本体 + 编译 + 签认(池的定义、A/B 不融合、免费层锁免费渠道、动作参数合法取值、时段 / 同意书 / 去重约束);② TAU_B 归属——原脚本注释称「结构性阈值」,拆分按「有下限这件事是边界(L409)、下限的值是策略(params.TAU_B)」处理,待本体 owner 认;③ 策略表的生产载体与发布流程(版本、生效期、审批、回滚)归谁建;④ 执行记录表要带 strategy_version + model_a_version + model_b_version 三列(F-80 的 audit 已输出)。 [2026-09-22] 补:① F-80 subtype 填「策略引擎」,说明书 2.5 六型(查询/编辑/流式/模型集成/通知/API调用)未含,待 v3.1 加一型或归并;② 策略编排 copilot 已登为 F-81(模型集成),决策步查阅点已写 writes=N089 草稿、human_gate;策略平台接入时 agent_tools.json 按此生成。
涉及:N089 触达策略行F-80 触达分层与四旋钮解析L408L409L410L411A-39 下发通知F-77F-78F-81 策略编排 copilot出处:S3 模型三层拆分 2026-09-21
登记原文策略表无载体;策略 vs 边界分界未成文
○ 待收口
G-220缺口U08 治理与观测(支撑流程、埋点、后台配置、Risk Workbench)

登录历史对象与登录新鲜度未接入,四旋钮「可达性」实际未起作用

现象:四旋钮渠道分流的第一层是可达性(近 7 天登录即时 / 8–30 天普通 / >30 天转电销),输入为登录新鲜度;原脚本从 fact_usr_login_hist 读,但生产包里未接(login_recency=None),两批实测所有账户可达性 = 「未知」,渠道只按价值 / 紧急分流,失联户不会自动转电销。 已做:立 N090 登录历史、P266 登录新鲜度(天),策略引擎已预留输入。 要做:科技给登录事件的表 / 主键 / writer(fact_usr_login_hist 是数仓投影,源系统 writer 未定,见 Q1);数据侧把登录新鲜度并进对象层快照。
涉及:N090 登录历史P266 登录新鲜度(天)F-80A-39出处:S3 模型三层拆分 2026-09-21
登记原文登录新鲜度未接入,可达性分流失效
○ 待收口
G-221缺口U04 账单与账期、常规还款

两代账期在模型特征装配里写死,应改读产品参数

现象:score_s3_production._due_from_billing() 写死「账单日 25 号 → 次月 3 号还款,其余 +9 天」,用于算目标 Y 与还款日相关特征。科技 9/17 对 L250 / L251 的判定是:两代分流与具体日期都是 CoreProductCredit.virtualBillCycle / pmtDueDayCalcStrategy / pmtGracePrd 参数,固定源码只证「按参数加载」,值未核。 后果:参数一变(或 2025 前后分流口径与写死的近似不一致),模型的 Y 与科技的出账口径就分叉,而且没人知道。 要做:特征装配改读 ProductCredit / TM_PRM 的现网参数(与 Q8 同一机制);在 L250 / L251 参数核完前,模型包的这条近似要标「未核」。本条属模型层输入侧,不在三层拆分范围内,单独登。 [2026-09-23] L250 / L251 / L252 / L255 语句已参数化(只登结构与参数名,值退为历史样本);模型侧 _due_from_billing 仍写死,待改读 ProductCredit 参数。
涉及:L250L251L252L255F-77P239 账单日P241 本期还款日出处:S3 模型三层拆分 2026-09-21
登记原文两代账期写死在模型特征装配
○ 待收口
G-222缺口U04 账单与账期、常规还款

免费 B 层「先取名额再剔除 A 层重叠」,名额不等于实际人数

现象:原脚本 build_lists 先按 b_score 取 top b_free,再剔除已进付费 A 层的账户,所以免费层实际人数 < 名额(0601 批:名额 200、实到 88;0525 批:200 → 156)。运营给的名额从来没有被用满,而且用不满多少取决于 A/B 重叠度,不可控。 已做:策略行 B_FREE 增加 exclude_when 字段;v1 = after_rank(原样,证等价),v2 示例 = before_rank(先剔除再排名,0601 批实到 149 = 名额 149)。 要定:v2 是否采纳——采纳则免费层人数上升、首滑覆盖度变化需回测;这是策略变更,走策略发布不走改本体。
涉及:L411N089F-80P255出处:S3 模型三层拆分 2026-09-21
登记原文B 层名额≠实际人数(先取后剔)
○ 待收口

数据源:PayLater 产品知识库 2026-08-13 版 × 本体知识库说明书 v2 · 2026-08-17 全量重抽(9 单元并行判定+合并校验)· 冲突只登记不判断 · 「缺口」为按纲要三态纪律显式暴露的待补项;冲突登记不改写,结论在「缺口·冲突」页收口