AR-1000 · Ecosystem Architecture · Draft 3
Airspace Registry Ecosystem Architecture
Companion to the Charter (AR-0001). Field definitions live in the API Specification (AR-1004).
1 · Introduction
Modern software increasingly interacts with the physical world. Drones plan routes over neighborhoods. Augmented-reality applications anchor content to buildings. Robots navigate sidewalks and loading docks. Autonomous vehicles read the environment around them. Each of these systems needs to understand not only where a place is, but how it is preferred to be treated.
Conventional mapping answers the first question and stops there.
A conventional map
“Where is this place?”
A context-aware location
“Given that I’m here, what should I know?”
This architecture exists because software increasingly needs to understand the context of places, not just their coordinates. We call a place described this way a context-aware location: a physical place with an open, machine-readable profile of preferences and conditions that applications can discover and voluntarily consider.
DNS did not become important because of DNS records. It became important because the Internet needed a universal, open way to associate information with names. This architecture plays the same role for the physical world.
This is not a proposal for the future. AirspaceRegistry.org is a working reference implementation today — a live public API, a layered resolver, open standards output (GeoJSON, OGC GeoPose, Open AR Cloud), and global place coverage. The architecture below describes both what runs now and the framework it is designed to grow into.
2 · The Problem
The people responsible for physical places — owners, custodians, operators, communities, and public agencies — have no open, standardized, machine-readable way to express how they would like those places treated by the technologies that now interact with them.
Today that information is either absent, locked inside proprietary systems, or inferred by each application on its own. The result is duplicated effort, inconsistent behavior across applications, and no common surface for a responsible party to publish preferences once and have any system discover them.
Maps describe geometry. Regulations describe law. Neither describes preference and context — the operating layer between “where a place is” and “what the law requires,” where most real-world interaction actually happens.
3 · Purpose
The purpose of this architecture is to define an open, neutral, extensible framework for publishing and discovering context-aware location metadata. It defines what a Location and a Responsible Party are; what a Location Profile contains; how applications discover and evaluate that metadata; and the ecosystem roles that keep the framework neutral while allowing it to be sustained commercially. It deliberately does not define regulatory authority, permissions, or operational approval.
The ecosystem publishes information. Applications decide how to use it.
4 · Core Concepts
4.4 · The Four Context Classes
Every field in a Location Profile belongs to one of four context classes. These are to this architecture what resource-record types are to DNS: a small, fixed, extensible taxonomy that organizes everything without itself churning. AR-1000 defines the four classes; AR-1004 defines the fields within each.
| Spatial | What and where the location isGeometry, 3D volume, altitude bands, stable identifiers. |
| Operational | What is happening at the location, and whenActivities, schedules, recurring windows, temporary conditions. |
| Interaction | How external systems are preferred to engageDrone / AR / robotics / autonomous-system preferences, coordination requirements. |
| Evaluation | How to reconcile and prioritizePrecedence, priority ordering, conflict resolution, provenance, verification. |
The Operational / Interaction distinction is deliberate: Operational describes the state of the place; Interaction describes the rules for outside systems. Adding a new context class is a rare, deliberate act — like introducing a new DNS record type. Adding fields within a class is routine, and happens in AR-1004.
5 · How Applications Use Location Metadata
- Discover — resolve the location(s) relevant to the operation, by identifier, bounding box, or proximity.
- Read context — read the relevant classes: geometry (Spatial), current activity and schedule (Operational), engagement preferences (Interaction).
- Evaluate — where multiple profiles apply, use the Evaluation Context (precedence, priority, provenance) together with the application’s own rules to reconcile them.
- Decide — the application makes its own decision. The registry never returns a verdict, permission, or authorization — only published information.
The registry expresses preference and precedence. It never expresses regulatory permission. Applications remain responsible for compliance with applicable law and with their own authoritative systems.
6 · Architectural Principles
7 · Ecosystem Components
The ecosystem separates four independent functions. Keeping them separate is what makes the registry’s neutrality structural rather than promised.
| Intellectual Property | The underlying architecture, which may be commercially licensed — funding and protecting the framework without controlling its content. |
| Commercial Implementations | Organizations that license the intellectual property to build products, services, registrars, APIs, and platforms. SpatialDNS LLC is one commercial implementation — not the ecosystem itself; others may exist. |
| Public Registry | AirspaceRegistry.org — neutral public infrastructure for publishing and discovering Location Profiles, with a free community registry as the common reference implementation. |
| Applications | Drones, AR, robotics, and mapping systems that independently decide how to interpret and apply published information. |
Because the registry, the commercial implementations, and the intellectual property are distinct functions, no single commercial participant — including SpatialDNS LLC — determines the content of the public registry.
8 · Document Family
| AR-0001 | CharterWhy the registry exists — principles, governance, neutrality. Read → |
| AR-1000 | Ecosystem Architecture — this documentWhat it is and how it works — concepts, context classes, roles. |
| AR-1004 | API SpecificationThe exact parameters — fields within each context class, formats, endpoints. Read → |
Low numbers govern principles and governance; the 1000-series governs technical specification. AR-1000 defines the framework; AR-1004 fills it in.
9 · Long-Term Vision
The Internet connected information. The next generation of technology will increasingly interact with places — physically, spatially, and autonomously. As it does, the people responsible for those places should be able to publish context once, in the open, and have any system discover it.
This architecture is the framework for that layer: open, neutral, extensible, and already running. Its ambition is not to control how software interacts with the physical world, but to give the physical world a common, machine-readable way to be understood.
Maps tell us where places are. Location Profiles help technology understand how to interact with them.
AR-1000 · Ecosystem Architecture