# 政务公文知识图谱本体 V1 PRD

## 1. 文档信息

| 字段 | 内容 |
|------|------|
| 文档名称 | 政务公文知识图谱本体 V1 PRD |
| 版本 | v1.0 |
| 适用范围 | 地市级政务办公与政务服务知识管理场景 |
| 文档目标 | 定义一版可落地、可演进、可与现有系统融合的通用政务公文图谱本体 |
| 当前定位 | 运行时增强版 V1 本体，不等于全量终态本体 |

---

## 2. 背景与问题

### 2.1 背景

当前系统已经具备基础知识图谱能力，核心包括：

1. Document 文档节点与文档间治理关系
2. Organization、Region、PolicyTheme 等通用实体
3. Matter、Condition、Material、TimeLimit、TargetGroup 等办事能力层实体
4. 基于 OpenSearch 与 Neo4j 的检索、问答、图谱展示与事项卡片能力

现阶段产品希望将图谱从“治理图 + 事项图”扩展为“通用政务公文图”，用于承接更广泛的办公、公文、任务、项目、系统、数据、预算等语义。

### 2.2 当前问题

当前系统存在以下约束：

1. 运行时 schema 偏精简，适合少量高价值标签，不适合一次性接入过大的本体全集。
2. 实体抽取提示词由运行时 schema 动态生成，标签与关系过多会直接抬高抽取复杂度并拉低精度。
3. 查询层已有 Matter 卡片、PolicyTheme 聚合、Region 过滤等既有假设，无法承受大规模语义替换。
4. 产品侧提出的大而全本体更适合作为长期上位分类体系，而不是当前阶段直接落地的运行时模型。

### 2.3 核心判断

本期不应直接落地“18 个一级类、68 个二级类、72 种关系”的全量本体，而应建设一版与现有系统兼容、覆盖面明显扩大的增强版 V1：

1. 以通用政务公文图为核心。
2. 办事能力层保留，但不作为默认主轴。
3. 条款图和人员会议等增强能力进入运行时支持范围，但不在所有文档上默认开启。

---

## 3. 产品目标

### 3.1 本期目标

本期目标是形成一版可运行、可抽取、可查询、可持续扩展的政务公文知识图谱本体增强版 V1，满足以下要求：

1. 支撑通用公文的主题、机构、地域、政策、任务、项目、系统、数据、预算等核心语义建模。
2. 与现有 Document、Organization、Region、PolicyTheme、Matter 能力兼容。
3. 允许产品提出的二级分类体系接入，但以 subtype 属性而非大规模新标签方式落地。
4. 在运行时 schema 中预置更多高潜力实体与关系，为人员、事件、机制、基础设施、技术等场景留出空间。
5. 明确区分“运行时支持范围”和“默认抽取范围”，在扩大 schema 的同时控制抽取复杂度。

### 3.2 非目标

本期不以以下目标为交付范围：

1. 不建设全量人事任免关系图。
2. 不建设完整会议活动图。
3. 不建设完整安全保障图。
4. 不把所有产品定义中的二级类型都直接升格为一级运行时标签。
5. 不要求所有进入运行时 schema 的实体在本期都默认参与主抽取。

---

## 4. 设计原则

### 4.1 少标签、多属性

一级实体标签只保留高复用、高聚合价值对象；二级类别主要通过属性承载。

### 4.2 兼容优先

优先复用当前系统已有标签和关系，不做大规模重命名或语义替换。

### 4.3 分层演进

运行时本体分为核心层、办公扩展层、办事能力层，不同能力通过 phase 和文档场景控制启用。

### 4.4 支持范围与抽取范围分离

系统支持的实体和关系范围可以大于默认抽取范围。运行时 schema 可以适度超前布局，但默认抽取集必须保持稳定、可控。

### 4.5 节制入图

只有具备跨文档复用价值、稳定抽取边界和明确查询价值的信息才进入图谱主干。

