第229章 ICAI认知数据表

229.1 认知数据层的定位

第228章建立了 ICAI 的核心事实数据层：

individuals
objects
attributes
states
relations
scenes

这一层主要回答：

系统当前有什么、是什么状态、对象之间有什么关系、处于什么场景。

第229章进一步进入认知数据层。

认知数据层负责描述：

Knowledge
Need
Goal
Capability
Method
Decision

因此：

$CognitiveData=Knowledge+Need+Goal+Capability+Method+DecisionCognitiveData= Knowledge+ Need+ Goal+ Capability+ Method+ Decision$

其基本认知链为：

Knowledge
   ↓
Need
   ↓
Goal
   ↓
Capability
   ↓
Method
   ↓
Decision

但是，这并不是简单的数据传递。

实际过程是：

事实
 ↓
知识
 ↓
需求
 ↓
目标
 ↓
能力匹配
 ↓
方法候选
 ↓
决策

最终进入：

Behavior
 ↓
Action
 ↓
Execution

所以第229章的数据表实际上是连接基础事实层与行为执行层的中间认知数据层。

229.2 六类认知Domain的区别

六类数据必须严格区分。

Knowledge

回答：

知道什么？

Need

回答：

为什么需要？

Goal

回答：

希望最终达到什么可验证状态？

Capability

回答：

有没有能力完成？

Method

回答：

可以怎么完成？

Decision

回答：

现在选择哪个方案？

因此：

$Knowledge≠NeedKnowledge\neq Need$ $Need≠GoalNeed\neq Goal$ $Goal≠CapabilityGoal\neq Capability$ $Capability≠MethodCapability\neq Method$ $Method≠DecisionMethod\neq Decision$

这六类数据不能因为数据库结构相近而合并为一张表。

229.3 Domain与数据库的映射原则

本章所有认知数据都遵循：

Domain Object
      ↓
Mapper
      ↓
Persistence Data
      ↓
Repository
      ↓
PDO
      ↓
MySQL

读取：

MySQL
   ↓
PDO
   ↓
Repository
   ↓
Mapper
   ↓
Domain Object

因此：

$DomainObject≠DatabaseRowDomainObject\neq DatabaseRow$

同时：

$DomainID≠PersistenceIDDomainID\neq PersistenceID$

例如：

Domain:
K-001

MySQL:
id = 17
knowledge_code = K-001

17 是数据库主键，K-001 是 Domain 层业务标识。

229.4 knowledge——知识核心表

Knowledge 是 ICAI 认知系统中的结构化知识对象。

第174章和第191章定义：

$K=(S,P,O,C,St)K=(S,P,O,C,S_t)$

其中：

$SS$ ：Subject，主体
$PP$ ：Predicate，谓词
$OO$ ：Object，客体
$CC$ ：Condition，条件
$StS_t$ ：State，知识状态

例如：

Object-A
   supports
Method-M1

可以表示：

$K=(ObjectA,supports,MethodM1,C,St)K=(ObjectA,supports,MethodM1,C,S_t)$

Knowledge不是文章，不是自然语言段落，也不是数据库中的一条普通文本记录。

它是可被 KnowledgeEngine 计算、匹配、验证和更新的结构化认知数据。

229.5 knowledge表设计

CREATE TABLE knowledge (
    id BIGINT NOT NULL AUTO_INCREMENT,
    knowledge_code VARCHAR(100) NOT NULL,
    subject_type VARCHAR(100) NOT NULL,
    subject_id VARCHAR(100) NOT NULL,
    predicate VARCHAR(100) NOT NULL,
    object_type VARCHAR(100) NULL,
    object_id VARCHAR(100) NULL,
    object_value TEXT NULL,
    condition_data TEXT NULL,
    state VARCHAR(50) NOT NULL,
    evidence TEXT NULL,
    knowledge_time DATETIME NULL,
    created_at DATETIME NOT NULL,
    updated_at DATETIME NOT NULL,
    PRIMARY KEY (id),
    UNIQUE KEY uk_knowledge_code (knowledge_code),
    KEY idx_knowledge_subject (subject_type, subject_id),
    KEY idx_knowledge_predicate (predicate),
    KEY idx_knowledge_object (object_type, object_id),
    KEY idx_knowledge_state (state)
);

这里没有把 subject、predicate、object 全部压缩到一个 JSON 字段中。

因为 KnowledgeEngine 后续需要进行：

