BPOS-TMP-REPO/docs/数据域字段说明-W05.md

数据域字段说明 —— ACT-WORK-05 差异评估

对应设计中心 → 数据域「ACT-WORK-05 · 差异评估」分组。字段以活动清单的台账声明为准 (activities/part-substitution-assessment/src/manifest.ts 的 declarations.ledger); 主数据六张(customer.profile / parts.profile / parts.document / demand.request / substitution.relation + difference_item / validation.record)的物理结构由平台基线 apps/api/src/app/seed-mvp-data.ts 的 MASTER_OBJECTS 物化(字段名与《SS02-SS03-SS04_Demo 台账字段细化与统一方案》§4.2 一字不差),声明合并对基线是纯 add-column: 活动只追加自己要用的列与标记(required / tally / refersTo / requiredWhen / distinct), 不改基线已有列的语义。那份声明同时是授权面:没声明的列写不进去,也不会出现在件上、 判据里、数据域的活动分组里。

怎么读这份文档

• ★ = 重点字段。每张表挑 5–8 个,在「重点字段」小节里按重要程度从高到低排; 数据结构表里在列名后打 ★。
• 【人填】= 人在活动过程中亲手填、提交后入库的字段(执行工单 / 数据工单的件上编辑, 或数据录入卡)。这类字段一律进重点:它们是这一单里唯一不能靠 AI 补出来的事实。
• 「写入者」一栏的口径与「约束」一栏的词表,与 docs/数据域字段说明-E04-I01.md 「怎么读这份文档」是同一套,不重复抄一遍:人(件上)/ 人(录入卡)/ AI / 工具 / 基座 / 承继;主键 / 自增 / 必填 / 建议填 / 取值域 / 引用 / 去重计数 / 脱敏。 requiredWhen 类字段(某一列到某个值才必填)统一写「条件必填 · <字段>=<值> 时」—— 与 E04-I01 的「发布时必填」是同一种约束机制,ACT-WORK-05 的触发条件不止「发布」一种, 所以逐列写清条件,不套用那个专用词。
• ACT-WORK-05 比 E04/I01 多两种「写入者」写法,单列在这里:
  • AI(据人的意见改) —— S4 审核决策卡驳回、T_release 打回重做时,人写的是自然语言意见, 不是结构化字段值;基座按字面比对定位到哪一行,AI 照意见改那一行的具体列(同 PK 覆盖写), 意见本身不落进任何一张台账的某一列。
  • AI(抄自 input_gap.supplement) —— demand.request 的 application_scenario / bom_position 两列,人是在 sub_eval.input_gap 的「补充内容」列作答,S1 收口那一拍才由 AI 抄进 P-01;人没有直接编辑过 demand.request 本身。

一览

全景	台账地址	人读名	性质	本活动用到的列	人填列
L-02	customer.profile	客户档案	主数据 · 共享	4	3(录入卡,仅新客户)
P-08	parts.profile	芯片主数据	主数据 · 共享	12	12(数据工单件上)
P-10	parts.document	原厂技术资料库	主数据 · 共享	9	9(数据工单件上)
P-01	demand.request	客户需求主记录	主数据 · 共享	17	0(应用场景 / BOM 位经执行单由 AI 抄入)
P-11	substitution.relation	替代关系主记录	主数据 · 共享	17	0(只审不改)
P-11 子	substitution.difference_item	差异明细	主数据 · 共享	15	0
P-06	validation.record	芯片验证记录	主数据 · 共享	8	0(只写验证要求)
—	sub_eval.pn_check	料号存在性核对	本活动工作台账	6	0(决策卡定放弃)
—	sub_eval.input_gap	评估输入清单	本活动工作台账	8	3(补充内容 / 加行)
—	sub_eval.verdict	本次评估结论	本活动工作台账	14	0