### 4.6 面向查询闭环设计

任何新增实体或关系都应能服务于具体查询、聚合、推荐、问答或展示场景，而不是只为覆盖概念目录。

---

## 5. 适用范围

本体 V1 主要服务以下场景：

1. 政务公文主题导航与聚合
2. 发文机关、责任单位、适用地域查询
3. 政策与任务、项目、系统之间的关联追踪
4. 数字政府办公场景中的系统、数据、预算、指标关联检索
5. 事项图与通用公文图的联合问答和研究

---

## 6. 本体总体结构

本体 V1 分为三层：

### 6.1 核心层

面向通用政务公文图，默认启用。

### 6.2 办公扩展层

面向人员、事件、机制、标准、基础设施、技术等常见办公语义，进入运行时 schema，但按场景启用。

### 6.3 办事能力层

面向办事指南、事项清单、流程型文档，按场景启用。

---

## 7. V1 一级实体定义

### 7.1 核心层实体

本期建议默认启用以下 12 个一级实体：

| 实体 | 定义 | 说明 |
|------|------|------|
| Document | 公文、正式文书、文件载体 | 全图中心节点 |
| Organization | 机关、事业单位、国企、社会组织、内设机构、临时机构等 | 统一承接机构语义 |
| Region | 行政区划、功能区域、政务服务场所 | 承接地域与适用范围 |
| PolicyTheme | 政策主题、专题领域、宏观分类 | 承接主题聚合 |
| Policy | 从文档中抽出的具体政策单元 | 承接规定、措施、办法、行动等 |
| Task | 工作任务、重点任务、督办事项、专项行动等 | 承接落实语义 |
| Project | 信息化项目、试点项目、采购项目、基建工程等 | 承接项目语义 |
| System | 政务服务平台、协同办公平台、专题系统、基础支撑平台等 | 承接系统语义 |
| DataResource | 数据目录、数据集、电子证照、接口、知识库等 | 承接数据资源语义 |
| Indicator | 量化指标、考核指标、时限指标等 | 承接评价与目标语义 |
| Budget | 财政预算、项目经费、专项资金、合同、绩效评价等 | 承接资金与预算语义 |
| Industry | 产业、行业、产业链、产业集群 | 承接产业经济语义 |

### 7.2 办公扩展层实体

本期建议将以下实体纳入运行时 schema，但按文档场景启用，不要求所有文档默认抽取：

| 实体 | 定义 | 说明 |
|------|------|------|
| Person | 领导、联系人、经办人、专家、供应商人员等 | 服务领导批示、任职、督办、联络等场景 |
| Event | 会议、调研、培训、评审、应急响应、论坛等活动事件 | 服务会议纪要、活动、公务动态场景 |
| Mechanism | 工作机制、监督机制、协作机制、应急机制、运营模式等 | 服务制度机制建模 |
| Standard | 技术标准、服务标准、考核指标、目标要求等规范性对象 | 服务标准与指标关联场景 |
| Infrastructure | 政务云、政务网络、数据中心、物联设施、安全设施等 | 服务基础设施承载与覆盖场景 |
| Technology | AI、大数据、区块链、云计算、信创、5G 等技术概念 | 服务项目和系统技术画像 |

### 7.3 办事能力层实体

本期保留以下办事能力层实体，不作为通用公文图默认主轴：

| 实体 | 定义 | 说明 |
|------|------|------|
| Matter | 可独立办理或规范的事项 | 保持当前事项图能力 |
| Condition | 条件、资格、前置要求 | 服务事项预审 |
| Material | 材料、证明、申请表等 | 服务材料核对 |
| TimeLimit | 办理时限、法定时限、承诺时限 | 服务时限问答 |
| TargetGroup | 适用对象类型 | 服务事项对象约束 |
| Article | 条款节点，用于条款回链与细粒度语义 |

### 7.4 暂不独立实体化的概念