Subject匹配
Predicate匹配
Object匹配
Condition判断
State判断

因此基础字段应该保持可查询结构。

229.6 Knowledge状态

Knowledge不能简单使用：

exists / not_exists

至少应该区分：

candidate
valid
verified
unverified
outdated
invalid
conflicted
archived

因此：

$Exists≠ValidExists\neq Valid$ $Valid≠VerifiedValid\neq Verified$

一条知识存在于数据库中，不代表它已经经过验证。

229.7 Knowledge Evidence

知识更新必须具有证据。

可以建立：

CREATE TABLE knowledge_evidence (
    id BIGINT NOT NULL AUTO_INCREMENT,
    evidence_code VARCHAR(100) NOT NULL,
    knowledge_code VARCHAR(100) NOT NULL,
    source_type VARCHAR(100) NOT NULL,
    source_id VARCHAR(100) NULL,
    evidence_type VARCHAR(100) NULL,
    evidence_value TEXT NULL,
    evidence_time DATETIME NULL,
    created_at DATETIME NOT NULL,
    PRIMARY KEY (id),
    UNIQUE KEY uk_knowledge_evidence_code (evidence_code),
    KEY idx_knowledge_evidence_knowledge (knowledge_code)
);

形成：

Knowledge
    ↓
Evidence
    ↓
Verification
    ↓
Valid Knowledge

229.8 needs——需求核心表

Need是认知过程的重要起点。

Need回答：

为什么需要某个目标或行为？

Need与Goal不能混合。

例如：

Need:
需要处理订单

并不等于：

Goal:
订单状态必须变为 completed

因此：

$Need≠GoalNeed\neq Goal$

Need是需求来源，Goal是可验证的目标结构。

229.9 Need模型

可以定义：

$N=(ID,T,C,P,S)N=(ID,T,C,P,S)$

其中：

$IDID$ ：Need标识
$TT$ ：Need类型
$CC$ ：Need条件
$PP$ ：Priority，优先级
$SS$ ：Need状态

例如：

N-001
type = process
condition = order_received
priority = high
state = active

229.10 needs表

CREATE TABLE needs (
    id BIGINT NOT NULL AUTO_INCREMENT,
    need_code VARCHAR(100) NOT NULL,
    individual_id BIGINT NOT NULL,
    need_type VARCHAR(100) NOT NULL,
    description TEXT NULL,
    condition_data TEXT NULL,
    priority INT NOT NULL DEFAULT 0,
    state VARCHAR(50) NOT NULL,
    source_type VARCHAR(100) NULL,
    source_id VARCHAR(100) NULL,
    created_at DATETIME NOT NULL,
    updated_at DATETIME NOT NULL,
    PRIMARY KEY (id),
    UNIQUE KEY uk_need_code (need_code),
    KEY idx_need_individual (individual_id),
    KEY idx_need_type (need_type),
    KEY idx_need_state (state),
    KEY idx_need_priority (priority)
);

Need通常属于某个 Individual。

因此：

Individual
    ↓
Need

一个 Individual 可以具有多个 Need。

229.11 Need的生命周期

Need可以经历：

created
   ↓
pending
   ↓
active
   ↓
converted
   ↓
completed

也可能：

active
   ↓
cancelled

或者：

active
   ↓
expired

其中 converted 表示：

Need
 ↓
Goal Candidate

已经形成目标。

229.12 Need与Goal关系

Need与Goal之间不是一对一强制关系。

一个 Need 可以产生多个 Goal Candidate：

Need N-001
     ↓
 ┌───┼────┐
 ↓   ↓    ↓
G1  G2    G3

随后 GoalEngine 根据条件、优先级和规则形成可执行 Goal。

因此数据库应该建立关联：

CREATE TABLE need_goal_relations (
    id BIGINT NOT NULL AUTO_INCREMENT,
    relation_code VARCHAR(100) NOT NULL,
    need_code VARCHAR(100) NOT NULL,
    goal_code VARCHAR(100) NOT NULL,
    relation_type VARCHAR(100) NOT NULL,
    state VARCHAR(50) NOT NULL,
    created_at DATETIME NOT NULL,
    PRIMARY KEY (id),
    UNIQUE KEY uk_need_goal_relation_code (relation_code),
    KEY idx_need_goal_need (need_code),
    KEY idx_need_goal_goal (goal_code)
);

