本体登记表
知识库
全库 1033 个构件(2026-08-17 按说明书 v2 全量重抽),按纲要六类构件组织,规则=函数·规则型。(二期数据接地:对象 8/89 · 属性 83/273 · 关系 1/108,在详情页维护)
确认进度894/1033· 已确认=锁定,改前先解锁
这里不做判断,只记录结论:PM / 风控 / 后端把口径定下来之后,在对应条目上记一笔「定了什么、谁定的」。冲突记完可以顺手把说法错了的那条构件标成「待改」,提醒回去改。
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
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
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
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 接入渠道
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 积分账户
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）
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 单元并行判定+合并校验)· 冲突只登记不判断 · 「缺口」为按纲要三态纪律显式暴露的待补项;冲突登记不改写,结论在「缺口·冲突」页收口