九步(0.5 拆两项数据工单):绑定与存在性核对(S0_bind)→(等待数据:S0d_p08_master → S0d_p10_document,人)→ 人补评估输入(S1_input_confirm)→ 标准化对照表(S2_normalize)→ 逐项评估(S3_assess)→ 人审结论(S4_review,可循环)→ 拟落账(S5_prepare_landing)→ 人放行(T_release)。四道人环里 S0d_p08_master / S0d_p10_document / S1_input_confirm 三道 往台账里写下人亲手填的事实,S4_review / T_release 两道是审核与签字(人写意见,AI 据意见改台账)。

---

一、customer.profile 客户档案(L-02 · 共享主数据)

本活动平时不建这张表,只在客户不在库(启动入参 customerCode 在 customer.profile 里查无记录)那一刻代行建档职责:S0_bind 发一张数据录入卡,人核对名称与行业区域后确认。 除此之外整个活动流程里再不碰这张表。

重点字段(按重要程度)

1. customer_code ★ 主键 —— 值取自启动入参 customerCode,AI 不许自编;人在录入卡上核对确认,不是自由填写
2. name ★【人填】必填 —— 无名档案进不了正式表(与 E04 同一条墙);customerName 有给就 AI 预填,人核对
3. industry ★【人填】建议填 —— 所属行业,录入卡上从零填
4. region ★【人填】建议填 —— 区域,录入卡上从零填

数据结构

列名	人读名	类型	约束	写入者	说明
customer_code ★	客户编码	text	主键	AI(抄入参 customerCode)/ 人(录入卡确认)	老客户沿用,不经这张卡
name ★	客户名称	text	必填	AI 预填(customerName)/ 人(录入卡)	没传 customerName 就整格空着让人填
industry ★	所属行业	text	建议填	人(录入卡)
region ★	区域	text	建议填	人(录入卡)

---

二、parts.profile 芯片主数据(P-08 · 共享主数据)

一张表:料号一行,标准化参数集是它的一个字段(一行一参数 参数名 | 值 | 单位 | hard/soft | 说明,值是「未披露」的进 UNKNOWN)。库里按 internal_pn 查无记录 → 发数据工单,人在工作区的件上从零建整条(可加行);有上传 datasheet 就 AI 先按文本预填、人核对,没有就人全填;确认落草稿层,T_release 放行时才与其余表一起并入 正式版。

重点字段(按重要程度)

1. internal_pn ★【人填】主键 —— 全链路只认它,不可自由文本
2. normalized_parameter_set ★【人填】必填 —— 差异评估逐项比对的唯一输入;「未披露」进 UNKNOWN
3. lifecycle_status ★【人填】必填 · 取值域 active/nrnd/eol/discontinued/risk
4. package ★【人填】必填 —— 硬约束
5. specification_description ★【人填】必填
6. brand_name ★【人填】必填
7. datasheet_ref / datasheet_version ★【人填】建议填(成对)—— 证据回链

数据结构

列名	人读名	类型	约束	写入者	说明
internal_pn ★	内部料号	text	主键	人(件上)/ 种子	已在库的候选(如样例里预播的 LM2596S-5.0)不经这张单
brand_name ★	品牌名称	text	必填	人(件上)/ AI 预填
manufacturer_name	制造商名称	text	建议填	人(件上)	与品牌不一致时分开记
specification_description ★	规格描述	text	必填	人(件上)/ AI 预填
normalized_parameter_set ★	标准化参数集	text	必填	人(件上)/ AI 预填	一行一参数,不建子表
package ★	封装	text	必填	人(件上)/ AI 预填	硬约束
process_technology	工艺	text	建议填	人(件上)	硬约束
lifecycle_status ★	生命周期状态	text	必填 · 取值域	人(件上,下拉)
eol_pcn_status	EOL/PCN 状态	text	建议填	人(件上)
datasheet_ref ★	Datasheet 引用	text	建议填	人(件上)/ AI 预填
datasheet_version ★	Datasheet 版本	text	建议填	人(件上)/ AI 预填	有引用就该有版本
application_scenarios	适配应用场景	text	建议填	人(件上)

---

三、parts.document 原厂技术资料库(P-10 · 共享主数据)