以下概念本期暂不作为独立一级运行时实体，优先通过属性、subtype 或关系终点承接：

1. Position
2. 泛化 Resource
3. Time.Point
4. Time.Period
5. Time.FiscalYear
6. Time.Milestone

说明：

1. Position 更适合作为 Person 的属性或关系终点。
2. Resource 过于泛化，优先拆分到 Budget、DataResource、Infrastructure 等更稳定实体。
3. 时间相关语义优先落到实体属性，如 effective_date、deadline、fiscal_year、duration；后续如有必要再收敛为统一时间表达实体。

---

## 8. 与产品本体分类的融合规则

### 8.1 一级分类融合原则

产品提出的一级分类体系不等于运行时一级标签。融合规则如下：

1. Organization、Region、Document 等直接映射为运行时一级标签。
2. Policy、Task、Project、System、DataResource、Indicator、Budget 作为核心新增标签引入。
3. BusinessItem 不单独替换现有 Matter，而是对内映射到 Matter 能力层。
4. ServiceTarget 不单独引入，优先映射到 TargetGroup。
5. Person、Event、Mechanism、Standard、Infrastructure、Technology 进入运行时 schema，但不进入默认核心抽取集。
6. Position、泛化 Resource、细分 Time 系列不单独进入一级运行时标签。

### 8.2 二级分类融合原则

产品定义中的二级分类统一下沉为属性，不扩展为新标签。建议统一落到以下字段：

1. entity_type
2. entity_subtype
3. subtype_code

示例：

| 运行时实体 | entity_subtype | subtype_code |
|------|------|------|
| Organization | 政府机关 | ORG-GOV |
| Document | 通知 | DOC-NOTICE |
| Project | 信息化项目 | PRJ-IT |
| System | 协同办公平台 | SYS-OA |

---

## 9. 通用属性模型

所有实体建议统一保留以下公共属性：

| 字段 | 类型 | 说明 |
|------|------|------|
| entity_id | string | 全局唯一标识 |
| name | string | 规范名称 |
| normalized_name | string | 归一化名称 |
| alias | string[] | 别名与简称 |
| entity_type | string | 一级类型 |
| entity_subtype | string | 二级类型中文名 |
| subtype_code | string | 二级类型编码 |
| description | string | 描述 |
| source_doc_ids | string[] | 来源文档 ID 集合 |
| status | string | 有效、废止、归档、待确认等 |
| tags | string[] | 分类标签 |
| created_at | datetime | 首次入库时间 |
| updated_at | datetime | 最近更新时间 |

补充建议：

1. 对于运行时扩展实体，允许增加 extraction_mode、source_confidence、scene_scope 等内部控制字段，用于抽取与治理。
2. 对于 Person、Event、Mechanism、Technology 等高歧义类型，建议保留 evidence_text 或 raw_mention 便于回链。

---

## 10. 各类实体的最小专有属性

### 10.1 Document

| 字段 | 说明 |
|------|------|
| doc_id | 文档 ID |
| title | 标题 |
| normalized_title | 归一化标题 |
| doc_number | 文号 |
| doc_type | 文种 |
| doc_subtype | 文种细分 |
| issue_date | 发文日期 |
| effective_date | 生效日期 |
| expiry_date | 失效日期 |
| issuing_org_name | 发文机关名称 |
| knowledge_category | 管理分类 |
| summary | 摘要 |
| is_placeholder | 是否为引用占位文档 |

### 10.2 Organization

| 字段 | 说明 |
|------|------|
| org_type | 机构类型 |
| admin_level | 行政层级 |
| short_name | 简称 |
| region_code | 所属地域编码 |
| parent_org_name | 上级机构名称 |

### 10.3 Region

| 字段 | 说明 |
|------|------|
| region_code | 地域编码 |
| region_level | 地域层级 |
| parent_region_code | 上级地域编码 |

