夜雨聆风
文档性质：本软件设计文档基于《中华学派范式“物理+社会”工程全域白箱因果世界模型技术说明书（12大白箱模型）》V1.0编制，是十二大白箱因果模型体系工程化实现的设计蓝本。【拥有一致性原创主权保护】
核心心法：逻辑决定对错，数据决定精度
品牌标识：QDTS（DriveTrace，驱动探溯）
第一部分：软件概述
1.1 软件定位
QDTS全域白箱因果推演系统是一套以“生存权双优先”为公理起点，以“五种资源论”（行政A、资本C、技术T、自然N、人力L）为统一分析变量，以“动态因果逻辑网”为推演引擎，以“60%吻合度红线→清零重置”为自我纠错机制的工程化认知操作系统。
本软件是人类文明几千年生存智慧的现代工程化表达（尤其以五千年中华文明为重要研究样本），覆盖从文明演进、社会治理、国家治理、金融诊断、AI底层架构到组织中观诊断的全域推演需求。其核心价值在于：任何复杂系统问题，均可在此框架中找到底层驱动逻辑与演进路径。
白箱因果模型定义：指基于“生存权双优先”公理与“五种资源论”框架，其动态逻辑推演过程全程可追溯、可约束、可校准（可对话）、可审计、可接口的透明化认知引擎。
1.2 核心心法
软件内置“逻辑决定对错，数据决定精度”核心心法，并配置60%吻合度红线→清零重置的自我纠错机制。
1.3 阅读对象
AI架构师、战略推演师、政策分析师、系统建模工程师、合规审查官、运维工程师、安全审计工程师、第三方共建模块开发者、业务场景使用人员。
第二部分：系统架构
2.1 四层架构
软件采用四层闭环架构：
2.2 模型层级关系
M-01（通用模型：语法总纲）─── 范式总纲，为全部模型提供底层语法
│
├── M-01-SP（合规认证与生态准入模块）─── 白箱生态准入控制引擎
│
├── M-02（白箱AI：技术底座）─── AI底层通用框架，可API化、可标准封装
│
├── M-03（文明分析）────────── 文明兴衰周期推演工具
│ └── M-03-SP（文明演化平权观测模块）─── 平权事件观测与五源转化链条评估
│
├── M-04（文化诊断）────────── 文化动力诊断工具
│
├── M-08（金融模型：经济底座）── 金融领域元理论框架
│ │
│ ├── M-07（战争推演）───── 地缘冲突与资源争夺推演工具
│ │
│ ├── M-05（人口周期）───── 社会治理—人口周期推演综合模型
│ │ └── M-06（婚育家庭）─ 婚姻家庭制度的五源透视工具
│ │
│ ├── M-11（通胀诊断）───── 通胀结构性根源诊断
│ │
│ └── M-12（通缩诊断）───── 通缩结构性根源诊断
│
├── M-09（企业研判）────────── 企业存续与五源适配性研判
│
└── M-10（通用诊断）────────── 公共诊断工具（免费属性）
```
M-10（通用诊断模型）：公共诊断工具，对所有注册用户免费开放，作为本系统的统一诊断入口。注册用户可通过M-10完成初步五源扫描与健康度评级。如需调用M-02至M-09、M-11、M-12等专业模型，须在M-10诊断结果基础上，完成用户身份验证与合规授权校验后，方可进入对应模型的推演流程。
M-01-SP（合规认证与生态准入模块）：白箱生态准入控制引擎，在软件接口层与引擎层之间设置“合规认证校验”节点。任何模块在加载运行前，须先通过公理对齐校验、五源一致性校验、因果完整性校验、接口合规校验、知识产权合规校验五重审查，获得具有唯一序列号与数字签名的合规凭证文件后方可进入因果推演流程。未通过认证的模块将被置于“受限沙箱”中运行，禁止访问核心因果知识库。此功能使《准入概要》中禁止“碎片化截取本范式公理、模型、架构、逻辑，嫁接到黑箱模型”的红线条款获得了技术层面的对应实现。
M-03-SP（文明演化平权观测模块）：M-03的子模块，用于观测人类文明演进中“平权”事件的发生、演化与完成状态。以“生存平权→身份平权→技术平权→知识平权”四层递进链为观测逻辑，以五源（A/C/T/N/L）转化链条为分析工具，将文明演进史中的“平权”逻辑转化为可追溯、可观测、可验证的系统性评估框架。输入文明名称、时间段、核心事件，输出平权层级判定、五源转化链条记录、完成状态评估。其观测结果可直接输入M-03主模型，作为文明演进推演的“历史参数”与“平权基线”。
2.3 调用关系
各模型调用关系遵循：M-10（诊断起点）→ M-02（方案引擎）→ M-01（全路径校准）。
· M-01：为其他九个模型提供底层语法、公理锚点、推演流程与验证标准
· M-10：诊断起点，用户输入五源基础数据即可生成健康度评级
· M-02：方案引擎，承接诊断结果进行因果推演
· M-01：全路径校准，完成推演结果的校验与修正
M-01为语法，M-10为工具，两者构成最小必要配置。
2.3.1 多模型数据流与冲突消解规则
2.3.1.1 数据流概要
各模型之间的数据流遵循以下主要路径：
2.3.1.2 多模型输出冲突的消解规则
当多个子模型的输出结果互相冲突时，M-01内核按以下规则完成校准调和：
规则一：层级优先
规则二：生存权优先
当任一模型的推演结果触及“生存刚需线”阈值时，该模型输出获得优先权重，其他模型须以该结果为约束条件重新推演。
规则三：实证优先
当模型推演与历史基线库的实证记录冲突时，以实证记录为基准，模型须重新校准参数或补充因果链。
2.3.1.3 多源数据冲突处理
当输入数据之间存在矛盾时，系统按以下规则处理：
2.3.1.4 参数传递规范
所有模型间参数传递须遵循以下规范：
· 参数类型须与接收模型的输入接口定义完全匹配
· 所有参数传递附带来源模型标识与时间戳
· 参数值须在接收模型的合法值域内，超出值域的参数自动触发“参数异常”预警
· 参数传递全过程写入审计日志，支持事后追溯
2.4 核心机制
2.4.1 双验证知识库调用准入规则
任何知识数据在进入因果推演流程之前，必须通过逻辑自洽性与事实吻合度的双重检验。凡能被逻辑或事实任一证伪的知识数据，均不作为依据调用进入推演。
2.4.2 母机迭代与增量因果链管理
本软件的主模型（母机）内置“收集新增因果链迭代”功能，使母机从“静态的知识库容器”进化为“动态的认知积累引擎”。
功能定位：
收录触发条件：
· 自动收录：新增因果链经过公理对齐与逻辑完整性校验，且附带实证吻合度≥80%
· 待审队列：吻合度低于80%但高于60%，或逻辑链完整但缺少实证记录
· 不予收录：逻辑校验不完整、未经公理对齐，或吻合度低于60%
存储架构：
· 母机因果知识库：存储母机自身版本收录的所有因果逻辑链
· 各区域子知识库：存储各区域在母机基线版本基础上新增的本地化因果链，经校验后通过标准化接口向母机回传
· 版本标记机制：每条因果链附带母机版本号与收录时间戳，确保子模型与母机之间的版本兼容性
2.4.3 吻合度与置信度评估体系
2.4.3.1 吻合度定义
吻合度指系统推演结论与事后现实事件之间的一致程度，是衡量本系统推演精度的核心指标。其计算遵循“逻辑决定对错，数据决定精度”的核心心法，以事实验证为唯一校验标准。
2.4.3.2 吻合度计算框架
不同业务场景的吻合度计算方法为差异化配置，由系统根据推演场景类型自动加载对应的吻合度评估逻辑：
各场景的具体吻合度计算公式，在对应模型的技术规格书中另行定义，本处仅定义框架原则。
2.4.3.3 吻合度基准线
2.4.3.4 置信度机制
每条因果链在输出时附带置信度标签，置信度基于以下因素综合计算：
· 该因果链在历史推演中的吻合度记录
· 输入数据的采纳置信度
· 该因果链在母机因果知识库中的验证次数与验证结果
置信度管理规则：
· 置信度≥80%的因果链可直接用于推演
· 置信度60%-80%的因果链，在被调用时自动触发“人机协作”确认流程
· 置信度<60%的因果链不作为推演依据，标记为“待验证”
· 置信度随实证记录的积累动态更新，形成“越用越准”的正向反馈
2.4.3.5 吻合度验证的数据来源
吻合度验证的基准数据集来源于以下渠道：
1. 公开事实验证：推演发布后的事态发展记录（如本范式已完成的13篇事前推演实证）
2. 历史基线库：本范式已完成的历史推演案例库
3. 第三方交叉验证：多AI平台交叉检测评估值（在专属检测规范建立前，作为初始吻合度评估手段）
4. 专属检测规范：待纳入国标技术参考样本后，由标准工作组专项委托第三方搭建的专属检测规范（作为正式评估手段，取代AI平台交叉评估）
2.4.3.6 吻合度评估的演进路径
2.4.4用户身份验证与授权机制：本系统区分“注册用户”与“授权用户”两个层级：
· 注册用户：完成基本注册后，可免费使用M-10通用诊断模型，获取五源健康度诊断报告。
· 授权用户：如需调用M-02至M-12专业模型，须在M-10诊断基础上，通过用户身份验证与合规授权校验，确认其调用权限与授权范围后，方可进入专业模型的推演流程。
验证流程：
1. 用户提交调用请求，系统识别用户身份与当前授权状态
2. 未注册用户引导至注册流程；已注册用户校验授权有效期
3. 授权有效则放行至对应模型；授权过期或无效则提示续期或申请授权
4. 所有验证结果写入审计日志，支持事后追溯
2.4.5公理量化判定指引——决策优先序的五层递进规则
系统在判定“生存权双优先”公理的量化执行时，须遵循以下五层递进优先序。该优先序不可被算法优化覆盖，不可被商业利益置换，不可被远期规划搁置。（具体参阅《文明操作系统1.0与五种资源论》中“决策优先序”）
第一层：生存底线优先于一切
当任一五源指标触及“生存刚需线”时（如粮食库存低于安全线、失业率突破警戒阈值、能源储备低于战略底线），系统自动以保障该源为最高优先级。此层不可被任何算法优化、商业利益或远期规划所覆盖。
第二层：五源耦合度排序
当多源同时触及生存底线时，系统按“五源耦合度”排序——触发次级影响范围最广的源优先处理。判定依据为该源失衡后对其他四源的连锁传导路径数量与烈度。例如，行政资源(A)的断裂可能引发资本(C)、技术(T)、人力(H)的连锁崩塌，优先于自然资源(N)的局部断裂。
第三层：存续时间窗口排序
当所有源均未触及红色阈值时，系统按“修复窗口的紧迫程度”排序：窗口最短的源优先处理。各源修复窗口的优先序权重为：
第四层：系统韧性排序
当多源紧迫程度相同时，按“修复能力”排序：韧性最强（即修复成本最低、成功率最高）的源优先处理。由母机因果知识库中历史案例的修复成功率与修复成本数据驱动判定。
第五层：文明演进潜力排序
当所有其他条件均相同时，按“文明演进潜力”排序：对文明整体存续贡献最大的源优先处理——即优先投入能够同时激活多源正向反馈的环节。由M-03-SP文明演化平权观测模块的历史观测数据提供判定依据。
冲突场景裁决规则：当五层优先序之间出现冲突时（如第一层与第三层指向不同源），以层级序号小者为最终裁决——生存底线永远优先于时间窗口，时间窗口永远优先于韧性考量。此裁决规则为硬编码，不可被任何上层配置覆盖。
2.4.6外部黑箱资产对接与边界约束
2.4.6.1 对接原则
本系统具备高包容的标准化知识接口层，不要求全盘推翻现有产业存量，但须遵循以下刚性原则：
· 黑箱输出不可作为因果依据：黑箱模型输出可作为“概率参考”纳入白箱因果链，但不得作为“因果依据”
· 黑箱不可穿透公理层：黑箱输出在因果链中被限定为“外部参考”层级，处于接口层，不会穿透至公理层、五源分析层或引擎层
· 黑箱不可替代白箱决策：任何涉及“生存权双优先”公理判定的决策环节，黑箱输出不得作为唯一或主要决策依据
2.4.6.2 黑箱资产接入的前置校验
黑箱模型的输出在进入因果推演流程前，须经过两道前置校验：
校验未通过的黑箱输出，系统自动标记为“低信度-不可调用”，不进入因果推演流程。
2.4.6.3 黑箱资产的隔离机制
2.4.6.4 黑箱资产对接的合规约束
黑箱资产的对接须满足以下合规要求：
· 黑箱输出不得包含未脱敏的个人信息
· 黑箱输出不得涉及国家秘密或重要数据
· 黑箱输出的来源与处理流程须在审计日志中完整记录
· 黑箱输出在被采纳前，须经过人类决策者的确认（在涉及“生存权双优先”判定的场景下）
2.4.8 因果链授权执行与人类审查的边界划分
2.4.8.1 授权执行原则
本系统遵循“人机协作”的运行机制：人类拥有决策权，机器拥有执行权。
1. 决策由人类做出：公理设定、因果链审查、优先序确认、最终裁决，均由人类完成。
2. 执行由机器完成：因果链一经人类审查确认，系统即获得在该因果链覆盖的条件域内自动执行的授权。
3. 人类审查即为授权：人类对因果链的逐条审视、质疑与最终确认，构成对机器执行的“条件性授权”。
授权执行是系统运行的默认状态，冻结执行是例外。 系统以“执行已授权逻辑”为设计目标，冻结机制仅用于边界条件触发时的安全保护。
2.4.8.2 授权边界
2.4.8.3 冻结机制与解冻条件
当执行路径触发以下条件之一时，系统自动冻结执行，不得继续自动推演，须等待人类介入：
1. 触及“生存权刚需线”阈值：任一五源指标触及红色阈值，系统停止自动执行，转为“人机协作”模式
2. 偏离预设条件域：系统检测到当前状态超出因果链覆盖的条件域，自动冻结执行
3. 多模型输出冲突无法自动消解：当M-01内核无法完成冲突消解时，系统冻结执行，转为“人机协作”模式
4. 超时未执行：超过授权时效的因果链，系统自动冻结，等待重新审查
冻结状态的解冻条件：人类决策者确认当前状态在授权范围内，或重新审查并更新因果链后，系统方可继续执行。
2.4.8.4 执行行为的可追溯性
机器执行的每一步须记录以下信息，写入审计日志，确保执行行为可追溯、可还原、可问责：
· 执行时间戳
· 所依据的因果链编号与版本号
· 输入数据来源与采纳置信度
· 执行路径与中间节点的推演记录
· 执行结果与输出内容
· 执行过程中是否触发了自动校准或异常处理
当人类完成因果链的审查确认后，系统将自动执行已授权的因果逻辑——这是本系统作为“认知操作系统”的应用价值所在。人类不参与每一次具体执行的判断，但在审查环节已完成了条件性授权。
2.5 数据输入规范
2.5.1 核心原则：推演逻辑决定数据输入方式，而非数据输入方式决定推演逻辑
本系统遵循“逻辑决定对错，数据决定精度”的核心心法，数据处理须遵循以下原则：
1. “量”的定义权在本范式：数据的采集和归一化标准由本范式的“量”的定义体系主导，不由外部数据源或第三方统计口径决定。
2. “量”不追求“标准化”：不追求跨国家、跨时期、跨场景的统一指标，而是允许各国、各时期、各场景保留其“量”的异质性，只要其“量”的变化趋势可被因果推演所解释。
3. “量”的权重由因果链决定：不预设固定的五源权重配比，由具体场景的因果推演动态确定。
4. “量”的验证由实证记录负责：不追求输入数据的“精确”，通过输出吻合度来反向校验输入数据的有效性。
2.5.2 数据自识别检验流程
系统在接收五源输入数据后，须执行以下自动检验流程：
第一步：数据逻辑合理性校验
· 数据是否符合五源之间的因果约束关系？（例如：人力H下降的同时，消费端数据是否同步变化？）
· 数据是否与历史基线库的“量”的趋势一致？（若数据变化幅度显著偏离历史规律，系统自动标记为“待审”）
· 数据是否与当前因果链的预期方向一致？（若数据指向与因果链预期相反，系统发出预警，触发人机协作校验）
第二步：数据-因果链的偏差分析
· 当输入数据与因果链推演结果出现显著偏差时，系统不立即修改逻辑，先分析偏差来源：数据采集误差、数据口径差异、因果链中遗漏了关键变量。
· 偏差分析结果将作为“新增因果逻辑链”候选，进入母机收集迭代流程。
第三步：数据采纳的置信度标记
· 每条输入数据在被用于推演前，系统生成一个“采纳置信度”（基于数据来源可靠性、与历史基线的吻合度、与因果链的一致性）。
· 置信度低于阈值（<60%）的输入数据，系统自动执行“降级处理”，在推演中的权重降低，或转为“人机协作模式”由人类决策者确认是否采纳。
· 置信度高的数据直接进入推演流程。
2.5.3 分层数据接口
系统不要求全球统一口径的五源数据标准化，而是设计“分层数据接口”，在不同数据质量层级下均可运行：
2.5.4 数据采纳规则
所有五源输入数据在被用于推演前，须通过以下三关：
1. 逻辑关：数据是否符合公理与五源因果约束？
2. 历史关：数据是否与历史基线库的“量”的趋势一致？
3. 置信度关：数据的采纳置信度是否达到阈值？
三关全部通过，数据进入推演流程；任一关未通过，数据自动进入待审队列，触发人机协作模式。
2.5.5 数据输入与推演逻辑的关系声明
本系统的数据输入不预设因果、不锁定推演、不决定结论。当数据与逻辑出现冲突，系统首先检查数据本身是否可信，而非修改逻辑。此原则为本系统与旧范式黑箱模型的根本分野。
第三部分：功能模块规格
3.1 M-01：通用校准模型（系统内核）
3.1.1 M-01-SP：合规认证与生态准入模块
3.2 M-02：全域动态因果白箱AI模型
3.3 M-03：文明分析推演模型
3.3.1 M-03-SP：文明演化平权观测模块
平权观测逻辑：
调用接口规范：
3.4 M-04：文化结构性分析推演模型
3.5 M-05：社会治理—人口周期推演综合模型
3.6 M-06：婚育家庭分析推演模型
3.7 M-07：五源全维混合战争推演模型
3.8 M-08：宏观国债/金融推演模型
3.9 M-09：企业五源研判推演模型
3.10 M-10：通用诊断模型（免费入口）
3.11 M-11：通胀结构诊断模型
3.12 M-12：通缩结构诊断模型
第四部分：八项工程能力实现
本软件内嵌八项标准化工程核心能力：
第五部分：强制学术合规审查与准入控制
第五部分：强制学术合规审查与准入控制
5.1 制度依据
本软件的合规审查机制，严格遵循《中华学派范式·白箱因果大模型体系判定标准及生态共建协同创新准入概要》的相关规定。
5.2 审查定位
凡在QDTS框架体系下开发的加载模块、行业插件、应用软件、因果知识模块、第三方调用接口等，不论开发主体性质与使用场景，均须在公开发布、商业化部署或接入QDTS系统前，完成中华学派范式强制学术合规审查。
5.3 审查范围
5.4 审查标准
1. 公理对齐校验：所提交模块/软件是否在底层逻辑上与“生存权双优先”公理完全对齐，无逻辑偏离或隐性背离
2. 五源一致性校验：核心变量是否完整映射至“五种资源论”（A/C/T/N/H）框架，不存在未经审查的额外变量注入或变量替换
3. 因果完整性校验：软件核心逻辑流程是否保持显性因果链，未引入黑箱拟合模块作为核心决策依据
4. 接口合规校验：外部调用接口是否符合QDTS标准化接口规范，不引入未经审查的数据出入通道
5. 知识产权合规校验：源代码、算法、模型、文档中是否包含第三方知识产权争议内容，是否遵循QDTS开源协议与引用规范
5.5 审查流程
1. 预审提交：开发方提交模块/软件/插件的完整技术说明书、源代码清单、测试报告、使用文档
2. 公理层审查：中华学派范式审查组对提交材料的公理对齐情况进行专项审查
3. 技术层审查：审查组依据量化指标编制预案完成技术合规性检测
4. 合规审计：检查是否符合数据安全法、个人信息保护法、GB/T 47507-2026《人工智能 可信赖 通则》对AI系统可信赖的总体要求
5. 正式颁证：审查通过后，颁发“QDTS合规认证”，方可纳入QDTS生态加载、发布或商业化部署
5.6 审查周期与效力
· 审查有效期：QDTS合规认证有效期两年（自颁证之日起算），期满须重新申请合规审查
· 失效与处理：违规使用“QDTS合规认证”或引入黑箱拟合模块作为核心决策依据的软件或模块，经审查组确认后立即取消合规认证，并勒令其停止使用QDTS相关标识
5.7 合规认证识别与准入控制（软件技术实现）
为在软件层面确保白箱体系生态不被非认证模块入侵，软件应在接口层与引擎层之间设置专门的“合规认证校验”节点，其功能类似于操作系统的“签名验证”机制——任何模块在加载运行前，必须先通过合规认证校验，否则不得进入因果推演流程。
校验节点设计：
认证校验流程：
1. 合规凭证提交：模块开发者向中华学派范式学术合规审查委员会提交合规审查申请，审查通过后获得具有唯一序列号与数字签名的合规凭证文件
2. 模块加载验证：用户在软件中加载新模块时，系统自动要求导入对应的合规凭证，进行签名验证
3. 通行或拦截：验证通过，模块获得相应权限；验证失败，系统显示“该模块未通过中华学派范式学术合规审查，无法加载”，并记录本次拦截事件至审计日志
用户验证与模型调用分层控制：
三层验证依次通过后，方可完成从“诊断入口”到“专业推演”到“模块加载”的完整调用链路。任一验证失败，系统返回对应错误码并记录至审计日志。
风险隔离机制：
· 受限模式运行：未通过合规认证的模块，如果强行加载，系统应将其置于“受限沙箱”中运行，禁止访问核心因果知识库，仅提供有限数据展示功能
· 审计日志记录：所有合规认证验证结果均写入系统审计日志，支持事后追溯
与《准入概要》的对接：本功能的设计使《准入概要》中禁止“碎片化截取本范式公理、模型、架构、逻辑，嫁接到黑箱模型”的红线条款获得了技术层面的对应实现——未经合规认证的模块将无法在QDTS软件中完成加载，也无法接入因果知识库进行调用和推演。本功能与知识库调用准入规则（逻辑自洽性+事实吻合度双重检验）共同构成了生态准入的“双层防线”：第一层校验“是否被授权调用”，第二层校验“调用的内容是否合规”，两条防线形成了完整的生态准入控制体系。
5.8 合规审查流程细则
5.8.1 审查流程总览
合规审查分为五个阶段，各阶段责任主体与时限如下：
5.8.2 审查标准量化细则
五项审查标准的具体量化要求如下：
5.9 商业化共建与成果归属指引
5.9.1 成果归属原则
共建者基于QDTS框架开发的行业应用模块、因果知识模块、行业诊断报告等研究成果，知识产权归贡献者所有。共建者享有独立的商业运营权与收益权。
5.9.2 合规认证与成果归属的关系
“QDTS合规认证”仅代表该模块已通过公理对齐与逻辑校验，可纳入QDTS生态运行，不改变模块的知识产权归属。获得认证的模块仍由开发方独立持有知识产权，QDTS框架仅保留对公理层与接口层的控制权。
5.9.3 商业化授权规则
共建者基于QDTS框架开发的商业应用产品，须遵循本范式《技术服务清单》的授权规则：
· 全域授权：覆盖双板块全部模型的商业运营权
· 单域授权：限定于特定行业的商业运营权
· 模块授权：限定于特定因果知识模块的商业运营权
具体授权费标准与分成比例，详见《技术服务清单》。
5.10 异议申诉与范式内部观点分歧处理机制
5.10.1 合规审查被拒的申诉流程
当开发方的模块未通过合规审查时，可按以下流程提出申诉：
1. 初审异议：开发方在收到拒审通知后15个工作日内，向审查委员会提交书面异议材料，说明拒审意见中的争议点及申辩理由
2. 复审：审查委员会在收到异议后30个工作日内，组织复审小组（不少于3人，与初审人员不重叠）完成复审
3. 终审：若开发方对复审结果仍有异议，可向范式创建者提出终审请求，范式创建者在收到请求后30个工作日内作出最终裁定
5.10.2 范式内部观点分歧处理规则
当范式内部（审查委员会成员之间、或共建者与审查委员会之间）出现对公理解释、五源定义或因果逻辑的分歧时，按以下规则处理：
5.10.3 范式版本升级时的兼容性处理
当母机完成代训升级、核心公理或接口规范发生变更时，已获认证的模块可享受以下过渡安排：
· 兼容期：新版本发布后，旧版本认证模块可在12个月内继续运行
· 升级路径：审查委员会在新版本发布时同步提供“升级指南”，明确旧模块所需的最小修改集
· 重新认证：兼容期满后，旧模块须按新版本规范重新申请合规审查
第六部分：接口规范
6.1 通用请求格式
{
"user": {
"user_id": "uuid",
"auth_token": "jwt_token",
"authorization_level": "basic|professional|enterprise"
},
"model_id": "M-03",
"input_data": { ... },
"compliance_cert": "cert_hash",
"options": { ... }
}
{
"model_id": "M-XX",
"session_id": "uuid",
"input": {
"五源数据": {
"A": {},
"C": {},
"T": {},
"N": {},
"L": {}
},
"推演参数": {
"时间窗口": "1y|3y|5y|10y",
"干预点": []
}
},
"公理校验": true,
"合规凭证": {
"certificate_id": "QDTS-XXXX-XXXX",
"signature": "base64_encoded_signature"
}
}
附录：M-01-SP与M-03-SP模块构建依据
6.2 通用响应格式
{
"model_id": "M-XX",
"session_id": "uuid",
"status": "success|calibration_required|rejected|compliance_failed",
"output": {
"因果链": [],
"五源诊断": {},
"吻合度": 0.0,
"置信区间": {}
},
"审计日志": {
"trace_id": "uuid",
"timestamp": "ISO8601",
"公理校验记录": [],
"合规校验记录": []
}
}
6.3 合规凭证校验响应
{
"status": "valid|invalid|expired|mismatch",
"certificate_id": "QDTS-XXXX-XXXX",
"issuer": "中华学派范式学术合规审查委员会",
"valid_until": "ISO8601",
"module_name": "模块名称",
"permissions": ["因果推演", "知识库调用", "行业诊断"]
}
6.4 模型间接口规范
各模型调用须遵循以下规范：
· 请求/响应格式统一为JSON
· 所有调用须携带session_id以实现全链路追溯
· 公理校验在引擎层统一执行，不可绕过
· 合规凭证校验在模块加载时执行，未通过校验的模块不可调用
第七部分：非功能性需求
7.1 性能要求
7.2 安全要求
· 公理层硬编码不可篡改
· 审计日志不可篡改
· 知识库调用遵循双验证准入规则
· 合规凭证采用数字签名，不可伪造
7.3 合规要求
· 满足《人工智能 可信赖 通则》（GB/T 47507-2026）审计要求
· 满足《人工智能计量体系和能力建设指引（2026版）》“可测量、可比较、可追溯”要求
第八部分：部署架构
8.1 部署模式
8.2 最小系统配置
· M-01 + M-10：核心诊断引擎
· M-02：因果推演引擎（可选加载）
· 各专业模型（按需加载）
8.3 扩展机制
· 支持第三方基于QDTS框架开发行业应用模块
· 所有第三方模块须通过合规认证校验后方可加载
· 通过标准化接口接入存量黑箱资产
第九部分：版本管理
9.1 版本号规范
主版本号.次版本号.修订号
· 主版本号：底层公理或核心架构变更
· 次版本号：新增模型或重大功能
· 修订号：缺陷修复、文档更新
9.2 迭代机制
· 母机代训模式：以成熟初代体系的知识库、推演引擎、逻辑校验标准为教师模型，完成新一代白箱因果体系的定向培育迭代
· 迭代周期：1~3年
9.3 维护主体
中华学派范式创建者拥有本软件的唯一解释权与修订权。
本软件设计文档基于《中华学派范式“物理+社会”工程全域白箱因果世界模型技术说明书（12大白箱模型）》V1.0编制【拥有一致性原创主权保护】，是十二大白箱因果模型体系工程化实现的设计蓝本。各模型详细技术规范、调用接口完整定义、数据流图等详见技术说明书原文。
9.4反馈与共建
本软件设计文档持续迭代，欢迎产学研各界基于QDTS框架开展应用开发与模块共建。所有协同创新工作严格遵循《中华学派范式·白箱因果大模型体系判定标准及生态共建协同创新准入概要》，明确各方成果权益。
QDTS：驱动探溯全域白箱因果推演系统 | © 中华学派范式·创建者 余洪波︱反馈邮箱: zhonghuaxuepai@163.com