按 internal_pn 查无资料记录 → 发数据工单(与 P-08 那张分开,一张表一张单, 在 P-08 那张确认之后再发);S0d_p08_master 那一步先写骨架(document_type / document_status / brand_name 三格能填就填),人在 P-10 数据工单的件上补齐其余列。 同一料号多份资料就多加几行,序号 01/02… 人自己续(不是自增列)。

重点字段(按重要程度)

1. document_ref ★【人填】必填 —— 资料文件链接,差异评估的证据引用要指到它
2. internal_pn ★【人填】主键之一 —— 关联料号,与 P-08 同一个内部料号
3. doc_seq ★【人填】主键之一 —— 同一料号下 01/02… 人自己续号
4. document_type ★【人填】必填 · 取值域 —— datasheet/app_note/reference_design/white_paper/sample_doc/commitment_letter/other
5. document_title ★【人填】必填
6. document_version ★【人填】必填
7. document_status ★【人填】必填 · 取值域 valid/expired/pending/void
8. citation_locator ★【人填】建议填 —— 页码 / 章节 / 表格,证据定位精确到这里

数据结构

列名	人读名	类型	约束	写入者	说明
internal_pn ★	关联内部料号	text	主键之一	人(件上)	与 P-08 那一行同一个键
doc_seq ★	资料序号(同一料号下 01/02…)	text	主键之一	人(件上)	不是自增列,人自己续号
document_type ★	资料类型	text	必填 · 取值域	AI 预填骨架(S0d_p08_master)/ 人(件上,下拉)
brand_name	品牌名称	text	建议填	AI 预填骨架 / 人(件上)
document_title ★	资料标题	text	必填	人(件上)
document_version ★	资料版本	text	必填	人(件上)
document_ref ★	资料文件链接	text	必填	人(件上)
citation_locator ★	证据定位(页码/章节/表格)	text	建议填	人(件上)
document_status ★	资料状态	text	必填 · 取值域	AI 预填骨架(pending)/ 人(件上,下拉)

---

四、demand.request 客户需求主记录(P-01 · 共享主数据)

S0_bind 新建 V1(客户 / 需求描述 / 原 PN 三项照入参原样落,启动时未收的 application_scenario / bom_position 先不写);S1_input_confirm 人在评估输入清单上把这两项的「补充内容」补上, AI 收口那一拍原样抄回本表;S5_prepare_landing 放行前回写风险等级 / 验证要求 / 输出链接 / 下一步动作 / 当前阶段五项(current_stage = "gate03" 那一刻这五项转为必填)。本表没有一列 是人直接编辑的——人的手笔经由 sub_eval.input_gap.supplement 间接进来。

重点字段(按重要程度)

1. request_id ★ 主键 —— 需求编号,与 eval_ref 用同一串时刻数字铸出
2. customer_code ★ 必填 · 引用 customer.profile.customer_code
3. request_description ★ 必填 —— 客户需求原话,S0 落一次,不许改写
4. original_internal_pn ★ 必填
5. application_scenario ★ 建议填 —— 启动时未收,人在评估输入清单补的「补充内容」由 AI 抄进这一格(本表唯一带着人手笔的两列之一)
6. bom_position ★ 建议填 —— 同上
7. risk_level ★ 条件必填 · current_stage=gate03 时 —— 放行回写五项之一,取各候选风险最高档
8. verification_requirement ★ 条件必填 · current_stage=gate03 时 —— 列出挂的验证任务号

数据结构

