Relevant ≠ Applicable
A fact can match the topic and still be wrong for the current object, place, time window, or operating condition.
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.
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.
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.
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.
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, 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
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 →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
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, WorldState, or other provider.