### 10.4 PolicyTheme

| 字段 | 说明 |
|------|------|
| keywords | 主题关键词 |
| parent_theme_id | 上级主题 |

### 10.5 Policy

| 字段 | 说明 |
|------|------|
| policy_type | 政策类型 |
| policy_level | 政策层级 |
| issue_date | 形成或生效日期 |
| effective_date | 生效日期 |
| summary | 摘要 |

### 10.6 Task

| 字段 | 说明 |
|------|------|
| task_type | 任务类型 |
| source | 任务来源 |
| priority | 优先级 |
| deadline | 截止时间 |
| progress | 进展状态 |
| completion_rate | 完成率 |

### 10.7 Project

| 字段 | 说明 |
|------|------|
| project_code | 项目编号 |
| project_type | 项目类型 |
| budget_amount | 预算金额 |
| duration | 建设周期 |
| phase | 当前阶段 |
| acceptance_status | 验收状态 |

### 10.8 System

| 字段 | 说明 |
|------|------|
| system_code | 系统编号 |
| system_type | 系统类型 |
| security_level | 等保级别 |
| deployment | 部署方式 |
| launch_date | 上线日期 |
| operator_name | 运维单位 |
| xinchuang | 是否完成信创适配 |

### 10.9 DataResource

| 字段 | 说明 |
|------|------|
| data_type | 数据类型 |
| format | 数据格式 |
| data_source | 数据来源 |
| sharing_level | 共享级别 |
| update_frequency | 更新频率 |

### 10.10 Indicator

| 字段 | 说明 |
|------|------|
| indicator_type | 指标类型 |
| target_value | 目标值 |
| actual_value | 实际值 |
| unit | 单位 |
| period | 统计周期 |
| data_source | 数据来源 |

### 10.11 Budget

| 字段 | 说明 |
|------|------|
| budget_type | 预算类型 |
| amount | 金额 |
| fiscal_year | 财政年度 |
| fund_source | 资金来源 |
| execution_rate | 执行进度 |

### 10.12 Industry

| 字段 | 说明 |
|------|------|
| industry_type | 产业类型 |
| chain_level | 产业链层级 |
| region_focus | 重点区域 |

### 10.13 Person

| 字段 | 说明 |
|------|------|
| person_type | 人员类型 |
| gender | 性别 |
| appointment_date | 任职日期 |
| contact_info | 联系方式 |

### 10.14 Event

| 字段 | 说明 |
|------|------|
| event_type | 事件类型 |
| held_at_text | 举办时间文本 |
| held_location | 举办地点 |
| event_status | 状态 |

### 10.15 Mechanism

| 字段 | 说明 |
|------|------|
| mechanism_type | 机制类型 |
| mechanism_scope | 适用范围 |
| operation_mode | 运作方式 |

### 10.16 Standard

| 字段 | 说明 |
|------|------|
| standard_type | 标准类型 |
| target_value | 目标值 |
| unit | 单位 |
| period | 周期 |

### 10.17 Infrastructure

| 字段 | 说明 |
|------|------|
| infra_type | 基础设施类型 |
| capacity | 容量或规模 |
| coverage_text | 覆盖范围 |

### 10.18 Technology

| 字段 | 说明 |
|------|------|
| tech_type | 技术类型 |
| maturity | 成熟度 |
| vendor_ecosystem | 生态或供应链 |

---

## 11. V1 关系模型

### 11.1 文档基础关系

| 关系 | 起点 | 终点 | 说明 |
|------|------|------|------|
| ISSUED_BY | Document | Organization | 文件由机构发布 |
| APPLIES_TO_REGION | Document | Region | 文件适用地域 |
| BELONGS_TO_THEME | Document | PolicyTheme | 文件主题归类 |
| BASED_ON | Document | Document | 文件依据上位文件制定 |
| AMENDS | Document | Document | 文件修订其他文件 |
| REPEALS | Document | Document | 文件废止其他文件 |
| REFERENCES | Document | Document | 文件普通引用其他文件 |
| CONTAINS_POLICY | Document | Policy | 文件包含的政策单元 |
| DEPLOYS_TASK | Document | Task | 文件部署的任务 |
| APPROVES_PROJECT | Document | Project | 文件批复或推动的项目 |