这样不会把 Need 与 Goal 强行合并。

229.13 goals——目标核心表

Goal定义为：

$G=(ID,N,T,C,P,S)G=(ID,N,T,C,P,S)$

其中：

$IDID$ ：Goal标识
$NN$ ：Goal名称
$TT$ ：Goal类型
$CC$ ：Goal条件
$PP$ ：Priority
$SS$ ：Goal状态

Goal必须能够最终验证。

因此：

$GoalCompleted=Result+VerificationGoalCompleted=Result+Verification$

仅仅执行某个行为，并不能证明 Goal 已完成。

229.14 goals表设计

CREATE TABLE goals (
    id BIGINT NOT NULL AUTO_INCREMENT,
    goal_code VARCHAR(100) NOT NULL,
    individual_id BIGINT NOT NULL,
    need_code VARCHAR(100) NULL,
    goal_name VARCHAR(255) NOT NULL,
    goal_type VARCHAR(100) NOT NULL,
    target_type VARCHAR(100) NULL,
    target_id VARCHAR(100) NULL,
    condition_data TEXT NULL,
    priority INT NOT NULL DEFAULT 0,
    state VARCHAR(50) NOT NULL,
    created_at DATETIME NOT NULL,
    updated_at DATETIME NOT NULL,
    PRIMARY KEY (id),
    UNIQUE KEY uk_goal_code (goal_code),
    KEY idx_goal_individual (individual_id),
    KEY idx_goal_need (need_code),
    KEY idx_goal_type (goal_type),
    KEY idx_goal_state (state),
    KEY idx_goal_priority (priority)
);

Goal与Need通过：

need_code

关联。

229.15 Goal状态

Goal至少可以具有：

created
pending
active
paused
blocked
completed
failed
cancelled
expired

特别需要区分：

blocked
failed
completed

三者完全不同。

blocked

当前无法继续。

failed

已经执行但没有达到预期。

completed

实际结果已经满足目标，并且完成验证。

因此：

$Failed≠BlockedFailed\neq Blocked$ $Completed≠ExecutedCompleted\neq Executed$

229.16 capabilities——能力核心表

Capability回答：

当前有没有能力完成这个目标或执行这个方法？

能力模型：

$C=(T,Co,S,R,V)C=(T,Co,S,R,V)$

其中：

$TT$ ：能力类型
$CoCo$ ：能力条件
$SS$ ：能力状态
$RR$ ：能力范围
$VV$ ：能力验证

229.17 capabilities表设计

CREATE TABLE capabilities (
    id BIGINT NOT NULL AUTO_INCREMENT,
    capability_code VARCHAR(100) NOT NULL,
    individual_id BIGINT NOT NULL,
    capability_type VARCHAR(100) NOT NULL,
    condition_data TEXT NULL,
    state VARCHAR(50) NOT NULL,
    range_min DECIMAL(20,6) NULL,
    range_max DECIMAL(20,6) NULL,
    range_unit VARCHAR(50) NULL,
    range_scope VARCHAR(255) NULL,
    verification_data TEXT NULL,
    created_at DATETIME NOT NULL,
    updated_at DATETIME NOT NULL,
    PRIMARY KEY (id),
    UNIQUE KEY uk_capability_code (capability_code),
    KEY idx_capability_individual (individual_id),
    KEY idx_capability_type (capability_type),
    KEY idx_capability_state (state)
);

229.18 Capability的几个状态层级

Capability必须区分：

Exists
Available
Matched
Verified

例如：

Capability C-001 存在

只说明数据库中有该能力。

如果：

state = available

说明当前可用。

如果：

Goal + Capability

通过 MatchingEngine 检查，才是：

Matched

如果经过实际执行和验证，则：

Verified

所以：

$Exists≠Available≠Matched≠VerifiedExists \neq Available \neq Matched \neq Verified$

229.19 Capability条件与范围

能力不能只保存：

capability_type

还必须保存：

condition
range
state
verification

例如：

Capability:
process_object

Condition:
resource >= 2

Range:
0 - 100

State:
available

表示：

只有 Resource ≥ 2，并且当前状态允许时，该能力才处于可用条件。

因此：

$CapabilityAvailable=Type∧Condition∧State∧RangeCapabilityAvailable = Type \land Condition \land State \land Range$

验证后：

$CapabilityVerified=CapabilityAvailable∧VerificationCapabilityVerified = CapabilityAvailable \land Verification$

