AR-1000 · Architecture Specification · Draft

Airspace Registry Architecture Specification

Object model and resolution architecture for Location Profiles. Companion to the Charter (AR-0001); concrete fields are specified in AR-1004.

Abstract

AR-1000 defines the object model and resolution architecture for machine-readable Location Profiles associated with physical places. It specifies the objects and their relationships, the structure of a Location Profile, and the resolution process by which an application obtains the set of profiles applicable to an operation. This specification does not define regulatory authority, permissions, routing decisions, or application behavior.

1 · Scope

This specification defines:

• the object model for Location Profiles and the objects that produce, contain, and consume them;
• the internal structure of a Location Profile, organized into context classes;
• the resolution process by which an application obtains the set of profiles applicable to a location, time, activity, object, or operating volume;
• the extension mechanism by which the model evolves.

This specification does not define:

• regulatory authority, permissions, or operational approval;
• routing, deconfliction, or any application decision;
• the concrete field set of each context class — that is AR-1004;
• ecosystem governance or commercial arrangements — that is AR-0001.

2 · Problem Statement

Existing spatial systems answer one question: where is a place, and what is its geometry? A growing class of applications — autonomous and semi-autonomous systems that operate in physical space — requires a different answer: given a location and an operation, what published context applies here?

This context is not law, not rules, and not authority. It is the set of preferences and conditions the parties responsible for a place have chosen to publish, expressed so that any application can resolve and evaluate it. No existing system provides a common, machine-readable representation of this context, resolvable by location, time, activity, object, or operating volume. AR-1000 specifies that representation and its resolution.

3 · Core Objects

The architecture is defined in terms of seven objects.

4 · Location Profile

A Location Profile is the central object of the architecture. It is bound to exactly one Location, is published by a Responsible Party, and is composed of an Identity, a set of Context Classes, and an Extension area.

Location Profile
  Identity
    profile id
    location reference
    responsible-party reference
    version
  Spatial Context
    boundaries · volumes
    altitude bands
    indoor references
  Temporal Context
    schedules
    recurring windows
    temporary events
  Operational Context
    activities
    published preferences
    conditions
  Interaction Context
    inquiry endpoints
    notification preferences
    contacts
  Evaluation Context
    provenance
    verification status
    precedence
    confidence
  Extension
    namespaced fields (future schemas)

Identity anchors the profile; the five context classes organize its published context; the Extension area admits new schemas without altering the model. Identity and Extension are structural — they are not context classes. The concrete fields of each class are specified in AR-1004.

5 · Resolution

Resolution is the process of obtaining the Profile Set applicable to an operation. Given a query — a location, and optionally a time, activity, object, or operating volume — the Resolver returns every Location Profile whose scope contains the query.

operation  (location, time, activity, object, volume)
     |
     v
  Resolver
     |
     v
  Profile Set   (0..n applicable Location Profiles)
     |
     v
  Application    evaluates the Profile Set
     |
     v
  decision       determined by the application, not the registry

Resolution is selection, not decision. The Resolver returns what applies; the Application determines what to do. A Profile Set of size zero is a valid result: it states that no published context applies to the operation.

6 · Overlapping Profiles

A single operation frequently resolves to more than one applicable Location Profile. Profiles overlap because context originates independently — from different Responsible Parties, spatial volumes, time windows, or activities — and no coordinating authority merges them.

Operation:  a drone mission over a downtown block

Resolves to:
  municipal profile         (city)
  park profile              (public green space)
  property-owner profile    (a building)
  event profile             (temporary, time-bounded)
  construction profile      (temporary, activity-scoped)
  altitude-band profile     (operating volume)
  AR-installation profile   (interaction-scoped)

  Profile Set = 7 applicable profiles

The Resolver returns all seven. The Application evaluates them against its own operational and business requirements and determines behavior. The registry does not rank, merge, or decide among them. Precedence and confidence are published within each profile’s Evaluation Context as inputs to the application’s evaluation — never as an outcome imposed by the registry.

Profiles and operations are typed — by activity (for example delivery, survey, or filming), by operator class (for example public safety, owner, commercial, or recreational), and by the class of the Responsible Party (for example a municipality, a business, or a property owner). These typings determine which profiles are applicable to an operation and how an application weighs them.

7 · Context Classes

A Location Profile’s fields are grouped into context classes. A context class is a named group of fields that evolves independently of the others. Classes exist so that the schema for one dimension of context can grow without coordinating with, or destabilizing, the rest.

Context classes are the unit of extension. Adding a field to a class is routine (§8). Adding a class is a rare, deliberate act, analogous to introducing a new record type.

8 · Extensibility

The model is designed so that context can grow without architectural change.

new field
   |  added to an existing context class (via AR-1004)
   v
existing profile structure    unchanged
   |
   v
existing resolver             unchanged
   |
   v
existing applications         ignore fields they do not understand

A new field enters an existing context class through AR-1004; the object model, the Resolver, and existing applications are unaffected. Applications process the classes and fields they understand and ignore the rest. A new context class, or a new schema in the Extension area, extends the model the same way — additively, without redefinition.

9 · Ecosystem

This specification is implemented within an ecosystem of four independent functions. They are noted here only insofar as they bound conformance; their governance is defined in AR-0001.

The Registry never determines application behavior; applications never depend on the Registry to decide.

10 · Open Problems

The following problems are unresolved. They are stated here because they define the architecture’s frontier — not because this specification answers them.

These problems are open. This specification does not depend on their resolution to be implemented, but their resolution will shape its evolution.

Document family

AirspaceRegistry.org is a working reference implementation of this specification — a public API, a resolver, and open-standard output.