### 11.2 组织职责关系

| 关系 | 起点 | 终点 | 说明 |
|------|------|------|------|
| LEAD_BY | Task | Organization | 任务牵头单位 |
| ASSISTED_BY | Task | Organization | 任务配合单位 |
| ASSIGNED_TO | Policy | Organization | 政策责任主体 |
| IMPLEMENTED_BY | Project | Organization | 项目实施单位 |
| OPERATED_BY | System | Organization | 系统管理或运维单位 |
| SUBORDINATE_TO | Organization | Organization | 上下级机构关系 |
| COOPERATES_WITH | Organization | Organization | 协同机构关系 |

### 11.3 业务对象关系

| 关系 | 起点 | 终点 | 说明 |
|------|------|------|------|
| APPLIES_TO_REGION | Policy | Region | 政策独立适用地域 |
| RELATES_TO_THEME | Policy | PolicyTheme | 政策内容级主题归类 |
| IMPLEMENTS | Task | Policy | 任务落实政策 |
| LOCATED_IN | Project | Region | 项目落地区域 |
| SUPPORTED_BY | Project | Policy | 项目受政策支持 |
| FUNDS | Budget | Project | 预算支持项目 |
| FUNDS | Budget | Task | 预算支持任务 |
| MANAGES | System | DataResource | 系统管理数据资源 |
| EVALUATES | Indicator | Task | 指标评价任务 |
| EVALUATES | Indicator | Project | 指标评价项目 |

### 11.4 办公扩展层关系

建议纳入运行时 schema，但按场景启用：

| 关系 | 起点 | 终点 | 说明 |
|------|------|------|------|
| SERVES_IN | Person | Organization | 人员任职于机构 |
| LEADS | Person | Task | 人员负责任务 |
| INSTRUCTS | Person | Document | 领导对文档作出批示 |
| CONTACTS_FOR | Person | Project | 人员作为项目联络人 |
| HELD_BY | Event | Organization | 事件主办单位 |
| CHAIRED_BY | Event | Person | 事件主持人 |
| ATTENDED_BY | Event | Person 或 Organization | 事件参加者 |
| PRODUCES | Event | Document | 事件形成文件 |
| DECIDES | Event | Task | 会议议定任务 |
| HELD_IN | Event | Region | 事件举办地点 |
| ESTABLISHED_BY | Mechanism | Document | 机制由文件建立 |
| MANAGED_BY | Mechanism | Organization | 机制日常管理单位 |
| APPLIES_TO | Mechanism | Task 或 Project 或 System | 机制适用对象 |
| STIPULATED_BY | Standard | Document | 标准由文件规定 |
| CONFORMED_BY | Standard | System 或 DataResource | 标准被遵循 |
| EVALUATES | Standard | Task 或 Project | 标准用于考核 |
| MANAGED_BY | Infrastructure | Organization | 基础设施运维管理方 |
| HOSTS | Infrastructure | System | 基础设施承载系统 |
| COVERS | Infrastructure | Region | 基础设施覆盖区域 |
| USES_TECH | Project 或 System | Technology | 项目或系统采用技术 |
| SUPPORTED_BY | Industry | Policy | 产业受政策支持 |
| LOCATED_IN | Industry | Region | 产业所在区域 |
| MANAGED_BY | Industry | Organization | 产业主管部门 |

### 11.5 办事能力层关系

本期保留以下现有事项图关系：