229.20 methods——方法核心表

Method回答：

如何实现目标？

方法模型：

$M=(T,C,P,A,R)M=(T,C,P,A,R)$

其中：

$TT$ ：Method Type
$CC$ ：Condition
$PP$ ：Process
$AA$ ：Action
$RR$ ：Expected Result / Requirements

Method不是一次实际执行。

例如：

Method M-001
    ↓
Action A1
    ↓
Action A2
    ↓
Action A3

它只是定义：

可以按照什么过程完成目标。

229.21 methods表设计

CREATE TABLE methods (
    id BIGINT NOT NULL AUTO_INCREMENT,
    method_code VARCHAR(100) NOT NULL,
    individual_id BIGINT NULL,
    method_type VARCHAR(100) NOT NULL,
    method_name VARCHAR(255) NOT NULL,
    condition_data TEXT NULL,
    process_data TEXT NULL,
    expected_result TEXT NULL,
    required_resource TEXT NULL,
    state VARCHAR(50) NOT NULL,
    created_at DATETIME NOT NULL,
    updated_at DATETIME NOT NULL,
    PRIMARY KEY (id),
    UNIQUE KEY uk_method_code (method_code),
    KEY idx_method_individual (individual_id),
    KEY idx_method_type (method_type),
    KEY idx_method_state (state)
);

229.22 Method Process与Action

为了避免把整个执行过程塞入 process_data，工程上可以继续拆表：

methods
   ↓
method_processes
   ↓
method_actions

例如：

CREATE TABLE method_processes (
    id BIGINT NOT NULL AUTO_INCREMENT,
    process_code VARCHAR(100) NOT NULL,
    method_code VARCHAR(100) NOT NULL,
    process_order INT NOT NULL,
    process_name VARCHAR(255) NOT NULL,
    condition_data TEXT NULL,
    created_at DATETIME NOT NULL,
    PRIMARY KEY (id),
    UNIQUE KEY uk_method_process_code (process_code),
    KEY idx_method_process_method (method_code),
    KEY idx_method_process_order (method_code, process_order)
);

这样可以保证：

$Process={P1,P2,…,Pn}Process=\{P_1,P_2,\ldots,P_n\}$

具有明确顺序。

229.23 Method与Capability

方法通常要求某些能力。

例如：

Goal
 ↓
Method M-001
 ↓
Required Capability
 ↓
Capability C-001

因此可以建立：

CREATE TABLE method_capabilities (
    id BIGINT NOT NULL AUTO_INCREMENT,
    method_code VARCHAR(100) NOT NULL,
    capability_code VARCHAR(100) NOT NULL,
    requirement_type VARCHAR(100) NULL,
    condition_data TEXT NULL,
    created_at DATETIME NOT NULL,
    PRIMARY KEY (id),
    UNIQUE KEY uk_method_capability (
        method_code,
        capability_code
    ),
    KEY idx_method_capability_method (method_code),
    KEY idx_method_capability_capability (capability_code)
);

这里的关联数据不是 Capability 本身，也不是 Method 本身。

它表达：

这个方法需要什么能力。

229.24 decisions——决策核心表

Decision回答：

在多个候选方案中，现在选择哪个？

Decision模型：

$D=(C,Ca,R,H)D=(C,Ca,R,H)$

其中：

$CC$ ：Decision Condition
$CaCa$ ：Candidates
$RR$ ：Decision Result
$HH$ ：Decision History

Decision不是Method。

例如：

Method M1
Method M2
Method M3

通过条件和规则计算：

M1 → available
M2 → blocked
M3 → available

再进行：

Decision
    ↓
M1

因此：

$Method=候选方案Method=候选方案$ $Decision=选择过程与选择结果Decision=选择过程与选择结果$

229.25 decisions表设计

CREATE TABLE decisions (
    id BIGINT NOT NULL AUTO_INCREMENT,
    decision_code VARCHAR(100) NOT NULL,
    individual_id BIGINT NOT NULL,
    goal_code VARCHAR(100) NULL,
    decision_type VARCHAR(100) NOT NULL,
    condition_data TEXT NULL,
    selected_candidate_type VARCHAR(100) NULL,
    selected_candidate_code VARCHAR(100) NULL,
    result_data TEXT NULL,
    state VARCHAR(50) NOT NULL,
    decision_time DATETIME NOT NULL,
    created_at DATETIME NOT NULL,
    updated_at DATETIME NOT NULL,
    PRIMARY KEY (id),
    UNIQUE KEY uk_decision_code (decision_code),
    KEY idx_decision_individual (individual_id),
    KEY idx_decision_goal (goal_code),
    KEY idx_decision_state (state),
    KEY idx_decision_time (decision_time)
);

