From aed9e6d636fc8939cc5959bb6986d5ce7f6a565d Mon Sep 17 00:00:00 2001 From: stpku <83755634+stpku@users.noreply.github.com> Date: Thu, 27 Aug 2026 09:48:33 +0800 Subject: [PATCH 01/17] docs: reposition GeoTask as task context engine --- README.md | 497 +++++++++++++++++++++--------------------------------- 1 file changed, 195 insertions(+), 302 deletions(-) diff --git a/README.md b/README.md index 00668dbf..ac8b83e4 100644 --- a/README.md +++ b/README.md @@ -2,11 +2,9 @@ **简体中文** | [English](README.en.md) -> **面向AI智能体的可验证时空任务协议与确定性核心** +> **GeoTask 是面向 AI Agent 的时空任务上下文引擎（Spatiotemporal Task Context Engine）。** > -> 当前：把观察、证据、世界状态和行动条件转化为可计算、可更新、可追溯的机器契约。 -> 近期：形成可信世界状态运行时的Reference Agent与开发者产品。 -> 长期：成为高风险物理世界智能体的可信任务基础设施之一。 +> 它不试图把“整个世界”塞进 Agent 的上下文，而是围绕当前任务，构造**真正需要、适用、分辨率足够且可明确判断充分性**的最小上下文。 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](LICENSE) [![Python 3.10+](https://img.shields.io/badge/python-3.10%2B-blue)](https://www.python.org/) @@ -15,356 +13,251 @@ [![Release](https://img.shields.io/github/v/release/stpku/GeoTask?include_prereleases&label=release)](https://github.com/stpku/GeoTask/releases) [![PyPI](https://img.shields.io/pypi/v/geotask-core)](https://pypi.org/project/geotask-core/) -```bash -pip install geotask-core -geotask inspect capabilities -geotask inspect health -geotask agent demo --output ./geotask-reference-agent -``` +## 为什么是 Task Context，而不是“更多上下文” -`inspect capabilities` 从已安装包现有的 Operator、Artifact、Schema、Runtime/Provider 接口、Reference Agent 与 Benchmark 元数据中生成公共 Core 能力索引，不扫描外部插件、真实 Runtime/Provider 或行业 Pack，也不新增任何 Artifact/Schema/Operator。`inspect health` 会继续检查这些安装能力及 Schema/Artifact/Operator 注册表、Reference Agent bundle 与固定离线 benchmark；它不访问网络、不调用模型、不接触生产系统，其诊断结果也不是注册 GeoTask Artifact，不代表现实正确性。随后，`agent demo` 会校验安装包内的 Reference Agent 教材 bundle、生成一个可自由修改的本地工作目录，并立即执行一次确定性成功场景重放；它不会读取外部真实数据、写生产状态或授权现实动作。 - -GeoTask把多模态模型、传感器、地图、权威数据和人工输入转化为显式的世界对象、时空关系、状态、证据和行动约束，构建可计算、可验证、可更新、可追溯的时空世界状态。它不是把整个世界隐式压进一个神经网络，而是让智能体依赖的现实事实能够被查看、复算、纠偏和持续维护。 - -- **多模态模型负责感知与开放推理：** 从文本、地图、图像、视频和状态数据中形成观测、假设与方案； -- **GeoTask核心负责世界状态规范与验证内核：** 显式表达对象、坐标、时间、关系、证据和命题，并用本地确定性路径验证； -- **验证与控制机制负责维护世界：** 保留已证实事实，标记冲突和未知，限定纠偏范围，并管理行动资格； -- **运行时与行业能力包负责连接现实：** 接入权威数据、行业规则、本地预测模型、人工复核和生产动作。 - -> **工程边界：** GeoTask核心提供可验证时空世界模型的公共状态规范、接口契约、验证内核和制品基础，“可验证时空任务协议”仍是当前实现形式。当前公共实现覆盖观测记录、世界状态、受限观测合并、状态转换、验证会话、差异报告、纠偏请求、影响图、受限重算推导、受限后继状态物化、增量复核结果，以及验证提供方描述符、验证请求、验证响应、可信保证策略、对象同一性审定、对象身份归并提案、对象身份归并审批记录、对象关系图变更请求和对象关系图变更应用审批记录。公共核心只校验结构、语义和原始字节级绑定，不获取外部事实、不推断未声明的来源优先级、不发布生产环境输出，也不授权或执行现实动作。 - -## 从这里开始 - -- [体验42个公开可验证示例（38个场景入口）](https://stpku.github.io/GeoTask/) -- [English ecosystem homepage](https://stpku.github.io/GeoTask/en/) -- [5分钟中文入门](docs/tutorials/quickstart.zh-CN.md) -- [GeoTask白皮书v0.1](docs/whitepaper/GeoTask_White_Paper_v0.1.md) -- [白皮书英文摘要](docs/whitepaper/GeoTask_White_Paper_v0.1.md#english-abstract) -- [GT01—GT20中文案例手册](docs/cookbook/gt01-gt20.zh-CN.md) -- [GT21—GT28世界状态循环案例手册](docs/cookbook/gt21-gt28.zh-CN.md) -- [GT38—GT42无人机身份治理复合案例](docs/cookbook/gt38-gt42-uav-identity-governance.zh-CN.md) -- [当前实现语言与执行规范v1.0](docs/spec/geotask-language-spec-v1.0.md) -- [Observation v0.1](docs/spec/geotask-observation-v0.1.md) -- [World State v0.1](docs/spec/geotask-world-state-v0.1.md) -- [Observation Merge Result v0.1](docs/spec/geotask-observation-merge-result-v0.1.md) -- [State Transition v0.1](docs/spec/geotask-state-transition-v0.1.md) -- [Verification Session v0.1](docs/spec/geotask-verification-session-v0.1.md) -- [Discrepancy Report v0.1](docs/spec/geotask-discrepancy-report-v0.1.md) -- [Correction Request v0.1](docs/spec/geotask-correction-request-v0.1.md) -- [Impact Graph v0.1](docs/spec/geotask-impact-graph-v0.1.md) -- [Recompute Derivation Result v0.1](docs/spec/geotask-recompute-derivation-result-v0.1.md) -- [World State Materialization Result v0.1](docs/spec/geotask-world-state-materialization-result-v0.1.md) -- [Incremental Reevaluation Result v0.1](docs/spec/geotask-incremental-reevaluation-result-v0.1.md) -- [Agent集成Profile v0.1](docs/spec/geotask-agent-integration-profile-v0.1.md) -- [运行时接口规范 v0.1](docs/spec/geotask-runtime-interface-profile-v0.1.md) -- [验证提供方接口规范 v0.1](docs/spec/geotask-verification-provider-profile-v0.1.zh-CN.md) -- [对象关系图变更请求 v0.1](docs/spec/geotask-object-graph-change-request-v0.1.md) -- [中文术语规范](docs/terminology.zh-CN.md) -- [GeoTask核心智能体技能](skills/geotask-core/SKILL.md) -- [VS Code Schema配置示例](.vscode/settings.json) -- [v0.4.1 能力发现与发布加固维护版说明](docs/release_v0_4_1.md) -- [v0.4.0 Core产品化与Reference Agent发布说明](docs/release_v0_4_0.md) -- [v0.3.0 Agent集成版发布说明](docs/release_v0_3_0.md) -- [v0.2.0制品契约版发布说明](docs/release_v0_2_0.md) -- [架构宣言 v1](docs/architecture_manifesto_v1.md) -- [GeoTask Architecture Series v0.1](docs/articles/architecture-series/README.zh-CN.md) -- [Reference Agent v0.1 规格](docs/reference/reference-agent-v0.1.md) -- [运行 Reference Agent：虚构低空设施评估更新](examples/reference_agent/facility_assessment_update/README.md) -- [Reference Agent从零教程](docs/tutorials/reference-agent.zh-CN.md) -- [Verification Quality Benchmark v0.1](docs/reference/verification-quality-benchmark-v0.1.md) —— 安装包可直接运行 `geotask benchmark quality` -- [Verification Quality Benchmark v0.2](docs/reference/verification-quality-benchmark-v0.2.md) —— `geotask benchmark quality --suite perturbation` 运行34个确定性合成扰动案例，不外推为现实准确率或跨域泛化 -- [GeoTask ↔ Lowa-GT Integration Contract v0.1](docs/reference/lowa-gt-integration-contract-v0.1.md) -- [Cross-Line Promotion Gate v0.1](docs/reference/cross-line-promotion-gate-v0.1.md) -- [Core Distribution Boundary v0.1](docs/reference/core-distribution-boundary-v0.1.md) -- [产品化路线图 v0.2](docs/productization_roadmap_v0_2.md) -- [公共路线图](ROADMAP.md) -- [中文文档导航](docs/README.md) +Agent 进入真实任务后，问题通常不是“有没有数据”，而是： -## 智能体为什么需要可验证的世界模型 +- **这个任务到底需要知道什么？** +- **某条信息虽然相关，但对当前对象、空间、时间和条件真的适用吗？** +- **它的空间/时间/语义分辨率足够支持当前任务吗？** +- **已有上下文是否足够，还是仍存在关键缺口？** +- **能否减少无关上下文，同时不漏掉关键上下文？** +- **现实发生变化后，哪些 Requirement 需要重评，哪些上下文可以继续复用？** -多模态大模型越来越会看懂场景、调用工具和生成计划，但模型内部的“世界理解”通常隐含在上下文、向量或参数中。进入真实行动前，智能体还需要一个外显、共享、可验证的世界状态，持续回答： +GeoTask 将这些问题变成显式、可组合、可测试的 Task Context 合同与方法。 -- 世界中有哪些对象，它们在哪里、何时存在、处于什么状态； -- 哪些关系和约束已经成立，哪些仍然未知、冲突或缺少证据； -- 新观察到来后，哪些世界状态和结论需要更新或失效； -- 哪些事实来自模型、传感器、权威数据或人工复核； -- 当前世界状态允许智能体采取什么行动。 +```text +Task + ↓ +derive requirements + ↓ +discover candidates + ↓ +Relevance + ↓ +Applicability + ↓ +Resolution Adequacy + ↓ +Sufficiency + ↓ +Minimum Sufficient TaskContext + ↓ +Explicit Gaps / Trace / Cost +``` -一次Tool Calling可以完成局部函数调用，却不会自动维护对象身份、世界快照、证据状态、变化影响和行动边界。GeoTask把这些信息组织为可验证、可审计的世界模型原语与Artifact： +## 核心语义 -```mermaid -flowchart LR - O[多模态观察与外部状态] --> W[显式时空世界状态] - W --> R[关系、约束与世界命题] - R --> V[本地验证与证据治理] - V --> U[状态更新、纠偏与复核] - U --> G[行动资格与外部Runtime] - N[新观察到来] --> W -``` +当前公共 Core 已提供面向 Task Context 的一组稳定原语与组合接口，包括： -当前公共核心已经实现世界对象与空间参考约束、来源与证据绑定、观测记录、世界状态、受限观测合并、状态转换、验证会话、差异报告、纠偏请求、影响图、来源绑定的受限重算推导、受限后继状态物化、增量复核结果、验证提供方公共接口契约、对象同一性审定、对象身份归并提案、对象身份归并审批记录、对象关系图变更请求、对象关系图变更应用审批记录、世界命题、确定性关系验证、控制状态、智能体机械修复和限定路径重试。自动差异计算、未声明策略的歧义冲突消解、影响关系自动发现与传播执行、对象关系图变更应用与应用结果以及通用推导方法仍属于后续路线图。 +- `TaskFrame` +- `ContextRequirement` +- `ContextCandidate` +- `RelevanceResult` +- `ApplicabilityResult` +- `ResolutionRequirement` / `ResolutionAdequacyResult` +- `ContextAssessment` +- `ContextGap` +- `SufficiencyAssessment` +- `TaskContext` +- `ContextConstructionTrace` +- `ContextMinimalityAssessment` +- `MinimumSufficientTaskContext` +- Temporal Reassessment / Continuity contracts -## 5分钟运行 +这些对象刻意保持几个边界： -```bash -python -m pip install geotask-core -geotask --help -geotask inspect operators +```text +Context ≠ World State +Relevant ≠ Applicable +Applicable ≠ Sufficient +Candidate exists ≠ Requirement satisfied +Large payload ≠ Sufficient context +Provider returned a value ≠ Valid task context +Context sufficient ≠ Domain decision +Context sufficient ≠ Action authorization ``` -将下面的最小任务保存为`my_distance.yaml`： +## GeoTask 负责什么 -```yaml -geotask: - id: "example" - schema_version: "1.0" +GeoTask 负责 **Task-relative Context**： -objects: - a: {type: "point", coordinates: [0, 0]} - b: {type: "point", coordinates: [3, 4]} +1. 用 `TaskFrame` 明确当前任务、目标与作用域； +2. 从任务导出或接收 `ContextRequirement`； +3. 从 GIS、API、Sensor、Database、WorldState 或其他 Provider 获取 `ContextCandidate`； +4. 分别评估 Relevance、Applicability 与 Resolution Adequacy； +5. 显式形成 Requirement-level Assessment 与 Gap； +6. 由明确方法组合 `SufficiencyAssessment`； +7. 构造 `TaskContext`，并在不增加 Critical Context Miss 的前提下寻找 Minimum Sufficient Context； +8. 当 Provider / Reality 变化时，仅重评受影响 Requirement，并尽量复用未受影响 Context。 -operator_set: [distance_2d] +GeoTask **不拥有世界真值**，也不替代 Agent Harness、GIS、数据库、知识图谱、RAG 系统或领域决策系统。 -tasks: - - id: "calc" - assertions: - - id: "ab" - operator: "distance_2d" - object_refs: ["a", "b"] +```text +World / Data Providers +WorldState · GIS · API · Sensor · Database · GSTAR · ... + │ + ▼ + ┌─────────┐ + │ GeoTask │ + │ Task │ + │ Context │ + └────┬────┘ + │ + ▼ + Agent / Harness + │ + ▼ + Domain Decision / Action ``` -本地执行器会得到： +**Provider 可以告诉 GeoTask“候选事实是什么”；GeoTask 判断的是“它对当前任务是否需要、适用、足够”。** -```text -ab = 5.0 meter -assurance_level = local_deterministic -``` +## North Star：充分，而不是堆积 -```bash -geotask validate my_distance.yaml -geotask run my_distance.yaml -``` +GeoTask 的长期目标是： -## 42个公开可验证示例，38个场景入口 - -GeoTask不是只展示几个几何函数，而是通过机器人、无人机、车辆和低空任务，逐步展示模型方案如何被结构化、复算、验错、补证、纠偏和行动门控。其中GT38—GT42不是五个彼此独立的应用案例，而是“巡检无人机UAV-017失联后重新编号”的一个五阶段身份治理复合案例。 - -| 阶段 | 案例 | 核心问题 | -|---|---|---| -| 空间关系 | GT01—GT03 | 距离、边界接触和多段路线到底是什么关系？ | -| 时空组合 | GT04—GT06 | 水平、高度和时间条件是否同时成立？ | -| 不确定性与证据 | GT07—GT09 | 缺证据或证据冲突时，系统应该怎么办？ | -| 行动与可行性 | GT10—GT20 | 约束确认以后，下一步具体执行什么？ | -| 世界状态循环 | GT21—GT28 | 多源观测、状态变化、影响范围、限定纠偏和行动门禁怎样闭环？ | -| 验证提供方生态 | GT29—GT32 | 多个外部来源冲突、显式裁决、渐进授权和行动门禁怎样形成独立可信保证？ | -| 动态世界对象 | GT33—GT37＋GT38—GT42复合案例 | 前五例处理轨迹与同一性候选；后五个参考例共同描述UAV-017失联后重新编号的证据审定、归并提案、审批、变更请求和应用审批。 | - -重点案例： - -- **GT07：** 时间条件无法核验时，`unknown`不能被偷换成`false`； -- **GT09：** 两份分别已核验的临时禁飞通知仍可能互相冲突； -- **GT10：** 两台机器人抢同一条窄通道，需要显式协调规则； -- **GT11：** 目标只有50米，轮式机器人却可能必须绕行300米； -- **GT12：** 无人机电量够到达，不等于能保留安全余量完成任务； -- **GT13：** 道路开放，不等于具体车辆的安全包络能够通过； -- **GT14：** 距离最近，不等于救援队能够最早到达并满足响应时限； -- **GT15：** 地图结构可通行，不等于机器人当前路线没有被实时障碍占据； -- **GT16：** 初始计划已验证，不等于新遥测到来后可以停止监测；延误使预测间隔从120秒缩至80秒，系统应保留有效结论并准备增量复核； -- **GT17：** 十次上报不等于十起事件，应合并为一个任务并保留十份来源证据； -- **GT18：** 最短路线能够到达目标，不等于它满足环境风险和救援机器人耐受能力约束； -- **GT19：** 无人机到达目标上空，不等于投放区已经净空并获得载荷释放授权； -- **GT20：** 车辆获得绿灯，不等于下游出口净空且能够完整驶离路口； -- **GT21：** 遥测显示延误60秒，运行审核记录显示55秒时，AI不能按到达顺序覆盖、取平均或自行判断来源权威；必须暴露冲突并执行业务方明确声明的规则； -- **GT22：** 无人机的位置和电量来自两个系统时，AI不能简单拼接“最新字段”；必须先确认对象、时间和字段归属，才能形成可追溯的统一运行快照； -- **GT23：** 无人机飞行五分钟后位置和电量都变化时，不能只覆盖最新值；必须保留前后快照，绑定300秒时间差，并明确记录位置、电量和对象有效期变化； -- **GT24：** 临时禁飞区发布后，不能把全部任务一律重算，也不能只更新地图；必须沿显式依赖链只复核相交航线、对应任务、审批结论和起飞动作； -- **GT25：** 无人机位置从走廊100米更新到130米后，只重算与位置相关的起重机和通信塔距离，同时保留固定设施间距与电池余量； -- **GT26：** 飞行服务站营业时间从08:00—22:00调整为09:00—18:00后，只替换营业计划，保留位置、频率、服务类型和联系方式，并阻断20:30任务直至复核； -- **GT27：** 东区风速由6升至12米/秒后，只复核同区域且处于更新生效时段的任务A、D；任务A变为不适飞，任务D复核后仍适飞，任务B、C继续复用； -- **GT28：** 路线、高度、天气窗口和风速预检全部通过，但空域、运营人、起降场、气象放行和任务授权仍缺失；预检结论可引用，自动起飞授权与起飞指令保持阻断； -- **GT29：** 模拟气象服务给出8米/秒，现场传感器给出13米/秒；两个来源都新鲜且来自不同独立分组，但结果仍然冲突，因此天气结论保持未知并请求第三个独立来源； -- **GT30：** 第三个独立来源也给出13米/秒，形成二比一；但可信保证策略未声明多数表决，因此系统仍保持未知、保留8米/秒少数来源，并请求显式气象审定； -- **GT31：** 人工复核精确绑定三份冲突响应和虚构上下文证据，保留原始读数并将两份13米/秒限定为局部测试气流影响；8米/秒天气结论可用，但自动起飞授权和起飞指令继续阻断； -- **GT32：** 空域、运营人、起降场、气象放行和任务授权逐项到达，未知项从5降至0；最后两个起飞相关输出转为可用，但公共核心不发布结果、不发送指令，也不执行飞行动作； -- **GT33：** 三次带时区位置观测绑定同一移动对象，形成严格递增的离散轨迹并确定性计算持续300秒；公共核心不插值、不预测、不地图匹配，也不执行现实动作。 -- **GT34：** 三次明确观测按相邻顺序绑定为两个轨迹分段，分别计算120/180秒持续时间、60/90个文档水平单位距离和0.5水平单位/秒平均速度；公共核心不把平均速度冒充瞬时速度，不插值、预测或执行动作； -- **GT35：** 调用方显式声明5米停留半径、120秒最短停留时长、300秒最大观测间隔和缺口许可后，三个相邻分段分别输出`stationary_candidate`、`moving_observed`和`observation_gap`；缺口不允许时同一超限分段返回`unverifiable`，公共核心不推断失联、异常或连续停留； -- **GT36：** 以分段中点为代表时刻，在300秒最大观测间隔内计算相邻分段平均速度变化率；前两个转换输出0和1/300水平单位/秒²，第三个转换因下一分段持续600秒而返回`unverifiable`并保持速度差和加速度为`null`，公共核心不推断瞬时或向量加速度、方向变化、未来位置或现实动作； -- **GT37：** 两个不同临时身份绑定的轨迹边界相隔60秒、5米且对象类别相同，在调用方声明的120秒、10米和同类要求下输出`same_object_candidate`对象同一性候选；公共核心保留两个原始身份和`subject_ref`，不自动归并对象、不证明现实身份，也不发布或执行身份更新。 -- **GT38—GT42复合案例：** 虚构巡检无人机UAV-017进入建筑遮挡区后短暂失联，恢复观测时被建立为新的轨迹和临时主体。资产登记系统确认相同Remote ID和设备序列号，人工复核确认任务、机型、运营人和时间连续；GT38形成对象同一性审定，GT39选择原始主体并保留临时主体为别名，GT40记录提案审批，GT41把范围收敛为`track_beta /subject_ref`从`provisional_beta`改为`provisional_alpha`的一项请求，GT42记录应用审批。五个阶段均保持实际引用、对象关系图和World State未变，详见[复合案例手册](docs/cookbook/gt38-gt42-uav-identity-governance.zh-CN.md)。 - -GT01—GT20见[基础案例手册](docs/cookbook/gt01-gt20.zh-CN.md)，GT21—GT28见[世界状态循环案例手册](docs/cookbook/gt21-gt28.zh-CN.md)，GT29—GT32见[验证提供方接口规范](docs/spec/geotask-verification-provider-profile-v0.1.zh-CN.md)，GT33—GT42见[轨迹与移动对象Profile](docs/spec/geotask-trajectory-profile-v0.1.zh-CN.md)，GT38审定制品见[Trajectory Identity Adjudication v0.1](docs/spec/geotask-trajectory-identity-adjudication-v0.1.md)，GT39归并提案见[Identity Merge Proposal v0.1](docs/spec/geotask-identity-merge-proposal-v0.1.md)，GT40审批记录见[Identity Merge Approval Record v0.1](docs/spec/geotask-identity-merge-approval-record-v0.1.md)，GT41变更请求见[Object Graph Change Request v0.1](docs/spec/geotask-object-graph-change-request-v0.1.md)，GT42应用审批记录见[Object Graph Change Application Approval Record v0.1](docs/spec/geotask-object-graph-change-application-approval-record-v0.1.md)。 - -## 当前公共Core真正支持什么 - -### Canonical对象类型 - -`point`、`polyline`、`multi_polyline`、`polygon`、`rect`、`time_interval`、`altitude_interval`、`feature_collection`、`moving_object`和`trajectory`。 - -`moving_object`只声明稳定身份，不内嵌位置；`trajectory`必须引用一个`moving_object`，包含至少两个严格递增、带时区的二维观测样本，并显式声明`interpolation: none`。`feature_collection`已经进入Canonical IR，但具体算子只接受算子注册表中声明的对象组合。 - -### 十四个本地确定性算子 - -| 算子 | 输入 | 输出 | -|---|---|---| -| `distance_2d` | 点、点 | 数值 | -| `line_intersects_rect` | 折线、矩形 | 布尔值 | -| `multi_polyline_intersects_rect` | 多折线、矩形 | 布尔值 | -| `point_in_polygon` | 点、多边形 | 布尔值 | -| `polygon_contains_point` | 多边形、点 | 布尔值 | -| `point_to_line_distance_2d` | 点、折线 | 数值 | -| `rect_contains_point` | 矩形、点 | 布尔值 | -| `time_overlap` | 时间区间、时间区间 | 布尔值 | -| `altitude_overlap` | 高度区间、高度区间 | 布尔值 | -| `trajectory_duration_seconds` | 离散轨迹 | 秒数 | -| `trajectory_segment_metrics` | 离散轨迹 | 有序分段列表（持续时间、水平距离、平均速度） | -| `trajectory_segment_classifications` | 离散轨迹+显式阈值 | `stationary_candidate`、`moving_observed`、`observation_gap`或`unverifiable`的有序列表 | -| `trajectory_segment_acceleration_estimates` | 离散轨迹+显式中点/间隔参数 | 相邻分段平均速度变化率；缺口转换返回`unverifiable`且数值为`null` | -| `trajectory_identity_candidate` | 两段离散轨迹+显式时间/距离/类别策略 | `same_object_candidate`、`different_object_candidate`或`unverifiable`；不合并身份、不改写引用 | - -### 跨任务空间参考与单位约束 - -同一文档中的全部任务共享一套CRS、坐标顺序、水平/垂直单位和边界语义。平面算子只接受`local_cartesian`或带标识的`projected`坐标，且坐标顺序必须为`[x, y]`；Core不会把经纬度直接当作欧氏坐标，也不会自动换算单位。距离断言与高度对象必须匹配文档单位；当前边界敏感算子只支持`closed`，声明`open`会失败关闭。纯时间任务不受平面CRS门禁影响。 - -### 来源、证据与审计 - -文档可选声明`provenance.sources`、`evidence_bindings`和`audit`。Core严格校验来源ID、类型、URI/Artifact身份、SHA-256、带时区时间、断言绑定和审计引用；通过后将声明的来源ID写入对应`CheckResult.evidence_refs`。该机制不联网获取来源、不重算外部摘要，也不会仅因存在来源元数据而提升Assurance等级。 - -`geotask inspect schemas --format json`还会为每类公共Artifact返回`ide_file_patterns`，可直接用于VS Code YAML、JetBrains或其他支持JSON Schema文件匹配的IDE配置。 - -### 公共一致性与性能基准 +> **Task Sufficiency at Minimum Context Cost** -```bash -geotask benchmark core --enforce-performance --output core-benchmark.json -``` +也就是在保证关键 Requirement 不被遗漏的前提下，用尽可能少、尽可能局部的上下文支撑任务。 + +建议同时观察正指标与反指标： + +| 目标 | Counter Metric | +|---|---| +| Critical Requirement Coverage ↑ | **Critical Context Miss Rate** | +| Sufficiency Accuracy ↑ | **False Sufficiency Rate** | +| Context Reduction ↑ | **Critical Context Miss Rate** | +| Applicability Accuracy ↑ | **Irrelevant / Inapplicable Context Rate** | +| Local Rebuild ↑ | **Unnecessary Context Rebuild** | -该离线基准使用10个固定虚构案例覆盖全部14个公共确定性算子，并检查结果往返、重复执行语义指纹和Provenance证据绑定；同时测量`JSON解码→Canonical化→验证→执行→序列化`全链路。默认100毫秒p95阈值仅用于发现本机严重性能回归，不是跨硬件排名、生产SLA或模型能力评测。报告可作为`geotask.core-benchmark-report`再次严格验证。 +上下文成本不只等于 Token，可以包括网络获取、携带字节、Provider 延迟、人类恢复成本等。 -### 执行主链 +## 已公开的独立消费者：Warehouse Robot Picking + +GeoTask 已提供一个**不依赖官方 WorldState、也不依赖低空领域**的独立消费者示例： ```text -解析YAML → Canonical IR → 验证 → 执行 → GeotaskResult +Indoor GIS / topology +Inventory API +Aisle-clearance sensor + ↓ +TaskFrame + ↓ +ContextRequirement[] + ↓ +ContextCandidate[] + ↓ +Relevance / Applicability / Resolution Adequacy + ↓ +SufficiencyAssessment + ↓ +Minimum Sufficient TaskContext + ↓ +Sensor change + ↓ +Bounded Temporal Reassessment ``` -公共Core已经包含： +示例中特意保留一个关键语义：**即使测得通道比机器人更窄，只要这个测量本身相关、适用、新鲜且分辨率足够，GeoTask 仍可以判断“上下文充分”；但它不会因此判断“机器人可以通行”。** 领域安全判断与动作授权仍属于下游系统。 + +- [Warehouse Robot Picking 示例](examples/independent_consumers/warehouse_robot_picking/README.md) + +## 安装与现有工具 -- YAML解析与兼容处理； -- Canonical IR； -- 结构化诊断； -- 算子注册与确定性执行； -- 结果汇总和Assurance等级； -- 模型输出归一化； -- 模型结果与本地结果比较； -- Agent工具契约发现、生成草稿机械修复、结构化修订请求、差异约束重试、四类报告Artifact离线验证与GT08补证据恢复； -- CLI、JSON Schema、案例和一致性测试。 +```bash +pip install geotask-core +geotask inspect capabilities +geotask inspect health +``` -## 案例扩展语义 +当前公共包同时保留既有确定性算子、Artifact、Verification、Runtime/Provider、Reference Agent 与 Benchmark 能力。它们是 GeoTask 演化过程中已经发布的公共兼容资产；**新的长期语义所有权以 Task Context Engine 为主线**。 -GT07—GT20还展示了： +如果想直接查看 Task Context Engine 的组合方式，优先从独立消费者开始： -```text -unverifiable -conflicted -blocked -evidence_request -blocked_outputs -resume_when -next_action +```bash +python - <<'PY' +from examples.independent_consumers.warehouse_robot_picking.consumer import ( + build_warehouse_pick_context, +) + +run = build_warehouse_pick_context() +print(run.construction.sufficiency.status) +print(len(run.construction.context.values), len(run.minimum.context.values)) +PY ``` -这些仍是`extensions`中的控制与工作流语义，而不是基础`ClaimStatus`枚举。当前公共Core已经通过`geotask.control/1.0`对其进行严格校验和只读评估，并支持单一命名条件的补证据后重新执行；恢复过程可输出并离线验证`geotask.agent-evidence-recovery` Artifact。真实证据获取、审批和动作执行仍属于外部Runtime或Domain Pack。 +预期高层结果： -## 当前不包含什么 +```text +sufficient +4 3 +``` -公共Core不包含： +该示例是确定性参考实现，不代表真实仓储集成或机器人安全认证。 -- 托管大模型调用和模型密钥； -- 生产级任务编排、模型路由和成本治理； -- 行业Domain Pack和客户规则； -- 私有数据连接器、审批阈值和评分模型； -- 自动设备控制； -- 专利敏感优化方法和商业运行逻辑。 +## Reality Change：下一条重要主线 -详见[目标规范状态](docs/spec/target-specification-status.md)和[安全说明](SECURITY.md)。 +Task Context 不是一次性 Prompt 组装。对长任务，现实会变化：状态过期、Provider 更新、冲突出现、Unknown 被解决。 -## CLI +GeoTask 的变化响应边界是： -```bash -geotask validate -geotask run -geotask normalize -geotask eval -geotask inspect operators -geotask agent inspect --format json -geotask agent prepare --repaired-output -geotask agent retry --verification-output --prepared-output -geotask agent recover --evidence --output -geotask artifact validate geotask.agent-evidence-recovery --format json -geotask runtime inspect examples/core/runtime_reference_descriptor.json --format json -geotask runtime check examples/core/runtime_reference_descriptor.json examples/core/runtime_validate_artifact_request.json --format json -geotask runtime mock examples/core/runtime_validate_artifact_request.json --output runtime-response.json -geotask provider inspect --profile --format json -geotask provider check examples/core/verification_provider_descriptor_authoritative_weather_gt29.json examples/core/verification_request_weather_conflict_gt29.json --format json -geotask provider validate examples/core/verification_response_authoritative_weather_gt29.json --request examples/core/verification_request_weather_conflict_gt29.json --descriptor examples/core/verification_provider_descriptor_authoritative_weather_gt29.json --format json -geotask verify examples/core/verification_session_uav_recheck.json --state examples/core/world_state_uav_separation_recheck.json --observation examples/core/observation_uav_b_delay_recheck.json --bind task-gt16=examples/core/uav_route_crossing_temporal_separation.yaml --bind result-gt16-initial=examples/core/verification_session_uav_execution_result.json --bind transition-uav-recheck=examples/core/state_transition_uav_separation_recheck.json --format json -geotask recheck examples/core/incremental_reevaluation_result_uav_recheck.json --bind base-world-state=examples/core/world_state_uav_separation_recheck.json --bind successor-world-state=examples/core/world_state_uav_separation_successor.json --bind impact-graph-uav-recheck=examples/core/impact_graph_uav_recheck.json --bind correction-uav-recheck=examples/core/correction_request_uav_recheck.json --bind discrepancy-uav-recheck=examples/core/discrepancy_report_uav_recheck.json --bind result-gt16-reevaluation=examples/core/incremental_reevaluation_uav_execution_result.json --format json +```text +Changed facts / provider state + ↓ +Affected ContextRequirements + ↓ +Reassess Applicability / Resolution / Sufficiency + ↓ +ContextGap delta + ↓ +Minimal rebuild only when needed ``` -公共仓还提供[`examples/adapters/http_json_runtime_adapter.py`](examples/adapters/http_json_runtime_adapter.py)，演示如何在`geotask_core`之外把已离线检查的Descriptor绑定到独立HTTP Runtime。配套的[`examples/endpoints/reference_runtime_http_server.py`](examples/endpoints/reference_runtime_http_server.py)可在回环地址启动一个真实HTTP Endpoint，形成Adapter—Endpoint端到端闭环。两者均不在线获取Descriptor、不处理凭据、不重试、不调用模型，也不执行生产动作；传输错误与Runtime状态严格分离，返回结果仍由Core执行Descriptor / Request / Response三方契约校验。 +目标不是每次变化都重建全部上下文，而是让 **Context Rebuild Locality** 可解释、可测量。 -[`examples/model_adapters/provider_neutral/`](examples/model_adapters/provider_neutral/)进一步提供一个可独立构建的Provider-neutral模型Adapter包骨架：定义非秘密配置、结构化Provider Protocol、Mock Provider和`execute-nonlocal`映射，并在调用前验证输入Artifact、调用后验证输出Artifact及模型真实性。它拒绝模型结果冒充`verified`、`local_deterministic`或确定性执行。 +## 公开路线 -[`examples/model_adapters/openai_responses/`](examples/model_adapters/openai_responses/)在此基础上实现首个真实Provider集成：由私有启动代码注入已认证的官方OpenAI SDK客户端，公共包执行一次关闭重试、关闭存储、禁用工具的Responses API严格结构化输出调用，并将结果继续交给Artifact和真实性门禁。仓库测试仅使用模拟SDK客户端，不读取密钥，也不发起线上调用。 +当前 Task Context 主线按以下研究问题持续推进： -## 版本说明 +- **Requirement Derivation** — Task → Requirement 的稳定方法； +- **Relevance / Applicability Separation** — 同一事实对不同任务可以有不同适用性； +- **Resolution Adequacy & Sufficiency** — “有数据”不等于“足够支持任务”； +- **Minimum Context Cost** — 在 Critical Miss 不上升的前提下降低上下文成本； +- **Temporal Reassessment** — 变化只触发有界重评与最小重建； +- **Independent Consumers** — 用第二、第三领域验证 Core 不被单一业务塑形。 -| 名称 | 当前版本 | 含义 | -|---|---:|---| -| GeoTask Core包 | `0.4.1` | Python实现版本 | -| GeoTask文档Schema | `1.0` | YAML/JSON任务格式版本 | -| 语言与执行规范 | `1.0` | 当前公共实现规范 | -| Agent Integration Profile | `0.1` | 模型无关工具契约、补证据恢复与恢复报告Artifact | -| 运行时接口规范 | `0.1` | 核心与外部运行时之间的描述符、请求、响应契约 | -| 验证提供方接口规范 | `0.1` | 验证提供方描述符、验证请求、验证响应和可信保证策略 | -| 白皮书 | `0.1` | 公开概念草案 | +路线图描述研究方向和公共能力演化，不构成交付日期承诺。 -## 文档 +## Legacy / Compatibility -- [中文文档导航](docs/README.md) -- [English documentation index](docs/README.en.md) -- [中文快速入门](docs/tutorials/quickstart.zh-CN.md) -- [英文快速入门](docs/tutorials/quickstart.md) -- [GT01—GT20中文案例手册](docs/cookbook/gt01-gt20.zh-CN.md) -- [GT01—GT20 English Cookbook](docs/cookbook/gt01-gt20.md) -- [GT21—GT28世界状态循环案例手册](docs/cookbook/gt21-gt28.zh-CN.md) -- [GT21–GT28 World-State Cycle Cookbook](docs/cookbook/gt21-gt28.md) -- [JSON Schema](schemas/geotask-v1.0.schema.json) -- [状态与可信等级](docs/reference/status-model.md) -- [证据、冲突、阻断与恢复](docs/reference/evidence-and-recovery.md) -- [架构说明](docs/architecture.md) -- [算子扩展指南](docs/operator-guide.md) +GeoTask 早期公开版本以“可验证时空任务协议 / World-State Cycle / Verification”为主线，已经形成大量可验证 Artifact、案例和文档。这些资产继续保留，用于兼容、可追溯历史和已发布能力维护，但**不再定义 GeoTask 的长期产品定位**。 -## 参与项目 +需要理解旧资产时，可从以下入口进入： -欢迎提交： +- [中文文档导航](docs/README.md) +- [GT01—GT20 Cookbook](docs/cookbook/gt01-gt20.zh-CN.md) +- [GT21—GT28 World-State Cycle](docs/cookbook/gt21-gt28.zh-CN.md) +- [Reference Agent](docs/reference/reference-agent-v0.1.md) +- [Verification Quality Benchmark](docs/reference/verification-quality-benchmark-v0.2.md) +- [历史白皮书 v0.1](docs/whitepaper/GeoTask_White_Paper_v0.1.md) -- Bug和结构化诊断问题； -- 通用确定性算子建议； -- 文档与中文表达改进； -- 新的机器人、无人机、自动驾驶和城市治理案例； -- 对状态、证据和恢复语义的讨论。 +> 历史文档中的 “GeoTask = World-State Runtime / Verifiable World Model” 应按其发布时的版本语境理解；当前定位以 **Task Context Engine** 为准。 -请阅读[中文贡献指南](CONTRIBUTING.zh-CN.md)或[English Contributing Guide](CONTRIBUTING.md)。 +## 开始使用 -参与开发时再使用源码安装： +- [GeoTask 项目主页](https://stpku.github.io/GeoTask/) +- [Warehouse Robot Picking 独立消费者](examples/independent_consumers/warehouse_robot_picking/README.md) +- [5 分钟中文入门](docs/tutorials/quickstart.zh-CN.md) +- [公共 API](src/geotask_core/v1/) +- [Examples](examples/) +- [Issues](https://github.com/stpku/GeoTask/issues) +- [Releases](https://github.com/stpku/GeoTask/releases) -```bash -git clone https://github.com/stpku/GeoTask.git -cd GeoTask -python -m pip install -e ".[dev]" -pytest -``` +## License + +GeoTask Core 使用 [MIT License](LICENSE)。 -## 开源许可与边界 +--- -GeoTask Core使用[MIT License](LICENSE)。公开代码、规范和案例，与私有Runtime、Domain Pack、客户数据及专利敏感实现保持明确分离。 +**一句话：GeoTask 不负责“知道整个世界”，而负责让 Agent 在当前任务中，只拿到真正需要、适用且足够的时空上下文。** From ca1e976add71f4582c3a293ac6da6690593b21ee Mon Sep 17 00:00:00 2001 From: stpku <83755634+stpku@users.noreply.github.com> Date: Thu, 27 Aug 2026 09:49:00 +0800 Subject: [PATCH 02/17] docs: align English positioning with task context engine --- README.en.md | 457 ++++++++++++++++++++++----------------------------- 1 file changed, 197 insertions(+), 260 deletions(-) diff --git a/README.en.md b/README.en.md index 3c2413d1..7b197566 100644 --- a/README.en.md +++ b/README.en.md @@ -2,11 +2,9 @@ [简体中文](README.md) | **English** -**Open verifiable spatiotemporal task protocol and deterministic Core for AI agents.** - -> **Current:** turn observations, evidence, world state and action conditions into computable, updatable and traceable machine contracts. -> **Near term:** deliver a Reference Agent and developer product toward a trusted world-state runtime. -> **Long term:** become a reusable trusted task infrastructure layer for high-consequence physical-world agents. +> **GeoTask is a spatiotemporal Task Context Engine for AI agents.** +> +> It does not try to put “the whole world” into an agent context. It constructs the **minimum context that the current task actually needs, that is applicable, resolution-adequate, and explicitly sufficient**. [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](LICENSE) [![Python 3.10+](https://img.shields.io/badge/python-3.10%2B-blue)](https://www.python.org/) @@ -15,312 +13,251 @@ [![Release](https://img.shields.io/github/v/release/stpku/GeoTask?include_prereleases&label=release)](https://github.com/stpku/GeoTask/releases) [![PyPI](https://img.shields.io/pypi/v/geotask-core)](https://pypi.org/project/geotask-core/) -```bash -pip install geotask-core -geotask inspect capabilities -geotask inspect health -geotask agent demo --output ./geotask-reference-agent -``` +## Why Task Context instead of more context? -`inspect capabilities` projects an installed public Core index from the existing Operator, Artifact, Schema, Runtime/Provider interface, Reference Agent, and benchmark metadata. It does not discover external plugins, real Runtime/Provider instances, or domain packs, and it does not add an Artifact, Schema, or Operator. `inspect health` then checks those installed capabilities together with the Schema/Artifact/Operator registries, packaged Reference Agent, and fixed offline benchmarks without network, model, or production access. Its diagnostic payload is not a registered GeoTask Artifact and does not claim real-world correctness. `agent demo` then verifies the packaged Reference Agent teaching bundle, materializes an editable local workspace, and immediately replays the deterministic success scenario. It does not fetch external truth, write production state, or authorize a real-world action. +For an agent working on a real task, the hard questions are usually not “do we have data?” but: -GeoTask turns multimodal models, sensors, maps, authoritative data, and human input into explicit world objects, spatiotemporal relations, state, evidence, and action constraints. It builds a world state that is computable, verifiable, updatable, and traceable. Rather than hiding the whole world inside a neural representation, GeoTask makes the facts an agent depends on inspectable, recomputable, correctable, and maintainable. +- **What does this task actually need to know?** +- A fact may be relevant, but is it applicable to this object, place, time, and condition? +- Is its spatial, temporal, or semantic resolution adequate for the task? +- Is the resulting context sufficient, or is a critical gap still open? +- Can irrelevant context be removed without increasing critical misses? +- When reality changes, which requirements must be reassessed and which context can be reused? -- **Multimodal models perceive and reason openly:** observations, hypotheses, explanations, and plans from text, maps, imagery, video, and state data. -- **GeoTask Core provides world-state specifications, interface contracts, and a verification kernel:** explicit objects, coordinates, time, relations, evidence, and claims with local deterministic verification. -- **Verification and control maintain the world:** preserve supported facts, expose conflict and unknown states, constrain correction, and manage action eligibility. -- **Runtimes and Domain Packs connect reality:** authoritative data, industry rules, local predictive models, human review, and production actions. +GeoTask turns these questions into explicit, composable, testable Task Context contracts and methods. -> **Engineering boundary:** GeoTask Core provides public world-state contracts, deterministic validation, exact Artifact binding, and fail-closed control semantics; the verifiable task protocol remains the current implementation form. The implemented public profile covers Observation, World State, bounded Observation Merge, State Transition, Verification Session, Discrepancy Report, Correction Request, Impact Graph, bounded recompute derivation, bounded successor materialization, Incremental Reevaluation Result, Verification Provider Descriptor, Verification Request, Verification Response, Assurance Profile, Trajectory Identity Adjudication, Identity Merge Proposal, Identity Merge Approval Record, Object Graph Change Request, and Object Graph Change Application Approval Record. Core does not fetch external truth, invent undeclared source precedence, publish production output, authorize actions, or execute side effects. +```text +Task + ↓ +derive requirements + ↓ +discover candidates + ↓ +Relevance + ↓ +Applicability + ↓ +Resolution Adequacy + ↓ +Sufficiency + ↓ +Minimum Sufficient TaskContext + ↓ +Explicit Gaps / Trace / Cost +``` -## Start here +## Core semantics -- [Explore 42 public reference examples across 38 scenario entries](https://stpku.github.io/GeoTask/) -- [English ecosystem homepage](https://stpku.github.io/GeoTask/en/) -- [Quickstart](docs/tutorials/quickstart.md) -- [White Paper v0.1](docs/whitepaper/GeoTask_White_Paper_v0.1.md) -- [White paper English abstract](docs/whitepaper/GeoTask_White_Paper_v0.1.md#english-abstract) -- [Implemented Language and Execution Specification v1.0](docs/spec/geotask-language-spec-v1.0.md) -- [GeoTask Observation v0.1](docs/spec/geotask-observation-v0.1.md) -- [GeoTask World State v0.1](docs/spec/geotask-world-state-v0.1.md) -- [GeoTask Observation Merge Result v0.1](docs/spec/geotask-observation-merge-result-v0.1.md) -- [GeoTask State Transition v0.1](docs/spec/geotask-state-transition-v0.1.md) -- [GeoTask Verification Session v0.1](docs/spec/geotask-verification-session-v0.1.md) -- [GeoTask Discrepancy Report v0.1](docs/spec/geotask-discrepancy-report-v0.1.md) -- [GeoTask Correction Request v0.1](docs/spec/geotask-correction-request-v0.1.md) -- [GeoTask Impact Graph v0.1](docs/spec/geotask-impact-graph-v0.1.md) -- [GeoTask Recompute Derivation Result v0.1](docs/spec/geotask-recompute-derivation-result-v0.1.md) -- [GeoTask World State Materialization Result v0.1](docs/spec/geotask-world-state-materialization-result-v0.1.md) -- [GeoTask Incremental Reevaluation Result v0.1](docs/spec/geotask-incremental-reevaluation-result-v0.1.md) -- [GeoTask Agent Integration Profile v0.1](docs/spec/geotask-agent-integration-profile-v0.1.md) -- [GeoTask Runtime Interface Profile v0.1](docs/spec/geotask-runtime-interface-profile-v0.1.md) -- [GeoTask Verification Provider Profile v0.1](docs/spec/geotask-verification-provider-profile-v0.1.md) -- [GeoTask Object Graph Change Request v0.1](docs/spec/geotask-object-graph-change-request-v0.1.md) -- [English Terminology Guide](docs/terminology.en.md) -- [GeoTask Core Agent Skill](skills/geotask-core/SKILL.md) -- [VS Code Schema association example](.vscode/settings.json) -- [GT01–GT20 Cookbook](docs/cookbook/gt01-gt20.md) -- [GT21–GT28 World-State Cycle Cookbook](docs/cookbook/gt21-gt28.md) -- [GT38–GT42 UAV Identity-Governance Composite Case](docs/cookbook/gt38-gt42-uav-identity-governance.md) -- [v0.4.1 Capability Discovery and Release-Hardening maintenance release notes](docs/release_v0_4_1.md) -- [v0.4.0 Core Productization and Reference Agent release notes](docs/release_v0_4_0.md) -- [v0.3.0 Agent Integration release notes](docs/release_v0_3_0.md) -- [v0.2.0 artifact-contract release notes](docs/release_v0_2_0.md) -- [Architecture Manifesto v1](docs/architecture_manifesto_v1.md) -- [Reference Agent v0.1 specification](docs/reference/reference-agent-v0.1.md) -- [Run the Reference Agent: fictional facility assessment update](examples/reference_agent/facility_assessment_update/README.md) -- [Reference Agent end-to-end tutorial](docs/tutorials/reference-agent.md) -- [Verification Quality Benchmark v0.1](docs/reference/verification-quality-benchmark-v0.1.md) — run from an installed package with `geotask benchmark quality` -- [Verification Quality Benchmark v0.2](docs/reference/verification-quality-benchmark-v0.2.md) — run 34 deterministic synthetic perturbations with `geotask benchmark quality --suite perturbation`; no real-world accuracy or cross-domain claim -- [GeoTask ↔ Lowa-GT Integration Contract v0.1](docs/reference/lowa-gt-integration-contract-v0.1.md) -- [Cross-Line Promotion Gate v0.1](docs/reference/cross-line-promotion-gate-v0.1.md) -- [Core Distribution Boundary v0.1](docs/reference/core-distribution-boundary-v0.1.md) -- [Productization Roadmap v0.2](docs/productization_roadmap_v0_2.md) -- [Public roadmap](ROADMAP.md) -- [Documentation index](docs/README.en.md) +The current public Core exposes task-context primitives and composition seams including: -## Why agents need a verifiable world model +- `TaskFrame` +- `ContextRequirement` +- `ContextCandidate` +- `RelevanceResult` +- `ApplicabilityResult` +- `ResolutionRequirement` / `ResolutionAdequacyResult` +- `ContextAssessment` +- `ContextGap` +- `SufficiencyAssessment` +- `TaskContext` +- `ContextConstructionTrace` +- `ContextMinimalityAssessment` +- `MinimumSufficientTaskContext` +- temporal reassessment / continuity contracts -Multimodal models are becoming better at understanding scenes, calling tools, and proposing plans, but their “understanding of the world” is usually implicit in context, vectors, or parameters. Before real action, an agent still needs an explicit, shared, verifiable world state that continuously answers: +The contracts deliberately preserve these distinctions: -- which objects exist, where and when they exist, and what state they are in; -- which relations and constraints hold, remain unknown, conflict, or lack evidence; -- which world states and conclusions must change when a new observation arrives; -- which facts come from models, sensors, authoritative data, or human review; -- which actions are currently permitted by the maintained world state. +```text +Context ≠ World State +Relevant ≠ Applicable +Applicable ≠ Sufficient +Candidate exists ≠ Requirement satisfied +Large payload ≠ Sufficient context +Provider returned a value ≠ Valid task context +Context sufficient ≠ Domain decision +Context sufficient ≠ Action authorization +``` -A tool call can compute one function, but it does not automatically maintain object identity, world snapshots, evidence state, change impact, or action boundaries. GeoTask organizes those concerns into verifiable and auditable world-model primitives and Artifacts: +## What GeoTask owns -```mermaid -flowchart LR - O[Multimodal observations and external state] --> W[Explicit spatiotemporal world state] - W --> R[Relations, constraints, and world claims] - R --> V[Local verification and evidence governance] - V --> U[State update, correction, and recheck] - U --> G[Action eligibility and external Runtime] - N[New observation arrives] --> W -``` +GeoTask owns **task-relative context**: -The current public Core implements world objects and spatial contracts, source and evidence bindings, Observation, World State, bounded Observation Merge, State Transition, Verification Session, Discrepancy Report, Correction Request, Impact Graph, source-bound bounded recompute derivation, bounded successor-state materialization, Incremental Reevaluation Result, Verification Provider contracts, Trajectory Identity Adjudication, Identity Merge Proposal, Identity Merge Approval Record, Object Graph Change Request, Object Graph Change Application Approval Record, world claims, deterministic relation verification, control states, mechanical Agent repair, and bounded-path retry. Automatic diff computation, resolution of ambiguous claims without a declared policy, automatic impact discovery and propagation execution, object-graph change application and application-result records, and general-purpose derivation methods remain roadmap capabilities. +1. frame the task, goal, and scope with `TaskFrame`; +2. derive or receive `ContextRequirement` objects; +3. acquire `ContextCandidate` objects from GIS, API, sensor, database, WorldState, or other providers; +4. assess relevance, applicability, and resolution adequacy separately; +5. keep requirement-level assessments and gaps explicit; +6. compose `SufficiencyAssessment` through an explicit method; +7. construct `TaskContext` and seek a minimum sufficient context without increasing critical misses; +8. when a provider or reality changes, reassess only affected requirements and reuse unaffected context where valid. -## Five-minute quickstart +GeoTask **does not own world truth** and does not replace an agent harness, GIS, database, knowledge graph, RAG system, or domain decision system. -```bash -python -m pip install geotask-core -geotask --help -geotask inspect operators +```text +World / Data Providers +WorldState · GIS · API · Sensor · Database · GSTAR · ... + │ + ▼ + ┌─────────┐ + │ GeoTask │ + │ Task │ + │ Context │ + └────┬────┘ + │ + ▼ + Agent / Harness + │ + ▼ + Domain Decision / Action ``` -Save this minimal task as `my_distance.yaml`: +**A provider can tell GeoTask what candidate information exists. GeoTask evaluates whether that information is needed, applicable, and sufficient for the current task.** + +## North Star: sufficiency, not accumulation + +GeoTask's long-term North Star is: + +> **Task Sufficiency at Minimum Context Cost** + +The goal is to support the task with the smallest useful context while keeping critical requirement misses visible. -```yaml -geotask: - id: "example" - schema_version: "1.0" +Positive metrics should be paired with counter-metrics: -objects: - a: {type: "point", coordinates: [0, 0]} - b: {type: "point", coordinates: [3, 4]} +| Goal | Counter-metric | +|---|---| +| Critical Requirement Coverage ↑ | **Critical Context Miss Rate** | +| Sufficiency Accuracy ↑ | **False Sufficiency Rate** | +| Context Reduction ↑ | **Critical Context Miss Rate** | +| Applicability Accuracy ↑ | **Irrelevant / Inapplicable Context Rate** | +| Local Rebuild ↑ | **Unnecessary Context Rebuild** | -operator_set: [distance_2d] +Context cost can include acquisition cost, carried bytes, token cost, provider latency, and human recovery cost. -tasks: - - id: "calc" - assertions: - - id: "ab" - operator: "distance_2d" - object_refs: ["a", "b"] +## Public independent consumer: Warehouse Robot Picking + +GeoTask includes an independent public consumer that does **not** require the official WorldState implementation and does not depend on the low-altitude domain: + +```text +Indoor GIS / topology +Inventory API +Aisle-clearance sensor + ↓ +TaskFrame + ↓ +ContextRequirement[] + ↓ +ContextCandidate[] + ↓ +Relevance / Applicability / Resolution Adequacy + ↓ +SufficiencyAssessment + ↓ +Minimum Sufficient TaskContext + ↓ +Sensor change + ↓ +Bounded Temporal Reassessment ``` -The local executor returns `ab = 5.0 meter` with `assurance_level: local_deterministic`. +The example preserves an important boundary: if an aisle is measured narrower than the robot, GeoTask may still conclude that **the context is sufficient** when that measurement is relevant, applicable, fresh, and resolution-adequate. It does **not** conclude that the robot may traverse the aisle. Domain safety and action authorization remain downstream. + +- [Warehouse Robot Picking example](examples/independent_consumers/warehouse_robot_picking/README.md) + +## Install and inspect ```bash -geotask validate my_distance.yaml -geotask run my_distance.yaml +pip install geotask-core +geotask inspect capabilities +geotask inspect health ``` -## 42 public reference examples across 38 scenario entries - -The examples show how model proposals are materialized, recomputed, contradicted, evidence-gated, corrected, and kept behind action boundaries across robotics, UAV, vehicle, and emergency scenarios. GT38–GT42 are not five independent application cases: together they form one five-stage identity-governance composite case about inspection drone UAV-017 receiving a new provisional identity after a brief tracking loss. - -| Stage | Cases | Main question | -|---|---|---| -| Geometry | GT01–GT03 | What spatial relationship is actually true? | -| Space-time composition | GT04–GT06 | Do horizontal, vertical, and temporal conditions all hold? | -| Uncertainty and evidence | GT07–GT09 | What happens when evidence is missing or conflicting? | -| Action and feasibility | GT10–GT20 | What executable action follows from verified spatial, resource, response, live-environment, multi-UAV conflict, city-event deduplication, equipment-capability, and high-risk action-gate constraints? | -| World-state cycle | GT21–GT28 | How do multi-source observations, state change, impact scope, bounded correction, incremental reevaluation, and action gates close the loop? | -| Verification Provider ecosystem | GT29–GT32 | How do independent sources, explicit adjudication, progressive authorization, and action gates remain separate? | -| Dynamic world objects | GT33–GT37 plus the GT38–GT42 composite case | The first five examples cover trajectory semantics and identity candidates; the final five reference examples form one UAV-017 re-identification and identity-governance workflow. | - -Selected examples: - -- **GT07:** unknown is not false when a schedule cannot be verified. -- **GT09:** two individually verified no-fly notices can still conflict. -- **GT10:** two robots competing for one corridor need an explicit coordination policy. -- **GT11:** a target 50 meters away may require a 300-meter accessible route. -- **GT12:** enough energy to arrive is not enough to complete a UAV mission safely. -- **GT13:** an open road may still be impassable for a specific vehicle envelope. -- **GT14:** the nearest rescue team may not have the earliest verified arrival or meet the response deadline. -- **GT15:** a structurally passable map corridor may still be occupied by a live obstacle. -- **GT16:** an initially verified plan does not justify stopping monitoring after new telemetry arrives; a delay reduces predicted separation from 120 to 80 seconds, so valid findings are preserved while reevaluation remains armed. -- **GT17:** ten reports of one incident should create one dispatch task while preserving all ten evidence sources. -- **GT18:** the geometrically shortest route may be unsafe when it crosses a hazard beyond the rescue robot's operating capability. -- **GT19:** reaching the target overhead does not authorize payload release while the live ground-clearance condition remains false. -- **GT20:** a green signal does not authorize intersection entry while the downstream exit cannot store and clear the full vehicle. -- **GT21:** when telemetry says a 60-second delay and an operations review says 55 seconds, the AI must not overwrite by arrival order, average the values, or invent source authority; it must expose the conflict and apply a caller-declared rule. -- **GT22:** when position and battery data come from different systems, the AI must not assemble a “current state” from the latest fields alone; it must first bind object identity, time, and field ownership into one traceable operational snapshot; -- **GT23:** when position and battery change over five minutes, the system must not overwrite the earlier values; it must retain both snapshots, bind the 300-second interval, and explicitly record position, battery, and object-validity changes; -- **GT24:** when a temporary no-fly zone is published, the system must neither recompute every operation nor update only the map; it must follow an explicit dependency chain and recheck only the intersecting route, its mission, approval conclusion, and launch action; -- **GT25:** when the UAV position moves from corridor chainage 100 to 130 metres, the system recomputes only the crane and tower distances that depend on position while preserving fixed-facility spacing and battery state; -- **GT26:** when a flight-service station schedule changes from 08:00–22:00 to 09:00–18:00, the system replaces only the schedule, preserves location, radio frequency, service types, and contact channel, and blocks the 20:30 mission until recheck; -- **GT27:** when east-zone wind rises from 6 to 12 m/s, the system reevaluates only Missions A and D in the matching region and active time window; Mission A becomes unsuitable, Mission D remains suitable after recheck, and Missions B and C are reused; -- **GT28:** route, altitude, weather-window, and wind checks all pass, but airspace, operator, departure-site, weather-release, and mission authorizations remain absent; the precheck is reusable while automatic takeoff authorization and the takeoff command stay blocked. -- **GT29:** a mock weather service reports 8 m/s while an onsite sensor reports 13 m/s against a 12 m/s mission limit; both responses are fresh and independently grouped, but the result remains unknown and a third independent source is requested; -- **GT30:** a third independent source also reports 13 m/s, creating a two-to-one split; because no majority policy is declared, Assurance remains unknown, the 8 m/s minority source is preserved, and explicit weather adjudication is requested; -- **GT31:** a fictional human review binds the three conflicting responses and scoped context evidence, preserves all raw results, and treats the two 13 m/s readings as local-test-flow observations; the 8 m/s weather conclusion becomes eligible while automatic takeoff authorization and the takeoff command remain blocked; -- **GT32:** five fictional authorization records arrive one by one, reducing unknown authorization fields from five to zero. The final control evaluation makes automatic takeoff authorization and the takeoff command eligible, while Core still does not publish output, send a command, authorize reality, or execute flight. -- **GT33:** three timezone-aware position observations bind to one moving object as a strictly ordered discrete trajectory. Core deterministically returns a 300-second duration without interpolation, prediction, map matching, publication, or action execution. -- **GT34:** three explicit observations bind into two adjacent trajectory segments. Core returns 120/180-second durations, 60/90 document-horizontal-unit distances, and 0.5 horizontal-unit-per-second averages without treating average speed as instantaneous state, interpolating, predicting, or executing action. -- **GT35:** with a caller-declared 5-unit stationary radius, 120-second minimum duration, 300-second maximum observation interval, and explicit gap permission, three adjacent segments become `stationary_candidate`, `moving_observed`, and `observation_gap`. When gap marking is disallowed, the same excessive interval becomes `unverifiable`; Core does not infer lost link, anomaly, or continuous stationary motion. -- **GT36:** segment midpoints represent adjacent segment-average speeds under a caller-declared 300-second maximum interval. The first two transitions produce scalar acceleration estimates of 0 and 1/300 horizontal units per second squared; the third becomes `unverifiable` with null speed change and acceleration because the next segment lasts 600 seconds. Core does not infer instantaneous or vector acceleration, direction change, future position, or action. -- **GT37:** two trajectory fragments bound to different provisional identities have boundary samples 60 seconds and 5 meters apart and share the same object class. Under caller-declared 120-second, 10-unit, and class-equality limits, Core returns `same_object_candidate` while preserving both identities and subject references. It does not verify real-world identity, merge objects, publish, or execute an identity update. -- **GT38–GT42 composite case:** fictional inspection drone UAV-017 enters a building-shadow region and is briefly lost. Observation resumes 60 seconds later and five meters away, but the tracker creates a new trajectory and provisional subject. A fictional asset registry reports the same Remote ID and device serial number, while a fictional human review confirms mission, model, operator, and temporal continuity. GT38 adjudicates the identity evidence; GT39 selects the original subject and retains the resumed subject as an alias; GT40 records proposal approval; GT41 narrows the requested mutation to `track_beta /subject_ref`, from `provisional_beta` to `provisional_alpha`; and GT42 records application approval. All five stages keep the actual references, object graph, and World State unchanged. See the [composite-case cookbook](docs/cookbook/gt38-gt42-uav-identity-governance.md). - -See the [GT01–GT20 Cookbook](docs/cookbook/gt01-gt20.md), the [GT21–GT28 World-State Cycle Cookbook](docs/cookbook/gt21-gt28.md), the [Verification Provider Profile](docs/spec/geotask-verification-provider-profile-v0.1.md) for GT29–GT32, the [Trajectory and Moving Object Profile](docs/spec/geotask-trajectory-profile-v0.1.md) for GT33–GT42, the [Trajectory Identity Adjudication v0.1](docs/spec/geotask-trajectory-identity-adjudication-v0.1.md) for GT38, the [Identity Merge Proposal v0.1](docs/spec/geotask-identity-merge-proposal-v0.1.md) for GT39, the [Identity Merge Approval Record v0.1](docs/spec/geotask-identity-merge-approval-record-v0.1.md) for GT40, the [Object Graph Change Request v0.1](docs/spec/geotask-object-graph-change-request-v0.1.md) for GT41, and the [Object Graph Change Application Approval Record v0.1](docs/spec/geotask-object-graph-change-application-approval-record-v0.1.md) for GT42. - -## Implemented public Core - -### Canonical object types - -`point`, `polyline`, `multi_polyline`, `polygon`, `rect`, `time_interval`, `altitude_interval`, `feature_collection`, `moving_object`, and `trajectory`. - -A `moving_object` declares stable identity without embedding position. A `trajectory` must reference one `moving_object`, contain at least two strictly increasing timezone-aware 2D observation samples, and declare `interpolation: none`. `feature_collection` remains represented in the Canonical IR; individual operators accept only combinations declared by the operator registry. - -### Deterministic operators - -| Operator | Inputs | Output | -|---|---|---| -| `distance_2d` | point, point | number | -| `line_intersects_rect` | polyline, rect | boolean | -| `multi_polyline_intersects_rect` | multi-polyline, rect | boolean | -| `point_in_polygon` | point, polygon | boolean | -| `polygon_contains_point` | polygon, point | boolean | -| `point_to_line_distance_2d` | point, polyline | number | -| `rect_contains_point` | rect, point | boolean | -| `time_overlap` | time interval, time interval | boolean | -| `altitude_overlap` | altitude interval, altitude interval | boolean | -| `trajectory_duration_seconds` | discrete trajectory | seconds | -| `trajectory_segment_metrics` | discrete trajectory | ordered segment list with duration, horizontal distance, and average speed | -| `trajectory_segment_classifications` | discrete trajectory + explicit thresholds | ordered `stationary_candidate`, `moving_observed`, `observation_gap`, or `unverifiable` records | -| `trajectory_segment_acceleration_estimates` | discrete trajectory + explicit midpoint/gap parameters | adjacent segment-average speed-change rates; gap transitions are `unverifiable` with null values | -| `trajectory_identity_candidate` | two discrete trajectories + explicit time/distance/class policy | `same_object_candidate`, `different_object_candidate`, or `unverifiable` without identity merge or reference mutation | - -### Cross-task space contract - -All tasks in one document share one CRS, coordinate order, horizontal/vertical unit, and boundary contract. Planar operators accept only `local_cartesian` or an identified `projected` CRS and require `[x, y]`; Core does not treat longitude/latitude as Euclidean coordinates or convert units. Distance assertions and altitude objects must match the document units. Current boundary-sensitive operators support `closed` only and fail closed when `open` is declared. Pure temporal tasks are not blocked by the planar CRS gate. - -### Provenance, evidence, and audit - -Documents may optionally declare `provenance.sources`, `evidence_bindings`, and `audit`. Core strictly validates source identity, kind, URI/Artifact identity, SHA-256, timezone-aware timestamps, assertion bindings, and audit references. Valid bindings are copied to the corresponding `CheckResult.evidence_refs`. Core does not fetch sources, recompute external digests, or raise assurance merely because provenance metadata exists. - -`geotask inspect schemas --format json` also returns portable `ide_file_patterns` for every public Artifact, suitable for VS Code YAML, JetBrains, and other IDEs that associate files with JSON Schemas. - -### Public conformance and performance benchmark +The public package also retains previously released deterministic operators, Artifacts, Verification, Runtime/Provider, Reference Agent, and benchmark capabilities. They remain supported public compatibility assets from GeoTask's earlier evolution; **the long-term semantic direction is now Task Context Engine**. + +To inspect the Task Context Engine composition directly, start with the independent consumer: ```bash -geotask benchmark core --enforce-performance --output core-benchmark.json +python - <<'PY' +from examples.independent_consumers.warehouse_robot_picking.consumer import ( + build_warehouse_pick_context, +) + +run = build_warehouse_pick_context() +print(run.construction.sufficiency.status) +print(len(run.construction.context.values), len(run.minimum.context.values)) +PY ``` -The offline benchmark uses ten fixed fictional cases to cover all fourteen public deterministic operators, result round trips, semantic replay digests, and provenance evidence bindings. It measures the full `JSON decode → canonicalize → validate → execute → serialize` path. The default 100 ms p95 threshold is only a broad local regression guardrail, not a cross-hardware ranking, production SLA, or model-quality benchmark. The retained report is registered as `geotask.core-benchmark-report` and can be strictly validated again. - -### Execution chain +Expected high-level output: ```text -parse YAML → canonicalize → validate → execute → GeotaskResult +sufficient +4 3 ``` -The public Core includes YAML parsing, Canonical IR, structured diagnostics, deterministic execution, result assembly, assurance metadata, model-output normalization, local verification, Agent tool-contract discovery, mechanical preparation of generated drafts, structured revision requests, guarded revision-diff retries, offline validation of four registered Agent report Artifacts, deterministic GT08 evidence recovery, CLI commands, JSON Schema, examples, and conformance tests. +This is a deterministic reference example, not a live warehouse integration or robot-safety certification. -## Workflow semantics in the weekly cases +## Reality change is a context problem too -The cases also demonstrate `unverifiable`, `conflicted`, `blocked`, `evidence_request`, `blocked_outputs`, `resume_when`, and `next_action`. These remain control and workflow semantics under `extensions`, not base `ClaimStatus` enum values. The public Core strictly validates and read-only evaluates them through `geotask.control/1.0`, and can recover one single-named condition by rerunning the affected deterministic assertion. The recovery trace is available as the offline-verifiable `geotask.agent-evidence-recovery` Artifact. Real evidence retrieval, approval, and action execution remain outside Core in a Runtime or Domain Pack. +Task Context is not one-shot prompt assembly. During long-running work, reality changes: state expires, providers update, conflicts appear, and unknowns are resolved. -## Not included in the public Core +GeoTask's change-response boundary is: -- Hosted model execution or API keys -- Production orchestration and model routing -- Industry Domain Packs and customer rules -- Private data connectors and approval thresholds -- Automatic device control -- Patent-sensitive optimization and commercial governance +```text +Changed facts / provider state + ↓ +Affected ContextRequirements + ↓ +Reassess Applicability / Resolution / Sufficiency + ↓ +ContextGap delta + ↓ +Minimal rebuild only when needed +``` -See [Target Specification Status](docs/spec/target-specification-status.md) and [Security](SECURITY.md). +The objective is not to rebuild everything after every change, but to make **context rebuild locality** explicit and measurable. -## CLI +## Public research direction -```bash -geotask validate -geotask run -geotask normalize -geotask eval -geotask inspect operators -geotask agent inspect --format json -geotask agent prepare --repaired-output -geotask agent retry --verification-output --prepared-output -geotask agent recover --evidence --output -geotask artifact validate geotask.agent-evidence-recovery --format json -geotask runtime inspect examples/core/runtime_reference_descriptor.json --format json -geotask runtime check examples/core/runtime_reference_descriptor.json examples/core/runtime_validate_artifact_request.json --format json -geotask runtime mock examples/core/runtime_validate_artifact_request.json --output runtime-response.json -geotask provider inspect --profile --format json -geotask provider check examples/core/verification_provider_descriptor_authoritative_weather_gt29.json examples/core/verification_request_weather_conflict_gt29.json --format json -geotask provider validate examples/core/verification_response_authoritative_weather_gt29.json --request examples/core/verification_request_weather_conflict_gt29.json --descriptor examples/core/verification_provider_descriptor_authoritative_weather_gt29.json --format json -geotask verify examples/core/verification_session_uav_recheck.json --state examples/core/world_state_uav_separation_recheck.json --observation examples/core/observation_uav_b_delay_recheck.json --bind task-gt16=examples/core/uav_route_crossing_temporal_separation.yaml --bind result-gt16-initial=examples/core/verification_session_uav_execution_result.json --bind transition-uav-recheck=examples/core/state_transition_uav_separation_recheck.json --format json -geotask recheck examples/core/incremental_reevaluation_result_uav_recheck.json --bind base-world-state=examples/core/world_state_uav_separation_recheck.json --bind successor-world-state=examples/core/world_state_uav_separation_successor.json --bind impact-graph-uav-recheck=examples/core/impact_graph_uav_recheck.json --bind correction-uav-recheck=examples/core/correction_request_uav_recheck.json --bind discrepancy-uav-recheck=examples/core/discrepancy_report_uav_recheck.json --bind result-gt16-reevaluation=examples/core/incremental_reevaluation_uav_execution_result.json --format json -``` +The current Task Context line advances through these problems: -The public repository also includes [`examples/adapters/http_json_runtime_adapter.py`](examples/adapters/http_json_runtime_adapter.py), showing how an offline-inspected Descriptor can be bound to an independently hosted HTTP Runtime outside `geotask_core`. The paired [`examples/endpoints/reference_runtime_http_server.py`](examples/endpoints/reference_runtime_http_server.py) starts a real loopback HTTP Endpoint and completes the Adapter-to-Endpoint path. Neither example fetches the Descriptor online, manages credentials, retries, calls a model, or executes production actions; transport errors remain separate from Runtime states, and the returned Response still passes Core's Descriptor / Request / Response three-way contract validation. +- **Requirement Derivation** — stable Task → Requirement methods; +- **Relevance / Applicability Separation** — the same fact can have different applicability for different tasks; +- **Resolution Adequacy & Sufficiency** — data availability is not the same as task adequacy; +- **Minimum Context Cost** — reduce context cost without increasing critical misses; +- **Temporal Reassessment** — bounded reassessment and minimal rebuild after change; +- **Independent Consumers** — validate the Core in additional domains so one product cannot shape the semantics. -[`examples/model_adapters/provider_neutral/`](examples/model_adapters/provider_neutral/) adds an independently buildable provider-neutral model Adapter package skeleton. It defines non-secret configuration, a structural Provider Protocol, a Mock Provider, and `execute-nonlocal` mapping, validates registered input and output Artifacts, and rejects model output that pretends to be `verified`, `local_deterministic`, or deterministic. +These are research and public capability directions, not delivery-date commitments. -[`examples/model_adapters/openai_responses/`](examples/model_adapters/openai_responses/) builds the first real provider integration on that boundary. Private startup code injects an authenticated official OpenAI SDK client; the public package performs one no-retry, no-storage, tool-free Responses API call with strict Structured Outputs and then sends the nested result through Artifact and truthfulness validation. Repository tests use only a fake SDK-shaped client, read no key, and make no live request. +## Legacy / compatibility -## Version map +Earlier public GeoTask releases centered on a verifiable spatiotemporal task protocol, World-State Cycle, Verification, and related Artifacts. Those assets remain for compatibility, traceability, and maintenance of released capabilities, but they **no longer define GeoTask's long-term product positioning**. -| Artifact | Current version | Meaning | -|---|---:|---| -| GeoTask Core package | `0.4.1` | Python implementation version | -| GeoTask document schema | `1.0` | YAML/JSON document format | -| Language specification | `1.0` | Implemented public normative profile | -| Agent Integration Profile | `0.1` | Model-neutral tool contract, evidence recovery, and recovery-report Artifact | -| Runtime Interface Profile | `0.1` | Descriptor, Request, and Response contracts between Core and an external Runtime | -| Verification Provider Profile | `0.1` | Provider Descriptor, Verification Request, Verification Response, and Assurance Profile contracts | -| White paper | `0.1` | Public conceptual draft | +Useful legacy entry points: -## Documentation +- [Documentation index](docs/README.en.md) +- [GT01–GT20 Cookbook](docs/cookbook/gt01-gt20.md) +- [GT21–GT28 World-State Cycle](docs/cookbook/gt21-gt28.md) +- [Reference Agent](docs/reference/reference-agent-v0.1.md) +- [Verification Quality Benchmark](docs/reference/verification-quality-benchmark-v0.2.md) +- [Historical White Paper v0.1](docs/whitepaper/GeoTask_White_Paper_v0.1.md) -- [English documentation index](docs/README.en.md) -- [中文文档导航](docs/README.md) -- [JSON Schema](schemas/geotask-v1.0.schema.json) -- [Status and Assurance Model](docs/reference/status-model.md) -- [Evidence, Conflict, Blocking, and Recovery](docs/reference/evidence-and-recovery.md) -- [Architecture](docs/architecture.md) -- [Operator extension guide](docs/operator-guide.md) +> Historical documents that describe “GeoTask = World-State Runtime / Verifiable World Model” should be read in their release-era context. The current positioning is **Task Context Engine**. -## Contributing +## Start here -Read [CONTRIBUTING.md](CONTRIBUTING.md) or [中文贡献指南](CONTRIBUTING.zh-CN.md). Bug reports, operator proposals, documentation improvements, and new application-case ideas are welcome. +- [GeoTask project homepage](https://stpku.github.io/GeoTask/) +- [Warehouse Robot Picking independent consumer](examples/independent_consumers/warehouse_robot_picking/README.md) +- [Quickstart](docs/tutorials/quickstart.md) +- [Public API](src/geotask_core/v1/) +- [Examples](examples/) +- [Issues](https://github.com/stpku/GeoTask/issues) +- [Releases](https://github.com/stpku/GeoTask/releases) -Use an editable source install only when contributing to development: +## License -```bash -git clone https://github.com/stpku/GeoTask.git -cd GeoTask -python -m pip install -e ".[dev]" -pytest -``` +GeoTask Core is released under the [MIT License](LICENSE). -## License and boundary +--- -GeoTask Core is released under the [MIT License](LICENSE). Public code, specifications, and examples are separate from private Runtime, Domain Packs, customer data, and patent-sensitive implementation details. +**In one sentence: GeoTask does not try to know the whole world; it helps an agent obtain only the spatiotemporal context that the current task actually needs, that applies, and that is sufficient.** From 48aeb51ed849fcf3b3ef418b399aae025dcdac3f Mon Sep 17 00:00:00 2001 From: stpku <83755634+stpku@users.noreply.github.com> Date: Thu, 27 Aug 2026 09:50:08 +0800 Subject: [PATCH 03/17] docs: rebuild Chinese portal around task context --- site/index.html | 426 +++++++++++------------------------------------- 1 file changed, 93 insertions(+), 333 deletions(-) diff --git a/site/index.html b/site/index.html index 076e9ddf..44124560 100644 --- a/site/index.html +++ b/site/index.html @@ -3,394 +3,154 @@ - - - + + + - + + - - + + - - - GeoTask｜面向智能体的可验证时空世界模型 + + + GeoTask｜面向 AI Agent 的时空任务上下文引擎 - - -
+
- GTGeoTask -
-
+
-

显式、可验证的时空世界模型

-

智能体的可验证
时空世界模型

-

GeoTask将多模态模型、传感器、地图、权威数据和人工输入转化为显式的世界对象、关系、状态、证据与行动约束，让智能体依赖的现实世界可以被计算、验证、更新和追溯。

-
让大模型理解世界，让GeoTask验证并维护世界。
+

Spatiotemporal Task Context Engine for AI Agents

+

不是给 Agent 更多上下文，
而是给它当前任务真正需要的上下文。

+

GeoTask 围绕任务构造相关、适用、分辨率足够且可明确判断充分性的时空上下文，并在现实变化后只重评真正受影响的部分。

+
Task Sufficiency at Minimum Context Cost —— 用最小必要上下文支撑任务，同时让 Critical Context Miss 保持可见。
- 体验一次世界状态更新 - 查看世界模型架构 - 阅读中文白皮书 + 查看 GitHub + 看独立消费者 + 阅读 README
-
-
42公开可验证示例
-
14本地确定性算子
-
31公共制品
-
MITGeoTask核心许可
+
+
Task-relative围绕当前任务，不维护“整个世界”
+
Provider-neutralGIS / API / Sensor / WorldState 均可接入
+
Explicit Sufficiency充分与缺口都必须显式
+
Minimum Context减少成本，但不隐藏关键遗漏
-
+
-

智能体不只需要理解世界，更需要一个可以验证的世界模型

模型内部的世界理解通常隐含在上下文或参数中；现实行动需要一个外显、共享、可审计的状态层，说明“世界现在是什么样、我们为什么相信它、变化后还能做什么”。

-
-
01 · 观察

观察世界

多模态模型、传感器、地图和权威数据产生带来源与时间的观测记录。

- -
02 · 建模

显式建模

对象、位置、时间、状态、关系、约束和证据形成可读取的世界状态。

- -
03 · 验证

验证与更新

本地算法、规则和验证提供方复算命题，保留事实并标记未知、冲突和变化。

- -
04 · 行动

约束行动

行动门控根据当前世界状态决定继续、阻断、补证、纠偏或人工复核。

+

Problem

Agent 的上下文问题，本质上不是“装多少”，而是“什么足够”。

长上下文窗口、RAG、数据库和工具都能提供更多信息，但它们不会自动回答这些信息是否真的适用于当前任务。

+
+

相关 ≠ 适用

同一条事实可以与任务主题相关，却不适用于当前对象、区域、时间窗口或运行条件。

+

有数据 ≠ 分辨率足够

存在地图、气象、库存或传感器值，并不意味着空间、时间、精度和语义粒度足以支持任务。

+

上下文很多 ≠ 上下文充分

大 payload 可能仍遗漏一个 critical requirement；反过来，大量可选信息也可能只是增加 token、网络与认知成本。

-
-
-

30秒看懂一次世界状态更新

-

GT16展示的不是一次“改答案”，而是现实世界发生变化后，世界模型如何接收新的观测记录、更新关系、保留仍然有效的事实，并重新计算行动资格。

-
-
初始世界状态两架无人机的路线、高度和计划时间窗已建模；计划间隔120秒，高于60秒门槛。
-
新的观测记录A机最新遥测显示延误40秒；对象未变，时间状态和证据时间戳发生变化。
-
世界关系更新预测间隔缩至80秒，剩余余量20秒；原有空间事实保留，永久安全假设失效。
-
行动资格更新当前仍可继续，但必须保持监测；间隔降至60秒或证据过期时重新门控。
-
-
世界模型不是一次性结论：它维护某一状态快照下的事实、证据、有效范围和下一次更新条件。
-
进入GT16世界状态更新体验
-
-
- -
-
-
-

P1 Reference Agent：从单项Capability进入完整产品闭环

GT01—GT42证明单项能力；Reference Agent第一次把新证据、World State、Discrepancy、Correction、Impact与Control串成一条可运行、可失败、可重放的设施评估更新链。

- 进入Reference Agent体验 → -
-
-
rev1 → rev2新观测记录先只更新事实，不把旧评估偷偷一起修改。
-
Discrepancy → Impact注册Artifact明确哪些结论已经stale、哪些路径需要重算、哪些结果继续复用。
-
rev3只重算障碍距离与净空结论，不触发整站全局重算。
-
Control条件全部满足只使报告更新eligible，生产写入和现实动作仍为false。
+
+
+
+

Task → Context，而不是 World → Prompt

+

GeoTask 先从任务建立 Requirement，再评估候选信息；Relevance、Applicability、Resolution 和 Sufficiency 保持分离，最终形成最小充分 TaskContext 与显式 Gap / Trace。

+
+ Task→Requirements→Candidates→Relevance→Applicability→Resolution→Sufficiency→Minimum TaskContext +
+
核心对象包括 TaskFrame、ContextRequirement、ContextCandidate、ContextAssessment、ContextGap、SufficiencyAssessment、TaskContext、ContextConstructionTrace，以及 Minimum Context 与 Temporal Reassessment 相关合同。
-
体验完整闭环
- -
+
-
-

GT01—GT42公开参考例

共42个可验证参考例，对应38个场景入口；GT38—GT42作为一个五阶段复合案例，完整展示无人机身份从证据审定到应用审批的治理链。

- 查看中文文档导航 → -
-
-

1空间关系：对象、算子与边界语义

-
- GT01

模型得到5米，为什么还要本地复算？

用两个点和distance_2d建立第一条模型—确定性验证路径。

进入体验 → - GT02

答对，不等于已经验证

比较模型给出的144.22米与浏览器本地确定性结果。

进入体验 → - GT03

最后一段进入限制区，整条路线算相交吗？

逐段检查折线，而不是只看起点与终点。

进入体验 → -
-
-
-

2时空组合：二维、高度与时间

-
- GT04

水平相交但高度分离，算冲突吗？

二维投影重叠不等于三维空间冲突。

进入体验 → - GT05

位置高度相同，但时间不同，算冲突吗？

显式核验时间区间，而不是只看空间关系。

进入体验 → - GT06

多项条件怎样组合成最终结论？

路线相交、高度重叠、时间不重叠，通过显式AND得到false。

进入体验 → -
-
-
-

3不确定性与证据：不知道以后怎么办

-
- GT07

时间条件无法核验，AI能强行判断吗？

true AND true AND unknown仍然是unknown。

进入体验 → - GT08

AI知道自己不知道以后，下一步做什么？

生成结构化补证据任务，并在证据补齐后重新执行受影响断言。

进入体验 → - GT09

两份禁飞通知互相矛盾，信哪一份？

单份证据已核验，不代表多份证据彼此一致。

进入体验 → -
-
-
-

4行动与可行性：从判断走向执行

-
- GT10

两台机器人抢同一条窄通道，谁先走？

把容量、占用时间和优先级转化为可执行协调计划。

进入体验 → - GT11

目标只有50米，机器人为什么绕行300米？

几何距离不等于对象在真实网络中的可达路线。

进入体验 → - GT12

电量够到达，无人机为什么仍不能起飞？

能到达目标不等于能保留安全余量完成任务。

进入体验 → - GT13

道路开放，车辆为什么还是过不去？

道路状态与具体车辆的安全空间包络必须分别判断。

进入体验 → - GT14

最近的救援队，为什么不一定最快到达？

直线距离只是空间事实，派遣动作必须验证真实路线、准备时间和响应窗口。

进入体验 → - GT15

地图说可以通行，机器人为什么停下来了？

静态地图描述结构可通行性，实时感知决定当前路线是否被障碍占据。

进入体验 → - GT16

计划已经安全，为什么无人机仍要持续监测？

初始间隔满足要求，但A机延误40秒后预测间隔从120秒缩至80秒；结论仍可用，却必须持续监测并准备增量复核。

进入体验 → - GT17

同一个事件被上报十次，系统应该生成十个任务吗？

空间、时间和事件语义一致时，应合并处置任务并保留全部来源证据。

进入体验 → - GT18

最短路线已经找到，为什么救援机器人仍然不能进入？

路线能够到达目标仍不足以执行，还必须核验危险区和具体设备耐受能力。

进入体验 → - GT19

无人机已经到达目标上空，为什么仍然不能投放物资？

导航到达、高度和时间合规仍不足以释放载荷，还必须取得新鲜的地面净空证据。

进入体验 → - GT20

车辆已经获得绿灯，为什么仍然不能进入路口？

信号许可仍不足以进入冲突区，还必须证明下游出口净空并能容纳完整车辆。

进入体验 → -
-
-
-

5世界状态循环：观测记录、快照与增量复核

-
- GT21

遥测显示延误60秒，运行审核记录显示55秒，AI应该相信哪一个？

同一架无人机的延误数据来自两个系统。直接覆盖、取平均或按到达顺序选择都会掩盖冲突，必须使用业务方明确声明的处理规则。

进入体验 → - GT22

无人机的位置和电量来自两个系统，AI怎样形成同一时刻的可靠运行快照？

位置与电量分别到达时，不能简单拼接成“当前状态”。系统必须确认对象、时间和字段归属，才能形成可追溯的统一运行快照。

进入体验 → - GT23

无人机飞行五分钟后位置和电量都变了，系统如何证明“现在”不是“刚才”？

只覆盖最新值会丢失历史和变化依据。系统必须保留前后运行快照，绑定300秒时间差，并明确记录位置、电量和对象有效期变化。

进入体验 → - GT24

临时禁飞区发布后，哪些航线、任务和审批结论必须重新检查？

医疗航线穿越临时禁飞区，巡检航线绕开。系统只将医疗航线、任务、审批和起飞动作纳入复核链，避免全量重算或只更新地图。

进入体验 → - GT25

无人机位置更新后，哪些安全距离需要重算，哪些结果可以继续沿用？

无人机从走廊100米移动到130米后，只重算与无人机位置相关的两项安全距离，同时保留固定设施间距和电池余量。

进入体验 → - GT26

飞行服务站营业时间已经失效，系统应该改哪条数据，而不是推翻全部结果？

服务站营业计划从08:00—22:00调整为09:00—18:00，系统只允许替换营业计划，保留位置、频率、服务类型和联系方式，并阻断20:30任务直至复核。

进入体验 → - GT27

一条气象数据更新后，如何只复核受影响的飞行任务？

东区风速由6升至12米/秒后，只复核同区域且处于更新生效时段的配送和应急任务；一个结果变为不适飞，另一个复核后仍适飞，西区和更新前任务继续复用。

进入体验 → - GT28

路线安全、天气合格，就可以自动起飞吗？

路线、高度、天气窗口和风速预检全部通过，但空域、运营人、起降场、气象放行和任务授权仍缺失；预检结论可引用，自动起飞授权与起飞指令保持阻断。

进入体验 → -
-
-
-

6验证提供方生态：外部核验与可信保证

-
- GT29

气象服务数据和现场传感器冲突时，AI应该相信谁？

模拟气象服务给出8米/秒，现场传感器给出13米/秒。两个来源都新鲜且相互独立，但数值仍然冲突，因此天气结论保持未知，并请求第三个独立来源。

进入体验 → - GT30

第三个独立气象来源加入后，冲突就自动解决了吗？

第三个独立来源也给出13米/秒，形成二比一；但可信保证策略没有声明多数表决规则，因此系统仍保持未知，不静默删除8米/秒来源，并请求显式气象审定。

进入体验 → - GT31

人工复核解决气象冲突后，天气合格就能自动起飞吗？

人工复核精确绑定GT30冲突响应与虚构上下文证据，保留三份原始响应并将两份13米/秒读数限定为局部测试气流影响；8米/秒天气结论可用，但自动起飞授权与起飞指令继续阻断。

进入体验 → - GT32

五项授权陆续到达后，什么时候才算可起飞？

空域、运营人、起降场、气象放行和任务授权逐项到达，未知项从5降至0；最后两个起飞相关输出转为可用，但公共核心不发布结果、不发送指令，也不执行飞行动作。

进入体验 → -
-
-
-

7动态世界对象：移动对象、轨迹与时间观测

-
- GT33

三个带时间位置点连起来，就是一条可验证轨迹吗？

用移动对象引用、严格递增的带时区时间戳和三次二维观测建立离散轨迹，确定性计算持续300秒；不插值、不预测、不地图匹配，也不执行现实动作。

进入体验 → - GT34

三个轨迹样本之间，每一段到底移动了多远、多快？

将三次明确观测按相邻顺序绑定为两个分段，分别计算持续120/180秒、距离60/90个文档水平单位和0.5水平单位/秒平均速度；不插值、不推断瞬时速度、不预测未来或执行动作。

进入体验 → - GT35

位置几乎没变就是停留，十分钟没观测就是失联吗？

使用调用方显式声明的5米停留半径、120秒最短时长、300秒最大观测间隔和缺口许可，将三个相邻分段分类为停留候选、已观测移动和观测缺口；不允许缺口标记时返回不可核验，不推断失联、异常或连续运动。

进入体验 → - GT36

两段平均速度变了，就能证明瞬时加速度和连续运动吗？

以相邻分段中点为代表时刻，在调用方声明的300秒最大观测间隔内计算平均速度变化率；输出零加速度、正加速度和缺口驱动的不可核验，不推断瞬时或向量加速度、方向变化、未来位置或现实动作。

进入体验 → - GT37

两段轨迹只差60秒和5米，就能自动认定为同一个对象吗？

比较前一轨迹末样本与后一轨迹首样本，在调用方声明的时间、距离和对象类别策略下输出对象同一性候选、不同对象候选或不可核验；不自动归并身份、不改写subject_ref，也不证明现实身份。

进入体验 → -
复合案例 · 5阶段

巡检无人机短暂失联后被重新编号，如何确认并安全归并身份？

虚构巡检无人机UAV-017进入建筑遮挡区后短暂失联，恢复观测时被系统建立为新的临时主体。资产登记证据与人工复核均支持“同一架无人机”，但GeoTask仍将审定、归并提案、提案审批、变更请求和应用审批拆成五个可审计阶段。

GT38 证据审定GT39 归并提案GT40 提案审批GT41 变更请求GT42 应用审批
-
+

Boundary

GeoTask 不拥有世界真值，也不替代 Agent Runtime。

GeoTask 的独立价值来自 Task-relative Context。上游负责提供现实候选信息，下游负责推理、领域判断与动作授权。

+
+
UpstreamWorld / Data Providers

WorldState、GIS、API、Sensor、Database、GSTAR 或其他 Provider 提供候选事实、来源和状态。

+
GeoTaskTask Context

判断当前任务需要什么，哪些候选相关、适用、分辨率足够，以及上下文是否充分。

+
DownstreamAgent / Domain System

Agent Harness 运行推理；领域系统继续拥有专业判断、授权、执行和责任边界。

+
Context Sufficient ≠ Domain Decision ≠ Action Authorization
- -
-
-

四个平面构成可验证时空世界模型

-

GeoTask不是一个把现实隐式编码进参数的单体神经模型，而是通过公共合同组合多模态感知、显式世界状态、本地验证和现实行动。

-
-
1 · 感知与开放推理多模态模型、传感器和外部系统产生观察、假设、预测与候选方案。
-
2 · 显式时空世界状态对象、坐标、时间、属性、关系、证据和约束形成可读取、可交换的状态快照。
-
3 · 验证与状态演化确定性算子、规则和本地验证提供方核验世界命题，识别差异并更新受影响状态。
-
4 · 控制与现实行动控制评估管理行动资格；运行时连接授权、人工复核和生产系统。
+
+
+

Current Public Proof

已经有独立消费者，不再只靠定义证明自己。

当前公共 Core 已发布 Task Context 合同、候选 Provider、Relevance / Applicability / Resolution、Sufficiency Composition、Minimum Context 与 Temporal Continuity，并用非低空场景进行独立验证。

+
+

Warehouse Robot Picking

+

室内 GIS、库存 API 与通道净宽传感器分别提供 ContextCandidate。GeoTask 构造任务 Requirement，独立评估相关性、适用性与分辨率，形成 Sufficiency 和 Minimum TaskContext；传感器变化后只刷新受影响 Requirement。

+
Indoor GIS / Inventory API / Aisle Sensor + ↓ +TaskFrame → ContextRequirement[] → ContextCandidate[] + ↓ +Relevance / Applicability / Resolution Adequacy + ↓ +Sufficiency → Minimum Sufficient TaskContext + ↓ +Sensor Change → Bounded Temporal Reassessment
+

关键反例：即使通道实测宽度小于机器人宽度，只要这个测量本身相关、适用、新鲜且分辨率足够，GeoTask 仍可判断“上下文充分”；但它不会判断“机器人可以通行”。

+ 打开完整示例 →
-
当前公共核心已经提供世界对象、空间合同、来源证据、观测记录、世界状态、受限观测合并、状态转换、验证会话、差异报告、纠偏请求、影响图、受限重算推导、受限后继状态物化、增量复核结果、验证提供方公共合同、命题验证和控制语义。自动差异计算、对象身份发现、未声明策略的歧义冲突消解、影响关系自动发现与传播执行，以及更多受限推导方法仍是后续工程方向。
-
+
-

从世界模型定位到工程合同的文档体系

白皮书解释GeoTask与隐式神经世界模型的差异；架构与语言规范区分当前世界模型基础、公共边界和后续状态演化能力。

-
-
世界模型

中文白皮书

可验证时空世界模型定位、四平面架构、可信边界和典型应用模式。

阅读白皮书 →
-
语言规范

语言与执行规范

当前公共核心真正支持的字段、对象、算子、状态和执行语义。

查看规范 →
-
状态

世界状态 v0.1

版本化表达某一时刻的对象、属性、关系、有效时间、不确定性和证据引用闭包。

查看状态合同 →
-
转换

状态转换 v0.1

绑定前后快照语义指纹，记录观测记录支持的逐路径、关系与行动资格变化。

查看转换合同 →
-
会话

验证会话 v0.1

绑定世界状态与任务、结果、转换等精确制品，记录行动资格和复核触发条件。

查看会话合同 →
-
差异

差异报告 v0.1

记录期望与观测差异、影响范围，以及可变与不可变修订路径。

查看差异合同 →
-
纠偏

纠偏请求 v0.1

限定后继世界状态允许变更、验收标准、不可变路径和输出/行动门禁。

查看修订合同 →
-
影响

影响图 v0.1

将差异、修订、状态路径、断言、输出、动作和复核目标组织为可校验的有向无环图。

查看影响图合同 →
-
物化

世界状态物化结果 v0.1

按纠偏请求受限生成后继状态，绑定精确基准、请求与输出字节，并保留复核前门禁。

查看物化合同 →
-
增量复核

增量复核结果 v0.1

绑定基准/后继状态和精确来源，记录节点、目标、验收、差异消解以及输出/动作门禁结果。

查看增量复核合同 →
-
验证生态

验证提供方接口 v0.1

定义提供方身份、请求、响应、独立性、时效、校准和可信保证边界。

查看接口规范 →
-
动态对象

轨迹与移动对象Profile v0.1

定义移动对象身份、严格递增带时区观测、离散轨迹和禁止隐式插值/预测边界。

查看轨迹Profile →
-
术语

中文术语规范

明确中文与英文术语映射，避免中文页面和文档出现不必要的中英文混编。

查看术语表 →
-
快速入门

中文快速入门

安装核心、运行第一个任务、查看算子并验证模型输出。

5分钟开始 →
-
开发工具

结构规范

用于开发工具提示、任务结构校验和持续集成一致性检查。

查看结构规范 →
+

Measure

目标不是 Context Reduction 本身，而是“充分前提下的最小成本”。

任何“减少上下文”的正指标都必须配一个反指标，避免系统通过漏掉关键事实来获得更漂亮的成本数字。

+
+
Critical Requirement Coverage ↑Counter: Critical Context Miss Rate
+
Sufficiency Accuracy ↑Counter: False Sufficiency Rate
+
Context Reduction ↑Counter: Critical Context Miss Rate
+
Applicability Accuracy ↑Counter: Irrelevant / Inapplicable Context Rate
+
Context Rebuild Locality ↑Counter: Unnecessary Context Rebuild
-
+
-

六类能力共同维护智能体的世界

GeoTask不是替模型生成另一个答案，而是把智能体依赖的世界事实、来源、变化和行动资格组织成显式合同。

-
-

1 · 世界对象建模

  • 点、路线、多折线、区域、时间与高度对象
  • 坐标参考系、坐标顺序、单位和边界语义
  • 稳定对象引用和跨任务共享合同
-

2 · 多模态观测接入

  • 观测记录描述来源、时间、生产者和世界命题
  • 模型、传感器、地图、权威数据和人工均可作为来源
  • 结构校验不宣称命题真实，也不直接更新世界状态
-

3 · 关系与约束计算

  • 14个公共确定性算子
  • 空间、时间、高度、拓扑、离散轨迹、分段指标、显式分类、加速度估计与身份候选
  • 本地、可重复、无网络验证路径
-

4 · 事实验证与证据治理

  • 已验证、已矛盾与不可核验状态
  • 来源、证据绑定、冲突与审计信息
  • 智能体限定修订和证据恢复
-

5 · 状态变化与影响传播

  • 世界状态、状态转换和验证会话形成状态演化证据链
  • 差异报告、纠偏请求与影响图表达限定修订和影响关系
  • 受限物化生成后继快照，增量复核结果闭合复核目标、验收条件和门禁结果
-

6 · 验证生态与行动门控

  • 验证提供方描述身份、能力、时效、独立性和校准状态
  • 可信保证策略管理输出门禁和下一步动作
  • 运行时连接人工复核、外部授权和生产系统
-
+

Research Roadmap

下一阶段研究的不是更多 GT 编号，而是 Task Context 方法本身。

GeoTask 作为独立 Foundation 持续推进自己的问题、Benchmark 和跨领域验证。

+
+

Requirement Derivation

从显式 Requirement 继续走向稳定的 Task → Requirement 方法，并保留来源与推导轨迹。

+

Applicability & Resolution

证明“同一事实 + 不同任务 → 不同适用性”，同时把空间、时间、精度与语义分辨率变成可评估要求。

+

Minimum Context Cost

在 Critical Context Miss 不上升的前提下降低 carried bytes、token、Provider latency 与恢复成本。

+

Temporal Reassessment

现实变化映射到受影响 Requirement，只做有界重评和必要的最小重建。

+

Independent Consumers

继续用第二、第三领域验证公共 Core，不让任何单一产品的数据模型塑形 GeoTask。

+

Open Method & Protocol

长期公共资产是 Task Context Method、Engine、Benchmark 与开放合同，而不是一个封闭领域平台。

+
+
关于旧定位：GeoTask 早期公开版本中的 Verifiable World Model / World-State Cycle / Verification 资产继续保留并维护，用于兼容与历史可追溯；它们不再定义长期语义所有权。当前定位以 Task Context Engine 为准。
-
-
-

亲手体验一个会随现实变化而更新的世界模型

-

从GT16观察新遥测如何改变世界状态与行动资格，也可以从GT01开始，逐步理解对象、关系、证据、未知、冲突和行动门控。

-
- 体验GT16世界状态更新 - 从GT01系统学习 - 查看世界模型工程 +
+
+
+

从“给模型更多信息”，转向“证明当前任务的信息已经足够”。

+

GeoTask Core 采用 MIT License。你可以从独立消费者、Python API 或现有公开示例开始，把自己的 GIS、API、Sensor 或 WorldState Provider 接进来。

+
GitHub RepositoryDeveloper GuideEnglish
- +
GeoTask · Spatiotemporal Task Context Engine for AI AgentsUpdated positioning: 2026-08-27 · GitHub
From f7fda6c3e2eb17253f90efe87b084c55ba57b2eb Mon Sep 17 00:00:00 2001 From: stpku <83755634+stpku@users.noreply.github.com> Date: Thu, 27 Aug 2026 09:51:00 +0800 Subject: [PATCH 04/17] docs: rebuild English portal around task context --- site/en/index.html | 140 +++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 128 insertions(+), 12 deletions(-) diff --git a/site/en/index.html b/site/en/index.html index adc2c23e..c4c17a0e 100644 --- a/site/en/index.html +++ b/site/en/index.html @@ -3,32 +3,148 @@ - - + + - GeoTask | Explicit and Verifiable Spatiotemporal World Model + + + + + GeoTask | Spatiotemporal Task Context Engine for AI Agents -
GTGeoTask
+
+
+ GTGeoTask + +
+
+
-

OPEN CONTRACTS FOR VERIFIABLE WORLD STATE

An explicit and verifiable spatiotemporal world model for AI agents

GeoTask turns multimodal observations, sensors, maps, authoritative data, and human input into explicit world objects, relations, state, evidence, changes, and action constraints that can be validated, updated, exchanged, and audited.

Let models interpret the world. Let GeoTask make the world state explicit, verifiable, and maintainable.
Explore the UAV identity caseOpen the repositoryRead the English guide
42public reference examples
38scenario entries
32registered public Artifacts
MITGeoTask Core license
+
+
+

Spatiotemporal Task Context Engine for AI Agents

+

Not more context.
The context this task actually needs.

+

GeoTask constructs spatiotemporal context that is relevant, applicable, resolution-adequate, and explicitly sufficient, then reassesses only the parts that are actually affected when reality changes.

+
Task Sufficiency at Minimum Context Cost — minimize carried context while keeping critical context misses visible.
+
+ Open GitHub + Independent consumer + Read README +
+
+
Task-relativeContext for the task, not “the whole world”
+
Provider-neutralGIS / API / Sensor / WorldState
+
Explicit SufficiencySufficiency and gaps stay observable
+
Minimum ContextLower cost without hiding critical misses
+
+
+
+ +
+
+

Problem

The context problem is not how much an agent can carry. It is what is sufficient.

Long context windows, RAG, databases, and tools can expose more information. They do not automatically prove that information applies to the current task.

+
+

Relevant ≠ Applicable

A fact can match the topic and still be wrong for the current object, place, time window, or operating condition.

+

Available ≠ Adequate

A map, forecast, inventory value, or sensor reading may exist while its spatial, temporal, precision, or semantic resolution is still inadequate.

+

Large ≠ Sufficient

A huge payload can still miss one critical requirement; optional context can also add token, network, and human recovery cost without helping the task.

+
+
+
-

Four planes form a verifiable world model

GeoTask is not a monolithic neural model that hides the world inside parameters. It composes open reasoning, explicit world state, deterministic and Provider-based verification, and guarded real-world integration through stable contracts.

1 · Perception and reasoningModels, sensors, and external systems produce Observations, hypotheses, predictions, and candidate plans.
2 · Explicit world stateObjects, coordinates, time, attributes, relations, evidence, and constraints form readable snapshots.
3 · Verification and evolutionOperators, rules, and Verification Providers check claims, surface conflicts, and support bounded updates.
4 · Control and action boundaryControl Evaluation manages Action Eligibility while external Runtime implementations connect review, authorization, and production systems.
Public Core validates contracts and exact bindings. It does not fetch external truth, choose undeclared source precedence, publish production output, authorize action, or execute side effects.
+
+
+
+

Task → Context, not World → Prompt

+

GeoTask starts from task requirements, then assesses candidate information. Relevance, applicability, resolution, and sufficiency remain separate so the final TaskContext and its gaps are explicit.

+
+ Task→Requirements→Candidates→Relevance→Applicability→Resolution→Sufficiency→Minimum TaskContext +
+
Core concepts include TaskFrame, ContextRequirement, ContextCandidate, ContextAssessment, ContextGap, SufficiencyAssessment, TaskContext, ContextConstructionTrace, plus Minimum Context and Temporal Reassessment contracts.
+
+
+
-

Verification Provider ecosystem

The public Provider profile lets external deterministic operators, rule engines, data services, sensors, local models, and human review systems declare capabilities without self-assigning Assurance.

Provider Descriptor

Declares identity, type, capabilities, methods, independence group, reproducibility, calibration, validity, and side-effect boundaries.

Verification Request

Binds one claim, exact input Artifact hashes, required capabilities, allowed Provider types, deadline, and one Assurance Profile.

Verification Response

Binds exact Request and Descriptor bytes. A Provider cannot set independent verification, production release, authorization, or execution to true.

Assurance Profile

Caller-authored requirements determine provider count, independent groups, freshness, reproducibility, calibration, conflict policy, and gates.

+
+
+

Boundary

GeoTask does not own world truth and does not replace an agent runtime.

Its independent value is task-relative context. Upstream systems provide candidate reality; downstream systems keep reasoning, domain decisions, authorization, and execution.

+
+
UpstreamWorld / Data Providers

WorldState, GIS, APIs, sensors, databases, GSTAR, or other providers expose candidate facts, provenance, and state.

+
GeoTaskTask Context

Determines what the task needs and whether candidates are relevant, applicable, resolution-adequate, and sufficient.

+
DownstreamAgent / Domain System

The harness runs reasoning; domain systems continue to own professional judgment, authorization, execution, and responsibility.

+
+
Context Sufficient ≠ Domain Decision ≠ Action Authorization
+
+
-

Scenario-first public examples

Forty-two reference examples map to thirty-eight scenario entries. GT38–GT42 are one five-stage composite case: inspection drone UAV-017 is briefly lost, receives a new provisional identity, and proceeds through evidence adjudication, merge proposal, proposal approval, a bounded change request, and application approval.

GT38–GT42 · Composite

How should a briefly lost inspection drone be safely re-identified?

Two evidence sources support the same drone, but identity adjudication, merge proposal, approvals, exact path mutation, and actual application remain separate responsibilities.

Open the five-stage case →GT37

Do a 60-second gap and a five-meter distance prove two tracks are one object?

Core forms only a same-object candidate under caller-declared time, distance, and object-class limits.

Open case →GT32

When do five arriving authorization records make takeoff eligible?

Unknown authorization fields close one by one while production release, command sending, and flight execution remain external.

Open case →
Browse 42 examples across 38 entries
+
+
+

Current Public Proof

An independent consumer now proves the model outside its original domain.

The public Core includes Task Context contracts, provider candidates, relevance / applicability / resolution, sufficiency composition, minimum context, and temporal continuity, with a non-low-altitude consumer.

+
+

Warehouse Robot Picking

+

Indoor GIS, an inventory API, and an aisle-clearance sensor provide ContextCandidates. GeoTask derives requirements, evaluates relevance, applicability, and resolution separately, composes sufficiency, builds minimum context, and refreshes only the affected requirement after a sensor change.

+
Indoor GIS / Inventory API / Aisle Sensor + ↓ +TaskFrame → ContextRequirement[] → ContextCandidate[] + ↓ +Relevance / Applicability / Resolution Adequacy + ↓ +Sufficiency → Minimum Sufficient TaskContext + ↓ +Sensor Change → Bounded Temporal Reassessment
+

Counterexample by design: even when the measured aisle is narrower than the robot, GeoTask may correctly conclude that the context is sufficient if that measurement is relevant, applicable, fresh, and resolution-adequate. It still does not decide that the robot may traverse the aisle.

+ Open the complete example → +
+
+
-

English documentation

English and Chinese documentation have separate entry points. Terminology maps keep human-facing prose consistent while machine identifiers remain stable.

English documentation index

Architecture, specifications, tutorials, references, and release material.

Open documentation →

Verification Provider Profile

Public read-only contracts, strict bindings, Assurance rules, CLI, and GT29–GT32 reference behavior.

Open profile →

Trajectory and Moving Object Profile

Discrete observations, segment metrics, caller-declared classifications, bounded acceleration, identity candidates, exact-bound adjudication, review-only merge proposals, approval records, bounded object-graph change requests, and application approval records for GT33–GT42.

Open profile →
+
+
+

Measure

The objective is not context reduction by itself. It is minimum cost under sufficiency.

Every positive “reduce context” metric needs a counter-metric so the system cannot look efficient by silently dropping critical information.

+
+
Critical Requirement Coverage ↑Counter: Critical Context Miss Rate
+
Sufficiency Accuracy ↑Counter: False Sufficiency Rate
+
Context Reduction ↑Counter: Critical Context Miss Rate
+
Applicability Accuracy ↑Counter: Irrelevant / Inapplicable Context Rate
+
Context Rebuild Locality ↑Counter: Unnecessary Context Rebuild
+
+
+
-

Build a verifiable world-state workflow

Use the open contracts to validate AI-generated spatial tasks, represent changing world state, connect read-only Verification Providers, and keep action boundaries explicit.

Start on GitHubExplore the UAV identity case中文主页
+
+
+

Research Roadmap

The next frontier is the Task Context method itself, not more numbered examples.

GeoTask evolves as an independent foundation with its own problems, benchmarks, and cross-domain evidence.

+
+

Requirement Derivation

Move from manually supplied requirements toward stable Task → Requirement methods with explicit lineage.

+

Applicability & Resolution

Prove that the same fact can have different applicability across tasks while making spatial, temporal, precision, and semantic adequacy testable.

+

Minimum Context Cost

Reduce carried bytes, tokens, provider latency, and recovery cost without increasing critical misses.

+

Temporal Reassessment

Map reality changes to affected requirements and perform bounded reassessment plus only the rebuild that is actually needed.

+

Independent Consumers

Validate the Core in additional domains so no single product or data model shapes GeoTask semantics.

+

Open Method & Protocol

The durable public asset is a Task Context Method, Engine, Benchmark, and open contracts — not a closed domain platform.

+
+
About the previous positioning: early Verifiable World Model / World-State Cycle / Verification assets remain public and maintained for compatibility and traceability. They no longer define long-term semantic ownership. The current positioning is Task Context Engine.
+
+
+ +
+
+
+

Move from “give the model more information” to “prove this task has enough information.”

+

GeoTask Core is MIT licensed. Start with the independent consumer, the Python API, or the existing public examples, then connect your own GIS, API, sensor, or WorldState provider.

+
GitHub RepositoryDeveloper Guide中文
+
+
+
-
GeoTask Core · MIT License · Open contracts for verifiable spatiotemporal world state
+ +
GeoTask · Spatiotemporal Task Context Engine for AI AgentsUpdated positioning: 2026-08-27 · GitHub
From a1626654c6dc59e17569394018cc1e0273a5b096 Mon Sep 17 00:00:00 2001 From: stpku <83755634+stpku@users.noreply.github.com> Date: Thu, 27 Aug 2026 09:51:52 +0800 Subject: [PATCH 05/17] docs: reset public roadmap to task context engine --- ROADMAP.md | 593 ++++++++++++++++++++++++++++++++--------------------- 1 file changed, 361 insertions(+), 232 deletions(-) diff --git a/ROADMAP.md b/ROADMAP.md index 24bef7b0..e873550e 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -2,238 +2,367 @@ [简体中文](#中文路线图) | [English](#english-roadmap) -GeoTask follows an open, incremental roadmap. Items below describe public protocol, Core, tooling, and ecosystem directions; they are not promises of delivery dates. +> **Current positioning: GeoTask is a domain-neutral spatiotemporal Task Context Engine for AI agents.** +> +> The roadmap now follows the Task Context problem space. Earlier World-State / Verification milestones remain part of the released compatibility history, but they no longer define GeoTask's long-term semantic ownership. + +This roadmap describes public research and Core evolution directions. It is **not** a delivery-date commitment. + +--- ## 中文路线图 -### v0.1：公共预览 ✅ - -- 六类Canonical对象与六个本地确定性算子； -- YAML任务解析、规范化、结构验证与执行； -- 结果状态、Assurance和模型输出比较验证； -- Language Specification 1.0与JSON Schema 1.0； -- GT01—GT20渐进式应用案例； -- 中文项目门户、白皮书、Quickstart和Cookbook； -- Python 3.10—3.13持续集成与公共导出安全检查。 - -### v0.2.0：制品契约 ✅ - -- 公共Artifact Registry——Agent可在运行时发现四类注册制品； -- 离线Schema Bundle——五份公共JSON Schema及SHA-256 manifest随发行包分发； -- 统一制品校验入口——`geotask artifact validate`按Artifact ID分发验证； -- 验证报告自验证——报告自身作为注册制品可被再次校验，闭合信任环； -- 公共Python API——`geotask_core`与`geotask_core.v1`统一导出； -- 发布身份预检——版本溯源、Git标签、CHANGELOG、README导航与包元数据交叉核对。 - -### v0.3.0：Agent集成（上一稳定版） 🏷️ - -- 发布模型无关的Agent Integration Profile，明确Agent、Core与Runtime职责边界； -- 提供`inspect_artifacts`、`validate_artifact`、`execute_task`和`evaluate_control`四类稳定工具契约； -- 提供可直接注入Agent的GeoTask Core Skill； -- 建立Agent生成草稿的严格校验、机械修复、结构化修订请求、差异约束重试、重新校验和本地执行闭环，并将四类Agent报告注册为可离线验证的公共Artifact； -- 完成GT08补证据、恢复条件求值和受影响断言重新执行闭环； -- 保持unknown、blocked和`next_action`的失败关闭语义； -- 增加Agent生成路径与确定性验证路径的联合测试。 - -### v0.4.0：Core产品化、Reference Agent与Runtime接口（当前稳定） 🏷️ - -- 发布Runtime Interface Profile v0.1，定义Descriptor、Request、Response、输入基数、授权、幂等、审计及副作用边界； -- 提供Runtime Descriptor离线发现、Request无副作用预检和Descriptor/Request/Response三方交换校验； -- 提供仅执行只读Artifact验证的失败关闭参考Runtime，明确不调用模型、不解析外部证据、不执行生产动作； -- 提供至少两种模型适配参考实现； -- ✅ 已增加polygon、multi-polyline通用空间对象，以及point-in-polygon和multi-polyline/rect确定性算子； -- ✅ 已建立CRS、坐标顺序、水平/垂直单位和闭边界语义的跨任务失败关闭门禁； -- ✅ 已增加文档级来源、证据绑定与审计元数据，并通过Artifact Registry输出IDE Schema文件匹配； -- ✅ 已建立覆盖全部公共确定性算子的离线一致性与本机性能回归基准。 - -### v0.5：Verifiable World-State Cycle - -- ✅ 已发布Observation v0.1 Artifact，使模型、传感器、地图、权威数据和人工输入以带来源、时间、生产者、不确定性和世界命题的结构化观察进入系统，同时明确不验证命题真实性、不更新World State； -- ✅ 已发布World State v0.1 Artifact，表达某一时刻版本化的世界对象、属性、关系、证据、有效时间和不确定状态，并提供严格引用闭包、快照时点有效性和确定性语义指纹校验； -- ✅ 已发布Observation Merge Result v0.1 Artifact，将精确Observation字节按完整显式映射写入既有属性或关系；当多条命题指向同一目标时，仅接受调用方声明的语义相等合并或完整显式优先级，并记录全部参与命题的`applied`、`consolidated`或`superseded`审计状态，确定性生成后继World State，同时明确不推断对象身份、不发明优先级、不排序来源、不解决未声明策略的歧义冲突或计算State Transition； -- ✅ 已发布State Transition v0.1 Artifact，以前后World State语义指纹绑定快照，记录Observation支持的对象、属性、关系和行动资格变化，同时明确不自动计算差异、不应用补丁、不物化状态或授权行动； -- ✅ 已发布Verification Session v0.1 Artifact，绑定一个World State语义指纹与任务、执行结果、控制评估、State Transition及差异制品的精确字节哈希，记录行动资格与复核触发条件，同时明确不验证引用制品语义、不执行任务、控制或复核； -- ✅ 已发布Discrepancy Report v0.1 Artifact，绑定一个World State语义指纹与精确来源制品字节，记录差异类型、期望值/观测值、影响范围及可变/不可变修订路径，同时明确不自动比较来源、传播影响、生成修订请求或应用纠正； -- ✅ 已发布Correction Request v0.1 Artifact，绑定不可变基准World State与Discrepancy Report，限定后继状态允许变更、验收标准、不可变路径保护及输出/行动门禁，同时明确不原地修改快照、不应用修订、不物化后继状态或释放输出； -- ✅ 已发布Impact Graph v0.1 Artifact，将差异、修订、状态路径、断言、输出、动作和复核目标组织为来源绑定的有向无环图，并验证根可达性、无环性、精确文件绑定和关键边语义，同时明确不自动生成图、不执行传播或复核； -- ✅ 已发布Recompute Derivation Result v0.1 Artifact，将Correction Request中的每项`recompute`变更绑定到精确Observation/GeoTask Document路径，并通过有限白名单方法确定性生成完整重算值映射，同时明确不执行任意代码、模型调用、状态物化、复核或动作授权； -- ✅ 已发布受限后继World State物化与World State Materialization Result v0.1，将一个required Correction Request应用于不可变基准快照，绑定精确字节并保留来源、输出门禁和动作门禁； -- ✅ 已发布Incremental Reevaluation Result v0.1 Artifact，绑定基准/后继World State、Impact Graph、Correction Request、Discrepancy Report与执行结果的精确字节，完整记录节点/目标结果、验收条件、差异消解和输出/动作门禁，同时明确不执行复核、不生成后继状态、不授权或执行动作； -- ✅ 已提供`geotask verify`与`geotask recheck`高层只读入口，对完整显式Verification Session或Incremental Reevaluation Result制品束执行注册制品语义校验、精确引用覆盖和SHA-256绑定验证，同时明确不执行任务、复核、状态物化、输出释放或动作； -- 扩展受限Observation Merge的对象身份发现与未声明歧义冲突策略，并扩展重算推导方法注册表，保持本地、显式、可复现的世界状态快照语义； -- ✅ 已将GT21改为现实冲突主线：遥测显示延误60秒、运行审核记录显示55秒，先解释静默覆盖、取平均和擅自判断来源权威的业务风险，再在技术层展示失败关闭、`require_equal`与完整`explicit_precedence`； -- ✅ 已将GT22改为多源运行态势主线：位置与电量来自两个系统，先解释对象、时间和字段可能被错误拼接，再展示显式映射、revision 1、引用闭包、不确定性和稳定语义指纹； -- ✅ GT21—GT28统一采用“现实场景优先、必要性先行、技术概念后置”的案例叙事规范，主标题不得由Artifact、revision、semantic fingerprint或materialization等术语主导； -- ✅ 已发布GT23连续飞行状态案例，以10:02与10:07两个无人机运行快照展示只覆盖最新值为何会丢失历史和变化依据；案例显式记录位置、电量和对象有效期3项变化，绑定revision 1/2及语义指纹，并通过案例级路径核验确认before/after值，同时明确公共State Transition不执行通用diff、影响传播、风险重算或行动授权； -- ✅ 已发布GT24临时禁飞区影响范围案例：一条医疗航线穿越有效禁飞区，另一条巡检航线绕开；案例以显式声明的有限依赖链将医疗航线、任务、审批输出和起飞动作纳入复核，同时排除巡检链，并验证7节点、7条边、4个复核目标、精确文件绑定和无环结构，明确不执行几何求交、自动影响发现、传播、复核、输出释放或动作授权； -- ✅ 已发布GT25局部安全距离重算案例：无人机从走廊100米移动到130米后，只对两条无人机相关距离执行白名单`subtract`推导，将50/160米重算为20/130米，同时把110米固定设施间距和48%电池余量列为不可变复用路径；案例验证范围完整、范围互斥、精确字节绑定和未注册方法拒绝，并明确不自动发现依赖、不执行任意代码、状态物化、复核、输出释放或行动授权； -- ✅ 已发布GT26飞行服务站营业时间限定纠偏案例：新公告将营业计划从08:00—22:00调整为09:00—18:00，案例只允许替换1条营业计划路径，保留位置编码、通信频率、服务类型和联系方式4项不可变属性，并阻断20:30任务输出与派发动作直至后继状态有效且完成复核；案例明确不获取或比较真实公告、不应用修订、不物化状态、不发布输出或授权动作； -- ✅ 已发布GT27气象更新增量复核案例：东区风速由6升至12米/秒后，revision 7先吸收新气象值，再仅将同区域且处于更新生效时段的任务A、D纳入复核；任务A由适飞变为不适飞，任务D复核后仍适飞，任务B、C保持复用。案例绑定前后状态、差异、纠偏、影响图、执行结果和输出门禁，明确不自动发现依赖、不证明生产输出已发布或飞行动作获授权； -- ✅ 已发布GT28自动起飞授权门禁案例：路线、高度、天气窗口和风速预检全部满足，但空域、运营人、起降场、气象放行和任务授权五项信息仍为unknown；案例将可引用的路线天气预检标记为eligible，同时保持自动起飞授权与起飞指令blocked，并验证即使授权条件全部显式为true，公共Control Evaluation仍只标记输出eligible且`action_executed=false`； -- ✅ GT21—GT28世界状态循环场景案例已全部发布。 - -### v0.6：验证提供方与生态扩展（进行中） - -- ✅ 已发布验证提供方接口规范v0.1，覆盖确定性算子、规则引擎、权威数据提供方、传感器数据提供方、本地预测模型和人工复核； -- ✅ 已发布验证提供方描述符、验证请求、验证响应和可信保证策略四类公共制品，并提供只读的`geotask provider inspect/check/validate`命令； -- ✅ 已建立反自我增信、精确请求/描述符字节绑定、独立分组、时效、可复现性、校准和行动边界校验； -- ✅ 已发布GT29虚构气象冲突案例：模拟气象服务给出8米/秒、现场传感器给出13米/秒，两个新鲜独立来源仍冲突时保持未知并请求第三个独立来源； -- ✅ 已发布GT30三源气象冲突案例：第三个独立来源也给出13米/秒，形成二比一；由于可信保证策略未声明多数表决规则，系统仍保持未知、保留少数来源并请求显式气象审定； -- ✅ 已发布GT31人工气象裁决案例：虚构人工复核精确绑定GT30三份冲突响应和上下文证据，保留全部原始结果并限定两份13米/秒读数的适用范围；天气结论升级为可用，但自动起飞授权与起飞指令继续由独立控制门禁阻断； -- ✅ 已发布GT32渐进授权门禁案例：五份虚构授权记录逐项到达，公共核心在每次累计输入后重新评估同一有限控制表达式，未知授权从5项降至0项；最终两个起飞相关输出转为可用，但生产发布、指令发送、现实授权与动作执行继续保持为假； -- ✅ 已发布GT33首个移动对象与离散轨迹案例：移动对象身份与三次带时区二维观测分离表达，轨迹引用必须闭合、时间必须严格递增且插值固定为none；新增第10个确定性算子计算首末样本持续300秒，同时拒绝静态折线替代、隐式插值、未来位置预测、地图匹配和现实动作推断； -- ✅ 已发布GT34离散轨迹分段与平均速度案例：三次明确观测按相邻顺序形成两个分段，分别绑定起止样本索引、时间和坐标，计算120/180秒持续时间、60/90个文档水平单位距离与0.5水平单位/秒平均速度；新增第11个确定性算子，同时拒绝非相邻分段、零时长、单位冒充、瞬时速度推断、插值、平滑、预测和现实动作； -- ✅ 已发布GT35停留、移动与观测缺口案例：调用方显式声明停留半径、最短停留时长、最大观测间隔和缺口许可，三个相邻分段分别输出停留候选、已观测移动和观测缺口；新增第12个确定性算子，缺口不允许时返回不可核验，同时拒绝默认阈值、连续停留、失联、异常、插值和现实动作推断； -- ✅ 已发布GT36加速度与运动连续性案例：调用方显式声明分段中点代表时刻和最大观测间隔，前两个相邻速度转换输出0和1/300水平单位/秒²，第三个转换因下一分段持续600秒而返回不可核验并保持速度差与加速度为null；新增第13个确定性算子，同时拒绝瞬时/向量加速度、方向变化、跨缺口计算、预测和现实动作推断； -- ✅ 已发布GT37对象同一性候选案例：比较前一轨迹末样本与后一轨迹首样本，在调用方显式声明的最大时间差、最大空间距离和对象类别要求下输出同一对象候选、不同对象候选或不可核验；新增第14个确定性算子，保留原始轨迹、主体和类别引用，同时拒绝自动身份归并、subject_ref改写、现实身份自证、插值、预测和现实动作； -- ✅ 已发布GT38对象同一性证据与显式审定案例：新增第28类公共制品和第29份公共Schema，将GT37候选与原始字节级绑定的验证请求、可信保证策略、两个独立验证提供方及其响应组合为同一对象确认、不同对象确认或未决审定；即使同一对象证据满足策略，也只输出身份归并复核建议，不归并对象、不改写subject_ref、不发布、不授权也不执行身份更新； -- ✅ 已发布GT39对象身份归并提案案例：新增第29类公共制品和第30份公共Schema，将GT38对象同一性审定结果、调用方选择的现有主对象引用、提案理由和审批角色组合为ready_for_review提案；提案只覆盖两条原始轨迹，提出一项subject_ref改写，保留非主主体为别名，并声明阻断、撤销和回退要求，不创建新身份、不删除别名、不审批、不修改对象关系图或世界状态，也不发布、授权或执行更新； -- ✅ 已发布GT40对象身份归并审批记录案例：新增第30类公共制品和第31份公共Schema，原始字节级绑定GT39提案，对每个必需审批角色记录批准、拒绝或要求补证据的显式决定；任一拒绝优先，补证据继续阻断，全部批准只使后续受限变更请求具备条件，不执行身份归并、不改写subject_ref、不修改对象关系图或世界状态，也不发布、授权或执行更新； -- ✅ 已发布GT41对象关系图变更请求案例：新增第31类公共制品和第32份公共Schema，原始字节级绑定GT39提案与GT40全部批准记录，由公共核心派生唯一的轨迹`subject_ref`改写、保留别名、七项应用前置条件、五项验收条件和逆向回退操作；请求必须进入独立应用审批，不授权或应用变更，不修改对象关系图或世界状态，也不发布、授权或执行更新； -- ✅ 已发布GT42对象关系图变更应用审批记录案例：新增第32类公共制品和第33份公共Schema，原始字节级绑定GT41变更请求，对调用方声明的每个应用审批角色记录批准、拒绝或要求补证据的显式决定；任一拒绝优先，补证据继续阻断，全部批准只使后续受限应用制品具备条件，不产生应用授权、不改写`subject_ref`、不修改对象关系图或世界状态，也不发布、授权或执行更新； -- ✅ 已建立中英文独立项目入口及术语映射，并明确“契约、规范、协议、合同”四类中文用法，机器标识保持稳定； -- 继续扩展受限对象关系图变更应用结果、后继世界状态生成、应用后验收和可撤销身份治理规范； -- 发布可复用的行业扩展接口和非行业敏感的参考实现； -- 建立验错率、漏检率、纠偏成功率、增量复核范围和执行时延基准； -- 支持社区维护的验证提供方、案例、算子和通用扩展目录。 - -### 产品成熟度 Track（P0—P5） - -GT编号继续作为**Capability Track**，用于证明单项公共能力；它不再代表产品成熟度。GT42之后暂停“为编号而编号”，只有Reference Agent或真实行业集成暴露出缺失的通用原语时，才新增后续GT。 - -当前产品阶段判断：**P0 Architecture Definition 已完成首轮重新基线化；P1 Reference Agent 的代码、固定场景、注册制品链、教程、体验页和隔离公共导出冷启动已完成，外部陌生开发者激活验证仍待完成；P2 Core Product 的 0.4.0 发布门槛已经闭合：Verification Quality Benchmark v0.1、发布范围命名冻结、Artifact/Schema/Operator Registry 开发者体验、安装/迁移矩阵、wheel/sdist/33-Schema Bundle、安装包驱动 Reference Agent、Python 3.10—3.13 实际 CI、公共导出与 RC Readiness Gate 均已通过，GeoTask Core 0.4.0 已于 2026-08-08 正式发布。P3 已进入真实 Lowa-GT shadow 阶段，但其结果仍属于 Integration 验证，不构成 Core Promotion；任何跨线能力仍需显式 Promotion Gate。** - -| 阶段 | 名称 | 核心验收 | -|---|---|---| -| P0 | Architecture Definition | 当前事实、近期目标、长期愿景和Core/行业边界稳定一致 | -| P1 | Reference Agent | 陌生开发者可运行、修改、失败关闭并重放一个端到端闭环 | -| P2 | Core Product | 公共命名、Registry、质量基准、安装/迁移和发行体验达到产品级 | -| P3 | Industry Integration | 首个真实行业系统复用Core且不复制第二套业务事实 | -| P4 | Ecosystem Validation | 独立团队能构建并复用可验证扩展 | -| P5 | Commercial Validation | 真实客户拉动私有治理、部署和长期支持能力 | - -近期统一主轴为：`新证据 → 世界状态更新 → 冲突/缺口验证 → 有限影响与重算 → 人工复核/审批 → 输出具备条件但不自动发布或执行`。首个公共Reference Agent采用**虚构低空设施评估更新**场景；首个真实行业集成采用Lowa-GT的证据—评估—报告影子闭环，而不是实时起飞授权。 - -详见[架构宣言](docs/architecture_manifesto_v1.md)、[Reference Agent v0.1规格](docs/reference/reference-agent-v0.1.md)、[Verification Quality Benchmark v0.1](docs/reference/verification-quality-benchmark-v0.1.md)、[GeoTask ↔ Lowa-GT Integration Contract v0.1](docs/reference/lowa-gt-integration-contract-v0.1.md)和[产品化路线图v0.2](docs/productization_roadmap_v0_2.md)。 - -## 参与方式 - -- 在[Issues](https://github.com/stpku/GeoTask/issues)提交Bug、算子建议或案例建议； -- 在[Discussions](https://github.com/stpku/GeoTask/discussions)讨论应用方式和协议演进； -- 从带有`good first issue`标签的任务开始贡献； -- 阅读[中文贡献指南](CONTRIBUTING.zh-CN.md)。 - -## English Roadmap - -### v0.1: Public Preview ✅ - -- Six canonical object types and six deterministic local operators; -- YAML parsing, canonicalization, validation, and execution; -- result status, assurance metadata, and model-output comparison; -- Language Specification 1.0 and JSON Schema 1.0; -- GT01–GT20 progressive application cases; -- project portal, white paper, Quickstart, and Cookbook; -- CI on Python 3.10–3.13 and public-export safety checks. - -### v0.2.0: Artifact Contracts ✅ - -- Public Artifact Registry — agents discover registered artifacts at runtime; -- Offline Schema Bundle — five public JSON Schemas distributed with SHA-256 manifest; -- Unified artifact validation — `geotask artifact validate` dispatches by Artifact ID; -- Self-validating reports — validation reports are registered artifacts, closing the trust loop; -- Public Python API — unified exports from `geotask_core` and `geotask_core.v1`; -- Release identity preflight — version source, tag, CHANGELOG, README, and metadata cross-check. - -### v0.3.0: Agent Integration (previous stable) 🏷️ - -- Publish a model-neutral Agent Integration Profile that separates Agent, Core, and Runtime responsibilities; -- expose stable contracts for `inspect_artifacts`, `validate_artifact`, `execute_task`, and `evaluate_control`; -- provide a directly injectable GeoTask Core Agent Skill; -- establish strict validation, mechanical repair, structured revision requests, guarded revision-diff retries, evidence-gated recovery, revalidation, and local execution for Agent-generated drafts, with four Agent reports registered as offline-verifiable public Artifacts; -- complete the GT08 evidence request, resume-condition evaluation, and affected-assertion re-execution loop; -- preserve fail-closed semantics for unknown, blocked outputs, and `next_action`; -- add joint tests for Agent generation paths and deterministic verification paths. - -### v0.4.0: Core Productization, Reference Agent, and Runtime Interfaces (current stable) 🏷️ - -- Publish Runtime Interface Profile v0.1 for Descriptor, Request, Response, input cardinality, authorization, idempotency, audit, and side-effect boundaries; -- provide offline Runtime Descriptor discovery, side-effect-free Request preflight, and three-way Descriptor/Request/Response exchange validation; -- provide a fail-closed reference Runtime that performs only read-only Artifact validation and never calls a model, resolves external evidence, or executes production actions; -- provide a public-safe external HTTP JSON transport Adapter and paired loopback-only reference Endpoint outside Core, with offline Descriptor binding, strict Request/Response loading, and transport/operation failure separation; -- provide an independently buildable provider-neutral model Adapter package skeleton with a no-network Mock Provider, opaque authorization/audit mapping, registered input/output Artifact validation, and model-output truthfulness guards; -- provide the first provider-specific OpenAI Responses Adapter with externally injected authenticated client, one no-retry strict Structured Outputs call, disabled storage/tools, audit binding, and fully offline contract tests; -- add a second provider-specific model Adapter only after installed-package compatibility and one explicitly authorized live smoke test are stable; -- ✅ Added polygon and multi-polyline objects plus deterministic point-in-polygon and multi-polyline/rectangle operators; -- ✅ Added fail-closed cross-task gates for CRS, coordinate order, horizontal/vertical units, and closed-boundary semantics; -- ✅ Added document-level source, evidence-binding, and audit metadata plus Artifact Registry IDE Schema file mappings; -- ✅ Established an offline conformance and local performance-regression benchmark covering every public deterministic operator. - -### v0.5: Verifiable World-State Cycle - -- ✅ Published Observation v0.1 so models, sensors, maps, authoritative data, and humans enter the system as structured observations with source, time, producer identity, uncertainty, and world claims, while explicitly not verifying claim truth or updating a World State; -- ✅ Published World State v0.1 for versioned objects, attributes, relations, evidence, validity time, and uncertainty at one snapshot, with strict reference closure, as-of validity, and deterministic semantic fingerprints; -- ✅ Published Observation Merge Result v0.1, applying complete explicit mappings from exact Observation bytes to existing attributes or relations; when multiple claims target one path, Core accepts only caller-declared semantic-equality consolidation or complete explicit precedence, records every participant as `applied`, `consolidated`, or `superseded`, and deterministically emits one successor World State revision without identity inference, invented precedence, source ranking, undeclared ambiguous-conflict resolution, or State Transition computation; -- ✅ Published State Transition v0.1, binding before/after World State snapshots by semantic fingerprint and recording Observation-supported object, attribute, relation, and action-eligibility changes, while explicitly not calculating diffs, applying patches, materializing state, or authorizing action; -- ✅ Published Verification Session v0.1, binding one World State semantic fingerprint to exact-byte task, execution-result, control-evaluation, State Transition, and discrepancy references plus action eligibility and recheck triggers, while explicitly not validating linked artifact semantics or executing tasks, controls, or rechecks; -- ✅ Published Discrepancy Report v0.1, binding one World State semantic fingerprint to exact source-artifact bytes and recording discrepancy kind, expected/observed values, downstream impact, and mutable/immutable correction paths, while explicitly not comparing sources, propagating impact, creating correction requests, or applying corrections; -- ✅ Published Correction Request v0.1, binding one immutable base World State to exact Discrepancy Reports and constraining successor-state changes, acceptance criteria, immutable-path preservation, and output/action gates while explicitly not editing snapshots, applying changes, materializing successors, or releasing outputs; -- ✅ Published Impact Graph v0.1, representing discrepancies, corrections, state paths, assertions, outputs, actions, and reevaluation targets as a source-bound directed acyclic graph with root reachability, exact-byte bindings, and key edge-semantic checks, while explicitly not discovering the graph or executing propagation or reevaluation; -- ✅ Published bounded successor-World-State materialization and World State Materialization Result v0.1, applying one required Correction Request to one immutable base snapshot with exact-byte bindings and explicit recompute values while preserving provenance, output gates, and action gates; -- ✅ Published Recompute Derivation Result v0.1, binding exact World State, Correction Request, Observation, and GeoTask Document bytes and deriving every requested `recompute` value through small allowlisted deterministic methods, without arbitrary code, model calls, state mutation, reevaluation, release, or action authorization; -- ✅ Published Incremental Reevaluation Result v0.1, binding exact base/successor World States, Impact Graph, Correction Requests, Discrepancy Reports, and execution results while closing graph-node, target, acceptance, discrepancy-resolution, output-gate, and action-eligibility outcomes without executing reevaluation, generating successors, authorizing actions, or executing actions; -- ✅ Added high-level, read-only `geotask verify` and `geotask recheck` commands that run registered semantic validation, exact reference coverage, and SHA-256 binding checks over complete explicit Verification Session or Incremental Reevaluation Result bundles while explicitly not executing tasks, reevaluation, state materialization, output release, or actions; -- expand the bounded derivation method registry and extend Observation Merge with object-identity discovery and policies for ambiguous conflicts that lack an explicit caller declaration, while preserving explicit, local, reproducible snapshot semantics; -- ✅ Reframed GT21 around the operational conflict: telemetry reports a 60-second delay while an operations review reports 55 seconds. The page explains the business risk of silent overwrite, averaging, and invented authority before deferring fail-closed behavior, `require_equal`, and complete `explicit_precedence` to the technical layer; -- ✅ Reframed GT22 around multi-source operational awareness: position and battery arrive from different systems. The page explains object, time, and field-mapping risks before deferring explicit mapping, revision 1, reference closure, uncertainty, and semantic fingerprinting to the technical layer; -- ✅ Adopted a scenario-first narrative contract for GT21–GT28: real task and necessity lead, generic-AI failure modes follow, and Artifact/revision/semantic-fingerprint/materialization terminology is deferred to technical implementation; -- ✅ Published GT23 as a continuous-flight state-change case using the 10:02 and 10:07 UAV snapshots to show why overwriting the latest fields loses history and change evidence. The case explicitly records position, battery, and object-validity changes, binds revisions 1 and 2 by semantic fingerprints, and checks every declared before/after value against the snapshots while preserving the boundary that public State Transition does not compute a generic diff, propagate impact, recompute risk, or authorize action; -- ✅ Published GT24 as a bounded temporary-no-fly-zone impact case: one medical route intersects the active zone while an inspection route avoids it. The case validates an explicit finite dependency chain covering the medical route, mission, approval outputs, and launch action while excluding the inspection chain, with seven nodes, seven edges, four reevaluation targets, exact-byte bindings, and acyclic structure; it does not compute geometry, discover impact automatically, execute propagation or reevaluation, release outputs, or authorize action; -- ✅ Published GT25 as a bounded safety-distance recompute case: after a UAV moves from corridor chainage 100 to 130 metres, only two UAV-dependent distances are derived through the allowlisted `subtract` method, changing 50/160 metres to 20/130 metres, while 110-metre fixed-facility spacing and 48% battery remain immutable reusable paths. The case validates complete and disjoint scope, exact-byte bindings, and rejection of unregistered methods while explicitly not discovering dependencies automatically, executing arbitrary code, materializing state, rerunning checks, releasing outputs, or authorizing action; -- ✅ Published GT26 as a bounded flight-service-station schedule correction case: a fictional notice narrows the schedule from 08:00–22:00 to 09:00–18:00; the case permits one schedule-path replacement, preserves four immutable station attributes, and blocks the 20:30 mission output and dispatch action until a valid successor state and completed recheck exist, while explicitly not fetching real notices, applying correction, materializing state, releasing output, or authorizing action; -- ✅ Published GT27 as a weather-triggered incremental reevaluation case: after east-zone wind rises from 6 to 12 m/s, revision 7 first absorbs the new weather value and only Missions A and D in the matching region and active time window enter recheck. Mission A changes from suitable to unsuitable, Mission D remains suitable after explicit recheck, and Missions B and C are reused. The case binds both states, discrepancy, correction, impact graph, execution result, and output gates while not claiming automatic dependency discovery, production output release, or flight authorization; -- ✅ Published GT28 as an automatic-takeoff authorization-gate case: route, altitude, weather-window, and wind preconditions pass, but five independent authorization identifiers remain unknown. The case records the reusable route-weather precheck as eligible while automatic-takeoff authorization and the takeoff command remain blocked, and proves that even a fully true authorization context only makes outputs eligible while `action_executed` stays false; -- ✅ Completed publication of the GT21–GT28 scenario-first World-State Cycle. - -### v0.6: Verification Providers and Ecosystem Extensions (in progress) - -- ✅ Published Verification Provider Profile v0.1 for deterministic operators, rule engines, authoritative data providers, sensor data providers, local predictive models, and human review; -- ✅ Published four public Artifacts: Verification Provider Descriptor, Verification Request, Verification Response, and Assurance Profile, with read-only `geotask provider inspect/check/validate` commands; -- ✅ Added anti-self-assurance rules, exact Request/Descriptor byte bindings, independent-group, freshness, reproducibility, calibration, and action-boundary validation; -- ✅ Published GT29 as a fictional weather conflict: a mock weather service reports 8 m/s and an onsite sensor reports 13 m/s; two fresh independent sources still conflict, so Assurance remains unknown and a third independent source is requested; -- ✅ Published GT30 as a three-source weather conflict: a third independent source also reports 13 m/s, producing a two-to-one split; without a declared majority policy, Assurance remains unknown, the minority source is preserved, and explicit adjudication is requested; -- ✅ Published GT31 as a fictional human weather adjudication: the review binds all three GT30 responses and scoped context evidence, preserves every raw result, and limits the applicability of the two 13 m/s readings; the weather conclusion becomes eligible while a separate Control Evaluation keeps automatic takeoff authorization and the takeoff command blocked; -- ✅ Published GT32 as a progressive authorization-gate case: five fictional authorization records arrive one by one, the same finite control profile is reevaluated after each cumulative input, and unknown identifiers fall from five to zero; both takeoff-related outputs become eligible only at the final step, while publication, command delivery, real-world authorization, and action execution remain false; -- ✅ Published GT33 as the first moving-object and discrete-trajectory case: identity is separated from three timezone-aware 2D observations, trajectory references must close, timestamps must be strictly increasing, and interpolation is fixed to `none`; the tenth deterministic operator returns a 300-second endpoint duration while rejecting static-polyline substitution, implicit interpolation, future-position prediction, map matching, and action inference; -- ✅ Published GT34 for discrete trajectory segments and average speed: three explicit observations form two adjacent segments that bind sample indexes, timestamps, and coordinates, returning 120/180-second durations, 60/90 document-horizontal-unit distances, and 0.5 horizontal-unit-per-second averages; the eleventh deterministic operator rejects non-adjacent collapse, zero duration, unit overclaiming, instantaneous-speed inference, interpolation, smoothing, prediction, and real-world action; -- ✅ Published GT35 for stop/move and observation-gap classification: caller-declared stationary radius, minimum stationary duration, maximum observation interval, and gap permission classify three adjacent segments as `stationary_candidate`, `moving_observed`, and `observation_gap`; the twelfth deterministic operator returns `unverifiable` when gap marking is disallowed and rejects default thresholds, continuous-stop, lost-link, anomaly, interpolation, and action inference; -- ✅ Published GT36 for acceleration and motion continuity: caller-declared segment-midpoint representative time and maximum observation interval produce scalar estimates of 0 and 1/300 horizontal units per second squared for the first two adjacent speed transitions; the third transition becomes `unverifiable` with null speed change and acceleration because the next segment lasts 600 seconds. The thirteenth deterministic operator rejects instantaneous/vector acceleration, direction change, cross-gap computation, prediction, and action inference; -- ✅ Published GT37 for object-identity candidates: the final explicit sample of one trajectory and the first explicit sample of another are evaluated under caller-declared time, distance, and object-class policy to return `same_object_candidate`, `different_object_candidate`, or `unverifiable`. The fourteenth deterministic operator preserves original trajectory, subject, and class references while rejecting automatic identity merge, `subject_ref` mutation, real-world identity self-verification, interpolation, prediction, and action inference; -- ✅ Published GT38 for identity-candidate evidence and explicit adjudication: the twenty-eighth public Artifact and twenty-ninth public Schema bind the exact GT37 candidate, Verification Request, caller-authored Assurance Profile, and two independently grouped Provider responses into confirmed-same, confirmed-different, or unresolved adjudication. Even confirmed same-object evidence only enables merge review and never merges objects, mutates `subject_ref`, publishes, authorizes, or executes an identity update; -- ✅ Published GT39 for bounded identity-merge proposals: the twenty-ninth public Artifact and thirtieth public Schema bind one exact GT38 same-object adjudication to a caller-selected existing canonical subject, exactly one proposed `subject_ref` rewrite, retained alias history, approval roles, closed blocking and withdrawal conditions, and an inverse reversal plan. The proposal never creates or deletes identity, approves itself, mutates the object graph or World State, publishes, authorizes, or executes an update; -- ✅ Published GT40 for identity-merge approval records: the thirtieth public Artifact and thirty-first public Schema bind one exact GT39 proposal to one explicit approved, rejected, or evidence-required decision for every required role. Rejection takes precedence, evidence requests keep the proposal blocked, and all-role approval only makes a later bounded change request eligible without merging identity, mutating `subject_ref`, changing the object graph or World State, publishing, authorizing, or executing an update; -- ✅ Published GT41 for bounded object-graph change requests: the thirty-first public Artifact and thirty-second public Schema bind exact GT39 proposal and GT40 all-role approval bytes, then derive exactly one trajectory `subject_ref` rewrite, retained alias history, seven application preconditions, five acceptance criteria, and one inverse rollback operation. The request still requires separate application approval and does not authorize or apply a change, mutate the object graph or World State, publish, authorize, or execute an update; -- ✅ Published GT42 for object-graph change application approval records: the thirty-second public Artifact and thirty-third public Schema bind exact GT41 request bytes and require one explicit approved, rejected, or evidence-required decision for every caller-declared application-approval role. Rejection takes precedence, evidence requests keep application blocked, and all-role approval only makes a later bounded application Artifact eligible while application authorization, reference mutation, object-graph mutation, World State update, publication, authorization, and execution remain false; -- ✅ Established separate Chinese and English project entry points plus terminology maps while keeping machine identifiers stable; the Chinese guide now distinguishes software contracts, specifications, protocols, and legal/commercial contracts by function; -- continue with bounded object-graph change application results, successor World State generation, post-application acceptance, and reversible identity-governance specifications; -- publish reusable extension interfaces and non-sensitive reference implementations; -- establish benchmarks for error-detection rate, missed errors, correction success, incremental scope, and execution latency; -- support community-maintained catalogs of Verification Providers, cases, operators, and generic extensions. - -### Product maturity track (P0–P5) - -GT numbers remain the **Capability Track**. They prove individual public capabilities but no longer represent product maturity. After GT42, additional GT cases are paused unless the Reference Agent or a real industry integration exposes a missing reusable primitive. - -Current product state: **P0 Architecture Definition has completed its first re-baseline; P1 Reference Agent code, fixed scenarios, registered artifact chain, tutorials, experience page, and isolated public-export clean-room startup are implemented, with external unfamiliar-developer activation validation still pending; P2 Core Product release gates for 0.4.0 are closed: Verification Quality Benchmark v0.1, release-scope naming freeze, Artifact/Schema/Operator Registry developer experience, installation/migration evidence, wheel/sdist/33-Schema Bundle verification, installed-package Reference Agent replay, executed Python 3.10–3.13 CI, public export, and the RC Readiness Gate all passed, and GeoTask Core 0.4.0 was formally released on 2026-08-08. P3 has entered the real Lowa-GT shadow phase, but those results remain Integration validation and do not constitute Core Promotion; every cross-line capability transfer still requires an explicit Promotion Gate.** - -| Stage | Name | Primary gate | -|---|---|---| -| P0 | Architecture Definition | current facts, near-term goals, long-term vision, and Core/industry boundaries are consistent | -| P1 | Reference Agent | a new developer can run, modify, fail closed, and replay one end-to-end workflow | -| P2 | Core Product | public naming, Registry, quality benchmark, install/migration and release experience are product-grade | -| P3 | Industry Integration | one real industry system reuses Core without creating a second business truth | -| P4 | Ecosystem Validation | independent teams can build and reuse validated extensions | -| P5 | Commercial Validation | real customers pull private governance, deployment and long-term support capabilities | - -The near-term common spine is: `new evidence → world-state update → conflict/gap verification → bounded impact and recomputation → human review/approval → output becomes eligible without automatic publication or execution`. The first public Reference Agent uses a **fictional low-altitude facility assessment update**. The first real Lowa-GT integration mirrors the evidence–assessment–report chain in shadow mode rather than real-time flight authorization. - -See the [Architecture Manifesto](docs/architecture_manifesto_v1.md), [Reference Agent v0.1 specification](docs/reference/reference-agent-v0.1.md), [Verification Quality Benchmark v0.1](docs/reference/verification-quality-benchmark-v0.1.md), [GeoTask ↔ Lowa-GT Integration Contract v0.1](docs/reference/lowa-gt-integration-contract-v0.1.md), and [Productization Roadmap v0.2](docs/productization_roadmap_v0_2.md). +### 1. 当前 North Star + +> **Task Sufficiency at Minimum Context Cost** + +GeoTask 的目标不是最大化 Context 数量，而是在不增加关键遗漏的前提下，让当前任务获得真正需要、适用且足够的信息。 + +核心反指标： + +> **Critical Context Miss Rate** + +同时关注： + +- False Sufficiency Rate； +- Irrelevant / Inapplicable Context Rate； +- Unnecessary Context Rebuild； +- Provider / carried-context / token / latency / human-recovery cost。 + +### 2. 当前公共基线 ✅ + +当前 GitHub Public Core 已发布： + +- `TaskFrame`； +- `ContextRequirement`； +- `ContextCandidate`； +- Relevance / Applicability contracts； +- `ResolutionRequirement` / `ResolutionAdequacyResult`； +- `ContextAssessment` / `ContextGap`； +- `SufficiencyAssessment`； +- `TaskContext` / `ContextConstructionTrace`； +- Requirement-level assessment composition； +- deterministic context construction； +- context minimality / `MinimumSufficientTaskContext`； +- temporal reassessment / continuity contracts； +- provider-neutral composition seams。 + +已经公开一个独立消费者： + +- `examples/independent_consumers/warehouse_robot_picking/` + - indoor GIS / topology； + - inventory API； + - aisle-clearance sensor； + - Task → Requirement → Relevance / Applicability / Resolution → Sufficiency → Minimum Context → bounded Temporal Reassessment； + - 不依赖官方 WorldState； + - 不把 Context Sufficiency 误当成机器人动作授权。 + +### 3. GT-C1 — Requirement Derivation + +**问题：** 如何从 Task 稳定地得到它真正需要的 Requirement，而不是让调用方手写一份不可解释的上下文清单？ + +研究重点： + +- critical vs optional； +- spatial / temporal / semantic requirement； +- resolution need； +- validity / freshness need； +- evidence / source constraints； +- task-dependent derivation trace； +- domain profile 留在 consumer，不污染 Core。 + +成功标准： + +```text +same Task + same explicit method + same inputs +→ stable, inspectable requirements +``` + +### 4. GT-C2 — Relevance / Applicability Separation + +**问题：** 为什么“相关”不能直接等同于“适用”？ + +需要持续证明： + +```text +same candidate fact ++ different task / scope / time / condition +→ different applicability +``` + +方向： + +- relevance 与 applicability 独立证据； +- explicit method / policy seam； +- cross-domain holdout； +- 误纳无关/不适用 Context 的反指标。 + +### 5. GT-C3 — Resolution Adequacy & Sufficiency + +**问题：** “有数据”什么时候才足以支持任务？ + +至少考虑： + +- spatial resolution； +- temporal resolution / freshness； +- precision / uncertainty； +- semantic resolution； +- coverage / scope； +- critical requirement closure。 + +核心原则： + +```text +Available ≠ Adequate +Applicable ≠ Sufficient +High confidence ≠ Sufficient +``` + +### 6. GT-C4 — Minimum Context Cost + +**问题：** 如何减少 Context，而不是通过“漏掉关键事实”获得漂亮的成本数字？ + +目标： + +```text +Context Cost ↓ +while +Critical Context Miss does not ↑ +``` + +成本至少区分： + +- network acquisition cost； +- carried-context bytes； +- token/context cost； +- provider latency； +- human recovery cost。 + +研究重点： + +- requirement-level contribution； +- optional context pruning； +- minimum sufficient proof； +- payload reduction 与 upstream acquisition cost 的边界区分。 + +### 7. GT-C5 — Temporal Reassessment + +**问题：** 现实或 Provider 变化后，为什么不应该重建全部 Context？ + +目标链路： + +```text +Changed facts / provider state + ↓ +Affected ContextRequirements + ↓ +Reassess applicability / resolution / sufficiency + ↓ +ContextGap delta + ↓ +Minimal rebuild only when needed +``` + +主要度量： + +- affected-requirement precision / recall； +- Context Rebuild Locality； +- unnecessary rebuild； +- stale-context exposure； +- unaffected-context reuse correctness。 + +### 8. GT-C6 — Independent Consumers + +**问题：** GeoTask 是否真的独立于某一个业务、某一种 Provider 或官方 WorldState？ + +当前： + +- Warehouse Robot Picking 独立消费者 ✅ + +下一步： + +- 第二、第三独立领域； +- 不要求 Core Fork； +- 不引入 domain-specific Core branch； +- 使用 GIS / API / Sensor / Database / other provider 直接完成 Task → Context； +- 用相同公共语义度量 Task Sufficiency 与 Context Cost。 + +### 9. 下一条动态主线 — Reality Change → Context Reassessment + +GeoTask 只拥有其中的 Context 部分： + +```text +Reality / Provider Change + ↓ +Affected Requirements + ↓ +Applicability / Resolution / Sufficiency Reassessment + ↓ +TaskContext / ContextGap Delta + ↓ +Downstream grounding / domain decision +``` + +GeoTask 不因此接管： + +- world truth resolution； +- Agent runtime lifecycle； +- domain decision； +- business authorization； +- physical action execution。 + +### 10. Open Strategy + +GeoTask 的长期公共资产是： + +> **Task Context Method / Engine / Benchmark / Open Protocol** + +Provider 必须保持开放： + +```text +WorldState +GIS +API +Sensor +Database +GSTAR +Other Provider +``` + +只要能够映射到 GeoTask 的 ContextCandidate / assessment contracts，就不要求采用官方 WorldState 实现。 + +### 11. Legacy / Compatibility + +v0.1–v0.6 阶段已经发布的以下资产继续保留： + +- Verifiable Task Protocol； +- deterministic operators； +- Artifact Registry； +- Verification / Control contracts； +- World-State Cycle； +- Runtime / Verification Provider profiles； +- Reference Agent； +- GT01–GT42 examples； +- historical white paper / cookbook / release notes。 + +它们是已发布公共兼容资产与项目历史，不静默删除。 + +但从本 Roadmap 起： + +```text +GeoTask long-term target +≠ Trusted World-State Runtime +≠ Verifiable World Model + +GeoTask long-term target += Task Context Engine +``` + +--- + +## English roadmap + +### 1. North Star + +> **Task Sufficiency at Minimum Context Cost** + +GeoTask does not optimize for maximum context volume. It aims to provide the context the current task actually needs while keeping critical misses visible. + +Primary counter-metric: + +> **Critical Context Miss Rate** + +Also track false sufficiency, irrelevant/inapplicable context, unnecessary rebuilds, provider latency, carried bytes, token cost, and human recovery cost. + +### 2. Current public baseline ✅ + +The GitHub Public Core now includes: + +- `TaskFrame`; +- `ContextRequirement`; +- `ContextCandidate`; +- relevance / applicability contracts; +- resolution requirements and adequacy results; +- `ContextAssessment` / `ContextGap`; +- `SufficiencyAssessment`; +- `TaskContext` / `ContextConstructionTrace`; +- explicit requirement-assessment composition; +- deterministic context construction; +- context minimality / `MinimumSufficientTaskContext`; +- temporal reassessment / continuity contracts; +- provider-neutral composition seams. + +A public independent consumer is available at: + +- `examples/independent_consumers/warehouse_robot_picking/` + +It composes indoor GIS, an inventory API, and an aisle-clearance sensor without requiring the official WorldState implementation and keeps context sufficiency separate from robot action authorization. + +### 3. GT-C1 — Requirement Derivation + +Develop stable, inspectable Task → Requirement methods, including criticality, spatial/temporal/semantic needs, resolution, validity, freshness, and source constraints. + +### 4. GT-C2 — Relevance / Applicability Separation + +Prove that the same candidate fact can have different applicability under different task scopes, times, objects, and conditions. Keep relevance and applicability evidence independent. + +### 5. GT-C3 — Resolution Adequacy & Sufficiency + +Move beyond “data exists” toward explicit spatial, temporal, precision, semantic, coverage, and critical-requirement adequacy. + +```text +Available ≠ Adequate +Applicable ≠ Sufficient +High confidence ≠ Sufficient +``` + +### 6. GT-C4 — Minimum Context Cost + +Reduce context cost only while critical misses do not increase. + +```text +Context Cost ↓ +while +Critical Context Miss does not ↑ +``` + +Separate network acquisition, carried bytes, token cost, provider latency, and human recovery cost. + +### 7. GT-C5 — Temporal Reassessment + +Map provider/reality changes to affected requirements, reassess only what changed, and rebuild only what is necessary. + +```text +Change +→ affected requirements +→ reassessment +→ context/gap delta +→ minimal rebuild +``` + +### 8. GT-C6 — Independent Consumers + +Continue validating Task → Context outside any one domain, provider family, or official WorldState implementation, without Core forks or domain-specific Core branches. + +### 9. Dynamic frontier — Reality Change → Context Reassessment + +GeoTask owns the context-reassessment portion only. It does not take ownership of world truth, agent runtime lifecycle, domain judgment, business authorization, or physical execution. + +### 10. Open strategy + +The durable public assets are: + +> **Task Context Method / Engine / Benchmark / Open Protocol** + +Providers remain open and implementation-neutral: WorldState, GIS, APIs, sensors, databases, GSTAR, and other providers can participate when they map cleanly to GeoTask contracts. + +### 11. Legacy / compatibility + +Previously released Verifiable Task Protocol, World-State Cycle, Verification, Runtime/Provider, Reference Agent, GT examples, and historical documentation remain public compatibility assets and project history. + +They no longer define the long-term positioning: + +```text +GeoTask long-term target += Task Context Engine +``` From dab955aac8ce9df1920874c189275319f02cdf57 Mon Sep 17 00:00:00 2001 From: stpku <83755634+stpku@users.noreply.github.com> Date: Thu, 27 Aug 2026 09:53:28 +0800 Subject: [PATCH 06/17] docs: preserve case and metadata compatibility in new portal --- site/index.html | 126 +++++++----------------------------------------- 1 file changed, 17 insertions(+), 109 deletions(-) diff --git a/site/index.html b/site/index.html index 44124560..512e384f 100644 --- a/site/index.html +++ b/site/index.html @@ -10,6 +10,7 @@ + @@ -20,84 +21,24 @@ GeoTask｜面向 AI Agent 的时空任务上下文引擎 + -
-
- GTGeoTask - -
-
+
GTGeoTask
-
-
-

Spatiotemporal Task Context Engine for AI Agents

-

不是给 Agent 更多上下文，
而是给它当前任务真正需要的上下文。

-

GeoTask 围绕任务构造相关、适用、分辨率足够且可明确判断充分性的时空上下文，并在现实变化后只重评真正受影响的部分。

-
Task Sufficiency at Minimum Context Cost —— 用最小必要上下文支撑任务，同时让 Critical Context Miss 保持可见。
-
- 查看 GitHub - 看独立消费者 - 阅读 README -
-
-
Task-relative围绕当前任务，不维护“整个世界”
-
Provider-neutralGIS / API / Sensor / WorldState 均可接入
-
Explicit Sufficiency充分与缺口都必须显式
-
Minimum Context减少成本，但不隐藏关键遗漏
-
-
-
+

Spatiotemporal Task Context Engine for AI Agents

不是给 Agent 更多上下文，
而是给它当前任务真正需要的上下文。

GeoTask 围绕任务构造相关、适用、分辨率足够且可明确判断充分性的时空上下文，并在现实变化后只重评真正受影响的部分。

Task Sufficiency at Minimum Context Cost —— 用最小必要上下文支撑任务，同时让 Critical Context Miss 保持可见。
查看 GitHub看独立消费者阅读 README
Task-relative围绕当前任务，不维护“整个世界”
Provider-neutralGIS / API / Sensor / WorldState 均可接入
Explicit Sufficiency充分与缺口都必须显式
Minimum Context减少成本，但不隐藏关键遗漏
-
-
-

Problem

Agent 的上下文问题，本质上不是“装多少”，而是“什么足够”。

长上下文窗口、RAG、数据库和工具都能提供更多信息，但它们不会自动回答这些信息是否真的适用于当前任务。

-
-

相关 ≠ 适用

同一条事实可以与任务主题相关，却不适用于当前对象、区域、时间窗口或运行条件。

-

有数据 ≠ 分辨率足够

存在地图、气象、库存或传感器值，并不意味着空间、时间、精度和语义粒度足以支持任务。

-

上下文很多 ≠ 上下文充分

大 payload 可能仍遗漏一个 critical requirement；反过来，大量可选信息也可能只是增加 token、网络与认知成本。

-
-
-
+

Problem

Agent 的上下文问题，本质上不是“装多少”，而是“什么足够”。

长上下文窗口、RAG、数据库和工具都能提供更多信息，但它们不会自动回答这些信息是否真的适用于当前任务。

相关 ≠ 适用

同一条事实可以与任务主题相关，却不适用于当前对象、区域、时间窗口或运行条件。

有数据 ≠ 分辨率足够

存在地图、气象、库存或传感器值，并不意味着空间、时间、精度和语义粒度足以支持任务。

上下文很多 ≠ 上下文充分

大 payload 可能仍遗漏一个 critical requirement；反过来，大量可选信息也可能只是增加 token、网络与认知成本。

-
-
-
-

Task → Context，而不是 World → Prompt

-

GeoTask 先从任务建立 Requirement，再评估候选信息；Relevance、Applicability、Resolution 和 Sufficiency 保持分离，最终形成最小充分 TaskContext 与显式 Gap / Trace。

-
- Task→Requirements→Candidates→Relevance→Applicability→Resolution→Sufficiency→Minimum TaskContext -
-
核心对象包括 TaskFrame、ContextRequirement、ContextCandidate、ContextAssessment、ContextGap、SufficiencyAssessment、TaskContext、ContextConstructionTrace，以及 Minimum Context 与 Temporal Reassessment 相关合同。
-
-
-
+

Task → Context，而不是 World → Prompt

GeoTask 先从任务建立 Requirement，再评估候选信息；Relevance、Applicability、Resolution 和 Sufficiency 保持分离，最终形成最小充分 TaskContext 与显式 Gap / Trace。

Task→Requirements→Candidates→Relevance→Applicability→Resolution→Sufficiency→Minimum TaskContext
核心对象包括 TaskFrame、ContextRequirement、ContextCandidate、ContextAssessment、ContextGap、SufficiencyAssessment、TaskContext、ContextConstructionTrace，以及 Minimum Context 与 Temporal Reassessment 相关合同。
-
-
-

Boundary

GeoTask 不拥有世界真值，也不替代 Agent Runtime。

GeoTask 的独立价值来自 Task-relative Context。上游负责提供现实候选信息，下游负责推理、领域判断与动作授权。

-
-
UpstreamWorld / Data Providers

WorldState、GIS、API、Sensor、Database、GSTAR 或其他 Provider 提供候选事实、来源和状态。

-
GeoTaskTask Context

判断当前任务需要什么，哪些候选相关、适用、分辨率足够，以及上下文是否充分。

-
DownstreamAgent / Domain System

Agent Harness 运行推理；领域系统继续拥有专业判断、授权、执行和责任边界。

-
-
Context Sufficient ≠ Domain Decision ≠ Action Authorization
-
-
+

Boundary

GeoTask 不拥有世界真值，也不替代 Agent Runtime。

GeoTask 的独立价值来自 Task-relative Context。上游负责提供现实候选信息，下游负责推理、领域判断与动作授权。

UpstreamWorld / Data Providers

WorldState、GIS、API、Sensor、Database、GSTAR 或其他 Provider 提供候选事实、来源和状态。

GeoTaskTask Context

判断当前任务需要什么，哪些候选相关、适用、分辨率足够，以及上下文是否充分。

DownstreamAgent / Domain System

Agent Harness 运行推理；领域系统继续拥有专业判断、授权、执行和责任边界。

Context Sufficient ≠ Domain Decision ≠ Action Authorization
-
-
-

Current Public Proof

已经有独立消费者，不再只靠定义证明自己。

当前公共 Core 已发布 Task Context 合同、候选 Provider、Relevance / Applicability / Resolution、Sufficiency Composition、Minimum Context 与 Temporal Continuity，并用非低空场景进行独立验证。

-
-

Warehouse Robot Picking

-

室内 GIS、库存 API 与通道净宽传感器分别提供 ContextCandidate。GeoTask 构造任务 Requirement，独立评估相关性、适用性与分辨率，形成 Sufficiency 和 Minimum TaskContext；传感器变化后只刷新受影响 Requirement。

-
Indoor GIS / Inventory API / Aisle Sensor +

Current Public Proof

已经有独立消费者，不再只靠定义证明自己。

当前公共 Core 已发布 Task Context 合同、候选 Provider、Relevance / Applicability / Resolution、Sufficiency Composition、Minimum Context 与 Temporal Continuity，并用非低空场景进行独立验证。

Warehouse Robot Picking

室内 GIS、库存 API 与通道净宽传感器分别提供 ContextCandidate。GeoTask 构造任务 Requirement，独立评估相关性、适用性与分辨率，形成 Sufficiency 和 Minimum TaskContext；传感器变化后只刷新受影响 Requirement。

Indoor GIS / Inventory API / Aisle Sensor ↓ TaskFrame → ContextRequirement[] → ContextCandidate[] ↓ @@ -105,50 +46,17 @@

Warehouse Robot Picking

↓ Sufficiency → Minimum Sufficient TaskContext ↓ -Sensor Change → Bounded Temporal Reassessment
-

关键反例：即使通道实测宽度小于机器人宽度，只要这个测量本身相关、适用、新鲜且分辨率足够，GeoTask 仍可判断“上下文充分”；但它不会判断“机器人可以通行”。

- 打开完整示例 → -
-
-
+Sensor Change → Bounded Temporal Reassessment

关键反例：即使通道实测宽度小于机器人宽度，只要这个测量本身相关、适用、新鲜且分辨率足够，GeoTask 仍可判断“上下文充分”；但它不会判断“机器人可以通行”。

打开完整示例 →
-
-
-

Measure

目标不是 Context Reduction 本身，而是“充分前提下的最小成本”。

任何“减少上下文”的正指标都必须配一个反指标，避免系统通过漏掉关键事实来获得更漂亮的成本数字。

-
-
Critical Requirement Coverage ↑Counter: Critical Context Miss Rate
-
Sufficiency Accuracy ↑Counter: False Sufficiency Rate
-
Context Reduction ↑Counter: Critical Context Miss Rate
-
Applicability Accuracy ↑Counter: Irrelevant / Inapplicable Context Rate
-
Context Rebuild Locality ↑Counter: Unnecessary Context Rebuild
-
-
-
+

Measure

目标不是 Context Reduction 本身，而是“充分前提下的最小成本”。

任何“减少上下文”的正指标都必须配一个反指标，避免系统通过漏掉关键事实来获得更漂亮的成本数字。

Critical Requirement Coverage ↑Counter: Critical Context Miss Rate
Sufficiency Accuracy ↑Counter: False Sufficiency Rate
Context Reduction ↑Counter: Critical Context Miss Rate
Applicability Accuracy ↑Counter: Irrelevant / Inapplicable Context Rate
Context Rebuild Locality ↑Counter: Unnecessary Context Rebuild
-
-
-

Research Roadmap

下一阶段研究的不是更多 GT 编号，而是 Task Context 方法本身。

GeoTask 作为独立 Foundation 持续推进自己的问题、Benchmark 和跨领域验证。

-
-

Requirement Derivation

从显式 Requirement 继续走向稳定的 Task → Requirement 方法，并保留来源与推导轨迹。

-

Applicability & Resolution

证明“同一事实 + 不同任务 → 不同适用性”，同时把空间、时间、精度与语义分辨率变成可评估要求。

-

Minimum Context Cost

在 Critical Context Miss 不上升的前提下降低 carried bytes、token、Provider latency 与恢复成本。

-

Temporal Reassessment

现实变化映射到受影响 Requirement，只做有界重评和必要的最小重建。

-

Independent Consumers

继续用第二、第三领域验证公共 Core，不让任何单一产品的数据模型塑形 GeoTask。

-

Open Method & Protocol

长期公共资产是 Task Context Method、Engine、Benchmark 与开放合同，而不是一个封闭领域平台。

-
-
关于旧定位：GeoTask 早期公开版本中的 Verifiable World Model / World-State Cycle / Verification 资产继续保留并维护，用于兼容与历史可追溯；它们不再定义长期语义所有权。当前定位以 Task Context Engine 为准。
-
-
+

Research Roadmap

下一阶段研究的不是更多 GT 编号，而是 Task Context 方法本身。

GeoTask 作为独立 Foundation 持续推进自己的问题、Benchmark 和跨领域验证。

Requirement Derivation

从显式 Requirement 继续走向稳定的 Task → Requirement 方法，并保留来源与推导轨迹。

Applicability & Resolution

证明“同一事实 + 不同任务 → 不同适用性”，同时把空间、时间、精度与语义分辨率变成可评估要求。

Minimum Context Cost

在 Critical Context Miss 不上升的前提下降低 carried bytes、token、Provider latency 与恢复成本。

Temporal Reassessment

现实变化映射到受影响 Requirement，只做有界重评和必要的最小重建。

Independent Consumers

继续用第二、第三领域验证公共 Core，不让任何单一产品的数据模型塑形 GeoTask。

Open Method & Protocol

长期公共资产是 Task Context Method、Engine、Benchmark 与开放合同，而不是一个封闭领域平台。

关于旧定位：GeoTask 早期公开版本中的 Verifiable World Model / World-State Cycle / Verification 资产继续保留并维护，用于兼容与历史可追溯；它们不再定义长期语义所有权。当前定位以 Task Context Engine 为准。
-
-
-
-

从“给模型更多信息”，转向“证明当前任务的信息已经足够”。

-

GeoTask Core 采用 MIT License。你可以从独立消费者、Python API 或现有公开示例开始，把自己的 GIS、API、Sensor 或 WorldState Provider 接进来。

-
GitHub RepositoryDeveloper GuideEnglish
-
-
-
+

Legacy Public Cases

GT01—GT42 继续保留，但不再承担“定义 GeoTask”的职责。

这些案例记录 GeoTask 从确定性时空任务协议、验证与 World-State Cycle 演化到 Task Context Engine 的公开历史。它们继续可访问、可复现、可追溯。

GT01GT02GT03GT04GT05GT06GT07GT08GT09GT10GT11GT12GT13GT14GT15GT16GT17GT18GT19GT20GT21GT22GT23GT24GT25GT26GT27GT28GT29GT30GT31GT32GT33GT34GT35GT36GT37GT38GT39GT40GT41GT42
+ +

Documentation

新主线与历史资产分层，而不是删除历史。

优先阅读 README 与新 Public Roadmap；需要追溯既有 Artifact、Verification、World-State Cycle 时再进入历史文档。

当前 README / Task Context Engine当前 Public Roadmap5 分钟中文 QuickstartWarehouse Robot Picking历史白皮书 v0.1历史 Language Spec v1.0历史 World State v0.1Verification Quality Benchmark v0.2
+ +

从“给模型更多信息”，转向“证明当前任务的信息已经足够”。

GeoTask Core 采用 MIT License。你可以从独立消费者、Python API 或现有公开示例开始，把自己的 GIS、API、Sensor 或 WorldState Provider 接进来。

GitHub RepositoryDeveloper GuideEnglish
GeoTask · Spatiotemporal Task Context Engine for AI AgentsUpdated positioning: 2026-08-27 · GitHub
From 2f0ba82b3d5fb09f41ebee44c556ba7b6914cc67 Mon Sep 17 00:00:00 2001 From: stpku <83755634+stpku@users.noreply.github.com> Date: Thu, 27 Aug 2026 09:54:06 +0800 Subject: [PATCH 07/17] test: align portal contract with task context positioning --- tests/test_project_portal.py | 90 ++++++++++++++++++------------------ 1 file changed, 44 insertions(+), 46 deletions(-) diff --git a/tests/test_project_portal.py b/tests/test_project_portal.py index c58e042c..c520bd1a 100644 --- a/tests/test_project_portal.py +++ b/tests/test_project_portal.py @@ -17,51 +17,55 @@ MANIFEST = ROOT / ".release" / "public-manifest.yaml" -def test_root_page_is_project_portal_not_gt01_experience() -> None: +def test_root_page_is_task_context_engine_portal() -> None: html = PORTAL.read_text(encoding="utf-8") - assert "智能体的可验证" in html - assert "时空世界模型" in html - assert "让大模型理解世界，让GeoTask验证并维护世界" in html - assert "智能体不只需要理解世界，更需要一个可以验证的世界模型" in html - assert "30秒看懂一次世界状态更新" in html - assert "四个平面构成可验证时空世界模型" in html - assert "六类能力共同维护智能体的世界" in html - assert "观测记录、世界状态、受限观测合并、状态转换、验证会话、差异报告、纠偏请求、影响图、受限重算推导、受限后继状态物化、增量复核结果、验证提供方公共合同" in html - assert "自动差异计算、对象身份发现、未声明策略的歧义冲突消解、影响关系自动发现与传播执行" in html - assert "新Observation" not in html - assert "公共Artifact" not in html - assert "保护商业运行层" not in html - assert "商业边界" not in html - assert "GT01—GT42公开参考例" in html - assert "42个可验证参考例" in html - assert "38个场景入口" in html - assert "巡检无人机短暂失联后被重新编号" in html - assert html.count('
') == 1 - assert 'id="demo"' in html - assert 'id="cases"' in html - assert 'id="architecture"' in html - assert 'id="docs"' in html + assert "时空任务上下文引擎" in html + assert "不是给 Agent 更多上下文" in html + assert "Task Sufficiency at Minimum Context Cost" in html + assert "相关 ≠ 适用" in html + assert "Task → Context" in html + assert "Context Sufficient ≠ Domain Decision ≠ Action Authorization" in html + assert "Warehouse Robot Picking" in html + assert "GT01—GT42 继续保留" in html + + # The previous World-State / Verifiable-World-Model positioning is historical, + # not the current portal identity. + assert "面向智能体的可验证时空世界模型" not in html + assert "让大模型理解世界，让GeoTask验证并维护世界" not in html + assert "六类能力共同维护智能体的世界" not in html + + for section_id in ( + "problem", + "method", + "boundary", + "architecture", + "proof", + "measure", + "roadmap", + "cases", + "docs", + ): + assert f'id="{section_id}"' in html assert 'id="copy-open"' not in html assert 'id="task-source"' not in html assert 'id: "minimal-distance-v1"' not in html -def test_portal_exposes_gt16_world_state_update_demo() -> None: +def test_portal_exposes_independent_task_context_consumer() -> None: html = PORTAL.read_text(encoding="utf-8") for fragment in ( - "初始世界状态", - "新的观测记录", - "世界关系更新", - "行动资格更新", - "计划间隔120秒", - "A机最新遥测显示延误40秒", - "预测间隔缩至80秒", - "间隔降至60秒", - "世界模型不是一次性结论", - 'href="gt16/"', + "Indoor GIS / Inventory API / Aisle Sensor", + "TaskFrame → ContextRequirement[] → ContextCandidate[]", + "Relevance / Applicability / Resolution Adequacy", + "Sufficiency → Minimum Sufficient TaskContext", + "Sensor Change → Bounded Temporal Reassessment", + "通道实测宽度小于机器人宽度", + "上下文充分", + "机器人可以通行", + "examples/independent_consumers/warehouse_robot_picking", ): assert fragment in html @@ -80,20 +84,14 @@ def test_portal_links_primary_public_resources() -> None: required = ( "https://github.com/stpku/GeoTask", + "README.md", + "ROADMAP.md", + "examples/independent_consumers/warehouse_robot_picking", + "docs/tutorials/quickstart.zh-CN.md", "docs/whitepaper/GeoTask_White_Paper_v0.1.md", "docs/spec/geotask-language-spec-v1.0.md", "docs/spec/geotask-world-state-v0.1.md", - "docs/spec/geotask-state-transition-v0.1.md", - "docs/spec/geotask-verification-session-v0.1.md", - "docs/spec/geotask-discrepancy-report-v0.1.md", - "docs/spec/geotask-correction-request-v0.1.md", - "docs/spec/geotask-impact-graph-v0.1.md", - "docs/spec/geotask-incremental-reevaluation-result-v0.1.md", - "docs/tutorials/quickstart.zh-CN.md", - "docs/spec/geotask-verification-provider-profile-v0.1.zh-CN.md", - "docs/spec/geotask-trajectory-profile-v0.1.zh-CN.md", - "docs/terminology.zh-CN.md", - "schemas/geotask-v1.0.schema.json", + "docs/reference/verification-quality-benchmark-v0.2.md", ) for fragment in required: assert fragment in html @@ -110,7 +108,7 @@ def test_portal_has_search_and_share_metadata() -> None: '', '', '
GTGeoTask
-
-

Spatiotemporal Task Context Engine for AI Agents

不是给 Agent 更多上下文，
而是给它当前任务真正需要的上下文。

GeoTask 围绕任务构造相关、适用、分辨率足够且可明确判断充分性的时空上下文，并在现实变化后只重评真正受影响的部分。

Task Sufficiency at Minimum Context Cost —— 用最小必要上下文支撑任务，同时让 Critical Context Miss 保持可见。
查看 GitHub看独立消费者阅读 README
Task-relative围绕当前任务，不维护“整个世界”
Provider-neutralGIS / API / Sensor / WorldState 均可接入
Explicit Sufficiency充分与缺口都必须显式
Minimum Context减少成本，但不隐藏关键遗漏
+

Spatiotemporal Task Context Engine for AI Agents

不是给 Agent 更多上下文，
而是给它当前任务真正需要的上下文。

GeoTask 是面向 AI Agent 的时空任务上下文引擎。它围绕任务构造相关、适用、分辨率足够且可明确判断充分性的上下文，并在现实变化后只重评真正受影响的部分。

Task Sufficiency at Minimum Context Cost —— 用最小必要上下文支撑任务，同时让 Critical Context Miss 保持可见。
查看 GitHub看独立消费者阅读 README
-

Problem

Agent 的上下文问题，本质上不是“装多少”，而是“什么足够”。

长上下文窗口、RAG、数据库和工具都能提供更多信息，但它们不会自动回答这些信息是否真的适用于当前任务。

相关 ≠ 适用

同一条事实可以与任务主题相关，却不适用于当前对象、区域、时间窗口或运行条件。

有数据 ≠ 分辨率足够

存在地图、气象、库存或传感器值，并不意味着空间、时间、精度和语义粒度足以支持任务。

上下文很多 ≠ 上下文充分

大 payload 可能仍遗漏一个 critical requirement；反过来，大量可选信息也可能只是增加 token、网络与认知成本。

+

Problem

Agent 的上下文问题，不是“装多少”，而是“什么足够”。

长上下文窗口、RAG、数据库和工具可以提供更多信息，但不会自动回答这些信息是否真的适用于当前任务。

相关 ≠ 适用

同一事实可以与任务主题相关，却不适用于当前对象、空间、时间窗口或运行条件。

有数据 ≠ 分辨率足够

存在地图、气象、库存或传感器值，并不意味着空间、时间、精度和语义粒度足以支持任务。

上下文很多 ≠ 上下文充分

大 payload 仍可能遗漏 critical requirement；大量可选信息也可能只增加 token、网络与认知成本。

-

Task → Context，而不是 World → Prompt

GeoTask 先从任务建立 Requirement，再评估候选信息；Relevance、Applicability、Resolution 和 Sufficiency 保持分离，最终形成最小充分 TaskContext 与显式 Gap / Trace。

Task→Requirements→Candidates→Relevance→Applicability→Resolution→Sufficiency→Minimum TaskContext
核心对象包括 TaskFrame、ContextRequirement、ContextCandidate、ContextAssessment、ContextGap、SufficiencyAssessment、TaskContext、ContextConstructionTrace，以及 Minimum Context 与 Temporal Reassessment 相关合同。
+

Task → Context，而不是 World → Prompt

GeoTask 先从任务建立 Requirement，再评估候选信息；Relevance、Applicability、Resolution Adequacy 和 Sufficiency 保持分离。

Task→Requirements→Candidates→Relevance→Applicability→Resolution→Sufficiency→Minimum TaskContext
核心对象包括 TaskFrame、ContextRequirement、ContextCandidate、ContextAssessment、ContextGap、SufficiencyAssessment、TaskContext 与 ContextConstructionTrace。
-

Boundary

GeoTask 不拥有世界真值，也不替代 Agent Runtime。

GeoTask 的独立价值来自 Task-relative Context。上游负责提供现实候选信息，下游负责推理、领域判断与动作授权。

UpstreamWorld / Data Providers

WorldState、GIS、API、Sensor、Database 或其他 Provider 提供候选事实、来源和状态。

GeoTaskTask Context

判断当前任务需要什么，哪些候选相关、适用、分辨率足够，以及上下文是否充分。

DownstreamAgent / Domain System

Agent Harness 运行推理；领域系统继续拥有专业判断、授权、执行和责任边界。

Context Sufficient ≠ Domain Decision ≠ Action Authorization
+

Boundary

GeoTask 不拥有世界真值，也不替代 Agent Runtime。

上游负责现实候选信息，下游负责推理、领域判断与动作授权；GeoTask 拥有的是 Task-relative Context。

UpstreamWorld / Data Providers

WorldState、GIS、API、Sensor、Database 或 Other Provider 提供候选事实与状态。

GeoTaskTask Context

判断当前任务需要什么，哪些候选相关、适用、分辨率足够，以及上下文是否充分。

DownstreamAgent / Domain System

Agent Harness 运行推理；领域系统继续拥有专业判断、授权、执行与责任边界。

Context Sufficient ≠ Domain Decision ≠ Action Authorization
-

Current Public Proof

已经有独立消费者，不再只靠定义证明自己。

当前公共 Core 已发布 Task Context 合同、候选 Provider、Relevance / Applicability / Resolution、Sufficiency Composition、Minimum Context 与 Temporal Continuity，并用非低空场景进行独立验证。

Warehouse Robot Picking

室内 GIS、库存 API 与通道净宽传感器分别提供 ContextCandidate。GeoTask 构造任务 Requirement，独立评估相关性、适用性与分辨率，形成 Sufficiency 和 Minimum TaskContext；传感器变化后只刷新受影响 Requirement。

Indoor GIS / Inventory API / Aisle Sensor +

Current Public Proof

已经有独立消费者，不再只靠定义证明自己。

公共 Core 已覆盖 Requirement、Candidate、Relevance / Applicability / Resolution、Sufficiency、Minimum Context 与 Temporal Reassessment。

Warehouse Robot Picking

室内 GIS、库存 API 与通道净宽传感器分别提供 ContextCandidate；GeoTask 构造 Requirement、判断充分性并在传感器变化后只刷新受影响 Requirement。

Indoor GIS / Inventory API / Aisle Sensor ↓ TaskFrame → ContextRequirement[] → ContextCandidate[] ↓ @@ -46,19 +45,118 @@ ↓ Sufficiency → Minimum Sufficient TaskContext ↓ -Sensor Change → Bounded Temporal Reassessment

关键反例：即使通道实测宽度小于机器人宽度，只要这个测量本身相关、适用、新鲜且分辨率足够，GeoTask 仍可判断“上下文充分”；但它不会判断“机器人可以通行”。

打开完整示例 →
+Sensor Change → Bounded Temporal Reassessment

关键反例：即使通道实测宽度小于机器人宽度，只要测量本身相关、适用、新鲜且分辨率足够，GeoTask 仍可判断“上下文充分”；但不会判断“机器人可以通行”。

打开完整示例 →
-

Measure

目标不是 Context Reduction 本身，而是“充分前提下的最小成本”。

任何“减少上下文”的正指标都必须配一个反指标，避免系统通过漏掉关键事实来获得更漂亮的成本数字。

Critical Requirement Coverage ↑Counter: Critical Context Miss Rate
Sufficiency Accuracy ↑Counter: False Sufficiency Rate
Context Reduction ↑Counter: Critical Context Miss Rate
Applicability Accuracy ↑Counter: Irrelevant / Inapplicable Context Rate
Context Rebuild Locality ↑Counter: Unnecessary Context Rebuild
+

Measure

充分前提下的最小成本，而不是 Context Reduction 本身。

任何“减少上下文”的正指标都必须配反指标，避免系统通过漏掉关键事实获得漂亮数字。

Critical Requirement Coverage ↑Counter: Critical Context Miss Rate
Sufficiency Accuracy ↑Counter: False Sufficiency Rate
Applicability Accuracy ↑Counter: Irrelevant / Inapplicable Context Rate
Context Rebuild Locality ↑Counter: Unnecessary Context Rebuild
-

Research Roadmap

下一阶段研究的不是更多 GT 编号，而是 Task Context 方法本身。

GeoTask 作为独立 Foundation 持续推进自己的问题、Benchmark 和跨领域验证。

Requirement Derivation

从显式 Requirement 继续走向稳定的 Task → Requirement 方法，并保留来源与推导轨迹。

Applicability & Resolution

证明“同一事实 + 不同任务 → 不同适用性”，同时把空间、时间、精度与语义分辨率变成可评估要求。

Minimum Context Cost

在 Critical Context Miss 不上升的前提下降低 carried bytes、token、Provider latency 与恢复成本。

Temporal Reassessment

现实变化映射到受影响 Requirement，只做有界重评和必要的最小重建。

Independent Consumers

继续用第二、第三领域验证公共 Core，不让任何单一产品的数据模型塑形 GeoTask。

Open Method & Protocol

长期公共资产是 Task Context Method、Engine、Benchmark 与开放合同，而不是一个封闭领域平台。

关于旧定位：GeoTask 早期公开版本中的 Verifiable World Model / World-State Cycle / Verification 资产继续保留并维护，用于兼容与历史可追溯；它们不再定义长期语义所有权。当前定位以 Task Context Engine 为准。
+

Research Roadmap

下一阶段研究 Task Context 方法本身。

Requirement Derivation

稳定的 Task → Requirement 方法与推导轨迹。

Applicability & Resolution

把对象、空间、时间、精度和语义分辨率变成显式要求。

Minimum Context Cost

在 Critical Context Miss 不上升的前提下降低上下文成本。

Temporal Reassessment

变化只触发有界重评和必要的最小重建。

Independent Consumers

用更多领域验证公共 Core 不被单一业务塑形。

Open Method & Protocol

长期公共资产是 Method、Engine、Benchmark 与开放合同。

关于旧定位：Verifiable World Model / World-State Cycle / Verification 资产继续作为历史兼容面维护，但不再定义长期语义所有权。当前定位以 Task Context Engine 为准。
-

Legacy Public Cases

GT01—GT42 继续保留，但不再承担“定义 GeoTask”的职责。

这些案例记录 GeoTask 从确定性时空任务协议、验证与 World-State Cycle 演化到 Task Context Engine 的公开历史。它们继续可访问、可复现、可追溯。

GT01GT02GT03GT04GT05GT06GT07GT08GT09GT10GT11GT12GT13GT14GT15GT16GT17GT18GT19GT20GT21GT22GT23GT24GT25GT26GT27GT28GT29GT30GT31GT32GT33GT34GT35GT36GT37GT38GT39GT40GT41GT42
+
+
+
+

P1 Reference Agent：历史 Product Track 的完整闭环

GT01—GT42证明单项能力；Reference Agent把新证据、World State、Discrepancy、Correction、Impact与Control串成一条可运行、可失败、可重放的设施评估更新链。它继续作为已发布兼容资产保留，但不再定义 GeoTask 的当前产品定位。

+ 进入Reference Agent体验 → +
+
+
rev1 → rev2新观测记录先只更新事实，不把旧评估偷偷一起修改。
+
Discrepancy → Impact注册Artifact明确哪些结论已经stale、哪些路径需要重算、哪些结果继续复用。
+
rev3只重算障碍距离与净空结论，不触发整站全局重算。
+
Control条件全部满足只使报告更新eligible，生产写入和现实动作仍为false。
+
+
体验完整闭环
+
+
-

Documentation

新主线与历史资产分层，而不是删除历史。

优先阅读 README 与新 Public Roadmap；需要追溯既有 Artifact、Verification、World-State Cycle 时再进入历史文档。

当前 README / Task Context Engine当前 Public Roadmap5 分钟中文 QuickstartWarehouse Robot Picking历史白皮书 v0.1历史 Language Spec v1.0历史 World State v0.1Verification Quality Benchmark v0.2
+ +
+
+
+

GT01—GT42公开参考例

共42个可验证参考例，对应38个场景入口；GT38—GT42作为一个五阶段复合案例，完整展示无人机身份从证据审定到应用审批的治理链。

+ 查看中文文档导航 → +
+
+

1空间关系：对象、算子与边界语义

+
+ GT01

模型得到5米，为什么还要本地复算？

用两个点和distance_2d建立第一条模型—确定性验证路径。

进入体验 → + GT02

答对，不等于已经验证

比较模型给出的144.22米与浏览器本地确定性结果。

进入体验 → + GT03

最后一段进入限制区，整条路线算相交吗？

逐段检查折线，而不是只看起点与终点。

进入体验 → +
+
+
+

2时空组合：二维、高度与时间

+
+ GT04

水平相交但高度分离，算冲突吗？

二维投影重叠不等于三维空间冲突。

进入体验 → + GT05

位置高度相同，但时间不同，算冲突吗？

显式核验时间区间，而不是只看空间关系。

进入体验 → + GT06

多项条件怎样组合成最终结论？

路线相交、高度重叠、时间不重叠，通过显式AND得到false。

进入体验 → +
+
+
+

3不确定性与证据：不知道以后怎么办

+
+ GT07

时间条件无法核验，AI能强行判断吗？

true AND true AND unknown仍然是unknown。

进入体验 → + GT08

AI知道自己不知道以后，下一步做什么？

生成结构化补证据任务，并在证据补齐后重新执行受影响断言。

进入体验 → + GT09

两份禁飞通知互相矛盾，信哪一份？

单份证据已核验，不代表多份证据彼此一致。

进入体验 → +
+
+
+

4行动与可行性：从判断走向执行

+
+ GT10

两台机器人抢同一条窄通道，谁先走？

把容量、占用时间和优先级转化为可执行协调计划。

进入体验 → + GT11

目标只有50米，机器人为什么绕行300米？

几何距离不等于对象在真实网络中的可达路线。

进入体验 → + GT12

电量够到达，无人机为什么仍不能起飞？

能到达目标不等于能保留安全余量完成任务。

进入体验 → + GT13

道路开放，车辆为什么还是过不去？

道路状态与具体车辆的安全空间包络必须分别判断。

进入体验 → + GT14

最近的救援队，为什么不一定最快到达？

直线距离只是空间事实，派遣动作必须验证真实路线、准备时间和响应窗口。

进入体验 → + GT15

地图说可以通行，机器人为什么停下来了？

静态地图描述结构可通行性，实时感知决定当前路线是否被障碍占据。

进入体验 → + GT16

计划已经安全，为什么无人机仍要持续监测？

初始间隔满足要求，但A机延误40秒后预测间隔从120秒缩至80秒；结论仍可用，却必须持续监测并准备增量复核。

进入体验 → + GT17

同一个事件被上报十次，系统应该生成十个任务吗？

空间、时间和事件语义一致时，应合并处置任务并保留全部来源证据。

进入体验 → + GT18

最短路线已经找到，为什么救援机器人仍然不能进入？

路线能够到达目标仍不足以执行，还必须核验危险区和具体设备耐受能力。

进入体验 → + GT19

无人机已经到达目标上空，为什么仍然不能投放物资？

导航到达、高度和时间合规仍不足以释放载荷，还必须取得新鲜的地面净空证据。

进入体验 → + GT20

车辆已经获得绿灯，为什么仍然不能进入路口？

信号许可仍不足以进入冲突区，还必须证明下游出口净空并能容纳完整车辆。

进入体验 → +
+
+
+

5世界状态循环：观测记录、快照与增量复核

+
+ GT21

遥测显示延误60秒，运行审核记录显示55秒，AI应该相信哪一个？

同一架无人机的延误数据来自两个系统。直接覆盖、取平均或按到达顺序选择都会掩盖冲突，必须使用业务方明确声明的处理规则。

进入体验 → + GT22

无人机的位置和电量来自两个系统，AI怎样形成同一时刻的可靠运行快照？

位置与电量分别到达时，不能简单拼接成“当前状态”。系统必须确认对象、时间和字段归属，才能形成可追溯的统一运行快照。

进入体验 → + GT23

无人机飞行五分钟后位置和电量都变了，系统如何证明“现在”不是“刚才”？

只覆盖最新值会丢失历史和变化依据。系统必须保留前后运行快照，绑定300秒时间差，并明确记录位置、电量和对象有效期变化。

进入体验 → + GT24

临时禁飞区发布后，哪些航线、任务和审批结论必须重新检查？

医疗航线穿越临时禁飞区，巡检航线绕开。系统只将医疗航线、任务、审批和起飞动作纳入复核链，避免全量重算或只更新地图。

进入体验 → + GT25

无人机位置更新后，哪些安全距离需要重算，哪些结果可以继续沿用？

无人机从走廊100米移动到130米后，只重算与无人机位置相关的两项安全距离，同时保留固定设施间距和电池余量。

进入体验 → + GT26

飞行服务站营业时间已经失效，系统应该改哪条数据，而不是推翻全部结果？

服务站营业计划从08:00—22:00调整为09:00—18:00，系统只允许替换营业计划，保留位置、频率、服务类型和联系方式，并阻断20:30任务直至复核。

进入体验 → + GT27

一条气象数据更新后，如何只复核受影响的飞行任务？

东区风速由6升至12米/秒后，只复核同区域且处于更新生效时段的配送和应急任务；一个结果变为不适飞，另一个复核后仍适飞，西区和更新前任务继续复用。

进入体验 → + GT28

路线安全、天气合格，就可以自动起飞吗？

路线、高度、天气窗口和风速预检全部通过，但空域、运营人、起降场、气象放行和任务授权仍缺失；预检结论可引用，自动起飞授权与起飞指令保持阻断。

进入体验 → +
+
+
+

6验证提供方生态：外部核验与可信保证

+
+ GT29

气象服务数据和现场传感器冲突时，AI应该相信谁？

模拟气象服务给出8米/秒，现场传感器给出13米/秒。两个来源都新鲜且相互独立，但数值仍然冲突，因此天气结论保持未知，并请求第三个独立来源。

进入体验 → + GT30

第三个独立气象来源加入后，冲突就自动解决了吗？

第三个独立来源也给出13米/秒，形成二比一；但可信保证策略没有声明多数表决规则，因此系统仍保持未知，不静默删除8米/秒来源，并请求显式气象审定。

进入体验 → + GT31

人工复核解决气象冲突后，天气合格就能自动起飞吗？

人工复核精确绑定GT30冲突响应与虚构上下文证据，保留三份原始响应并将两份13米/秒读数限定为局部测试气流影响；8米/秒天气结论可用，但自动起飞授权与起飞指令继续阻断。

进入体验 → + GT32

五项授权陆续到达后，什么时候才算可起飞？

空域、运营人、起降场、气象放行和任务授权逐项到达，未知项从5降至0；最后两个起飞相关输出转为可用，但公共核心不发布结果、不发送指令，也不执行飞行动作。

进入体验 → +
+
+
+

7动态世界对象：移动对象、轨迹与时间观测

+
+ GT33

三个带时间位置点连起来，就是一条可验证轨迹吗？

用移动对象引用、严格递增的带时区时间戳和三次二维观测建立离散轨迹，确定性计算持续300秒；不插值、不预测、不地图匹配，也不执行现实动作。

进入体验 → + GT34

三个轨迹样本之间，每一段到底移动了多远、多快？

将三次明确观测按相邻顺序绑定为两个分段，分别计算持续120/180秒、距离60/90个文档水平单位和0.5水平单位/秒平均速度；不插值、不推断瞬时速度、不预测未来或执行动作。

进入体验 → + GT35

位置几乎没变就是停留，十分钟没观测就是失联吗？

使用调用方显式声明的5米停留半径、120秒最短时长、300秒最大观测间隔和缺口许可，将三个相邻分段分类为停留候选、已观测移动和观测缺口；不允许缺口标记时返回不可核验，不推断失联、异常或连续运动。

进入体验 → + GT36

两段平均速度变了，就能证明瞬时加速度和连续运动吗？

以相邻分段中点为代表时刻，在调用方声明的300秒最大观测间隔内计算平均速度变化率；输出零加速度、正加速度和缺口驱动的不可核验，不推断瞬时或向量加速度、方向变化、未来位置或现实动作。

进入体验 → + GT37

两段轨迹只差60秒和5米，就能自动认定为同一个对象吗？

比较前一轨迹末样本与后一轨迹首样本，在调用方声明的时间、距离和对象类别策略下输出对象同一性候选、不同对象候选或不可核验；不自动归并身份、不改写subject_ref，也不证明现实身份。

进入体验 → +
复合案例 · 5阶段

巡检无人机短暂失联后被重新编号，如何确认并安全归并身份？

虚构巡检无人机UAV-017进入建筑遮挡区后短暂失联，恢复观测时被系统建立为新的临时主体。资产登记证据与人工复核均支持“同一架无人机”，但GeoTask仍将审定、归并提案、提案审批、变更请求和应用审批拆成五个可审计阶段。

GT38 证据审定GT39 归并提案GT40 提案审批GT41 变更请求GT42 应用审批
+
+
+
+
+ -

从“给模型更多信息”，转向“证明当前任务的信息已经足够”。

GeoTask Core 采用 MIT License。你可以从独立消费者、Python API 或现有公开示例开始，把自己的 GIS、API、Sensor 或 WorldState Provider 接进来。

GitHub RepositoryDeveloper GuideEnglish
-
+
GT01—GT42 继续保留。它们是 GeoTask 从确定性任务协议、Verification 与 World-State Cycle 演化到 Task Context Engine 的公开历史，不再承担定义当前产品定位的职责。
+

Documentation

新主线与历史资产分层，而不是删除历史。

当前 README / Task Context Engine当前 Public RoadmapWarehouse Robot Picking5 分钟中文 Quickstart历史白皮书 v0.1历史 Language Spec v1.0历史 World State v0.1Verification Quality Benchmark v0.2
+ +

从“给模型更多信息”，转向“证明当前任务的信息已经足够”。

GeoTask Core 采用 MIT License。可以从独立消费者、Python API 或公开案例开始接入自己的 GIS、API、Sensor 或 WorldState Provider。

GitHub RepositoryEnglish
+
From 972c1b982a2bbed0e59a8a7448edd1d04e648dd8 Mon Sep 17 00:00:00 2001 From: stpku <83755634+stpku@users.noreply.github.com> Date: Thu, 27 Aug 2026 10:12:56 +0800 Subject: [PATCH 17/17] docs: fix architecture series link --- README.en.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.en.md b/README.en.md index b4b68b5f..804e8466 100644 --- a/README.en.md +++ b/README.en.md @@ -260,7 +260,7 @@ The existing Runtime Interface Profile and Verification Provider Descriptor rema Useful legacy entry points: -- [GeoTask Architecture Series v0.1](docs/articles/architecture-series/README.md) +- [GeoTask Architecture Series v0.1](docs/articles/architecture-series/README.zh-CN.md) - [Documentation index](docs/README.en.md) - [GT01–GT20 Cookbook](docs/cookbook/gt01-gt20.md) - [GT21–GT28 World-State Cycle](docs/cookbook/gt21-gt28.md)