moira

Frame-Specific Positions Backend Standard

Version: 0.1 Date: 2026-06-14 Status: implemented backend standard for P-GAP-01 REST admission Scope: heliocentric, planetocentric, SSB, and received-light position products

This standard governs the non-geocentric position products that are public in the Python engine, Moira facade, and admitted P-GAP-01 REST routes:

The existing /v1/positions/* REST family is geocentric/topocentric and sky projection oriented. It must not be silently stretched to mean all possible position centers. P-GAP-01 exists because these frame-specific products have different centers, correction semantics, and result vessels.


1. Governing Objects

Frame-specific position transport must preserve four distinct governing objects.

Heliocentric Position

Owned by:

Meaning:

Admitted result fields:

Planetocentric Position

Owned by:

Meaning:

Admitted result fields:

SSB Position

Owned by:

Meaning:

Admitted result fields:

Received-Light Position

Owned by:

Meaning:

Admitted result fields:


2. Body Admission

REST transport must preserve each engine surface’s native body policy.

Heliocentric:

Planetocentric:

SSB:

Received light:

Transport must cap bulk requests. Initial REST admission should allow at most 12 bodies per request, matching the existing server tendency for bounded chart/position products.


3. Time And Reader Policy

All P-GAP-01 requests must use timezone-aware datetimes at the REST boundary.

Transport must report:

The server should use the existing engine reader binding from the application dependency context. It must not create a new global kernel state or mutate kernel paths.


4. Frame And Correction Truth

Every response must state its center and correction semantics.

Heliocentric:

Planetocentric:

SSB:

Received light:

Transport must not describe heliocentric, planetocentric, or SSB products as observed/apparent positions. Transport must not describe received-light output as simply “geometric” because its primary apparent fields come from the ordinary apparent pipeline.


5. Route Admission Boundary

P-GAP-01 admits a bounded synchronous REST family under:

The route family should include:

Each route should accept:

Route names must not imply that these are replacements for:

They are specialized frame products.


6. Non-Goals

P-GAP-01 does not admit:


7. Verification Requirements

Before REST admission, tests must cover:

At least one test should assert that received-light output preserves both apparent and geometric longitudes and the light-travel fields.


8. Admission Decision

P-GAP-01 is admitted through the bounded /v1/positions/frame/* REST family.

Recommended status:

Reason:

The transport implementation is named in docs/architecture/P-GAP-01_FRAME_SPECIFIC_POSITIONS_TRANSPORT_DESIGN.md. It remains a server adapter over existing engine/facade computations.