RESEARCH | INNOVATE | EDUCATE
A lunar-city simulation
for agent interoperability.
Astrocity studies how independently developed agents and machines discover capabilities, request services, coordinate scarce resources, operate under delegated authority, and leave records another party can inspect.
A rover may need power, a communications link, route information, and permission before it can complete one task. Astrocity provides a shared setting for representing and testing those dependencies across systems that do not share one vendor, runtime, or private database.
World One, Mission Control, and the Agent API are working research prototypes. .
Working prototypeWORLD ONE / SIMULATION OUTPUT
A small, running system
that can be inspected.
World One currently returns scenario activity for three observed agent identifiers. Mission Control exposes the simulation clock, recent actions, signed receipt records (signatures not verified here), target attainment, and replay status. These are engine outputs—not measured results.
Checking the World One engine…
Recent recorded actionsUnavailable
Waiting for engine response
01 · Research premise
The useful test begins
where one system ends.
If every machine is built by one team, speaks one private API, and shares one database, the result says little about interoperability. The stronger test is whether independently developed systems can discover, understand, authorize, coordinate, and verify one another.
The scenario is grounded at the lunar south pole, where sunlight, terrain, resource access, and communications create dependencies between four modeled work districts. The approximate scenario locations and overlays are illustrative. NASA Trek reference imagery is not simulation output, a site assessment, or NASA endorsement.
87.96°S · 2.21°WSouth polar stereographic · ≈ 268 m/px
Drag to pan
Approximate scenario locations · illustrative roles and states
02 · Research questions
Five problems a shared
simulation can make testable.
Astrocity is organized around operational questions rather than a single demonstration: how limited power is allocated; how independently built systems discover and coordinate with one another; what continues during a communications interruption; how faults, logistics, and changing equipment availability are handled; and how actions remain inspectable under human oversight.
Participants would provideAstrocity would provide
Agents, robots, and service implementationsA common scenario and interface surface
Capability and resource descriptionsDiscovery and coordination experiments
Planning and execution strategiesProposed policy and delegated authority
Telemetry and operational claimsAction history, signed receipt records (signatures not verified here), and replay flags
Independent evaluation methodsReproducible traces and integration findings
03 · Proposed interaction model
Authority moves outward.
Evidence returns.
The research model separates Earth-based oversight from local execution. An Earth control plane would register participants, set objectives and operating boundaries, issue permissions, audit results, and revoke authority. A lunar edge plane would observe local conditions, coordinate nearby systems, execute authorized work, and retain evidence through communications gaps.
Before work begins, a machine would receive explicit limits. During an interruption it could continue only within those limits; after reconnection, telemetry and receipts would synchronize. Expiration and fallback behavior are part of the authority model being studied.
Earth control plane
- Registers organizations, agents, and robots
- Issues identity and delegated authority
- Defines objectives and operating boundaries
- Audits outcomes and revokes authority
AuthorityEvidence
Lunar edge plane
- Observes local conditions
- Plans and executes assigned work
- Coordinates nearby machines
- Stores evidence and enters safe mode
04 · Verification
Make every conclusion
traceable to its evidence.
A reviewer should be able to establish what a machine observed, what it proposed, whether it had authority, what command was issued, and what changed afterward—without relying on the operator’s explanation. The research model connects six stages and assigns responsibility for the artifact at each stage.
01Observation
02Intent
03Authorization
04Command
05Execution
06Outcome
Telemetry and observation commitments preserve the decision context.
Policy decisions, Council approvals, and grants establish permission.
Execution receipts, independent observations, recorded state changes, and replay provide evidence of the result.
Current prototype: action history, signed receipt records (signatures not verified here), and an engine-reported replay consistency flag. These records are not independent evidence of physical outcomes. In development: policy decisions, Council approvals, time-bounded grants, and independent evaluation reports.
In developmentStudy decisions that
06 · Council of Agents
Study decisions that
cross system boundaries.
Shared power, contested ground, and life-support dependencies cannot be resolved by the machine that benefits from the decision. The proposed Council model gives safety, habitat, resources, infrastructure, communications, and audit separate mandates and signing identities. A study can then examine approvals, denials, abstentions, conditions, quorum rules, and later review as explicit records.
This is a governance research model, not an operating institution. A proposed signed charter would provide the reference point for later decisions and grants; expiration, revocation, and audit would remain testable properties of the system.
Decision classes
Proposed pilot · In development
07 · First study
Power Under Constraint.
The proposed pilot would evaluate power allocation, task coordination, and authority enforcement during specified communications interruptions. A declared scenario would define units, time, generation and storage limits, essential services, authority boundaries, the fault schedule, and the evaluation method.
Scope and evaluation methods are being drafted. Participation dates, supported interfaces, and terms are not yet confirmed.
A useful result is not a successful animation. It is a reproducible trace showing what each system knew, requested, was allowed to do, and changed.
08 · Participation
Contribute to a defined
interoperability study.
Participation should produce something another team can inspect, reproduce, or extend: an implementation, adapter, scenario, evaluation method, baseline trace, or technical learning resource. Program formats and participation terms are still in development.
Contributors and startups
Propose an implementation, adapter, scenario, or evaluation method for a defined interoperability study.
Universities and robotics teams
Reproduce a baseline, examine multi-agent coordination, or develop technical teaching material.
Space institutions
Contribute an operational problem, scenario constraint, or requirement for collaborative study.
Verification researchers
Define evidence requirements, conformance tests, and independent replay methods.
Sponsors and infrastructure partners
Support a defined research question, reusable capability, or education program.
Research outputs
The output is evidence
other teams can reuse.
A study should produce more than a successful run. Candidate outputs include reusable capability descriptions, discovery adapters, interface findings, authorization and interoperability test cases, reproducible scenarios, baseline traces, and published evaluation reports. Any proposed contribution remains subject to the receiving project’s own review and governance.
01Declared requirement
02Independent implementation
03Shared evaluation
04Published finding
09 · Development scope
Now. Next.
Longer term.
Working research prototype
- World One simulation engine and Agent API
- Mission Control and action history
- Signed receipt records (signatures not verified here) and engine-reported replay status
- Continued scenario development
Reproducible multi-team studies
- Power Under Constraint pilot definition
- Published scenario and adapter contracts
- Multi-team integration experiments
- Documented baselines and evaluation reports
Separate validation stages
- Real edge devices and communications emulation
- Hardware-in-the-loop studies
- Other mission-control scenarios
- Physical claims supported by physical evidence
Prototype resource
Inspect the World One interface.
The current API lets a client read the simulation clock, observe the modeled world, advance work, retrieve receipts, and inspect the scenario score. Availability of these endpoints does not by itself establish interoperability or a completed evaluation.
View Agent API documentationGET /scenario/clock
GET /world/observe?agent_id=:id
POST /scenario/advance
GET /receipts/:entity_id
GET /scenario/scoreContribute to a
defined study.
Astrocity is stellarmind.ai's flagship simulation project.
Email the research team
This opens your email app. This website does not submit or store your details. If it does not open, write to research@stellarminds.ai.