列名	人读名	类型	约束	写入者	说明
request_id ★	需求编号	text	主键	AI	REQ- + 案号数字串
customer_code ★	客户编码	text	必填 · 引用 customer.profile.customer_code	AI
requirement_version	需求版本	text	必填	AI	恒 V1
request_type	需求类型	text	必填	AI	恒「技术需求」
request_description ★	需求描述	text	必填	AI	入参原话,不改写
input_snapshot_ref	输入快照	text	必填	AI	SNAP- + 案号数字串
original_internal_pn ★	原内部料号	text	必填	AI
bom_position ★	BOM 位	text	建议填	AI(抄自 sub_eval.input_gap.supplement)	启动时未收
application_scenario ★	应用场景	text	建议填	AI(抄自 sub_eval.input_gap.supplement)	启动时未收
technical_constraints	技术约束	text	—	AI	人加的 input_gap 行汇总成一句
risk_level ★	风险等级	text	条件必填 · current_stage=gate03	AI	取各候选 risk_level 最高档
verification_requirement ★	验证/复测/确认要求	text	条件必填 · current_stage=gate03	AI	列出所有挂的 VAL 号
request_status	需求状态	text	必填 · 取值域	AI	pending → responded
current_activity	当前 Activity	text	条件必填 · current_stage=gate03	AI	恒 ACT-WORK-05
current_stage	当前阶段	text	—	AI	assessing → gate03
next_action	下一步动作	text	条件必填 · current_stage=gate03	AI	恒「提交 ACT-GATE-03 评审放行」
output_ref	标准输出链接	text	条件必填 · current_stage=gate03	AI	RPT- + 案号数字串

---

五、substitution.relation 替代关系主记录(P-11 · 共享主数据)

一个未放弃的候选一条:S2_normalize 写骨架(不含推荐/风险/摘要)、S3_assess 用两枚工具的 出参回填推荐等级与风险(AI 原样抄,不改一字)、S4_review 只审不改(人写意见,AI 据 意见改具体列)、S5_prepare_landing 把 analysis_status 推到 fae_confirmed。本活动没有 一列是人直接编辑的 —— 人的动作是通过 S4/T_release 的决策卡意见间接改台账。

重点字段(按重要程度)

1. substitution_relation_id ★ 主键
2. eval_ref ★ 必填 —— 本活动新增列(基线没有),评估案号,与 pn_check / verdict 同一个 eval_ref 串联全单
3. candidate_internal_pn ★ 必填 · 引用 parts.profile.internal_pn
4. original_internal_pn ★ 必填 · 引用 parts.profile.internal_pn
5. recommendation_level ★ 必填 · 取值域 recommended/conditional/alternate/not_recommended —— 工具算,AI 照抄不改一字
6. analysis_status ★ 必填 · 取值域 —— 分析层状态,S5 推到 fae_confirmed
7. risk_level ★ 必填 · 取值域 low/medium/high/critical —— 工具算
8. rule_version ★ 必填 —— 随结论落账,锁定 R-2026.07

数据结构

列名	人读名	类型	约束	写入者	说明
substitution_relation_id ★	替代关系ID	text	主键	AI	REL-<案号数字串>-01/02…
eval_ref ★	评估案号	text	必填	AI	本活动新增列(基线没有)
request_id	关联需求编号	text	必填	AI
bom_position	关联 BOM 位	text	建议填	AI	照 demand.request 现值抄
original_internal_pn ★	原内部料号	text	必填 · 引用 parts.profile.internal_pn	AI
candidate_internal_pn ★	候选内部料号	text	必填 · 引用 parts.profile.internal_pn	AI
substitution_type	替代类型	text	必填 · 取值域	AI	pin_to_pin/functional/parametric/other
recommendation_level ★	推荐等级	text	必填 · 取值域	工具(recommend)→ AI 照抄
recommendation_reason	推荐理由	text	必填	AI(可按人的驳回意见改)	工具 reason 扩写成人话
difference_summary	差异摘要	text	必填	AI	「7 项比对:4 MATCH / 1 MISMATCH / 1 UNKNOWN / 1 CONDITIONAL」句式
risk_level ★	替代风险等级	text	必填 · 取值域	工具(recommend)→ AI 照抄
verification_requirement	验证要求	text	条件必填 · recommendation_level=conditional	AI	列出 VAL 号
validation_id	关联验证ID	text	—	AI
analysis_status ★	分析状态	text	必填 · 取值域	AI	ai_draft → fae_confirmed(其余三档本活动不写)
analysis_report_ref	替代分析报告	text	建议填	AI	RPT-<案号数字串>
confidence_score	证据可信度	number	建议填	AI	取各行 confidence 最小值
rule_version ★	差异规则版本	text	必填	AI	锁定 R-2026.07

