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.
42public reference examples
38scenario entries
32registered public Artifacts
MITGeoTask Core license
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.
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.
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.
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 →GT37Do 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 →GT32When 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 →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 →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.