相关 ≠ 适用
同一事实可以与任务主题相关，却不适用于当前对象、空间、时间窗口或运行条件。
Problem
Agent 的上下文问题，不是“装多少”，而是“什么足够”。
长上下文窗口、RAG、数据库和工具可以提供更多信息，但不会自动回答这些信息是否真的适用于当前任务。
有数据 ≠ 分辨率足够
存在地图、气象、库存或传感器值，并不意味着空间、时间、精度和语义粒度足以支持任务。
上下文很多 ≠ 上下文充分
大 payload 仍可能遗漏 critical requirement；大量可选信息也可能只增加 token、网络与认知成本。
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 或 Other Provider 提供候选事实与状态。
GeoTaskTask Context
判断当前任务需要什么，哪些候选相关、适用、分辨率足够，以及上下文是否充分。
DownstreamAgent / Domain System
Agent Harness 运行推理；领域系统继续拥有专业判断、授权、执行与责任边界。
Context Sufficient ≠ Domain Decision ≠ Action Authorization
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[]
↓
Relevance / Applicability / Resolution Adequacy
↓
Sufficiency → Minimum Sufficient TaskContext
↓
Sensor Change → Bounded Temporal Reassessment
关键反例：即使通道实测宽度小于机器人宽度，只要测量本身相关、适用、新鲜且分辨率足够，GeoTask 仍可判断“上下文充分”；但不会判断“机器人可以通行”。
打开完整示例 →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
下一阶段研究 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 为准。
P1 Reference Agent：历史 Product Track 的完整闭环
GT01—GT42证明单项能力；Reference Agent把新证据、World State、Discrepancy、Correction、Impact与Control串成一条可运行、可失败、可重放的设施评估更新链。它继续作为已发布兼容资产保留，但不再定义 GeoTask 的当前产品定位。
GT01—GT42公开参考例
共42个可验证参考例，对应38个场景入口；GT38—GT42作为一个五阶段复合案例，完整展示无人机身份从证据审定到应用审批的治理链。
1空间关系：对象、算子与边界语义
2时空组合：二维、高度与时间
3不确定性与证据：不知道以后怎么办
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复合案例 · 5阶段
三个带时间位置点连起来，就是一条可验证轨迹吗？
用移动对象引用、严格递增的带时区时间戳和三次二维观测建立离散轨迹，确定性计算持续300秒；不插值、不预测、不地图匹配，也不执行现实动作。
进入体验 → GT34三个轨迹样本之间，每一段到底移动了多远、多快？
将三次明确观测按相邻顺序绑定为两个分段，分别计算持续120/180秒、距离60/90个文档水平单位和0.5水平单位/秒平均速度；不插值、不推断瞬时速度、不预测未来或执行动作。
进入体验 → GT35位置几乎没变就是停留，十分钟没观测就是失联吗？
使用调用方显式声明的5米停留半径、120秒最短时长、300秒最大观测间隔和缺口许可，将三个相邻分段分类为停留候选、已观测移动和观测缺口；不允许缺口标记时返回不可核验，不推断失联、异常或连续运动。
进入体验 → GT36两段平均速度变了，就能证明瞬时加速度和连续运动吗？
以相邻分段中点为代表时刻，在调用方声明的300秒最大观测间隔内计算平均速度变化率；输出零加速度、正加速度和缺口驱动的不可核验，不推断瞬时或向量加速度、方向变化、未来位置或现实动作。
进入体验 → GT37两段轨迹只差60秒和5米，就能自动认定为同一个对象吗？
比较前一轨迹末样本与后一轨迹首样本，在调用方声明的时间、距离和对象类别策略下输出对象同一性候选、不同对象候选或不可核验；不自动归并身份、不改写subject_ref，也不证明现实身份。
进入体验 →巡检无人机短暂失联后被重新编号，如何确认并安全归并身份？
虚构巡检无人机UAV-017进入建筑遮挡区后短暂失联，恢复观测时被系统建立为新的临时主体。资产登记证据与人工复核均支持“同一架无人机”，但GeoTask仍将审定、归并提案、提案审批、变更请求和应用审批拆成五个可审计阶段。
GT01—GT42 继续保留。它们是 GeoTask 从确定性任务协议、Verification 与 World-State Cycle 演化到 Task Context Engine 的公开历史，不再承担定义当前产品定位的职责。
从“给模型更多信息”，转向“证明当前任务的信息已经足够”。
GeoTask Core 采用 MIT License。可以从独立消费者、Python API 或公开案例开始接入自己的 GIS、API、Sensor 或 WorldState Provider。