只读边界:基线在这张表上还建了 customer_approval_status / customer_approval_at / customer_approval_ref 三列,由独立审批流维护;本活动的声明里没有这三列的写权 (禁令 no-customer-approval-write)。落账确认那一屏那一格是静态文案 「未提交 · 由审批流程维护,本活动不产生」,不是可取值的 data-slot ——审批流做起来后才改成真读数(见 docs/debt.md)。

---

六、substitution.difference_item 差异明细(P-11 子表 · 共享主数据)

一条参数一条记录。S2_normalize 按原 PN 的参数集写骨架(不含四态/影响)、S3_assess 第一拍 调 compare-parameters 拿到四态与风险后原样抄回 difference_status / compare_result / risk_level,AI 自己只补写证据引用 / 影响说明 / UNKNOWN 去向;S4_review 驳回时人写的意见由 AI 定位到具体行后改 impact_statement / unknown_disposition / evidence_ref。 substitution_relation_id 标了 distinct,「几条关系已经有明细」就是数它的不同值数 (S2 收步、S3 收步都读这个数)。

重点字段(按重要程度)

1. substitution_relation_id ★ 主键之一 · 去重计数 —— 「几条关系已有明细」就是数它的不同值
2. difference_item_id ★ 主键之一
3. difference_status ★ 必填 · 取值域 match/mismatch/unknown/conditional —— 工具算,AI 原样抄
4. compare_result ★ 建议填 —— 本活动新增列(基线没有),工具出参原样存底,供复核
5. constraint_type ★ 必填 · 取值域 hard/soft —— 决定这一项差异判得严不严
6. evidence_ref ★ 必填 —— 证据引用,验收判据「证据链可信」逐行核对它
7. impact_statement ★ 必填 —— MATCH 写「无」,其余写清对应用 / 验证 / 报价的影响
8. unknown_disposition ★ 条件必填 · difference_status=unknown 时 —— 本活动新增列(基线没有),UNKNOWN 的去向(挂验证任务号 / 补来源动作)

数据结构

列名	人读名	类型	约束	写入者	说明
substitution_relation_id ★	替代关系ID	text	主键之一 · 去重计数	AI
difference_item_id ★	差异明细ID	text	主键之一	AI	<关系id>-P01/P02…
parameter_name	标准参数名	text	必填	AI
original_value	原物料参数值	text	必填	AI
candidate_value	候选物料参数值	text	必填	AI	候选没有这个参数写「未披露」
parameter_unit	参数单位	text	建议填	AI	以原 PN 为准
constraint_type ★	约束类型	text	必填 · 取值域	AI	原 PN 那一行的 hard/soft
compare_result ★	比对结果(工具出参)	text	建议填	工具(compare-parameters)→ AI 照抄	本活动新增列
difference_status ★	差异状态	text	必填 · 取值域	工具(compare-parameters)→ AI 照抄
impact_statement ★	影响说明(MATCH 写「无」)	text	必填	AI
unknown_disposition ★	UNKNOWN 去向(验证任务号 / 补来源动作)	text	条件必填 · difference_status=unknown	AI(可按人的驳回意见改)	本活动新增列
risk_level	风险等级	text	必填 · 取值域 low/medium/high	工具(compare-parameters)→ AI 照抄
evidence_ref ★	差异证据引用	text	必填	AI(可按人的驳回意见改)
confidence	AI 置信度	number	建议填	AI	0~1
rule_version	差异规则版本	text	必填	AI	锁定 R-2026.07

---

七、validation.record 芯片验证记录(P-06 · 共享主数据)

事实类表:本活动只在 S3_assess 给每个 UNKNOWN 差异项挂一行「验证要求」占位 (validation_status 恒写 not_started),不经数据工单建 —— 真正测完、写测试结果是 另一件事(下游活动或线下流程的事)。S4_review 驳回若要补验证任务,同样由 AI 加一行。