229.26 decision_candidates

Decision必须保存候选方案，而不是只保存最终结果。

CREATE TABLE decision_candidates (
    id BIGINT NOT NULL AUTO_INCREMENT,
    candidate_code VARCHAR(100) NOT NULL,
    decision_code VARCHAR(100) NOT NULL,
    candidate_type VARCHAR(100) NOT NULL,
    candidate_id VARCHAR(100) NOT NULL,
    candidate_state VARCHAR(50) NOT NULL,
    score DECIMAL(20,8) NULL,
    reason TEXT NULL,
    evidence TEXT NULL,
    selected TINYINT(1) NOT NULL DEFAULT 0,
    created_at DATETIME NOT NULL,
    PRIMARY KEY (id),
    UNIQUE KEY uk_decision_candidate_code (candidate_code),
    KEY idx_decision_candidate_decision (decision_code),
    KEY idx_decision_candidate_state (candidate_state),
    KEY idx_decision_candidate_score (score)
);

这样可以保存：

Decision D-001

Candidates:
M-001 score 90 selected
M-002 score 75 rejected
M-003 score 40 blocked

而不是只留下：

selected = M-001

229.27 Decision的计算过程

DecisionEngine的计算可以表示为：

$CandidateFilter→ConditionEvaluation→CapabilityCheck→StateCheck→RiskCheck→CandidateScore→DecisionResultCandidateFilter \rightarrow ConditionEvaluation \rightarrow CapabilityCheck \rightarrow StateCheck \rightarrow RiskCheck \rightarrow CandidateScore \rightarrow DecisionResult$

例如：

$Score(Ci)=∑j=1nWjVijScore(C_i) = \sum_{j=1}^{n}W_jV_{ij}$

其中：

$CiC_i$ ：第 $ii$ 个候选方案
$WjW_j$ ：第 $jj$ 个评价维度权重
$VijV_{ij}$ ：候选方案 $ii$ 在维度 $jj$ 上的评价值
$nn$ ：评价维度数量

这些计算由 DecisionEngine 完成。

数据库只保存：

候选方案
计算结果
选择结果
原因
证据
历史

229.28 Decision不存在可选方案也是合法结果

例如：

M1 blocked
M2 unavailable
M3 capability mismatch

最终：

DecisionResult = no_candidate

这不是数据库错误。

它是一个合法认知结果：

$CandidateCount=0CandidateCount=0$

此时系统应该进入：

Risk
Conflict
Diagnosis
Replan
HumanInput

等后续处理。

不能为了让系统“必须选择一个”而虚构方案。

229.29 六张核心认知表之间的关系

总体结构：

knowledge
    │
    │ provides facts
    ↓
needs
    │
    ↓
goals
    │
    ↓
capabilities
    │
    ↓
methods
    │
    ↓
decisions

但实际数据库关系更准确地表示为：

Individual
    │
    ├────────→ Needs
    │             │
    │             ↓
    │           Goals
    │             │
    │       ┌─────┴─────┐
    │       ↓           ↓
    │  Capabilities   Methods
    │       │           │
    │       └─────┬─────┘
    │             ↓
    │         Decisions
    │
    └────────→ Knowledge

Knowledge可以同时作用于：

Goal
Capability
Method
Decision

因此 Knowledge不是简单的上游表，而是整个认知层的基础知识来源之一。

229.30 六类数据的工程职责

数据	主要问题	主要Engine	主要Repository
Knowledge	知道什么	KnowledgeEngine	KnowledgeRepository
Need	为什么需要	Goal/Need相关计算	NeedRepository
Goal	要达到什么	GoalEngine	GoalRepository
Capability	能不能做	CapabilityEngine	CapabilityRepository
Method	怎么做	MethodEngine	MethodRepository
Decision	选哪个	DecisionEngine	DecisionRepository

这里必须注意：

$Repository≠EngineRepository\neq Engine$

例如：

KnowledgeEngine

负责知识计算。

KnowledgeRepository

负责知识保存和查询。

同理：

DecisionEngine