| 关系 | 起点 | 终点 | 说明 |
|------|------|------|------|
| GOVERNS | Document 或 Article | Matter | 文档或条款规范事项 |
| HAS_CONDITION | Matter | Condition | 事项适用条件 |
| REQUIRES_MATERIAL | Matter | Material | 事项所需材料 |
| HAS_TIME_LIMIT | Matter | TimeLimit | 事项时限 |
| APPLIES_TO_TARGET | Matter | TargetGroup | 事项适用对象 |
| HANDLED_BY | Matter | Organization | 事项办理机构 |
| APPLIES_TO_REGION | Matter | Region | 事项独立地域约束 |

---

## 12. 与现有系统的兼容策略

### 12.1 保留既有标签名

为降低改造成本，本期不建议重命名以下既有标签：

1. Organization
2. Region
3. PolicyTheme
4. Matter
5. Condition
6. Material
7. TimeLimit
8. TargetGroup
9. Article

### 12.2 采用新增而非替换

本期在既有标签基础上新增：

1. Policy
2. Task
3. Project
4. System
5. DataResource
6. Indicator
7. Budget
8. Industry
9. Person
10. Event
11. Mechanism
12. Standard
13. Infrastructure
14. Technology

### 12.3 通过属性吸收产品分类体系

产品定义中的一级类和二级类不要求一一映射到标签，而主要通过以下字段落地：

1. entity_type
2. entity_subtype
3. subtype_code
4. tags

### 12.4 办事能力层继续保留

Matter 图仍然保留，承担：

1. 办事核心语义抽取
2. Matter 卡片能力
3. 材料、条件、时限、办理部门等查询能力
4. 标准办事指南等场景的补充语义层

### 12.5 运行时支持范围与默认抽取范围

建议明确区分两套范围：

1. 运行时支持范围
包括核心层、办公扩展层、办事能力层全部实体与关系，允许后端 schema、写图、查询、管理接口识别。

2. 默认抽取范围
默认对所有文档启用的主抽取集应控制在高稳定类型，包括：
Document、Organization、Region、PolicyTheme、Policy、Task、Project、System、DataResource、Budget、Indicator、Industry。

3. 场景抽取范围
以下类型建议按场景启用：
Person、Event、Mechanism、Standard、Infrastructure、Technology、Matter、Condition、Material、TimeLimit、TargetGroup、Article。

4. 这样可以在扩大运行时 schema 的同时，避免默认 prompt 和抽取结果失控。

---

## 13. Phase 规划

### Phase 0：核心公文图落地

目标：建设通用政务公文图主干。

范围：

1. Document
2. Organization
3. Region
4. PolicyTheme
5. Policy
6. Task
7. Project
8. System
9. DataResource
10. Indicator
11. Budget
12. Industry

### Phase 1：办公扩展层接入

目标：把高价值扩展实体纳入运行时 schema，并按场景启用。

范围：

1. Person
2. Event
3. Mechanism
4. Standard
5. Infrastructure
6. Technology
7. 扩展层关系接入抽取、写图和查询接口

### Phase 2：办事能力层对齐

目标：将现有事项图与核心公文图建立稳定映射关系。

范围：

1. Matter 继续作为办事能力层主节点
2. BusinessItem 概念对内映射 Matter
3. ServiceTarget 概念对内映射 TargetGroup
4. QA、Research、搜索场景联合使用核心公文图与事项图证据

### Phase 3：增强层深化

目标：在明确业务需求后逐步扩展条款和更复杂的人事、会议、治理语义。

候选范围：

1. Article
2. 更完整的人事关系
3. 更完整的事件关系
4. 更复杂的安全保障关系
5. 统一时间表达模型

---

## 14. 研发实现建议

### 14.1 Schema 层

建议调整图谱 schema 配置方式：

1. 保留现有活跃 phase 过滤机制。
2. 在 phase_0 中扩充核心公文图实体与关系。
3. 保留 phase_1 事项图能力。
4. 保留 phase_2a、phase_2b 作为增强层起点，后续再扩展。