重点字段(按重要程度)

1. validation_id ★ 主键
2. validation_internal_pn ★ 必填 · 引用 parts.profile.internal_pn
3. validation_status ★ 必填 · 取值域 —— 本活动只写 not_started(占位待测)
4. next_validation_action ★ 必填 —— 要测什么、什么条件
5. validation_type ★ 必填 · 取值域
6. request_id ★ 必填 —— 关联需求编号

数据结构

列名	人读名	类型	约束	写入者	说明
validation_id ★	验证ID	text	主键	AI	VAL-<案号数字串>-01/02…
request_id ★	关联需求编号	text	必填	AI
validation_internal_pn ★	验证内部料号	text	必填 · 引用 parts.profile.internal_pn	AI	候选
validation_type ★	验证类型	text	必填 · 取值域	AI	恒 pin_to_pin(本活动只挂这一种)
validation_status ★	验证状态	text	必填 · 取值域	AI	恒 not_started
test_condition	测试条件	text	建议填	AI
next_validation_action ★	后续验证动作	text	必填	AI(可按人的驳回意见改)	要测什么、什么条件
evidence_ref	验证证据引用	text	建议填	AI

---

八、sub_eval.pn_check 料号存在性核对(本活动工作台账)

S0_bind 逐个料号(原 PN + 每个候选)在 parts.profile 里核对一遍写下的表:原 PN 一行、 候选各一行。exists_status 是这张表的核心结论 —— 两项数据工单的入场哨兵、S1 的入场哨兵 都读它。候选 ≥2 且不在库时,S0d_p08_master 发决策卡问放弃还是创建,人选的答案决定这一行 exists_status 改成 abandoned 还是等数据工单确认后改成 created。

重点字段(按重要程度)

1. exists_status ★ 必填 · 取值域 found/absent/created/abandoned —— 存在性检查的核心结论,S0d 两项与 S1 的入场哨兵都读它
2. internal_pn ★ 主键之一
3. eval_ref ★ 主键之一 —— 串联本单十张表的案号
4. role ★ 必填 · 取值域 original/candidate
5. abandon_reason ★ 条件必填 · exists_status=abandoned 时 —— 人在决策卡选放弃、没写理由时,AI 补写「负责人本轮放弃(未注明原因)」

数据结构

列名	人读名	类型	约束	写入者	说明
eval_ref ★	评估案号	text	主键之一	AI
internal_pn ★	内部料号	text	主键之一	AI
role ★	角色	text	必填 · 取值域	AI	original(恰一行)/ candidate
exists_status ★	在库状态	text	必填 · 取值域	AI	found(在库)→ 或 absent → created/abandoned(数据工单/决策卡确认后改)
abandon_reason	放弃原因	text	条件必填 · exists_status=abandoned	AI(据人的决策卡选项改)	人选放弃未写理由时 AI 补写默认句
note	备注	text	—	AI	如「PCN 转 NRND」

---

九、sub_eval.input_gap 评估输入清单(本活动工作台账)

S1_input_confirm 一拍写全:已绑定四项(status=ok)、待补两项(应用场景/BOM 位,status=gap)、 默认可改三项(status=default)、逐颗候选「未披露」参数各一行(status=gap)、齐备项(原 PN 资料 版本,status=ok)。这张表是本活动唯一让人直接在件上补内容的执行工单载体:人在 「补充内容」列把 status=gap 的行填上答案,也可以加一行补充 AI 没列出的资料项、删一行标 「不适用」。

重点字段(按重要程度)

1. supplement ★【人填】条件必填 · status=gap 时 —— 缺口行的答案,这一单里唯一不能靠 AI 补出来的事实
2. status ★ 必填 · 取值域 gap/default/ok —— 决定哪一行必须有 supplement
3. item_key ★【人填,加行时】主键之一 —— 英文短键;已绑定 / 待补 / 默认 / 待确认各占一批行
4. input_item ★【人填,加行时】必填 —— 人读名,加一行 = 补充 AI 没列出的资料项
5. origin ★ —— ai / human-added,标出哪几行是人加的(与 E04 candidate.origin 同一口径)
6. source_ledger ★ 建议填 —— 缺口来自哪张台账(P-01/P-08/P-09/P-10)