负责决策计算。

DecisionRepository

负责决策持久化。

229.31 六类数据的完整Domain模型

可以统一表示：

Knowledge

$K=(S,P,O,C,St)K=(S,P,O,C,S_t)$

Need

$N=(ID,T,C,P,S)N=(ID,T,C,P,S)$

Goal

$G=(ID,N,T,C,P,S)G=(ID,N,T,C,P,S)$

Capability

$C=(T,Co,S,R,V)C=(T,Co,S,R,V)$

Method

$M=(T,C,P,A,R)M=(T,C,P,A,R)$

Decision

$D=(C,Ca,R,H)D=(C,Ca,R,H)$

这些模型中的符号虽然存在局部重复，但每个模型内部具有明确语义。

工程代码中应该使用明确字段名称，避免直接依赖单字母变量造成混淆。

229.32 从Need到Decision的完整认知过程

一个完整过程：

Need
 ↓
Need Validation
 ↓
Goal Candidate
 ↓
GoalEngine
 ↓
Goal
 ↓
CapabilityEngine
 ↓
Capability Candidates
 ↓
MatchingEngine
 ↓
MethodEngine
 ↓
Method Candidates
 ↓
DecisionEngine
 ↓
Decision
 ↓
Selected Method

之后：

Selected Method
      ↓
BehaviorEngine
      ↓
Behavior
      ↓
ActionEngine
      ↓
ExecutionEngine

229.33 数据验证原则

六类认知数据都不能使用“只要字段存在就有效”的判断。

例如：

knowledge_code存在

不能直接推出：

Knowledge有效

同样：

goal_code存在

不能推出：

Goal有效

因此：

$Exists≠ValidExists\neq Valid$

更进一步：

$Valid≠VerifiedValid\neq Verified$

只有满足相应证据、条件、规则和验证要求，才能进入后续可靠计算。

229.34 数据更新原则

认知数据更新统一遵循：

$Dt+ΔF→Dt+1D_t+\Delta F\rightarrow D_{t+1}$

其中：

$DtD_t$ ：当前认知数据
$ΔF\Delta F$ ：经过验证的新事实变化
$Dt+1D_{t+1}$ ：更新后的认知数据

例如 Knowledge：

$Kt+ΔK→Kt+1K_t+\Delta K\rightarrow K_{t+1}$

Capability：

$Ct+ΔC→Ct+1C_t+\Delta C\rightarrow C_{t+1}$

Method：

$Mt+ΔM→Mt+1M_t+\Delta M\rightarrow M_{t+1}$

Goal：

$Gt+ΔG→Gt+1G_t+\Delta G\rightarrow G_{t+1}$

更新不是简单覆盖。

必须保存：

Before
Change
Reason
Evidence
Verification
After
Time

229.35 History与当前认知数据

当前数据：

knowledge
needs
goals
capabilities
methods
decisions

与历史数据必须分开。

例如：

methods
method_history

以及：

decisions
decision_history

不能直接把历史记录覆盖掉。

因为后续：

MemoryEngine
ExperienceEngine
LearningEngine
DiagnosisEngine

都可能需要使用这些历史事实。

因此：

$CurrentData≠HistoryCurrentData\neq History$

229.36 推荐的历史表

本认知数据层可以建立：

knowledge_history
need_history
goal_history
capability_history
method_history
decision_history

例如：

CREATE TABLE goal_history (
    id BIGINT NOT NULL AUTO_INCREMENT,
    history_code VARCHAR(100) NOT NULL,
    goal_code VARCHAR(100) NOT NULL,
    state_before VARCHAR(50) NULL,
    state_after VARCHAR(50) NULL,
    change_data TEXT NULL,
    reason_data TEXT NULL,
    evidence TEXT NULL,
    created_at DATETIME NOT NULL,
    PRIMARY KEY (id),
    UNIQUE KEY uk_goal_history_code (history_code),
    KEY idx_goal_history_goal (goal_code),
    KEY idx_goal_history_time (created_at)
);

历史数据采用追加方式更容易保持完整轨迹。

229.37 PHP Domain目录

对应PHP工程：

