From 50e0f5206f62b06088fbeb8918a4aec30393bc94 Mon Sep 17 00:00:00 2001 From: yi-ge Date: Sun, 23 Aug 2026 15:06:57 +0800 Subject: [PATCH] =?UTF-8?q?docs:=20=E8=A1=A5=E5=85=85=E4=B8=9A=E5=8A=A1?= =?UTF-8?q?=E6=9C=AC=E4=BD=93=E4=B8=8E=20AI=20=E8=90=BD=E5=9C=B0=E8=AF=B4?= =?UTF-8?q?=E6=98=8E?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../03-enterprise-coordination.md | 18 ++ docs/04-concepts/13-business-ontology.md | 223 ++++++++++++++++++ docs/04-concepts/index.md | 3 + docs/05-more/03-glossary.md | 9 + docs/index.md | 1 + .../03-enterprise-coordination.md | 20 +- .../04-concepts/13-business-ontology.md | 223 ++++++++++++++++++ .../current/04-concepts/index.md | 3 + .../current/05-more/03-glossary.md | 9 + .../current/index.md | 1 + 10 files changed, 509 insertions(+), 1 deletion(-) create mode 100644 docs/04-concepts/13-business-ontology.md create mode 100644 i18n/en/docusaurus-plugin-content-docs/current/04-concepts/13-business-ontology.md diff --git a/docs/03-use-cases/03-solutions/03-enterprise-coordination.md b/docs/03-use-cases/03-solutions/03-enterprise-coordination.md index ff1f5ac..4b2dc2f 100644 --- a/docs/03-use-cases/03-solutions/03-enterprise-coordination.md +++ b/docs/03-use-cases/03-solutions/03-enterprise-coordination.md @@ -110,6 +110,24 @@ DesireCore: 收到紧急任务，正在调整资源优先级... 预计 5 分钟内首次回复客户。 ``` +## 先建立共享业务语境 + +多 Agent 协同不能只依赖每个成员各自理解一段提示词。进入真实企业流程前，团队应先对关键业务概念形成一致定义： + +| 本体维度 | 企业协同中的示例 | +|---|---| +| 对象 | 产品、发布计划、协议、预算、客户投诉、交付物 | +| 关系 | 任务负责人、前后依赖、材料来源、决策影响范围 | +| 规则 | 合规要求、预算阈值、截止时间、优先级与升级条件 | +| 动作 | 委派、暂停、提交审批、发布、通知与系统回写 | +| 治理 | 谁可以查看或修改、哪些动作需要人闸门、怎样保留回执 | + +可以使用 [企业业务本体](/concepts/business-ontology) 方法，把这些语义、规则和动作边界组织进 AgentFS、Skills、Workflow 与 Policy。这样，法律顾问、财务助手和产品经理讨论“发布”“风险”或“完成”时，指向的是同一组对象、状态和验收标准。 + +:::note +业务本体是协同实施方法，不会自动授予任何 Agent 新权限。每个成员仍受自己的[智能体权限边界](/concepts/agent-permission-boundary)、工具授权、人闸门与审计规则约束。 +::: + ## 核心能力 ### 任务编排 diff --git a/docs/04-concepts/13-business-ontology.md b/docs/04-concepts/13-business-ontology.md new file mode 100644 index 0000000..d4838dc --- /dev/null +++ b/docs/04-concepts/13-business-ontology.md @@ -0,0 +1,223 @@ +--- +title: 企业业务本体与 AI 落地 +description: 理解业务本体如何统一对象、关系、规则、动作与权限，并与 AgentFS、Skills、Workflow、多 Agent 和治理能力结合 +keywords: [企业本体, 业务本体, 本体驱动 AI, FDE, 知识图谱, RAG, AI 落地] +sidebar_position: 13 +last-reviewed: 2026-08-23 +--- + +# 企业业务本体与 AI 落地 + +企业 AI 面临的核心问题，通常不是“模型不知道某个术语”，而是模型缺少一套稳定的业务语境：它不知道当前处理的是哪个对象、对象处于什么状态、哪些规则适用、能够调用什么动作，以及什么时候必须交给人确认。 + +**企业业务本体（Enterprise Business Ontology）**把对象、关系、规则、动作和权限组织成共同模型，让人和智能体能够围绕同一个业务世界理解、判断和协作。 + +:::info 能力边界 +本页介绍的是**业务本体驱动的实施方法**。DesireCore 通过 AgentFS、记忆与知识图谱、Skills、Workflow、多 Agent、Hook / Policy、审批和回执承接相关资产与执行，但不把这些能力描述为一个独立、封闭的“本体引擎”。具体数据连接、自动化动作和企业治理能力以当前版本、授权范围与正式项目方案为准。 +::: + +## 本体不是术语表 + +术语表只能解释“这个词是什么意思”；面向 AI 落地的业务本体还要回答四类问题： + +| 组成 | 要回答的问题 | 示例 | +|---|---|---| +| **对象与状态** | 业务世界里有什么？现在处于什么状态？ | 设备 A、合同 v3、待审批订单 | +| **关系与证据** | 对象怎样关联？结论从哪里来？ | 负责人、上下游依赖、引用标准、来源页码 | +| **规则与逻辑** | 应该怎样判断？哪些约束必须满足？ | 审批阈值、校核规则、决策树、计算逻辑 | +| **动作与治理** | 允许做什么？由谁确认？如何记录？ | 生成报告、提交复核、写回系统、人闸门 | + +可以把它简化为一句话： + +> 语义负责理解，逻辑负责判断，动作负责执行，权限与证据负责可信。 + +## 从数据到行动的闭环 + +业务本体位于数据、知识与执行之间。它不替换企业现有的数据库、ERP、CRM、文档库或专业系统，而是让这些系统中的信息能够被统一解释，并在授权范围内连接到实际业务动作。 + +```mermaid +flowchart LR + A[业务资料与实时数据
文档 · 表格 · 系统 · 事件] --> B[业务本体语境
对象 · 关系 · 规则 · 动作 · 权限] + B --> C[人 + Agent 团队
理解 · 计划 · 分工 · 复核] + C --> D[Workflow 与业务动作
工具调用 · 审批 · 交付 · 回写] + D --> E[结果、回执与反馈
证据 · 异常 · 人工意见 · 指标] + E -. 经验回流 .-> B +``` + +这个闭环包含两个重要约束： + +1. **本体必须连接真实来源。** 对象状态、规则与证据需要能够回到具体数据、文档版本或业务系统。 +2. **动作必须受治理。** 理解某个对象不等于获得修改它的权限；执行仍受工具授权、文件范围、策略、人闸门与审计约束。 + +## 本体、知识图谱与 RAG 的区别 + +这三类能力可以组合，但不应混为一谈。 + +| 能力 | 核心问题 | 典型输出 | 单独使用时的边界 | +|---|---|---|---| +| **RAG / 语义检索** | 哪些材料与当前问题相关？ | 文档片段、引用、摘要 | 能找到信息，但不天然理解完整业务状态或允许的动作 | +| **知识图谱** | 哪些实体存在，它们怎样连接？ | 实体、关系、路径、来源 | 能表达关系，但不必然包含流程、权限和执行语义 | +| **业务本体** | 业务世界如何定义、判断并行动？ | 对象、关系、规则、动作、权限 | 需要与真实数据、系统和一线流程共同维护 | +| **Agent Workflow** | 怎样围绕目标完成一组任务？ | 计划、工具调用、交付物、回执 | 没有共享语义时，跨系统理解与治理容易碎片化 | + +组合后的职责是： + +- RAG 提供相关材料； +- 知识图谱提供实体关系和来源； +- 业务本体提供稳定语义、规则和动作边界； +- Agent 围绕目标进行规划、协作与执行。 + +## DesireCore 能力如何承接本体方法 + +DesireCore 不要求把本体资产放进一个额外的黑盒系统，而是让它们落在已有、可检查的能力中。 + +| DesireCore 能力 | 在本体实施中的作用 | 可检查的资产或证据 | +|---|---|---| +| [AgentFS](./agentfs) | 保存身份、规则、资料、Skills、Workflow、版本与回执 | 文件、目录、Git 版本、来源信息 | +| 记忆与知识图谱 | 连接业务术语、对象关系、用户纠正和任务经验 | 记忆条目、作用域、关系、来源 | +| Skills / 决策树 | 承载专家规则、示例、判断路径和验收标准 | `SKILL.md`、脚本、规则与测试材料 | +| Workflow | 组合确定性步骤、Agent 判断、工具调用和异常处理 | 节点配置、执行记录、重试与回放 | +| 多 Agent Runtime | 让研究、执行、复核等角色共享语义并分工 | 委派记录、成员输出、合并与复核结果 | +| Hook / Policy / Human Gate | 限制高风险动作和系统回写 | 策略命中、审批、拒绝与临时授权 | +| [回执系统](./receipt-system) | 记录本体驱动任务使用了什么信息、规则与动作 | 输入输出、工具调用、证据和异常记录 | + +:::warning 不要把方法写成不存在的产品能力 +当项目只使用文件、记忆、Skill 和 Workflow 来组织业务语境时，应准确描述这些资产如何组合。只有在实际实现了专门的数据模型、编辑器、查询接口或运行时之后，才能进一步声称提供对应的“本体平台”能力。 +::: + +## FDE 式落地：从最小可用本体开始 + +FDE（Forward Deployed Engineer，前线部署工程师）式方法强调进入真实业务现场，与一线专家共同建模、集成和验证。它不要求先建设一个覆盖全公司的“大而全本体”，而是从一条价值明确的业务链开始。 + +### 1. 贴近业务现场 + +**核心问题：** 谁在什么条件下做出什么决定？ + +- 跟随一条真实任务，而不是只访谈理想流程； +- 盘点角色、输入、输出、系统、异常路径和风险边界； +- 记录当前耗时、错误类型、人工接管和业务结果。 + +**阶段输出：** 业务链地图、责任主体、输入输出、基线指标。 + +### 2. 建立最小可用本体 + +**核心问题：** 完成这条业务链必须理解哪些概念？ + +- 定义关键对象、关系和状态； +- 收集专家规则、优先级、例外和验收标准； +- 列出允许的动作、权限条件和证据要求。 + +**阶段输出：** 对象词典、关系图、规则清单、动作与权限表。 + +### 3. 组装 Agent 工作闭环 + +**核心问题：** 怎样让共享语义进入真实执行？ + +- 将资料、规则和角色边界组织到 AgentFS； +- 用 Skills、决策树和 Workflow 承载判断与步骤； +- 接入必要工具，并设置人闸门、异常处理和回写边界； +- 明确各 Agent 的职责、交接和复核关系。 + +**阶段输出：** 可运行场景、角色分工、审批点、交付模板。 + +### 4. 评测、上线与持续迭代 + +**核心问题：** 怎样证明有效，并安全扩大自动化范围？ + +- 使用真实测试集、边界案例和失败分类； +- 检查对象识别、规则判断、交付质量与专业复核差异； +- 观察权限命中、人工接管、成本、时延和业务结果； +- 通过回放、回执和版本对比更新本体资产。 + +**阶段输出：** 验收报告、评测基线、运行看板、迭代计划。 + +## 场景建模示例 + +### AI 标书写作 + +| 维度 | 示例 | +|---|---| +| 对象 | 招标条款、资格要求、评分点、企业材料、章节、风险项 | +| 关系 | 评分点对应章节、资格要求引用企业材料、结论引用来源页码 | +| 规则 | 响应完整性、资格匹配、格式要求、禁用表述 | +| 动作 | 拆解要求、匹配证据、并行撰写、风险复核、Word 交付 | +| 人工边界 | 关键承诺、报价、资质和最终投标文件由责任人确认 | + +### 工程图解析与设计校核 + +| 维度 | 示例 | +|---|---| +| 对象 | 设备、管线、仪表、回路、图页、坐标、版本、校核规则 | +| 关系 | 拓扑连接、回路归属、跨页引用、对象与证据位置 | +| 规则 | 编号一致性、拓扑检查、专业规则、冻结基线 | +| 动作 | 识别、关联、差异检查、形成问题清单和证据定位 | +| 人工边界 | 设计基准须先冻结，结果由具备资质的工程师复核签发 | + +### 合同审查与履约跟踪 + +| 维度 | 示例 | +|---|---| +| 对象 | 合同、条款、主体、义务、期限、金额、风险、审批记录 | +| 关系 | 主体承担义务、条款引用法规、风险关联审批人 | +| 规则 | 企业模板、法规要求、金额阈值、缺失与冲突条款 | +| 动作 | 逐条审查、证据引用、风险分级、提交审批、生成报告 | +| 人工边界 | 法律判断、重大风险接受和签署由授权人员完成 | + +## 治理与验收清单 + +上线前，不应只检查模型“回答得像不像”。至少需要覆盖以下四类证据： + +### 语义与证据 + +- [ ] 对象、关系和状态定义得到业务专家确认 +- [ ] 同名异义、字段冲突和版本差异有处理规则 +- [ ] 关键结论能够定位到来源、版本、页码或坐标 + +### 任务与质量 + +- [ ] 测试集包含正常案例、边界案例和反例 +- [ ] 交付格式、业务规则和专业要求可自动或人工校验 +- [ ] AI 结果与专业人员复核差异被记录和分类 + +### 动作与权限 + +- [ ] 工具、文件、数据和系统回写遵循最小权限 +- [ ] 高风险动作进入 [Human Gate](./step-types) +- [ ] 危险操作能够被策略拒绝，敏感信息能够被限制或脱敏 + +### 运行与改进 + +- [ ] 每次任务保留回执、异常和人工接管记录 +- [ ] 监控通过率、失败率、成本、时延和业务结果 +- [ ] 本体、Skill 和 Workflow 的更新经过版本与评测控制 + +## 常见误区 + +### “有一个知识库，就已经有业务本体” + +知识库提供材料，不一定定义对象状态、业务规则和可执行动作。判断是否形成业务本体，要看人和 Agent 能否基于同一语义进行判断和受治理执行。 + +### “本体越大越完整越好” + +没有真实工作流验证的大型模型很容易过时。更可靠的做法是围绕一个业务目标构建最小本体，形成反馈闭环后再扩展。 + +### “有本体以后，Agent 可以自动决定一切” + +本体能让决策上下文更清楚，但不会自动消除风险、专业责任和权限限制。工程、法律、财务等高风险结论仍需要相应资质和授权人员确认。 + +## 行业参考 + +- [W3C OWL 2 Overview](https://www.w3.org/TR/owl2-overview/)：本体语言、类、属性、个体和关系的标准化基础。 +- [Palantir Ontology Overview](https://www.palantir.com/docs/foundry/ontology/overview)：对象、关系、动作、函数与治理连接到运营工作流的公开说明。 +- [Palantir AI FDE Overview](https://www.palantir.com/docs/foundry/ai-fde/overview)：通过自然语言参与数据集成、本体编辑、函数、治理与验证的公开工作方式。 + +外部资料用于解释行业方法，不代表 DesireCore 与资料发布方存在产品从属关系。 + +## 相关文档 + +- [AgentFS 文件系统](./agentfs) +- [智能任务编排](./task-orchestration) +- [智能体权限边界](./agent-permission-boundary) +- [固化步骤、灵活步骤与人闸门](./step-types) +- [回执系统](./receipt-system) +- [企业服务协同](/use-cases/solutions/enterprise-coordination) diff --git a/docs/04-concepts/index.md b/docs/04-concepts/index.md index a02ab69..9dd35e1 100644 --- a/docs/04-concepts/index.md +++ b/docs/04-concepts/index.md @@ -29,6 +29,7 @@ DesireCore 围绕"培养并托管数字同伴"这一核心理念，构建了一 | [智能任务编排](./task-orchestration) | 自动拆解任务、匹配最佳智能体的"项目经理" | 想理解任务分配机制 | | [Auto Dream](./auto-dream) | 无损遗忘，在压缩中保留价值 | 想理解记忆整合机制 | | [智能体权限边界](./agent-permission-boundary) | 谁动手就按谁的权限算，越权责任在执行方 | 想理解多同伴协作时的权限归属 | +| [企业业务本体](./business-ontology) | 用对象、关系、规则、动作与权限连接业务语义和 AI 执行 | 想理解本体、RAG、知识图谱与 FDE 式落地 | ## 阅读建议 @@ -40,3 +41,5 @@ DesireCore 围绕"培养并托管数字同伴"这一核心理念，构建了一 4. 最后根据兴趣阅读其他概念 如果你是技术背景用户，可以直接跳到 **AgentFS 文件系统** 和 **回执系统**，这两个概念最能体现 DesireCore 的技术创新。 + +如果你负责企业 AI 或行业方案落地，建议继续阅读 **[企业业务本体](./business-ontology)**，理解如何从一条真实业务链建立共享语义、动作边界和验收证据。 diff --git a/docs/05-more/03-glossary.md b/docs/05-more/03-glossary.md index ad20248..26e2d8d 100644 --- a/docs/05-more/03-glossary.md +++ b/docs/05-more/03-glossary.md @@ -25,6 +25,9 @@ Automatic Speech Recognition 的缩写，将语音转换为文字的技术。Des ## B +### Business Ontology（企业业务本体） +将企业中的对象、关系、规则、动作和权限组织成共享业务语境的方法，使人和 Agent 能够基于同一含义进行判断与受治理执行。DesireCore 通过 AgentFS、记忆与知识图谱、Skills、Workflow、多 Agent、Policy 和回执承接相关资产；详见[企业业务本体与 AI 落地](../04-concepts/13-business-ontology.md)。 + ### BYOK（Bring Your Own Key） "自带钥匙"模式。用户使用自己的 AI 供应商 API Key，DesireCore 不做中间代理，费用直接由供应商向用户结算。 @@ -69,6 +72,9 @@ DesireCore 的核心交互范式。不是"我问你答"，而是"我教你做" ## F +### FDE（Forward Deployed Engineer） +前线部署工程师。进入真实业务现场，与一线专家共同识别决策、建立最小可用本体、连接数据与工具，并通过业务测试和运行证据持续迭代。FDE 是一种交付角色与工作方式，不是 DesireCore 的独立产品模块。 + ### Feedback（反馈） 用户对智能体执行结果的评价和纠正。正面反馈强化行为，负面反馈触发调整，是智能体进化的重要信号。 @@ -107,6 +113,9 @@ DesireCore 的核心交互范式。不是"我问你答"，而是"我教你做" ## R +### RAG（Retrieval-Augmented Generation，检索增强生成） +先从知识源检索与当前问题相关的材料，再将其作为上下文提供给生成模型的方法。RAG 擅长提供资料与引用，但不天然定义完整业务状态、规则优先级、可执行动作和权限边界。 + ### Receipt（回执） 智能体完成任务后生成的详细记录，包含输入输出摘要、工具调用清单、检索轨迹、步骤类型统计等信息。是"可信委派"的证据链。 diff --git a/docs/index.md b/docs/index.md index 8eb4bf6..27564da 100644 --- a/docs/index.md +++ b/docs/index.md @@ -81,6 +81,7 @@ keywords: [DesireCore, 用户手册, AI 智能体, 委派式交互, Agent OS] - [配置 API Key](./getting-started/configure-api-key) — 连接 AI 服务的第一步 - [教会智能体](./user-guide/teaching/delegation-interaction) — DesireCore 最核心的能力 - [智能任务编排](./concepts/task-orchestration) — 自动拆解任务、匹配最佳智能体 +- [企业业务本体](./concepts/business-ontology) — 连接对象、规则、动作、权限与 FDE 式 AI 落地 - [GUI 桌面自动化](./user-guide/capabilities/computer-use) — 让智能体操控电脑和手机 - [超级文书](./user-guide/super-document/overview) — 像 Code Review 一样协作写文档 - [快捷键速查](./more/keyboard-shortcuts) — 提升操作效率 diff --git a/i18n/en/docusaurus-plugin-content-docs/current/03-use-cases/03-solutions/03-enterprise-coordination.md b/i18n/en/docusaurus-plugin-content-docs/current/03-use-cases/03-solutions/03-enterprise-coordination.md index a371ed5..1388b56 100644 --- a/i18n/en/docusaurus-plugin-content-docs/current/03-use-cases/03-solutions/03-enterprise-coordination.md +++ b/i18n/en/docusaurus-plugin-content-docs/current/03-use-cases/03-solutions/03-enterprise-coordination.md @@ -98,6 +98,24 @@ DesireCore: Received emergency task, adjusting resource priority... Expected first response to customer within 5 minutes. ``` +## Establish shared business context first + +Multi-agent coordination cannot rely only on each member interpreting a separate prompt. Before entering a real enterprise process, the team should share explicit definitions for critical business concepts: + +| Ontology dimension | Enterprise-coordination example | +|---|---| +| Objects | Product, release plan, agreement, budget, complaint, deliverable | +| Links | Owner, task dependency, material source, decision impact | +| Rules | Compliance, budget threshold, deadline, priority, escalation | +| Actions | Delegate, pause, submit approval, release, notify, write back | +| Governance | Who can read or change, which actions need Human Gates, how receipts are retained | + +Use the [Enterprise Business Ontology](/concepts/business-ontology) method to organize these semantics, rules, and action boundaries across AgentFS, Skills, Workflows, and Policies. Legal, finance, and product agents then use the same objects, state, and acceptance criteria when they discuss “release,” “risk,” or “done.” + +:::note +A business ontology is an implementation method; it does not grant new permissions to any agent. Every member remains governed by its own [Agent Permission Boundary](/concepts/agent-permission-boundary), tool grants, Human Gates, and audit policy. +::: + ## Core Capabilities ### Task Orchestration @@ -150,4 +168,4 @@ A trackable multi-agent collaboration workflow: tasks are decomposed, delegated, - When describing requirements, state the overall goal (e.g., "release new product"), deadline, existing materials and non-negotiable constraints - For projects with clear deadlines, inform time constraints from the start—the scheduler will prioritize tasks on the critical path - Regularly check progress summaries and promptly respond to items requiring your decision to avoid blocking other agents' subsequent work -::: \ No newline at end of file +::: diff --git a/i18n/en/docusaurus-plugin-content-docs/current/04-concepts/13-business-ontology.md b/i18n/en/docusaurus-plugin-content-docs/current/04-concepts/13-business-ontology.md new file mode 100644 index 0000000..b704fd9 --- /dev/null +++ b/i18n/en/docusaurus-plugin-content-docs/current/04-concepts/13-business-ontology.md @@ -0,0 +1,223 @@ +--- +title: Enterprise Business Ontology and AI Deployment +description: Learn how a business ontology unifies objects, relationships, rules, actions, and permissions with AgentFS, Skills, Workflows, multi-agent teams, and governance +keywords: [enterprise ontology, business ontology, ontology-driven AI, FDE, knowledge graph, RAG, AI deployment] +sidebar_position: 13 +last-reviewed: 2026-08-23 +--- + +# Enterprise Business Ontology and AI Deployment + +The central problem in enterprise AI is usually not that the model lacks a particular term. It lacks a stable business context: which object is being handled, what state it is in, which rules apply, which actions are available, and when a person must take responsibility. + +An **Enterprise Business Ontology** organizes objects, relationships, rules, actions, and permissions into a shared model so people and agents can understand, judge, and collaborate against the same operational world. + +:::info Capability boundary +This page describes an **ontology-driven implementation method**. DesireCore uses AgentFS, memory and knowledge graphs, Skills, Workflows, multi-agent teams, Hooks / Policies, approvals, and receipts to carry the related assets and execution. It does not describe these capabilities as a separate, closed “ontology engine.” Data connections, automated actions, and enterprise governance depend on the current release, authorized scope, and formal solution design. +::: + +## An ontology is not a glossary + +A glossary explains what a term means. An operational business ontology for AI must answer four kinds of questions: + +| Element | Question | Example | +|---|---|---| +| **Objects and state** | What exists in the business world, and what state is it in? | Asset A, contract v3, pending order | +| **Links and evidence** | How are objects related, and where did a conclusion come from? | Owner, upstream dependency, cited standard, source page | +| **Rules and logic** | How should a judgment be made, and which constraints apply? | Approval threshold, review rule, decision tree, calculation | +| **Actions and governance** | What may happen, who confirms it, and how is it recorded? | Generate report, submit review, write back, Human Gate | + +A useful shorthand is: + +> Semantics enables understanding, logic enables judgment, actions enable execution, and permissions plus evidence enable trust. + +## The loop from data to action + +The business ontology sits between data, knowledge, and execution. It does not replace databases, ERP, CRM, document repositories, or professional systems. It gives information from those systems a consistent meaning and connects it to business action within an authorized scope. + +```mermaid +flowchart LR + A[Sources and live data
Documents · Tables · Systems · Events] --> B[Business ontology context
Objects · Links · Rules · Actions · Permissions] + B --> C[People + Agent teams
Understand · Plan · Assign · Review] + C --> D[Workflows and business actions
Tools · Approvals · Delivery · Write-back] + D --> E[Results, receipts, and feedback
Evidence · Exceptions · Human input · Metrics] + E -. Experience return .-> B +``` + +Two constraints apply throughout the loop: + +1. **The ontology must remain connected to real sources.** Object state, rules, and evidence need to trace to specific data, document revisions, or systems of record. +2. **Actions remain governed.** Understanding an object does not grant permission to modify it. Execution still follows tool grants, file scopes, policy, Human Gates, and audit. + +## Ontology, knowledge graphs, and RAG + +These capabilities work well together, but they are not interchangeable. + +| Capability | Core question | Typical output | Boundary when used alone | +|---|---|---|---| +| **RAG / Semantic Retrieval** | Which material is relevant now? | Chunks, citations, summaries | Finds information but does not inherently model complete business state or permitted action | +| **Knowledge Graph** | Which entities exist, and how are they linked? | Entities, relationships, paths, sources | Expresses relationships but may not include process, policy, or action semantics | +| **Business Ontology** | How is the business world defined, judged, and changed? | Objects, links, rules, actions, permissions | Must be maintained with real data, systems, and frontline workflows | +| **Agent Workflow** | How is a goal completed through tasks? | Plans, tool calls, deliverables, receipts | Without shared semantics, cross-system understanding and governance fragment easily | + +In combination: + +- RAG supplies relevant material; +- the knowledge graph supplies relationships and provenance; +- the business ontology supplies stable meaning, rules, and action boundaries; +- agents plan, collaborate, and execute toward a goal. + +## How DesireCore capabilities support the method + +DesireCore does not require ontology assets to be placed in another opaque system. They can live in existing, inspectable capabilities. + +| DesireCore capability | Role in an ontology implementation | Inspectable asset or evidence | +|---|---|---| +| [AgentFS](./agentfs) | Store identity, rules, sources, Skills, Workflows, versions, and receipts | Files, directories, Git versions, provenance | +| Memory and knowledge graphs | Connect terminology, object relationships, corrections, and task experience | Memory entries, scopes, links, sources | +| Skills / Decision Trees | Carry expert rules, examples, judgment paths, and acceptance criteria | `SKILL.md`, scripts, rules, test material | +| Workflow | Combine deterministic steps, agent judgment, tools, and exception handling | Node configuration, traces, retries, replay | +| Multi-Agent Runtime | Let research, execution, and review roles share meaning and divide work | Delegation, member output, merge and review results | +| Hook / Policy / Human Gate | Constrain high-risk action and system write-back | Policy decisions, approvals, denial, temporary grants | +| [Receipt System](./receipt-system) | Record which information, rules, and actions were used | Inputs, outputs, tool calls, evidence, exceptions | + +:::warning Do not document a method as a product capability that does not exist +When a project uses files, memory, Skills, and Workflows to organize business context, describe that composition accurately. A dedicated ontology platform should only be claimed after the corresponding data model, editor, query surface, or runtime has actually been implemented. +::: + +## FDE-style delivery: start with a minimum viable ontology + +An FDE (Forward Deployed Engineer) approach works at the operational edge with domain experts to model, integrate, and validate. It does not begin by building a complete ontology for the entire enterprise. It starts with one valuable business chain. + +### 1. Work at the operational edge + +**Core question:** Who makes which decision under what conditions? + +- Shadow a real task instead of documenting only the ideal process; +- map roles, inputs, outputs, systems, exception paths, and risk boundaries; +- record current time, error types, human takeover, and business outcomes. + +**Stage output:** workflow map, ownership, inputs and outputs, baseline metrics. + +### 2. Model the minimum viable ontology + +**Core question:** Which concepts are essential to complete this business chain? + +- Define critical objects, relationships, and state; +- collect expert rules, priorities, exceptions, and acceptance criteria; +- list permitted actions, policy conditions, and evidence requirements. + +**Stage output:** object dictionary, relationship map, rule inventory, action and policy table. + +### 3. Assemble the agent work loop + +**Core question:** How does shared meaning enter real execution? + +- Organize sources, rules, and role boundaries in AgentFS; +- carry judgment and steps through Skills, decision trees, and Workflows; +- connect required tools and define Human Gates, exception handling, and write-back boundaries; +- define responsibilities, handoffs, and review relationships across agents. + +**Stage output:** runnable scenario, role split, approval gates, delivery templates. + +### 4. Evaluate, release, and iterate + +**Core question:** How do we prove value and widen automation safely? + +- Use real test sets, boundary cases, and failure categories; +- check object recognition, rule decisions, delivery quality, and reviewer variance; +- observe policy decisions, human takeover, cost, latency, and business results; +- update ontology assets through replay, receipts, and version comparison. + +**Stage output:** acceptance report, evaluation baseline, operations dashboard, iteration plan. + +## Scenario modeling examples + +### AI proposal writing + +| Dimension | Example | +|---|---| +| Objects | Tender requirements, qualifications, scoring criteria, corporate evidence, chapters, risks | +| Links | Scoring criterion to chapter, qualification to evidence, conclusion to source page | +| Rules | Coverage, qualification fit, format, prohibited claims | +| Actions | Decompose, match evidence, draft in parallel, review risk, deliver Word | +| Human boundary | Commitments, pricing, qualifications, and the final submission require accountable human confirmation | + +### Engineering drawing review + +| Dimension | Example | +|---|---| +| Objects | Equipment, lines, instruments, loops, sheets, coordinates, revisions, review rules | +| Links | Topology, loop ownership, cross-sheet references, objects to evidence locations | +| Rules | Identifier consistency, topology checks, professional rules, frozen baselines | +| Actions | Recognize, link, compare, produce issue lists and evidence locations | +| Human boundary | Baselines must be frozen first; qualified engineers review and sign off findings | + +### Contract review and obligation tracking + +| Dimension | Example | +|---|---| +| Objects | Contracts, clauses, parties, obligations, deadlines, amounts, risks, approvals | +| Links | Party to obligation, clause to regulation, risk to approver | +| Rules | Corporate templates, legal requirements, thresholds, missing and conflicting clauses | +| Actions | Review clauses, cite evidence, grade risk, route approval, generate reports | +| Human boundary | Legal judgment, material risk acceptance, and signature remain with authorized people | + +## Governance and acceptance checklist + +Production acceptance should not only evaluate whether the model “sounds right.” It should cover at least four evidence classes. + +### Semantics and evidence + +- [ ] Objects, relationships, and state definitions are confirmed by domain experts +- [ ] Ambiguous terminology, field conflicts, and revision differences have explicit handling +- [ ] Critical conclusions trace to a source, revision, page, or coordinate + +### Task and quality + +- [ ] Test sets include normal cases, boundary cases, and counterexamples +- [ ] Delivery format, business rules, and professional requirements can be checked +- [ ] Differences between AI output and professional review are recorded and classified + +### Action and permission + +- [ ] Tools, files, data, and write-back follow least privilege +- [ ] High-risk action enters a [Human Gate](./step-types) +- [ ] Dangerous operations can be denied, and sensitive information can be restricted or masked + +### Operations and improvement + +- [ ] Every run preserves receipts, exceptions, and human takeover +- [ ] Pass rate, failure rate, cost, latency, and business outcomes are monitored +- [ ] Ontology, Skill, and Workflow changes are controlled through versions and evaluation + +## Common misconceptions + +### “We have a knowledge base, so we already have an ontology” + +A knowledge base supplies material. It does not necessarily define object state, business rules, or executable actions. A business ontology exists when people and agents can judge and act against the same governed meaning. + +### “The larger the ontology, the better” + +A large model that has not been validated in live work becomes stale easily. A more reliable approach builds a minimum ontology around one outcome, closes the feedback loop, and then expands. + +### “Once we have an ontology, agents can decide everything automatically” + +An ontology clarifies decision context. It does not remove risk, professional accountability, or permission constraints. High-risk engineering, legal, and financial conclusions still require qualified and authorized people. + +## Industry references + +- [W3C OWL 2 Overview](https://www.w3.org/TR/owl2-overview/): standards foundation for ontology languages, classes, properties, individuals, and relationships. +- [Palantir Ontology Overview](https://www.palantir.com/docs/foundry/ontology/overview): public explanation of connecting objects, links, actions, functions, and governance to operations. +- [Palantir AI FDE Overview](https://www.palantir.com/docs/foundry/ai-fde/overview): public workflow for using natural language across data integration, ontology editing, functions, governance, and validation. + +These references explain industry methods and do not imply any product affiliation between DesireCore and the publishers. + +## Related documentation + +- [AgentFS](./agentfs) +- [Task Orchestration](./task-orchestration) +- [Agent Permission Boundaries](./agent-permission-boundary) +- [Hardened, Flexible, and Human-Gate Steps](./step-types) +- [Receipt System](./receipt-system) +- [Enterprise Service Coordination](/use-cases/solutions/enterprise-coordination) diff --git a/i18n/en/docusaurus-plugin-content-docs/current/04-concepts/index.md b/i18n/en/docusaurus-plugin-content-docs/current/04-concepts/index.md index c200cda..c1b0ed3 100644 --- a/i18n/en/docusaurus-plugin-content-docs/current/04-concepts/index.md +++ b/i18n/en/docusaurus-plugin-content-docs/current/04-concepts/index.md @@ -59,6 +59,7 @@ DesireCore is built around the core philosophy of "cultivating and hosting digit | [Task Orchestration](./task-orchestration) | Automatic task decomposition and best-agent matching — your "project manager" | Want to understand task distribution | | [Auto Dream](./auto-dream) | Lossless forgetting — preserving value through compression | Want to understand memory consolidation | | [Agent Permission Boundaries](./agent-permission-boundary) | Whoever acts is bound by their own ceiling; accountability for overreach lies with the executor | Want to understand permissions across collaborating agents | +| [Enterprise Business Ontology](./business-ontology) | Connect business meaning and AI execution through objects, links, rules, actions, and permissions | Want to understand ontology, RAG, knowledge graphs, and FDE-style delivery | ## Reading Recommendations @@ -70,3 +71,5 @@ If you're new to DesireCore, we recommend reading in this order: 4. Finally, explore other concepts based on your interests If you have a technical background, you can jump directly to **AgentFS Filesystem** and **Receipt System** — these two concepts best demonstrate DesireCore's technical innovations. + +If you lead enterprise AI or industry-solution delivery, continue with **[Enterprise Business Ontology](./business-ontology)** to see how a real workflow becomes shared semantics, action boundaries, and acceptance evidence. diff --git a/i18n/en/docusaurus-plugin-content-docs/current/05-more/03-glossary.md b/i18n/en/docusaurus-plugin-content-docs/current/05-more/03-glossary.md index 4472ef3..1c014fe 100644 --- a/i18n/en/docusaurus-plugin-content-docs/current/05-more/03-glossary.md +++ b/i18n/en/docusaurus-plugin-content-docs/current/05-more/03-glossary.md @@ -25,6 +25,9 @@ A core interaction action beyond the Six Primitives, where users delegate specif ## B +### Business Ontology +A method for organizing enterprise objects, relationships, rules, actions, and permissions into shared business context so people and agents can judge and execute against the same governed meaning. DesireCore carries the related assets through AgentFS, memory and knowledge graphs, Skills, Workflows, multi-agent teams, Policies, and receipts. See [Enterprise Business Ontology and AI Deployment](../04-concepts/13-business-ontology.md). + ### BYOK (Bring Your Own Key) "Bring Your Own Key" mode. Users use their own AI provider API keys; DesireCore does not act as an intermediary, and fees are settled directly between the provider and the user. @@ -69,6 +72,9 @@ One of the Six Primitives. The agent acts from the current Plan within the allow ## F +### FDE (Forward Deployed Engineer) +A delivery role that works at the operational edge with domain experts to identify decisions, model a minimum viable ontology, connect data and tools, and iterate through business tests and operational evidence. FDE is a delivery role and method, not a standalone DesireCore product module. + ### Feedback User evaluation and correction of agent execution results. Positive feedback reinforces behavior; negative feedback triggers adjustment—an important signal for agent evolution. @@ -107,6 +113,9 @@ The agent's behavioral rules file (`principles.md`). Defines "must do," "never d ## R +### RAG (Retrieval-Augmented Generation) +A method that retrieves material relevant to the current question and supplies it as context to a generative model. RAG is effective for sources and citations, but it does not inherently define complete business state, rule priority, executable actions, or permission boundaries. + ### Receipt A detailed record generated after an agent completes a task, containing input/output summaries, tool call lists, retrieval traces, step type statistics, and more. The evidence chain of "trustworthy delegation." diff --git a/i18n/en/docusaurus-plugin-content-docs/current/index.md b/i18n/en/docusaurus-plugin-content-docs/current/index.md index 5157dc7..8fc6a03 100644 --- a/i18n/en/docusaurus-plugin-content-docs/current/index.md +++ b/i18n/en/docusaurus-plugin-content-docs/current/index.md @@ -78,6 +78,7 @@ Having issues? Find the most common answers here. - [Configure API Key](./getting-started/configure-api-key) — The first step to connect AI services - [Teach Your Agent](./user-guide/teaching/delegation-interaction) — DesireCore's core capability +- [Enterprise Business Ontology](./concepts/business-ontology) — Connect objects, rules, actions, permissions, and FDE-style AI delivery - [Super Document](./user-guide/super-document/overview) — Collaborate on documents like Code Review - [Keyboard Shortcuts](./more/keyboard-shortcuts) — Boost your productivity - [Agent Marketplace](./user-guide/agents/marketplace) — Discover and install professional agents