数据结构

列名	人读名	类型	约束	写入者	说明
eval_ref	评估案号	text	主键之一	AI
item_key ★	输入项键	text	主键之一	AI / 人(件上,加行时)	英文短键,如 application_scenario
input_item ★	输入项	text	必填	AI / 人(件上,加行时)	人读名
source_ledger ★	来源台账	text	建议填	AI
status ★	状态	text	必填 · 取值域	AI	gap(待补)/default(默认·可改)/ok(齐备)
detail	绑定值 / 缺口说明	text	建议填	AI
supplement ★	补充内容	text	条件必填 · status=gap	人(件上)	唯一的人手笔答案
origin ★	来源(ai/human-added)	text	—	AI

---

十、sub_eval.verdict 本次评估结论(本活动工作台账)

一单一行的收口结论,挂着几面「人环走到哪儿了」的记账旗 —— 它们是下一步能不能开工的哨兵 (与 E04 crm_coverage.verdict 同一种设计)。

重点字段(按重要程度)

1. input_confirmed_total ★ —— 评估输入已确认(人环凭据),S2 标准化那一步的入场哨兵之一
2. review_approved_total ★ —— 差异结论已审核通过(仅通过时置一),S5 拟落账那一步的入场哨兵
3. landing_prepared_total ★ —— 拟落账已备好,T_release 放行门的入场哨兵
4. summary ★ —— 本次评估结论,归档件上的那段话
5. relation_total ★ —— 替代关系条数
6. recommended_total / conditional_total / alternate_total / not_recommended_total ★ —— 四档分布,归档件摘要与放行口 assessment-released 载荷都用它

数据结构

列名	人读名	类型	约束	写入者	说明
eval_ref	评估案号	text	主键	AI
request_id	需求编号	text	—	AI
rule_version	规则版本	text	—	AI	锁定 R-2026.07
original_internal_pn	原内部料号	text	—	AI
candidate_total	候选数	integer	—	AI	候选数组长度
input_confirmed_total ★	评估输入已确认	integer	—	AI	人环凭据
review_approved_total ★	差异结论已审核通过	integer	—	AI	人环凭据(仅通过时置一)
landing_prepared_total ★	拟落账已备好	integer	—	AI	S5 写完时置一
relation_total ★	替代关系条数	integer	—	AI
recommended_total ★	推荐	integer	—	AI
conditional_total ★	条件推荐	integer	—	AI
alternate_total ★	备选	integer	—	AI
not_recommended_total ★	不推荐	integer	—	AI
summary ★	本次评估结论	text	—	AI	归档件上的那段话

---

十一、人填字段总表(按人办事的那一屏)

活动 · 屏	卡的形式	落进哪张表	人亲手填的列
S0_bind · 新客户建档(仅客户不在库)	数据录入卡(entry)	customer.profile	name · industry · region(customer_code 由入参给,人核对)
S0d_p08_master · 候选放弃/创建抉择(候选≥2 且部分缺库)	决策卡(decide)	间接改 sub_eval.pn_check.exists_status	选项值(create/abandon/custom:,不直接写字段)
S0d_p08_master · 数据工单·芯片主数据创建(P-08)	执行工单(件上编辑 + 增删行)	parts.profile	全部 12 列(internal_pn / brand_name / manufacturer_name / specification_description / normalized_parameter_set / package / process_technology / lifecycle_status / eol_pcn_status / datasheet_ref / datasheet_version / application_scenarios)
S0d_p10_document · 数据工单·原厂技术资料创建(P-10)	执行工单(件上编辑 + 增删行)	parts.document	全部 9 列(internal_pn / doc_seq / document_type / brand_name / document_title / document_version / document_ref / citation_locator / document_status)
S1_input_confirm · 评估输入与资料补齐确认	执行工单(件上编辑 + 增删行)	sub_eval.input_gap	supplement(缺口行必填);加一行时另填 item_key / input_item
S4_review · 差异评估结论审核	决策卡循环(通过 / 驳回 + 意见)	间接改 substitution.difference_item / substitution.relation / validation.record	意见文本(AI 据此改 evidence_ref / impact_statement / unknown_disposition / recommendation_reason;推荐等级不许改)
T_release · 评审放行与落账确认	验收工单(签字,可打回重做)	parts.profile / parts.document / demand.request / substitution.relation + difference_item / validation.record 并入正式版	裁决与意见(打回后 AI 按意见改台账本身,不开新行)