app/
├── Domain/
│   ├── Knowledge/
│   │   └── Knowledge.php
│   ├── Need/
│   │   └── Need.php
│   ├── Goal/
│   │   └── Goal.php
│   ├── Capability/
│   │   └── Capability.php
│   ├── Method/
│   │   └── Method.php
│   └── Decision/
│       └── Decision.php
│
├── Engines/
│   ├── KnowledgeEngine.php
│   ├── GoalEngine.php
│   ├── CapabilityEngine.php
│   ├── MethodEngine.php
│   └── DecisionEngine.php
│
├── Repositories/
│   ├── KnowledgeRepository.php
│   ├── NeedRepository.php
│   ├── GoalRepository.php
│   ├── CapabilityRepository.php
│   ├── MethodRepository.php
│   └── DecisionRepository.php
│
└── Mapping/
    ├── KnowledgeMapper.php
    ├── NeedMapper.php
    ├── GoalMapper.php
    ├── CapabilityMapper.php
    ├── MethodMapper.php
    └── DecisionMapper.php

229.38 Service、Engine、Repository的调用关系

完整结构：

Controller
    ↓
Service
    ↓
Engine
    ↓
Domain Object
    ↓
Mapper
    ↓
Repository
    ↓
PDO
    ↓
MySQL

但是 Engine 不应该直接调用 Repository。

更合理的职责划分是：

Service
 ├── Load Domain ← Repository
 │
 ├── Calculate ← Engine
 │
 ├── Validate
 │
 ├── Verify
 │
 └── Save Domain → Repository

因此：

$Service=OrchestrationService=Orchestration$ $Engine=CalculationEngine=Calculation$ $Domain=StructureDomain=Structure$ $Repository=PersistenceRepository=Persistence$ $MySQL=StorageMySQL=Storage$

229.39 一个完整认知案例

假设 Individual：

I-001

产生：

Need N-001

Need：

type = process
priority = high

GoalEngine产生：

Goal G-001

目标：

Object O-001
state → completed

随后 CapabilityEngine发现：

C-001
process_object
available

MatchingEngine：

G-001 ↔ C-001
matched

MethodEngine产生：

M-001
standard_process

以及：

M-002
alternative_process

DecisionEngine计算：

M-001 = available
M-002 = available

最终：

Decision D-001
selected = M-001

于是：

D-001
 ↓
M-001
 ↓
Behavior
 ↓
Action
 ↓
Execution

这就是六类认知数据进入实际行为的完整路径。

229.40 异常情况下的数据变化

如果：

M-001

执行失败：

Execution
 ↓
Result = failed
 ↓
Feedback
 ↓
Diagnosis

如果发现：

Resource Insufficient

那么不应该立即：

Capability C-001 = invalid

而应该首先判断：

Failure Cause
    ↓
Resource

如果能力本身仍然有效：

Capability C-001 = available

而方法条件可能被 LearningEngine发现需要变化：

Method M-001
condition:
resource >= 1

↓

Learning Candidate

↓

resource >= 2

最后：

UpdateEngine
 ↓
Method Update
 ↓
MethodRepository

这说明认知数据之间存在严格的因果边界。

229.41 六类认知数据与前后章节的连接

前一层：

Individual
Object
Attribute
State
Relation
Scene

进入本章：

Knowledge
Need
Goal
Capability
Method
Decision

下一层：

Behavior
Action
Execution
Result
Feedback

再往后：

Memory
Experience
Risk
Conflict
Diagnosis
Repair
Learning
Update

最终形成：

Core Data
     ↓
Cognitive Data
     ↓
Runtime Data
     ↓
Memory / Experience
     ↓
Risk / Diagnosis
     ↓
Learning / Update
     ↓
Core Data

这构成 ICAI 的数据闭环。

229.42 ICAI认知数据库总体结构

目前数据库已经可以形成三层：

第一层：核心事实数据

individuals
objects
attributes
states
relations
scenes

第二层：认知数据

knowledge
needs
goals
capabilities
methods
decisions

第三层：运行数据

behaviors
actions
executions
results
feedbacks

随后再接：

memories
experiences
risks
conflicts
abnormalities
diagnoses
repairs
learning_records
update_records

因此：

$ICAIData=Core+Cognitive+Runtime+Maintenance+LearningICAIData= Core + Cognitive + Runtime + Maintenance + Learning$

229.43 本章核心原则

第一：

$Knowledge≠NeedKnowledge\neq Need$

知识不是需求。

第二：

$Need≠GoalNeed\neq Goal$

需求不是目标。

第三：

$Goal≠CapabilityGoal\neq Capability$

目标不是能力。

第四：