### 14.2 抽取层

建议按文档场景控制抽取粒度：

1. 通用公文默认抽取核心层实体与关系。
2. 讲话稿、纪要、批示件、调研材料等文档按需额外启用 Person、Event、Mechanism。
3. 数字政府、项目建设、信息化材料按需额外启用 System、Infrastructure、Technology、DataResource、Standard。
4. 办事指南、事项清单类文档额外启用 Matter 能力层。
5. 条款型场景在后续深化阶段启用更细粒度条款抽取。

### 14.3 查询层

建议优先实现以下查询闭环：

1. 按文档查看主题、机构、地域、政策、任务、项目、系统、数据、预算、产业等关联对象。
2. 按 Policy、Task、Project、System、DataResource、Budget、Industry 做实体检索。
3. 保持 Matter 卡片和 Matter requirements 查询稳定可用。
4. 对高价值场景补充 Person、Event、Mechanism、Standard、Infrastructure、Technology 的查询与可视化支持。
5. 在问答和研究场景中融合核心公文图、办公扩展层与事项图证据。

---

## 15. 风险与约束

### 15.1 本体过大导致抽取质量下降

如果一次性启用过多标签和关系，抽取 prompt 会显著变长，导致抽取精度下降。因此本期必须控制运行时 schema 的规模。

### 15.2 过细标签造成图谱碎片化

若将二级分类直接升格为标签，会导致大量一次性节点和低复用节点，削弱图谱聚合价值。

### 15.3 运行时支持范围扩大后必须控制默认抽取范围

当运行时 schema 扩大后，如果默认抽取范围不加控制，会导致 prompt 过长、候选实体冲突增加和噪声关系增多。因此必须坚持场景化抽取。

### 15.4 办事能力不能被破坏

尽管本期主轴转为通用公文图，但 Matter 图已承载实际功能，不能因本体升级而退化。

---

## 16. 验收标准

### 16.1 本体层验收

1. 能形成一版明确的运行时一级实体列表、属性集合和关系集合。
2. 产品提出的二级分类可通过 subtype 属性稳定承接。
3. 核心层、办公扩展层、办事能力层边界清晰。
4. 明确运行时支持范围与默认抽取范围两套口径。

### 16.2 系统兼容性验收

1. 现有 Matter 图能力不受破坏。
2. 现有 Organization、Region、PolicyTheme 相关查询能力不受破坏。
3. 新增核心实体和办公扩展实体能够逐步接入抽取、写图与查询链路。

### 16.3 产品可用性验收

1. 能回答“某文由谁发文、适用于哪、涉及什么主题”。
2. 能回答“某政策由谁负责、落到哪些任务、支撑哪些项目、影响哪些产业”。
3. 能回答“某系统管理哪些数据、部署在哪些基础设施上、采用了哪些技术”。
4. 能回答“某任务或项目有哪些负责人、机制、事件或评审活动关联”。
5. 在办事场景下，仍能回答“需要什么材料、多久办完、谁办理”。

---

## 17. 最终结论

本 PRD 建议采用“核心公文图 + 办公扩展层 + 办事能力层”的三层本体结构。

本期运行时增强版 V1 本体的核心结论如下：

1. 以通用政务公文图为当前阶段主轴。
2. 保留 Matter 事项图作为能力层，而不是替换掉。
3. 将产品提出的复杂本体体系下沉为 subtype 分类体系，同时吸收其中一批高价值类型和关系进入运行时 schema。
4. 明确区分运行时支持范围与默认抽取范围，在扩大 schema 的同时控制抽取复杂度。
5. 先落地 12 个核心实体、6 个办公扩展实体、1 组办事能力层实体和 40+ 候选关系，形成可抽、可查、可扩展的系统骨架。

这一路径能够在不推翻现有系统能力的前提下，把图谱从“治理图 + 事项图”升级为“通用政务公文图”。