---

十二、在数据域里看这些表时的几条提醒

1. 主数据是共享的,物理表里还有别的用途留下的列,本活动不写它们:

   • customer.profile 还有 grade / owner / payment_terms / credit_limit / profile_tags / status(报价链早先声明的客户主台账列)
   • parts.profile 还有 customer_pn / pin_to_pin_relation_ref
   • parts.document 还有 document_date / source_contact_ref
   • demand.request 还有 project_code / bom_id / customer_pn
   • substitution.relation 还有 project_code,以及客户批准三列 + customer_feedback (见下条,单独说明只读边界)
   • validation.record 还有 customer_code / test_parameters / test_result / issue_risk / sample_version / sample_lot —— 本活动只写「验证要求」占位阶段, 不写实测结果(那是真验证发生后才有的事实)。

   记录浏览里看到它们空着是正常的;判断一列还算不算数,以活动清单的声明为准, 不以物理表结构为准。

2. 本活动往两张主数据表新增了列(基线没有,声明里 add-column 长出来的): substitution.relation.eval_ref(评估案号,串联本单十张表)与 substitution.difference_item.compare_result / unknown_disposition (工具出参原样存底、UNKNOWN 去向)。这三列只对 ACT-WORK-05 生效,不影响其它活动 对这两张表的读写。

3. customer_approval_status 是只读边界,不是本活动没做完:基线在 substitution.relation 上建了 customer_approval_status / customer_approval_at / customer_approval_ref 三列,由独立审批流维护;本活动的声明里没有这三列的写权 (禁令 no-customer-approval-write)。放行前那一屏那一格是静态文案 「未提交 · 由审批流程维护,本活动不产生」,不是取值的 data-slot(见 docs/debt.md)。

4. parts.profile 的标准化参数集是一个 text 列,不是子表:normalized_parameter_set 存的是一行一参数的行语法「参数名 | 值 | 单位 | hard/soft | 说明」,四态比对工具的入参 都靠解析这段文本,不是关系型的多行记录 —— 用户当场定的口径,《SS02-SS03-SS04》 字面上写的 Structure / 子表在本平台落成这样(见 docs/debt.md「参数集是 text 列的行语法」)。

5. 数据工单是零输入执行工单 + 工作区可加行的件:料号在 parts.profile / parts.document 里查无记录时,人从零建整条记录;确认落草稿层,T_release 放行那一刻 才与其余表一起并入正式版(平台铁律②:写只有草稿与意向,终局唯放行)。一张表一张单: P-08 一张、P-10 一张。

6. 试跑单默认也落真库:与 E04 / I01 同一个开关(sys.task.land_master,测试台起单 默认打开)—— 跑一遍活动,新建的客户档案、料号、资料记录都会真的进正式表;要它不落, 起单时显式关掉。

---

字段口径以 activities/part-substitution-assessment/src/manifest.ts 的 declarations.ledger 为准;六张主数据的物理结构见 apps/api/src/app/seed-mvp-data.ts 的 MASTER_OBJECTS;计划项与卡骨架见 activities/part-substitution-assessment/src/case-model.ts 的 ASSESSMENT_STEPS 与 NARRATIVE;业务设计源见 docs/SS02-ACT-WORK-05-html/ (活动流程与工单说明 / 一键启动入参说明)与《SS02-SS03-SS04_Demo台账字段细化与统一方案》。