$Capability≠MethodCapability\neq Method$

能力不是方法。

第五：

$Method≠DecisionMethod\neq Decision$

方法不是决策。

第六：

$Decision≠BehaviorDecision\neq Behavior$

决策不是行为。

第七：

$Exists≠Valid≠VerifiedExists\neq Valid\neq Verified$

存在、有效、验证通过是三个不同层次。

第八：

$CurrentData≠HistoryCurrentData\neq History$

当前数据与历史数据必须分离。

第九：

$Engine≠RepositoryEngine\neq Repository$

Engine负责计算，Repository负责持久化。

第十：

$Domain≠MySQLDomain\neq MySQL$

Domain Object不能直接等同于数据库记录。

229.44 本章总结

第229章建立了 ICAI 的核心认知数据层：

$Knowledge+Need+Goal+Capability+Method+Decision\boxed{ Knowledge+ Need+ Goal+ Capability+ Method+ Decision }$

其中：

$Knowledge→Need→Goal→Capability→Method→DecisionKnowledge \rightarrow Need \rightarrow Goal \rightarrow Capability \rightarrow Method \rightarrow Decision$

表达从认知基础、需求形成、目标确定、能力判断、方法形成到方案选择的完整认知路径。

数据库核心表：

knowledge
needs
goals
capabilities
methods
decisions

辅助关联表：

knowledge_evidence
need_goal_relations
method_capabilities
decision_candidates

历史表：

knowledge_history
need_history
goal_history
capability_history
method_history
decision_history

工程边界保持为：

Domain
   ↓
Engine
   ↓
Service
   ↓
Mapper
   ↓
Repository
   ↓
PDO
   ↓
MySQL

其中：

KnowledgeEngine
    = 知识计算

GoalEngine
    = 目标计算

CapabilityEngine
    = 能力计算

MethodEngine
    = 方法计算

DecisionEngine
    = 决策计算

而：

KnowledgeRepository
NeedRepository
GoalRepository
CapabilityRepository
MethodRepository
DecisionRepository

负责对应认知数据的保存、查询、更新和历史持久化。

最终形成：

$CoreData→CognitiveData→RuntimeData→Feedback→Learning→Update→CoreData\boxed{ CoreData \rightarrow CognitiveData \rightarrow RuntimeData \rightarrow Feedback \rightarrow Learning \rightarrow Update \rightarrow CoreData }$

至此，ICAI已经从第228章的核心事实数据层进入第229章的认知数据层。这一层为后续 Behavior、Action、Execution、Result、Feedback 以及 Memory、Experience、Learning 提供正式的数据基础。

第229章 ICAI认知数据表

第229章 ICAI认知数据表

229.1 认知数据层的定位

229.2 六类认知Domain的区别

Knowledge

Need

Goal

Capability

Method

Decision

229.3 Domain与数据库的映射原则

229.4 knowledge——知识核心表

229.5 knowledge表设计

229.6 Knowledge状态

229.7 Knowledge Evidence

229.8 needs——需求核心表

229.9 Need模型

229.10 needs表

229.11 Need的生命周期

229.12 Need与Goal关系

229.13 goals——目标核心表

229.14 goals表设计

229.15 Goal状态

blocked

failed

completed

229.16 capabilities——能力核心表

229.17 capabilities表设计

229.18 Capability的几个状态层级

229.19 Capability条件与范围

229.20 methods——方法核心表

229.21 methods表设计

229.22 Method Process与Action

229.23 Method与Capability

229.24 decisions——决策核心表

229.25 decisions表设计

229.26 decision_candidates

229.27 Decision的计算过程

229.28 Decision不存在可选方案也是合法结果

229.29 六张核心认知表之间的关系

229.30 六类数据的工程职责

229.31 六类数据的完整Domain模型

Knowledge

Need

Goal

Capability

Method

Decision

229.32 从Need到Decision的完整认知过程

229.33 数据验证原则

229.34 数据更新原则

229.35 History与当前认知数据

229.36 推荐的历史表

229.37 PHP Domain目录

229.38 Service、Engine、Repository的调用关系

229.39 一个完整认知案例

229.40 异常情况下的数据变化

229.41 六类认知数据与前后章节的连接

229.42 ICAI认知数据库总体结构

第一层：核心事实数据

第二层：认知数据

第三层：运行数据

229.43 本章核心原则

229.44 本章总结

Leave a Reply Cancel reply