REST_API_REFERENCE

Moira REST API Reference

Source of truth: moira_server.app.create_app() route registry

This document describes the HTTP transport surface currently registered by moira_server. It is separate from wiki/02_standards/API_REFERENCE.md, which documents the Python engine/import surface.

The REST layer is an access surface over the engine. It must preserve engine truth, explicit computation policy, and request-flow read-only behavior. Route presence here means the endpoint is registered by the live FastAPI application; it does not imply that the corresponding engine family is complete beyond the transport contract documented for that family.

The exact Hellenistic and supporting route/schema subset is regenerated in the Hellenistic API inventory. It also asserts that Hermetic geometry, Triacontaeteris, and Decennial L3/L4 have no registered route.

Current Surface Summary

• Application: Moira Server 0.1.0
• Registered OpenAPI paths: 473
• Registered OpenAPI operations: 473 (GET 36, POST 437)
• Operational/meta paths: 4
• Versioned /v1 paths: 469
• OpenAPI path, when enabled by server configuration: /openapi.json
• Interactive docs, when enabled by server configuration: /docs and /redoc
• Generation source: moira_server.app.create_app().openapi() via scripts/sync_rest_api_reference.py

Present Expansion State

The REST implementation is past bootstrap.

Implemented:

• phases 1-5: operational, chart, positions, transits, returns, batch, and visibility
• phase 6: stations, void-of-course, rise/set, eclipses, occultations, heliacal events, and parans
• phase 7: synastry, composite, Davison, chart shape, patterns, and midpoints
• phase 8: progressions, profections, timelords, Vimshottari dasha, Varshaphal, and primary directions
• phase 9 opened with Panchanga direct and chart-backed instant/profile routes, followed by chart-backed Shadbala result/profile/network/condition routes direct/chart-backed Jaimini karaka/profile/condition/pair routes, and chart-backed Classical Dignities result/reception/condition/profile/network routes, Church of Light natal Astrodynes doctrine/geometry/chart routes, followed by Classical Lots catalogue and chart-backed result/dependency/condition/profile/network routes, and Triplicity table/assignment/score routes, followed by Egyptian Bounds table, bound, classification, relation, condition, aggregate, and network routes, followed by Vedic Dignities direct and chart-backed dignity/relationship/profile routes, Ashtakavarga direct and chart-backed result/profile/sign-profile/ transit-strength routes, and alternate dasha direct and chart-backed Ashtottari/Yogini sequence/profile plus period-profile routes, Varga direct and chart-backed generic/named/Shodashvarga/batch routes, and Decanates direct and chart-backed decanate-placement routes. The source-reconstructed Hermetic name-and-face catalog and its research-only longitude/rising projections are absent from the application registry. The unsupported Hermetic night-hour implementation and transport scaffolding have been removed rather than retained behind an unregistered router
• source-scoped Pancha Pakshi admission adds explicit-profile discovery, governance-only Uromarisi constitutional status, aksara and natal identity, a pure nakshatra-to-bird source-table lookup, exact nominal schedule, directed relationship, pure Padu and first-samam EAT-seed lookups, and bounded astronomical-paksha inference, local-solar context, fixed-clock materialization, and fixed-clock current-cell routes, plus separate solar-proportional materialization and current-cell routes; it selects no default, the inference route accepts neither location nor paksha, and all five schedule-related astronomical routes continue to require caller-supplied paksha
• Phase 11 admitted surfaces: fixed stars, variable stars, multiple stars, asteroids, comets, asteroid subsets/families, Manazil, and planetary/ small-body nodes
• phase 10 opened with bounded Astrocartography line and subplanetary point routes, followed by bounded Local Space direct and chart-backed horizon position routes, and bounded Geodetic direct/chart-backed location-chart and equivalent-longitude routes, followed by bounded Galactic coordinate-frame transform, reference-point, and chart-position routes, followed by bounded Galactic Houses cusp, direct-placement, and chart-backed placement routes, and canonical Gauquelin direct/chart-backed sector routes; dense maps, tiles, contours, grids, projection products, geographic search, relocation synthesis, rendered galactic house charts, rendered Gauquelin wheels, statistical workflows, and catalog sweeps remain deferred
• Track A adds exact composite/Davison transit-target searches, source-resolved fixed-star Astrocartography, explicit-epoch transiting Astrocartography displacement receipts, and relocated solar/lunar/planetary return composition. These are geometry and chronology contracts only; they add no ranking, recommendation, travel-advice, or interpretation surface
• Track B adds one bounded Lilly 1647 Horary evidence route and one neutral Mundane event-chart route. Both preserve typed engine receipts and explicit missing-dependency states. Neither route infers a question topic or capital, emits a judgement, prediction, score, outcome, or advice, or creates a shared Horary/Mundane interpretation layer
• website support: locations, chart-wheel packets, and reduction-pipeline inspection aliases
• phase 12 opened with bounded Uranian/Hamburg School hypothetical-body catalog, single-position, and bulk-position routes, followed by bounded Harmonics preset, direct chart, age-harmonic chart, conjunction, pattern-score, aspect, sweep, fingerprint, composite, and sampled mixed-origin transit-forecast routes over caller-supplied longitudes, followed by bounded Phase/Photometry illuminated fraction, synodic, elongation, phase-angle, angular-diameter, and apparent-magnitude routes, followed by bounded ordinary Antiscia direct reflection, pair contact, and fixed-point contact routes, followed by a bounded Abu Ma'shar Nine Parts aggregate route, followed by bounded sunrise-based Planetary Hours schedule and hour-at routes, followed by direct-cusp Huber dynamic intensity, house-zone, Age Point, intensity-at-longitude, chart intensity profile, and bounded Age Point contact routes, followed by caller-seeded Lord of the Orb sequence and current-period routes, and a caller-supplied Solar Return Lord of the Turn profile route
• phase 13 opened with a bounded electional predicate-profile catalogue and electional window, raw moment, scorer-profile catalogue, and bounded scored window routes over server-defined predicate and numeric scorer profiles
• post-phase gap closure P-GAP-01 admits frame-specific position products: heliocentric, planetocentric, Solar System Barycenter, and received-light position routes under /v1/positions/frame/*
• post-phase gap closure P-GAP-02 admits bounded Vedic Muhurta moment classification and raw-score routes over direct and chart-backed Panchanga truth under /v1/muhurta/*
• post-phase gap closure P-GAP-03 admits heliocentric J2000 osculating orbital elements and heliocentric distance-extrema routes under /v1/orbits/*
• post-phase gap closure P-GAP-04 admits bounded generic phenomena and solar-condition routes under /v1/phenomena/* and /v1/solar-condition/*
• post-phase gap closure P-GAP-05 admits mechanical sidereal and Nakshatra utility routes under /v1/sidereal/* and /v1/nakshatra/*
• post-phase gap closure P-GAP-06 admits bounded harmogram vector, Zero-Aries vector, intensity-spectrum, projection, and explicit-sample trace routes under /v1/harmograms/*
• later Vedic transport admissions add Kakshya transit and Shodhya Pinda, extended Jaimini Argala/Arudha/Chara Dasha/Karakamsa, Avastha and Yoga evaluation, Upagraha Kala Velas and Sun-based points, Sade Sati status and windows, personal Muhurta scoring, Vimshopaka Varga strength, and chart-backed full Shadbala/Bhava Bala products
• later Parans admissions add the named star canon, natal angular contacts, and a website packet that composes those registered engine products
• bounded Western electional admissions add single-moment judgement, judgement-window scanning, and ranking under named non-advice policies
• profile-bundle admission admits composition-only Western and Vedic convenience endpoints under /v1/western/chart-profile and /v1/vedic/chart-profile; these bundle existing route-equivalent strata for frontend/workspace callers without adding interpretive synthesis

Not yet broadly exposed as REST families:

• broad phase 9 umbrella aggregation modules: wider /v1/vedic/* and /v1/classical/* families remain deferred beyond admitted /v1/vedic/chart-profile
• expanded phase 10 spatial and Earth-facing products beyond the admitted selected-subject and Track A contracts: dense Astrocartography, Local Space, Geodetic, Galactic, Galactic Houses, and Gauquelin map/rendering/projection/ statistical products remain deferred; progressed/directed cyclocartography and chart-backed comet MC/IC/ASC/DSC lines are also absent
• remaining phase 12 specialist analytical families: /v1/sothic/* now has three bounded direct routes, while epoch-search, drift, condition, and network routes remain deferred; /v1/longevity/* is deliberately deferred for doctrine, validation, and public-language safeguards; /v1/special/* also remains unexposed
• remaining phase 13 electional/search workflow surfaces: arbitrary predicate routes, arbitrary scorer routes, generic Western profile search/scoring, additional lineage profiles, and advice/recommendation language. The bounded Ramesey v1 single-moment evaluation is admitted separately.
• generic Phase 11 catalog umbrella routes: /v1/catalogs/* remain intentionally absent; P11-U1 permits only a future discovery-only registry design, not cross-family search, member lookup, computation, or catalog sweeps

Track A transport models

Route	Request model	Response model	Tags
POST /v1/composite/transits	CompositeTransitRequest	RelationshipTransitSearchResponse	relationship
POST /v1/davison/transits	DavisonTransitRequest	RelationshipTransitSearchResponse	relationship
POST /v1/astrocartography/fixed-stars	FixedStarAstrocartographyRequest	FixedStarAstrocartographyResponse	astrocartography
POST /v1/astrocartography/dynamic/transits	DynamicAstrocartographyRequest	DynamicAstrocartographyResponse	astrocartography
POST /v1/returns/relocated	RelocatedReturnRequest	RelocatedReturnResponse	predictive, astrocartography

Track B transport models

Route	Request model	Response model	Tags	Discovery family
POST /v1/horary/evidence-profile	HoraryEvidenceProfileRequest	HoraryEvidenceProfileResponse	horary	classical-vedic
POST /v1/mundane/event-chart-profile	MundaneEventChartProfileRequest	MundaneEventChartProfileResponse	mundane	predictive

Route Families

Family	Routes
meta	5
ashtakavarga	8
alternate-dashas	9
antiscia	3
astrocartography	8
astrodynes	15
asteroids	9
batch	7
chart	2
chart-shape	1
comets	3
aspects	2
composite	2
dasha	5
davison	2
decanates	6
dignities	6
draconic	3
egyptian-bounds	7
electional	12
eclipses	7
galactic	6
galactic-houses	3
gauquelin	3
geodetic	4
heliacal	2
hellenistic-aspects	2
horary	1
harmograms	5
harmonics	10
houses	2
huber	6
jaimini	8
locations	2
local-space	2
lord-of-the-orb	2
lord-of-the-turn	1
lots	7
lunar-phases	1
manazil	4
midpoints	5
muhurta	4
mundane	1
nakshatra	2
nodes	4
nine-parts	1
occultations	12
orbits	4
pancha-pakshi	19
panchanga	4
parans	8
patterns	3
phase	6
phenomena	3
planetary-hours	2
pipeline	3
positions	4
positions-frame	4
primary-directions	8
profections	3
progressions	17
returns	4
shadbala	4
rise-set	3
sidereal	3
solar-condition	2
stars	12
stations	4
synastry	9
timelords	16
transits	3
triplicity	3
uranian	3
varshaphal	9
varga	8
vedic-dignities	7
vedic-profile	1
visibility	2
void-of-course	4
website	3
western-profile	1

Operational Routes

Method	Path	Handler
GET	/health	health
GET	/ready	ready
GET	/meta/version	version
GET	/meta/kernel	kernel_meta
GET	/v1/meta/routes	route_catalog

Chart And Position Routes

Method	Path	Handler
POST	/v1/chart	chart_route
POST	/v1/chart/reduction	chart_reduction_route
POST	/v1/houses	houses_route
POST	/v1/houses/reduction	houses_reduction_route
POST	/v1/houses/dynamics	house_dynamics_route
POST	/v1/houses/dynamics/armc	house_dynamics_from_armc_route
POST	/v1/houses/dynamics/analytical	analytical_house_dynamics_route
POST	/v1/houses/polar-admissibility	houses_polar_admissibility_route
POST	/v1/positions/planet	planet_position_route
POST	/v1/positions/planet/reduction	planet_position_reduction_route
POST	/v1/positions/sky	sky_position_route
POST	/v1/positions/sky/reduction	sky_position_reduction_route
POST	/v1/positions/frame/heliocentric	frame_heliocentric_route
POST	/v1/positions/frame/planetocentric	frame_planetocentric_route
POST	/v1/positions/frame/ssb	frame_ssb_route
POST	/v1/positions/frame/received-light	frame_received_light_route
POST	/v1/pipeline/chart	pipeline_chart_route
POST	/v1/pipeline/positions/planet	pipeline_planet_position_route
POST	/v1/pipeline/positions/sky	pipeline_sky_position_route

House Dynamics And Polar Admissibility Contracts

The house-dynamics family exposes the existing public engine primitives without changing their mathematical doctrine:

• POST /v1/houses/dynamics computes the epoch-complete centered time difference through Moira.house_dynamics. dt_minutes defaults to 1.0 and is restricted to 0.00144 <= dt_minutes <= 1.0: the lower bound is the engine's documented numerical-noise floor, while the upper bound preserves its canonical one-minute half-step for an instantaneous transport product.
• POST /v1/houses/dynamics/armc computes moira.houses.house_dynamics_from_armc with obliquity held fixed. It accepts ARMC in [0, 360), true obliquity in (0, 90), latitude in (-90, 90), optional house policy and solar longitude, and a validated ARMC half-step in [0.001, 1.0] degrees.
• POST /v1/houses/dynamics/analytical exposes the exact public MC, Ascendant, and Vertex derivative functions. Singular Ascendant or Vertex results are represented by null plus an availability flag and reason; non-finite JSON numbers are never emitted.

Finite-difference responses include a computation receipt naming the engine surface, method, independent variable, half-step and unit, speed unit, and whether obliquity was held fixed. The analytical response carries the same receipt with no finite-difference step. Whole Sign cusps are piecewise constant with discontinuous sign-boundary jumps, so both finite-difference routes reject them instead of publishing step-dependent finite spikes. The time-based route likewise rejects Solar Sign cusp dynamics because solar-sign ingress is discontinuous; the analytical endpoint remains available for continuous angle velocities.

POST /v1/houses/polar-admissibility accepts the six experimental scanner systems (Placidus, Campanus, Regiomontanus, Topocentric, Koch, and Alcabitius) by canonical code or case-insensitive name. Obliquity must be in (0, 90); rho_max, when supplied, must be at least 1; and any supplied datetime must be timezone-aware. ARMC bounds stay within [0, 360], and the range is sampled on a grid containing no more than 3,601 points. stability_radius must fit inside that grid. The requested end is an inclusive upper bound rather than a required sample; last_sampled_armc reports the final grid point when the span is not exactly divisible by the step. Because each Placidus outer sample owns four fixed 12,001-point root scans, its system-specific ceiling is 73 samples, which still admits the default five-degree full-circle grid. The other five scanners retain the 3,601-sample ceiling. These checks run before scanner dispatch, preventing non-advancing loops and bounding system-specific work. The response echoes the resolved system and complete scan policy alongside the windows.

Profile Bundle Routes

These routes are convenience composition surfaces. They preserve the underlying route-equivalent sections as named response fields instead of returning a single interpretive synthesis.

Method	Path	Handler
POST	/v1/western/chart-profile	western_chart_profile_route
POST	/v1/vedic/chart-profile	vedic_chart_profile_route

Website Planet Pipeline Reduction Contract

POST /v1/pipeline/positions/planet is an alias over the planetary reduction surface with an added physical reduction breakdown for website inspection. The request is the ordinary PlanetPositionRequest: dt, body, optional observer_lat, observer_lon, observer_elev_m, and the correction flags apparent, aberration, grav_deflection, and nutation.

Generic position, chart, progression-backed, and chart-backed Astrocartography body fields share one small-body identity rule. Globally unique names and canonical comet designations resolve directly. A cross-family collision must use a qualifier such as "asteroid:Halley" or "comet:Halley"; an unqualified collision returns the standard HTTP 422 validation envelope with both catalog candidates. Structured Astrocartography subjects may instead declare kind: "asteroid" or kind: "comet". Dedicated /v1/asteroids/* and /v1/comets/* routes remain family-scoped and retain their existing name/alias contracts.

The response preserves result and the existing reduction.stage_sequence. For ordinary planets and admitted asteroids, reduction also includes:

• stages: ordered stage records {num, name, note, delta, enabled, ref_pos?}
• total_delta_arcsec: enabled stage deltas summed in arcseconds
• stage_longitudes: compatibility map for HTTP clients that compute deltas from intermediate longitudes
• geocentric_longitude: pre-topocentric ecliptic longitude

The canonical physical stage order is:

• 0 Geometric geocentric
• 1 Light-time iteration
• 2 Gravitational deflection
• 3 Annual aberration
• 4 IAU 2006 frame bias
• 5 IAU 2006 precession
• 6 IAU 2000A nutation
• 7 Topocentric parallax

Stages 0-4 are projected in the fixed J2000 ecliptic. Stage 5 is projected in the mean equator/ecliptic of date. Stages 6-7 are projected in the true equator/ecliptic of date, and the nutation stage reports delta as nutation in longitude (dpsi) rather than as a re-projected longitude residual.

Comets remain outside this planetary breakdown contract because their admitted small-body path is heliocentric-kernel routed and needs a separate reduction contract before Moira can expose comparable stage truth.

Frame-Specific Positions REST Admission Boundary

The admitted P-GAP-01 frame-specific position surface is the bounded /v1/positions/frame/* route family. It exposes heliocentric, planetocentric, Solar System Barycenter, and received-light products that were already public through the Python Moira facade.

These routes are transport adapters over existing engine computations. They do not build charts, mutate kernel paths, perform searches, generate dense ephemeris tables, or reinterpret the ordinary geocentric/topocentric /v1/positions/* routes.

All four responses preserve request echo, time reduction, center/frame truth, body bounds, validation truth, and provenance. Received-light responses also preserve the apparent position, same-time geometric comparison, emission Julian day, and one-way light-travel duration.

Admitted products:

• /v1/positions/frame/heliocentric: Sun-centered true-of-date ecliptic positions for admitted planets except Sun and Moon
• /v1/positions/frame/planetocentric: true-of-date ecliptic positions from a named observer body center, with observer-target identity rejected
• /v1/positions/frame/ssb: geometric Solar System Barycenter positions, including the Sun where requested
• /v1/positions/frame/received-light: Earth received-light positions for admitted physical planets, with nonphysical points rejected

Transits, Returns, Batch, And Visibility

Method	Path	Handler
POST	/v1/transits/search	transit_search_route
POST	/v1/transits/natal-aspects	natal_aspect_search_route
POST	/v1/transits/ingresses	ingress_search_route
POST	/v1/transits/next-ingress	next_ingress_route
POST	/v1/returns/solar	solar_return_route
POST	/v1/returns/lunar	lunar_return_route
POST	/v1/returns/planet	planet_return_route
POST	/v1/returns/relocated	relocated_return_route
POST	/v1/lunar-phases	lunar_phase_route
POST	/v1/batch/charts	batch_charts_route
POST	/v1/batch/charts/reduction	batch_charts_reduction_route
POST	/v1/batch/transits	batch_transits_route
POST	/v1/batch/returns	batch_returns_route
POST	/v1/batch/events	batch_events_route
POST	/v1/batch/progressions	batch_progressions_route
POST	/v1/batch/progressions/reduction	batch_progressions_reduction_route
POST	/v1/visibility/atmospheric-extinction	atmospheric_extinction_route
POST	/v1/visibility/assessment	visibility_assessment_route
POST	/v1/visibility/physical-assessment	physical_visibility_assessment_route
POST	/v1/visibility/physical-event	physical_visibility_event_route
POST	/v1/visibility/point-source-threshold	point_source_visibility_threshold_route
POST	/v1/visibility/tonight	visibility_tonight_route
POST	/v1/visibility/twilight-sky-brightness	twilight_sky_brightness_route

All seven /v1/batch/* request bodies are schema-bounded to 128 submitted items. The Varga named/Shodashvarga batches and orbit-class batch use the same ceiling. Oversized inputs fail request validation with HTTP 422; the server does not partially execute or silently truncate them. Domain-specific bulk routes may publish smaller limits.

The three standalone physical-model routes are engine-owned computation surfaces transported without hidden defaults. Their responses retain the declared model, intermediate quantities, units, and validity/reason fields. The assessment and tonight routes accept the same nested visibility policy as the Python surface; the legacy criterion remains their default.

The two additive physical visibility routes transport the complete typed physical policy and receipt graph. They do not accept a client filesystem path. The server operator must configure the external pack with MOIRA_SERVER_PHYSICAL_VISIBILITY_DATA_PACK_DIRECTORY; an optional immutable manifest pin is read from MOIRA_SERVER_PHYSICAL_VISIBILITY_DATA_PACK_MANIFEST_SHA256. If the directory is not configured, only the physical routes return the standard HTTP 503 server_not_configured envelope. The legacy assessment, tonight, and /v1/heliacal/visibility-event contracts are unchanged.

POST /v1/returns/relocated selects a solar, lunar, or admitted planetary return kind, delegates to the canonical return solver, and casts the same exact return sky into caller-supplied source and relocated house frames. The response preserves search-policy truth, return-moment truth, both chart contexts, and a relocation receipt proving that the epoch and celestial positions did not change. It adds no second return solver, place ranking, or interpretation.

POST /v1/transits/natal-aspects searches one mover (body: any planet, True Node, Mean Node, Lilith, True Lilith, or a named asteroid) against a grid of frozen ecliptic longitudes (natal_longitudes, degrees) for every aspect_angles entry, with an optional parallel aspect_orbs list (empty means exact hits). It transports Moira.natal_aspect_transits(): one native longitude series of the mover is scanned over the window and each (longitude, angle) pair is refined from it, so a full natal grid costs one scan rather than one search per pair. Every mover is scanned as one longitude series per window: native evaluators for planets and asteroids, resolver sampling for the lunar points. The response is events, ordered by jd_exact, in the same aspect_transit event shape as /v1/batch/events. The batch route accepts the same search as kind: "natal_aspect_transits" with natal_longitudes, aspect_angles, and aspect_orbs on the item; when aspect_orbs is omitted there, the item's orb applies to every angle. Neither surface adds an interpretation layer or a second solver.

Phenomena Routes

Method	Path	Handler
POST	/v1/stations/search	station_search_route
POST	/v1/stations/next	next_station_route
POST	/v1/stations/is-retrograde	station_state_route
POST	/v1/stations/retrograde-periods	retrograde_periods_route
POST	/v1/void-of-course/window	void_of_course_window_route
POST	/v1/void-of-course/next	next_void_of_course_route
POST	/v1/void-of-course/is-active	void_of_course_state_route
POST	/v1/void-of-course/range	void_of_course_range_route
POST	/v1/rise-set/phenomena	rise_set_phenomena_route
POST	/v1/rise-set/transit	rise_set_transit_route
POST	/v1/rise-set/twilight	twilight_times_route
POST	/v1/eclipses/solar/next	next_solar_eclipse_route
POST	/v1/eclipses/lunar/next	next_lunar_eclipse_route
POST	/v1/eclipses/solar/local-visible	next_visible_solar_eclipse_route
POST	/v1/eclipses/lunar/local	lunar_eclipse_local_route
POST	/v1/eclipses/lunar/visibility	lunar_eclipse_visibility_route
POST	/v1/eclipses/lunar/global-circumstances	lunar_eclipse_global_circumstances_route
POST	/v1/eclipses/solar/path	solar_eclipse_path_route
POST	/v1/eclipses/solar/footprint	solar_eclipse_footprint_route
POST	/v1/eclipses/solar/global-circumstances	solar_eclipse_global_circumstances_route
POST	/v1/eclipses/solar/cartography	solar_eclipse_cartography_route
POST	/v1/occultations/close-approaches	close_approaches_route
POST	/v1/occultations/lunar	lunar_occultations_route
POST	/v1/occultations/lunar-star	lunar_star_occultations_route
POST	/v1/occultations/all-lunar	all_lunar_occultations_route
POST	/v1/occultations/lunar-path	lunar_occultation_path_route
POST	/v1/occultations/lunar-path-at	lunar_occultation_path_at_route
POST	/v1/occultations/lunar-star-path	lunar_star_occultation_path_route
POST	/v1/occultations/lunar-star-path-at	lunar_star_occultation_path_at_route
POST	/v1/occultations/lunar-path-topology	lunar_occultation_path_topology_route
POST	/v1/occultations/lunar-path-topology-at	lunar_occultation_path_topology_at_route
POST	/v1/occultations/lunar-star-path-topology	lunar_star_occultation_path_topology_route
POST	/v1/occultations/lunar-star-path-topology-at	lunar_star_occultation_path_topology_at_route
POST	/v1/heliacal/planet	planet_heliacal_event_route
POST	/v1/heliacal/visibility-event	general_visibility_event_route
POST	/v1/parans/search	paran_search_route
POST	/v1/parans/natal	natal_paran_search_route
POST	/v1/parans/site	paran_site_route
POST	/v1/parans/field/samples	paran_field_samples_route
POST	/v1/parans/field/analysis	paran_field_analysis_route
POST	/v1/parans/field/contours	paran_field_contours_route
POST	/v1/parans/field/paths	paran_field_paths_route
POST	/v1/parans/field/structure	paran_field_structure_route

Solar-eclipse footprint/cartography, every occultation route, and Sade Sati window searches use a process-local 64-entry response LRU. A key includes the route, canonical validated request, engine version, and path-free active kernel identity. Equivalent aware datetimes are normalized to UTC, concurrent identical misses share one calculation, and only successful typed responses are retained. This accelerates repeated identical work; it does not reduce the first computation's runtime or alter the engine calculation.

Polar-Safe Occultation Path Topology Contract

The four *-path-topology routes are additive detailed surfaces. The existing lunar-path, lunar-path-at, lunar-star-path, and lunar-star-path-at request and response schemas remain unchanged.

Detailed topology requests default to sample_count=65 and admit integer counts from 9 through 721. Their response preserves the legacy OccultationPathGeometry shape under summary, then exposes one shared UT1 epoch lattice through centers and the ordered left and right boundary tracks. Left and right are intrinsic sides relative to increasing UT1 along the center track; they are not aliases for geographic north and south. The two greatest cross-track distances sum to summary.path_width_km. summary.duration_at_greatest_s is the fixed-observer occultation duration at the reported greatest latitude and longitude; it is not the longer lifetime of the moving global footprint. All UT-labeled Julian-day fields remain UT1; companion UTC datetime strings are produced by the explicit UT1-to-UTC result conversion.

Range requests treat step_days as a maximum coarse-cell width and admit 0 < step_days <= 0.25, a span no greater than 400 days, and at most 4096 coarse cells. These are explicit bounded search-policy limits. The engine constructs exact start/end cells before evaluating the parallax-aware candidate envelope, refines the first and last cells as well as interior maxima, and solves pole contacts on a fixed internal lattice independent of the requested presentation sample_count. Returned events have an unconstrained greatest instant inside (jd_start, jd_end) by more than the solver time tolerance max(4e-8 d, 8 binary64 ULP); at modern Julian Days its minimum term is about 3.456 ms. An optimum at, or numerically indistinguishable from, either global request boundary is only a constrained range result and is not emitted as a solved event greatest. Multiple optimizer witnesses are one event only when their open exact-positive temporal supports overlap beyond solver uncertainty; a zero-clearance touch alone does not join them. A connected component need not be unimodal: its greatest is selected from a private at-most-30-minute support lattice, independently refined lattice-local maxima, edge cells, and original candidate witnesses under a 128-cell fail-closed budget. The final greatest must satisfy that same solver-time boundary rule.

Exact geographic-pole contacts are reported separately in pole_crossings as north or south and ingress or egress. Exact poles use canonical longitude zero; ordinary track points retain their spherical longitude across polar passage. A crossing's boundary_side may be null when no single left/right branch can be assigned honestly.

The detailed product declares observer_geometry="WGS84_GEODETIC", width_metric="SPHERICAL_GREAT_CIRCLE_R6378_137_KM", time_scale="UT1", atmospheric_refraction=false, and saturn_rings_included=false. Lunar-limb and target-radius doctrine remain visible through lunar_limb_model and target_model. observer_elevation_m records the exact requested observer_elev_m used to solve the boundary, so a nonzero-elevation width is not mislabeled as sea-level geometry. Requests require observer_elev_m >= -6378.137 * (1 - 1/298.257223563) * 1000, approximately -6356752.314 m. This negative WGS 84 semi-minor-axis floor is a computational condition for the parallax envelope, not an endorsement of such a location as an observational site. Positive heights have no arbitrary cap; once the observer radius reaches a body's geocentric distance, candidate admission uses a conservative 180 degree parallax bound rather than the exterior-observer asin(R/d) formula. lunar_limb_model is fixed to "SPHERICAL_MEAN_LIMB": arbitrary limb-profile providers can create multi-contact or disconnected micro-topology and are not admitted into this two-sided nominal band. Existing profile-conditioned graze APIs are separate and unchanged.

Planetary topology targets exclude the Sun. Solar occultation geometry belongs to the first-class /v1/eclipses/* surfaces, and admitting it here would also mislabel Moira's separately sourced solar radius as a JPL planetary solid-body-radius product. The existing legacy occultation routes retain their prior target contract. Fixed-star topology labels must be nonblank, have no surrounding whitespace, and must not use a canonical Solar System body identity.

Topographic Lunar-Contact Engine Boundary

Topography-conditioned lunar contact chronology is intentionally an engine-only, direct-import product. Its immutable vessels and solver are available from moira.lunar_occultation_contacts, while event-specific lunar limb profiles are prepared through moira.lunar_limb. There is no Moira facade method, FastAPI route, OpenAPI operation, or request/response schema for this product.

The three related products retain separate meanings:

• the existing occultation topology routes return nominal spherical mean-limb path and limit geometry;
• the engine-only contact solver returns a predicted disappearance, reappearance, or tangency chronology conditioned on a prepared lunar topography profile; and
• frozen IOTA event reductions preserve observed contact timings as authority evidence rather than relabeling them as model output.

The Moira-derived LOLA RDR profile path uses a content-identified DE441/LE441 physical Moon-to-observer light cone, the NAIF DE440_ME421 lunar orientation resources, and official USGS LOLA topography. Its finite-distance tangent circle and perspective-equivalent radii avoid an orthographic surface approximation. The direct-only profile is a declared half-open-bin-maximum, centre-sample linear reconstruction and makes no exact sub-bin topography claim. Physical contact admission is airless and excludes observer-motion aberration and atmospheric refraction; its stellar ray uses the contact-private Klioner-equation deflection policy recorded in engine provenance. No topographic-contact comparison tolerance or numerical validation result is part of the REST contract. The separately admitted two-site IOTA/LOLA engine validation does not create a facade method, route, schema, or transport-level accuracy promise.

Lunar Eclipse Compatibility REST Contract

POST /v1/eclipses/lunar/local retains its existing request and response schemas. Its request accepts mode="native" or mode="nasa_compat"; native remains the default. In NASA-compatible mode, the response now reports canon_method="nasa_shadow_axis_apparent_sun_moon", and source_model describes the same repaired reduction.

That compatibility method obtains one reception-epoch Earth state, applies reception light-time and then annual aberration to both the Sun and Moon, and does not apply gravitational deflection, topocentric parallax, or atmospheric refraction to the canon contact geometry. The older geometric and retarded canon policies remain explicit engine method identifiers; the REST request does not silently select them.

This is an intentional numerical and provenance-label change within the existing contract. No route was added or renamed, and no request or response field changed. POST /v1/eclipses/lunar/next remains the existing native search surface.

Global Lunar-Eclipse Visibility REST Contract

POST /v1/eclipses/lunar/visibility exposes Moira.lunar_eclipse_visibility_map(...) for global map rendering. The request accepts jd_start, kind (any, total, partial, or penumbral), backward, mode (native or nasa_compat), and sample_count. The density defaults to 181 and is constrained to the inclusive range 9..721.

The response contains the searched lunar eclipse and one closed geographic horizon ring for every phase contact that actually occurs: P1, optional U1, optional U2, greatest eclipse, optional U3, optional U4, and P4. Each limit also carries the sublunar point. The visible side of a ring is explicitly the side containing that point, allowing a map client to draw or shade the contact-specific visibility hemisphere without recomputing astronomy.

This is not a solar-style shadow path. Each ring is the exact tangent intersection between the retarded geocentric Moon-center line of sight and the zero-elevation WGS-84 ellipsoid at the named UT1 contact. The product is admitted only with a content-identified DE441/LE441 reader. Metadata declares RETARDED_GEOMETRIC_MOON_CENTER, no atmospheric refraction, and the exclusion of observer elevation, terrain, and lunar-limb relief. sample_count changes only the emitted closed-ring density; contact solving and geometry are unchanged.

Solar Partial-Visibility Footprint REST Contract

POST /v1/eclipses/solar/footprint is the additive transport surface for Moira.solar_eclipse_footprint(...). Its request accepts jd_start, optional kind and backward search policy, and sample_count, which defaults to 181 and is constrained to the inclusive range 9..721. kind is a closed enum: any, total, annular, partial, central, or hybrid.

The response preserves the searched event, greatest-footprint point, P1/P4 and optional P2/P3 contacts, topology, and named boundary-track components. Track kinds distinguish north/south penumbral envelopes from geometric sunrise and sunset boundaries. Component identifiers are local to each kind; segment identifiers are local to each connected component and identify its strictly time-ordered branches across any shared temporal fold. Each penumbral kind admitted by the topology has exactly one connected component and therefore uses component_id=0. Its segment identifiers are contiguous 0..n-1; two segments meeting at a temporal fold share the refined endpoint. Boundary kind, contact kind (p1 through p4), and topology (one_limit_connected or two_limit_two_loop) are closed response enums. The two-limit topology also requires disjoint north/south horizon-incidence sets rather than two labels on one degenerate boundary. It is valid only for a central global eclipse, and each sunrise/sunset track remains wholly within P1-P2 or P3-P4 rather than crossing the internal P2-P3 interval. Provenance fields declare content-identified DE441/LE441, zero-elevation WGS 84, the spherical physical mean-limb convention, UT1 point epochs, and the absence of atmospheric refraction.

sample_count changes interior point density only. It does not change the returned (kind, component_id, segment_id) graph or its refined contacts, horizon incidences, and fold endpoints. The DE441 fold-regression slice checks this contract at 9, 99, 181, 257, and 721 requested samples.

Every footprint datetime_utc field is a UTC string. Modern dates retain the ordinary Python-datetime ISO form; epochs outside Python's datetime range fall back to Moira's BCE-safe proleptic-Gregorian ISO form with astronomical year numbering, including year 0000 and signed negative years.

This endpoint does not add observer elevation or terrain, lunar-limb topography, magnitude or obscuration contours, local apparent circumstances, or rendered map products. POST /v1/eclipses/solar/path and its SolarEclipsePath response remain unchanged.

Global Eclipse Circumstances And Solar Cartography REST Contracts

POST /v1/eclipses/solar/global-circumstances returns the searched event, P-contact topology, independently solved U1-U4 contacts where applicable, central-line limits, equatorial and ecliptic conjunction epochs, greatest eclipse, independently optimized greatest duration, apparent geocentric Sun/Moon states, Besselian elements and signed gamma, and explicit ephemeris, surface, limb, TT/UT1, and Delta-T metadata. Partial eclipses return null for central-only products rather than fabricated zero contacts.

POST /v1/eclipses/lunar/global-circumstances returns the selected native or nasa_compat geocentric analysis, scale-explicit greatest epoch, phase contacts and durations, apparent geocentric body parameters, signed gamma, separate penumbral/umbral magnitudes, shadow radii, and model identity. It does not emit a solar-style geographic path.

POST /v1/eclipses/solar/cartography accepts strictly increasing magnitude and obscuration thresholds, mesh_depth in 0..3, and an odd time_samples count in 9..129. angular_tolerance_deg is bounded to 0.1..90, and field_tolerance to 1e-6..0.25. Its response preserves the parent global circumstances, the evaluated spherical-mesh samples, and distinct magnitude and obscuration contour levels. Contour segments carry both component_id and segment_id; antimeridian crossings are split so no serialized segment contains a longitude jump greater than 180 degrees. The same geographic vertices can therefore be used by flat maps and 3D globes without projection-specific engine geometry. It also reports achieved refinement depth, triangle count, maximum angular edge, unresolved-edge count, and whether the requested convergence policy was met within the depth budget.

The cartography daylight policy is GEOMETRIC_SUN_CENTER_NONNEGATIVE_ALTITUDE. It is WGS-84 zero elevation, spherical mean limb, NumPy-free, and explicitly reports duration_contours_available=false. Refraction, terrain, weather, lunar-limb topography, and duration contours are not inferred by transport.

Relationship And Pattern Routes

Planet-first snapshot analysis

POST /v1/stelliums/analyze accepts schema_version: "moira.stellium.v1", full-precision positions, a source/frame context, optional Strict/Broad policy, explicit core/associated selection, and optional same-frame houses (the full HousesResponse plus longitude_frame). It computes no astronomy and has no datetime request alternative. Defaults: Strict four planets, eight degrees maximum total arc, sign/house/tight, ten core planets, no selected associated factors.

The result returns policy, input fingerprint, coverage, per-criterion evaluation and deduplicated core groups with independent matches. Missing houses are not evaluable; malformed houses fail with 422. Associated factors never satisfy the count. Legacy /v1/patterns/* remains unchanged. See the engine-owned contract.

Existing relationship and pattern operations

Method	Path	Handler
POST	/v1/aspects/motion-witness	aspect_motion_witness_route
POST	/v1/aspects/moon-connection-flow	moon_connection_flow_route
POST	/v1/aspects/from-longitudes	aspects_from_longitudes_route
POST	/v1/aspects/from-declinations	declination_aspects_from_declinations_route
POST	/v1/aspects/declination-motion-witness	declination_aspect_motion_witness_route
POST	/v1/synastry/aspects	synastry_aspects_route
POST	/v1/synastry/contacts	synastry_contacts_route
POST	/v1/synastry/contact-relations	synastry_contact_relations_route
POST	/v1/synastry/condition-profiles	synastry_condition_profiles_route
POST	/v1/synastry/overlay	synastry_directional_overlay_route
POST	/v1/synastry/overlays	synastry_overlays_route
POST	/v1/synastry/overlay-relations	synastry_overlay_relations_route
POST	/v1/synastry/chart-condition	synastry_chart_condition_route
POST	/v1/synastry/network	synastry_network_route
POST	/v1/composite/chart	composite_chart_route
POST	/v1/composite/transits	composite_transits_route
POST	/v1/davison/chart	davison_chart_route
POST	/v1/davison/transits	davison_transits_route
POST	/v1/chart-shape/classify	chart_shape_route
POST	/v1/patterns/find	patterns_route
POST	/v1/patterns/coherence	pattern_coherence_route
POST	/v1/patterns/chart-profile	pattern_chart_profile_route
POST	/v1/patterns/network	pattern_network_route
POST	/v1/midpoints/calculate	midpoints_route
POST	/v1/midpoints/to-point	midpoints_to_point_route
POST	/v1/midpoints/pictures	midpoint_pictures_route
POST	/v1/midpoints/weighting	midpoint_weighting_route
POST	/v1/midpoints/clusters	midpoint_clusters_route

Midpoint requests own include_nodes at the request top level. Supplying chart.include_nodes explicitly is rejected with HTTP 422 rather than being silently overridden. Node-bearing midpoint work also requires planet_set: "extended"; the classic and modern sets intentionally filter nodes after chart construction. The extended set recognizes the chart's canonical True Node and Mean Node names as well as the caller-facing North Node alias.

For the dial-aware picture, weighting, and cluster routes, a selected dial is the labelled modulus: 90° uses longitude mod 90, 45° uses longitude mod 45, and 22.5° uses longitude mod 22.5. The orb or cluster_orb is measured in those labelled dial degrees. The picture and weighting routes default to the 360° wheel; clusters default to the 90° dial.

POST /v1/chart-shape/classify implements Marc Edmund Jones's ten-body temperament method. The effective request must exclude nodes and must use exactly Sun through Pluto; include_nodes: true, a body subset, duplicate bodies, or any extra point fails with the standard HTTP 422 validation envelope. The nested chart's default body selection already supplies the canonical ten, so callers normally omit chart.bodies and send include_nodes: false (the route default).

Exact Relationship-Chart Transit Boundary

POST /v1/composite/transits and POST /v1/davison/transits build one immutable relationship-chart target set and search exact canonical transit perfections to selected planet, node, angle, or cusp targets. Responses retain the complete relationship-chart identity, construction truth, expanded target and aspect selection, transit policy, search count, and event receipts.

The server bounds moving bodies, named targets, expanded searches, scan samples, and minimum caller step size; it does not replace the engine solver. Orb-entry/exit windows, progressed/directed relationship charts, cross-chart multi-body patterns, scores, and interpretation remain outside the route contract.

Pattern Search And Dominance Policy

The shared PatternRequest for /v1/patterns/find, /v1/patterns/coherence, /v1/patterns/chart-profile, and /v1/patterns/network accepts chart, include_nodes, finite orb_factor in (0, 10], optional detector-name include, and dominant_only (default false). The routes use the same filtered pattern set so their events, chart condition, network views, and coherence evaluations cannot drift. dominant_only must be an actual JSON boolean, and orb_factor must be a JSON number; coercive strings and booleans are rejected.

dominant_only=true retains maximal structural aspect patterns. A candidate is contained only when its bodies and full preserved aspect signatures are both subsets of another admitted aspect-sourced pattern, with at least one strict inclusion. Thus a Grand Trine inside a Kite and a same-body Trapeze edge-subgraph inside a Cradle are suppressed, while a pattern with a different relation, an equal-body equal-edge overlap, or a position-based Stellium is retained. Selection happens first: an excluded Kite cannot hide an explicitly requested Grand Trine.

Pattern response condition_profile.state is role-resolution completeness, not applying/separating motion or astrological strength. The structured role repair means canonical Grand Trine, Minor Grand Trine, Cradle, and Trapeze responses no longer report mixed solely because their detectors lacked role labels.

Aspect Pattern Qualitative Scoring And Coherence Policy

Aspect pattern qualitative evaluation implements policy moira.pattern_coherence.qualitative.v1-draft. It provides deterministic, astronomically disciplined assessment of closed multi-body aspect patterns without ad-hoc scoring or ungrounded scalar percentages.

The policy is exposed via two complementary REST access patterns:

1. Dedicated Coherence Endpoint (POST /v1/patterns/coherence): Returns a PatternCoherenceSearchResponse containing a list of PatternCoherenceResponse objects with bands, motion qualifiers, limiting aspect ledgers, and plain language summaries for each pattern detected in the chart.
2. Enriched Pattern Discovery (POST /v1/patterns/find): Returns standard PatternSearchResponse where each AspectPatternResponse in events now embeds an optional coherence: PatternCoherenceResponse | None populated with its instantaneous qualitative score and motion witness data.

Both access patterns derive positions and speeds from one chart computation per request. When include_nodes=true, node longitude and node speed are admitted together, so node-linked aspects do not become indeterminate merely because planet-only speed accessors were used. Chart construction and coherence evaluation failures propagate through the standard error handling contract; they are not converted to missing or null coherence.

Reference Constants & Admitted Topologies

Reference orbs are frozen and independent of caller orb_factor:

• Opposition: 8.0°
• Square: 7.0°
• Trine: 7.0°
• Sextile: 5.0°
• Quincunx: 3.0°

Admitted topologies include: T-Square, Grand Trine, Grand Cross, Yod, Mystic Rectangle, and Kite. Other patterns (e.g., Stelliums or non-closed geometries) evaluate to the Not assessed band.

Weakest-Link Principle & Coherence Bands

Coherence is governed by the weakest link: the largest normalized orb ratio $R$ among all required topological links: $$R = \max_{a \in \text{required}} \frac{\text{actual_orb}(a)}{\text{reference_orb}(a)}$$

The ratio maps deterministically to qualitative bands:

• Very strong: $R \le 0.10$
• Strong: $0.10 < R \le 0.25$
• Moderate: $0.25 < R \le 0.50$
• Loose: $0.50 < R \le 0.75$
• Marginal: $R > 0.75$
• Not assessed: Unmatched topology, unadmitted pattern, or missing required links.

Instantaneous Motion Qualifiers

Each required link is evaluated via aspect_motion_witness using chart longitudes and instantaneous daily speeds (chart.speeds()). The pattern-level motion qualifier is evaluated in strict precedence order:

1. Motion unavailable: All required links lack motion data.
2. Partial motion: At least one link lacks motion data while others have it.
3. Station-sensitive: At least one required link involves a stationary planet.
4. Exact: All required links are exact within exact tolerance ($10^{-9}$ deg).
5. Applying: All required links are actively applying.
6. Separating: All required links are actively separating.
7. Mixed motion: Both applying and separating links exist in the pattern.

Positions-In Aspect REST Admission Boundary

POST /v1/aspects/from-longitudes is the additive, kernel-free analysis route for composite, Davison, harmonic, progressed, draconic, and other derived chart positions. It accepts between 2 and 64 named finite ecliptic longitudes, an explicit aspect tier (0, 1, or 2), a positive bounded orb_factor, and an include_nodes flag. Known engine node names are filtered only when that flag is false.

The route delegates through Moira.aspects_from_longitudes(...) to moira.aspects.aspects_from_longitudes(...), which normalizes the supplied longitudes, orders points by name for deterministic pair identity, and applies the canonical moira.constants.Aspect definitions through find_aspects. Responses use the existing AspectData transport shape and expose actual separation, target angle, orb, applied orb ceiling, classification, direction, and sign degrees.

These are caller-supplied positions, not a reconstructed birth moment. No ephemeris reduction, speed, retrograde state, applying/separating state, stationary state, house frame, score, or interpretation is fabricated. The response computation truth records normalized inputs, effective tier and orb factor, node exclusions, counts, engine/facade entry points, and motion_semantics: not_computed_without_speeds.

Declination-Aspect REST Admission Boundary

POST /v1/aspects/from-declinations is the kernel-free analysis route for caller-supplied equatorial declinations. It accepts between 2 and 64 named finite values in [-90°, +90°] and a bounded non-negative orb. The route also requires caller-declared reference_frame and timescale strings. It delegates through Moira.declination_aspects_from_declinations(...) to the first-class moira.declination_aspects engine while preserving the historical moira.aspects compatibility entrypoint. It returns classified Parallel and Contra-Parallel vessels with reconstructable orb admission truth.

Parallel requires the same nonzero hemisphere; Contra-Parallel requires opposite nonzero hemispheres. Two points exactly on the equator form one exact Parallel, while one equatorial and one non-equatorial point are unclassified. Computation truth exposes that ambiguity policy, normalized point order, the effective orb, counts, and the engine/facade entry points. The response records the declared frame, timescale, and provenance: caller_supplied_declinations; it does not infer an astronomical reduction product from the numbers alone.

Declination-Aspect Motion Witness

POST /v1/aspects/declination-motion-witness is the kernel-free, instantaneous motion surface for one caller-selected Parallel or Contra-Parallel. It requires two signed declinations in [-90°, +90°], optional declination speeds in degrees/day, the relationship name, orb and motion tolerances, and caller-declared frame/timescale provenance.

For a Parallel, signed error and relative rate are respectively declination1 - declination2 and speed1 - speed2. For a Contra-Parallel, they are declination1 + declination2 and speed1 + speed2. Away from exact, the sign-adjusted error rate is the orb rate: negative is applying, positive is separating, and a rate inside the declared tolerance is stationary. Exactness takes precedence; missing or partial speeds produce indeterminate. An individual zero declination speed does not by itself make the relationship stationary when the relative error is still changing.

The route enforces the same hemisphere and equator doctrine as detection and returns the shared declination classification plus the signed error, relative speed, orb rate, admission truth, policies, provenance, and evaluation scope. It does not search for a later perfection or prove that a currently applying relationship will perfect before reversing.

Signed Aspect-Motion Witness

POST /v1/aspects/motion-witness is the kernel-free, instantaneous motion surface for one caller-selected canonical longitude aspect. It accepts two named longitudes, optional daily speeds, the canonical aspect name, an orb factor, exact and relative-rate tolerances, and required caller-declared frame and timescale provenance.

The response preserves the shortest directed separation, selected signed aspect branch, directed error, relative speed (speed2 - speed1), orb rate, canonical scaled orb, admission truth, body-specific stationary thresholds, station flags and reasons, and one of applying, exact, separating, stationary, or indeterminate. Missing or partial speeds never fabricate motion. A non-conjunction aspect requested at zero separation has equally near positive and negative branches, so the branch and motion state remain explicitly indeterminate.

This endpoint does not cast a chart, search for a future perfection or station, or supply Dorothean interpretation. It is the first-class geometry witness required by later lunar-flow and classical-perfection doctrine.

Lunar Connection-Flow Witness

POST /v1/aspects/moon-connection-flow is the kernel-bound, interpretation- free exact-event surface for lunar flow. It requires a finite jd_ut and an explicit previous_window_policy: current_sign, which rejects a lookback, or fixed_lookback, which requires a positive previous_lookback_days value bounded to 30 days at REST. The optional modern flag changes the considered body set explicitly.

The response preserves current tropical sign ingress and egress, both search intervals, the last exact directional major aspect in the selected previous window, its signed error and instantaneous motion state at the query, and the first exact connection before current-sign egress. Event absence carries a typed reason rather than a fabricated body or aspect. Computation truth names the apparent geocentric true-ecliptic-of-date position product, UT1 input with internal TT ephemeris conversion, the canonical planet_at geocentric astrometric longitude-rate product used for motion, engine/facade entry points, and none_geometry_only interpretation semantics.

POST /v1/composite/chart and POST /v1/davison/chart also return this same analysis under their required aspects member. Their existing tier, orb_factor, and include_nodes request fields govern the nested analysis; omitted or null values resolve to tier 1, orb factor 1.0, and node inclusion. The composite and Davison chart vessels remain distinct, but REST consumers no longer need a second request to analyze the positions returned by those relationship-chart routes.

Panchanga Routes

Method	Path	Handler
POST	/v1/panchanga/instant	panchanga_instant_route
POST	/v1/panchanga/instant/profile	panchanga_instant_profile_route
POST	/v1/panchanga/chart	panchanga_chart_route
POST	/v1/panchanga/chart/profile	panchanga_chart_profile_route
GET	/v1/sidereal/ayanamsa-systems	sidereal_ayanamsa_systems_route
POST	/v1/sidereal/ayanamsa	sidereal_ayanamsa_route
POST	/v1/sidereal/convert	sidereal_convert_route
POST	/v1/nakshatra/position	nakshatra_position_route
POST	/v1/nakshatra/bulk	nakshatra_bulk_route
POST	/v1/muhurta/direct/classification	muhurta_direct_classification_route
POST	/v1/muhurta/direct/score	muhurta_direct_score_route
POST	/v1/muhurta/chart/classification	muhurta_chart_classification_route
POST	/v1/muhurta/chart/score	muhurta_chart_score_route

Pancha Pakshi Source-Scoped Routes

Method	Path	Handler
GET	/v1/pancha-pakshi/profiles	pancha_pakshi_profiles_route
GET	/v1/pancha-pakshi/profiles/{profile_id}	pancha_pakshi_profile_route
GET	/v1/pancha-pakshi/constitution/uromarisi	pancha_pakshi_uromarisi_constitution_status_route
POST	/v1/pancha-pakshi/identity/aksara	pancha_pakshi_aksara_identity_route
POST	/v1/pancha-pakshi/identity/natal-moon	pancha_pakshi_natal_moon_identity_route
POST	/v1/pancha-pakshi/mappings/nakshatra-bird	pancha_pakshi_nakshatra_bird_mapping_route
POST	/v1/pancha-pakshi/roles/padu	pancha_pakshi_padu_bird_mapping_route
POST	/v1/pancha-pakshi/schedule/nominal	pancha_pakshi_nominal_schedule_route
POST	/v1/pancha-pakshi/schedule/first-eat-bird	pancha_pakshi_first_eat_bird_mapping_route
POST	/v1/pancha-pakshi/sookshma/select	pancha_pakshi_sookshma_temporal_selection_route
POST	/v1/pancha-pakshi/sookshma/schedule-select	pancha_pakshi_schedule_sookshma_temporal_selection_route
POST	/v1/pancha-pakshi/sookshma/civil-time-select	pancha_pakshi_civil_time_sookshma_selection_route
POST	/v1/pancha-pakshi/context/astronomical-paksha	pancha_pakshi_astronomical_paksha_route
POST	/v1/pancha-pakshi/context/local-solar	pancha_pakshi_local_solar_context_route
POST	/v1/pancha-pakshi/schedule/fixed-clock	pancha_pakshi_fixed_clock_materialization_route
POST	/v1/pancha-pakshi/schedule/fixed-clock/current-cell	pancha_pakshi_fixed_clock_current_cell_route
POST	/v1/pancha-pakshi/schedule/solar-proportional	pancha_pakshi_solar_proportional_materialization_route
POST	/v1/pancha-pakshi/schedule/solar-proportional/current-cell	pancha_pakshi_solar_proportional_current_cell_route
POST	/v1/pancha-pakshi/relationships/directed	pancha_pakshi_directed_relationship_route

The Stage 2O civil-time request requires both profile IDs, aware dt, latitude, longitude, caller-supplied source Paksha, subject bird, one of the existing fixed-clock or solar-proportional materialization policy IDs, and one Stage 2K selector policy ID. There are no defaults. The response preserves the selected current-cell vessel, explicit routing policy, derived samam and exact rational elapsed nazhigai, and nested Stage 2N composition. A fixed-clock unmaterialized_solar_half_tail instead carries null samam, elapsed offset, and composition and is never replaced by proportional fallback. The request accepts no astronomical-paksha inference, outcome, condition, score, election, or forecast control.

Every computation request requires an explicitly named profile ID or profile IDs; no route selects a default. The kernel-free nakshatra mapping route accepts only profile_id, explicit source profile_paksha, and a zero-based nakshatra_index in [0, 26]; it does not infer a natal Moon, ayanamsa, instant, condition, score, or forecast. The Uromarisi constitution route exposes immutable SCP closure and admission metadata only. Historical cells, classifications, candidate relations, graph data, condition values, prognosis, and medical interpretation remain private and are not transport fields. The first admitted profile, agastya_madras_1879_akshara_fixed_clock, binds the named 1879 aksara/query-or-name-initial and operating-schedule source substrate. Its capability-gated products expose identity, nominal schedule, first-samam EAT seed, directed relationships, and separately labelled astronomical, local-solar, fixed-clock, and solar-proportional policies. They do not admit Padu, natal identity, condition, scoring, or forecasting semantics. Schedule inputs remain explicit source labels: purva or amara, day or night, and weekday.

The additive Stage 2F request contains only profile_id, aware dt, and the required literal policy_id="apparent_geocentric_moon_sun_longitude_paksha_half_open_v1". It accepts no latitude, longitude, observer elevation, caller-supplied paksha, ayanamsa, correction switch, schedule selector, or natal input. The aware datetime is normalized to UTC, crosses the facade boundary to UT1 once, and is converted once to the reader-bound TT used by both body evaluations.

The PanchaPakshiAstronomicalPakshaResponse publishes requested UT1 and TT, apparent geocentric Sun and Moon longitudes in the true ecliptic of date, normalized Moon-minus-Sun elongation, the shukla or krishna astronomical half, the source-mapped purva or amara profile label, exactly one mapping locator, the immutable policy, and provenance. The policy owns exact half-open classification with no tolerance or snapping: [0, 180) is Shukla/waxing/Purva and [180, 360) is Krishna/waning/Amara. Exact 0 and 180 degrees therefore belong to Shukla/Purva and Krishna/Amara respectively. No ayanamsa is applied because a common longitude offset cancels from the phase difference.

The Purva mapping is directly attested at IA leaf n16, and the Amara mapping at n26, for this named 1879 profile. Their reading status remains machine-assisted visual reading with explicit uncertainty and no human-review dependency; the route does not claim an independently corroborated or universal vocabulary. It performs no schedule selection, materialization, current-cell selection, automatic routing into another request, or natal identity. No source scan, PDF, OCR, page image, copied expression, or translation is bundled.

The separate Stage 2G route requires profile_id="bogamuni_chennai_2024_nakshatra_natal_identity", an aware dt, and the exact literal policy_id="bogamuni_2024_apparent_lahiri_natal_moon_identity_v1". Those are the only request fields. Location, supplied paksha, nakshatra or bird, caller-selected ayanamsa, correction switches, schedule/current-cell controls, scoring, and forecast controls are rejected. The aware datetime is normalized to UTC, crosses to UT1 once, and derives one reader-bound TT epoch shared by the apparent geocentric Sun/Moon evaluation and the Lahiri-true sidereal Moon. The response policy spells the interoperable ayanamsa token exactly as ayanamsa_system="Lahiri", matching the existing sidereal request surface.

PanchaPakshiNatalMoonIdentityResponse exposes requested UT1/TT, tropical Sun and Moon longitudes, Moon-minus-Sun elongation, astronomical and source Paksha, the phase-mapping locator, Lahiri ayanamsa, sidereal Moon longitude, 0-based nakshatra index and name, degrees within the sector, the nested source-table bird mapping and locator, the complete immutable policy, and provenance. The policy states that applying the source table to a birth Moon, selecting Lahiri true ayanamsa, and using 27 equal half-open 40/3-degree sectors are a modern Moira composition, not claims found in the source. Exact internal boundaries belong to the following nakshatra; the bounded one-ULP recovery only restores a mathematically exact boundary after binary representation.

The named Bogamuni 2024 source attests the Purva table at IA leaf n52, the complete Amara verse at n64, and the phase/Paksha binding at n167. The adjacent Amara commentary duplicates Shravana and omits Revati, so the declared verse_precedence_for_nakshatra_partition policy retains it as rejected conflict evidence instead of repairing or mixing it. The Uromarisi 1934 witness corroborates the Purva grouping and exhibits a related malformed Amara commentary but is not imported into the runtime table. Neither archival source artifact, OCR, rendered page, source prose, copied layout, nor translation is bundled.

The separate Stage 2H route requires profile_id="bogamuni_chennai_2024_padu_bird_mapping", an explicit profile_paksha (purva or amara), and an explicit weekday. Those are its only request fields. The strict request rejects datetime, location, day/night half, schedule or activity fields, natal inputs, policy IDs, Adhikara/Bharana aliases, condition, score, and forecast controls.

PanchaPakshiPaduBirdMappingResponse returns the explicit profile Paksha and weekday, one bird, mapping_status="direct_source_attested", the exact death-or-inoperative source-table semantics, the stanza-precedence assembly policy, three canonical source locators, and profile provenance. Purva cells cite the governing Bogamuni leaf n52; Amara cells cite n60; all cells also cite the repeated combined table and commentary at n157 and n158. The table has exactly fourteen cells and no day/night axis.

Padu is not converted to the schedule's RULE activity, a current-time role, an authority bird, or the separately labelled eating bird. The primary witnesses label an eating-bird table and authority days rather than an Adhikara Pakshi table, while Bharana is secondary-only terminology. The API therefore admits neither alias nor product and does not relabel first_eat_bird. Uromarisi 1934 and Bogar material remain separately observed, unbound research context and supply no REST/runtime cell or Stage 2H admission proof.

The Stage 2I route requires profile_id="agastya_madras_1879_akshara_fixed_clock", explicit profile_paksha (purva or amara), explicit half (day or night), and an explicit weekday. Those are its only request fields. The strict request rejects datetime, location, inferred Paksha, Padu or authority aliases, schedule/materialization controls, natal inputs, condition, score, and forecast fields.

PanchaPakshiFirstEatBirdMappingResponse returns the named generator ID, exact input axes, first_eat_bird, mapping_status="direct_source_attested", fixed source-table semantics, the complete canonical generator locator tuple, and profile provenance. The 28 possible cells bind the governing 1879 leaves n16, n21, n26, and n31; the other returned locators are same-witness generator confirmation. The operation does not materialize the 25-cell schedule. Its bird is only that generator's first-samam EAT seed, not an ambient whole-day eating bird, Padu, an authority/Adhikara/Bharana bird, current activity, condition, score, electional judgment, or forecast.

The Stage 2K selector route requires profile_id="bogamuni_chennai_2024_sookshma_temporal_selector", one explicit policy_id, one parent_activity, and an exact reduced elapsed_nazhigai={numerator, denominator} in [0, 6). The only policy IDs are bogamuni_2024_weighted_sookshma_samam_v1 and bogamuni_2024_eka_sookshma_equal_fifths_v1; neither is a default. The weighted response rotates the exact activity-duration vector from the parent activity. The equal-fifths response contains five exact ordinal cells with activity=null, because no subactivity assignment is attested. The response echoes the selected policy, all five exact half-open intervals, the unique selected ordinal and interval, two source locators, and provenance. The strict request rejects floating-point offsets, unreduced fractions, datetime, location, schedule, Uromarisi outcome, condition, score, electional, and forecast fields. No human-language reviewer is required.

The additive local-solar context request contains profile_id, aware dt, latitude, longitude, caller-supplied paksha, and the required literal policy_id="local_solar_day_explicit_paksha_v1". It derives the governing topocentric sunrise, sunset, next sunrise, day/night half, and local-mean-solar weekday, then selects the existing nominal schedule. The response exposes requested_jd_ut1, the three solar-event UT1 JDs, location, paksha, half, weekday, the complete fixed policy vessel, nominal schedule, and provenance.

The policy vessel makes the horizon convention explicit: observer elevation is fixed at 0 m, the solar-altitude signal is unrefracted, and the -0.833-degree threshold incorporates conventional standard refraction and solar semidiameter. The route does not accept an ambient elevation or weather model.

The additive fixed-clock request contains the same profile_id, aware dt, latitude, longitude, and caller-supplied paksha, plus the required literal policy_id="fixed_24_minute_nazhigai_from_local_solar_half_start_v1". It anchors day at governing sunrise or night at governing sunset, applies each exact nominal offset as 1440 SI seconds per nazhigai on reader-bound TT, and projects every endpoint to UT1. The response includes the Stage 2A context, complete fixed policy, TT and UT1 anchor/end fields, signed fixed_end_jd_tt_minus_solar_end_jd_tt topology, boundary relation, all half-open materialized cells, and provenance. The fixed end is never clipped or stretched to the solar end; 0.0001 s is only the numerical topology coalescence threshold.

The additive current-cell request contains the same profile_id, aware dt, latitude, longitude, and caller-supplied paksha, plus the required literal policy_id="fixed_clock_current_cell_half_open_solar_precedence_v1". It first resolves the governing half-open local-solar half, then applies exact zero-tolerance membership on reader-bound TT to that half's admitted Stage 2B cells. The response includes profile, requested UT1/TT, location, paksha, half, weekday, immutable selection policy, TT/UT1 anchor and end witnesses, signed solar-end residual and topology, finite selection_status, selected materialized current_cell or explicit null, and provenance. The complete materialization remains the governing engine object without being duplicated as a nested transport payload.

The status is selected when exactly one cell satisfies start_jd_tt <= requested_jd_tt < end_jd_tt. Shared endpoints belong to the following cell and the fixed end is excluded. At exact sunset or sunrise, the new governing half takes precedence; cells extending past the prior half's solar end are never eligible. When a long solar half continues after the fixed span, the route returns unmaterialized_solar_half_tail and current_cell=null. It never clips, wraps, repeats, stretches, or retains a cell, and the Stage 2B 0.0001 s topology coalescence does not affect membership.

The additive Stage 2D request contains profile_id, aware dt, latitude, longitude, caller-supplied paksha, and the required literal policy_id="solar_proportional_nominal_offsets_over_governing_half_tt_v1". It resolves the Stage 2A governing solar half, preserves every exact nominal offset as a rational fraction of the full 30-nazhigai schedule, and maps each distinct endpoint independently across that actual half on reader-bound TT. Interior endpoints are projected to UT1 through the same reader; the first and last endpoints close exactly on the TT and UT1 anchor and governing solar-half end.

The PanchaPakshiSolarProportionalMaterializationResponse result contains the local-solar context, the complete PanchaPakshiSolarProportionalMaterializationPolicyResponse, TT/UT1 outer bounds, solar_half_duration_seconds_tt, exactly 25 contiguous half-open PanchaPakshiSolarProportionalCellResponse values, and provenance. Each cell retains its unchanged nominal cell, exact start/end/span fractions, TT and UT1 endpoints, and TT duration. This explicit modern Moira policy does not use the Stage 2B fixed 1,440-second nazhigai, does not select a current cell, and does not infer paksha from the Moon. The named 1879 witness attests the nominal schedule and exact rational offsets, but it does not attest proportional sunrise-to-sunset timing.

The additive Stage 2E current-cell request uses the same explicit profile, aware dt, bounded location, and caller-supplied paksha, plus the required literal policy_id="solar_proportional_current_cell_half_open_solar_precedence_v1". It resolves the governing solar half first, constructs the unchanged Stage 2D materialization with the same reader, converts the requested instant to reader-bound TT once, and applies exact zero-tolerance half-open membership. The anchor belongs to cell zero, shared endpoints belong to the following cell, and exact sunrise or sunset belongs to the newly governing half.

PanchaPakshiSolarProportionalCurrentCellResponse is deliberately compact. It contains profile, requested UT1/TT, location, paksha, half, weekday, the complete 13-field selection policy, TT/UT1 governing bounds, TT half duration, selection_status="selected", one non-null proportional cell, and provenance; it does not duplicate the complete 25-cell materialization. Stage 2D covers the entire governing solar half, so the route exposes no null cell or fixed-clock tail status. Zero or multiple matches fail closed rather than invoking tolerance, clipping, wrapping, borrowing, fixed-clock fallback, or inference.

Responses preserve admission status, capabilities, decision identity, source and locator provenance, assembly policy, astronomical-routing status, and declared omissions. Exact nazhigai values serialize as integer numerator/denominator objects rather than binary floats.

The astronomical-paksha and natal-Moon routes accept a datetime but no location and return only their respective instantaneous products. The local-solar context, fixed-clock materialization, fixed-clock current-cell, solar-proportional materialization, and solar-proportional current-cell routes accept both a datetime and location and continue to require caller-supplied paksha. No result is ambiently inserted into another operation. The family does not accept a caller-supplied natal Moon longitude, paksha/nakshatra/bird override on the natal route, caller-supplied sunrise, timezone policy, scoring rule, or inferred name. Natal identity occurs only on the explicit Stage 2G route. The family performs no implicit seasonal scaling, vinadi or Uromarisi-outcome routing, Bharana/Adhikara computation, condition scoring, window search, or cross-witness normalization. Padu lookup occurs only on the explicit Stage 2H pure-table route and never supplies an input to another operation. First-EAT lookup occurs only on the explicit Stage 2I pure-table route and never materializes or selects a current schedule. Fixed 1,440-second nominal-offset materialization occurs only on the explicit Stage 2B route; proportional full-half materialization occurs only on the explicit Stage 2D route under its distinct modern policy, and proportional current-cell selection occurs only on the explicit Stage 2E route. The Stage 2A context route alone still returns no materialized interval, and Stage 2F never selects a schedule. Fixed-clock current-cell selection occurs only on the explicit Stage 2C route under its separate required policy and applies only to the Stage 2B fixed-clock cells. Stage 2G likewise never selects or materializes a schedule, current cell, score, or forecast. Stage 2H accepts no instant or location and never selects a schedule, current cell, identity, condition, score, or forecast. Stage 2I also accepts no instant or location and returns only one source-scoped generator seed. Stage 2K performs only explicit exact Sookshma selection within one samam; it never supplies a clock, schedule, Uromarisi outcome, condition, score, or forecast to another operation.

Sidereal And Nakshatra Utility REST Admission Boundary

The admitted P-GAP-05 utility surface is the bounded synchronous /v1/sidereal/* and /v1/nakshatra/* route family:

• GET /v1/sidereal/ayanamsa-systems
• POST /v1/sidereal/ayanamsa
• POST /v1/sidereal/convert
• POST /v1/nakshatra/position
• POST /v1/nakshatra/bulk

/v1/sidereal/ayanamsa-systems exposes the built-in ayanamsa registry and J2000 reference values. /v1/sidereal/ayanamsa exposes one date-specific ayanamsa value for an admitted named system and mode. /v1/sidereal/convert converts one longitude between tropical and sidereal frames.

/v1/nakshatra/position and /v1/nakshatra/bulk expose mechanical placement into Moira's current 27-equal-Nakshatra taxonomy. Responses preserve Nakshatra name, 0-based index, 1-based number, lord, pada, degrees elapsed, degrees remaining, and sidereal longitude.

This admission does not expose Panchanga judgement, Muhurta classification, Dasha balance, chart-backed Moon derivation, chart-backed sidereal houses, Varga projection, Manazil, Abhijit Nakshatra, user-defined ayanamsa REST payloads, mutable global sidereal mode, interpretation text, recommendations, dense tables, async sweeps, or kernel path mutation.

Muhurta REST Admission Boundary

The admitted P-GAP-02 Muhurta REST surface is the bounded synchronous /v1/muhurta/* route family. It exposes Vedic Muhurta moment classification and raw engine scoring over Panchanga truth.

Direct routes reuse the direct Panchanga derivation path: caller-supplied Sun longitude, Moon longitude, JD, and ayanamsa policy. Chart-backed routes reuse the chart-backed Panchanga derivation path: Moira.chart derives Sun/Moon truth, then moira.panchanga.panchanga_at supplies the five Panchanga limbs.

The admitted routes are:

• POST /v1/muhurta/direct/classification
• POST /v1/muhurta/direct/score
• POST /v1/muhurta/chart/classification
• POST /v1/muhurta/chart/score

Responses preserve request echo, Panchanga source limbs, exposed Muhurta policy weights, classification labels, reasons, and provenance. Score responses preserve the raw unbounded engine score, score breakdown, score scale, and score direction.

This admission does not expose Muhurta search windows, activity-specific guidance, Abhijit/Brahma Muhurta routes, Tara Bala inputs, recommendation language, Western electional search/scoring, arbitrary predicates, arbitrary scorers, or async search jobs. The separate Ramesey v1 single-moment route is not a Muhurta product or a search route.

Shadbala Routes

Method	Path	Handler
POST	/v1/shadbala/chart	shadbala_chart_route
POST	/v1/shadbala/chart/profile	shadbala_chart_profile_route
POST	/v1/shadbala/chart/network	shadbala_chart_network_route
POST	/v1/shadbala/chart/condition	shadbala_chart_condition_route

Jaimini Routes

Method	Path	Handler
POST	/v1/jaimini/karakas	jaimini_karakas_route
POST	/v1/jaimini/karakas/profile	jaimini_karakas_profile_route
POST	/v1/jaimini/karakas/condition	jaimini_karakas_condition_route
POST	/v1/jaimini/karakas/pair	jaimini_karakas_pair_route
POST	/v1/jaimini/chart/karakas	jaimini_chart_karakas_route
POST	/v1/jaimini/chart/profile	jaimini_chart_profile_route
POST	/v1/jaimini/chart/condition	jaimini_chart_condition_route
POST	/v1/jaimini/chart/pair	jaimini_chart_pair_route

Classical Dignities Routes

Method	Path	Handler
POST	/v1/dignities/chart	dignities_chart_route
POST	/v1/dignities/chart/receptions	dignities_chart_receptions_route
POST	/v1/dignities/chart/conditions	dignities_chart_conditions_route
POST	/v1/dignities/chart/condition	dignities_chart_condition_route
POST	/v1/dignities/chart/profile	dignities_chart_profile_route
POST	/v1/dignities/chart/network	dignities_chart_network_route

All six routes accept the shared optional dignity policy. Its accidental branch exposes include_oriental_occidental (default true), while accidental.sect exposes independent include_hayz and include_halb controls (both default true). Disabling a condition removes the assembled label and score contribution, but preserves available raw phase, proximity, besieging, horizon, Mercury-phase, and sect-component truth. These fields are explicit selection policy; they do not rewrite the underlying geometry.

The response models use concrete nested receipt schemas for essential components, accidental truth, solar truth, sect truth, and mutual reception. They are not open-ended dictionaries in OpenAPI.

The REST dignity policy does not admit include_timelord_distributions. Valens distribution scoring is a closed exclusion from the public contract; supplying that former option is a 422 validation_error, not an inert no-op or pending feature.

Unified Hellenistic Profile Route

Method	Path	Handler	Kernel
POST	/v1/hellenistic/chart-profile	hellenistic_chart_profile_route	Yes

The request requires timezone-aware natal and current datetimes plus observer latitude, longitude, and optional elevation. The server always derives a strict, no-fallback Whole Sign figure and the seven classical planets; callers cannot select another house system. Optional syzygy, prenatal lunation, and lord-of-hour longitudes support catalogued lot dependencies.

The seven planetary positions and longitude rates use the default apparent geocentric, true-ecliptic-of-date product. Observer coordinates are applied to the Whole Sign house figure and exact Ascendant/Midheaven, not silently to the planetary position frame. The response records that separation in provenance.

The policy surface keeps Classic-7 dignity doctrine, Dorothean triplicity, typed skip-and-report lot failure behavior, and Decennial L1/L2 fixed. Zodiacal Releasing supports Fortune, Spirit, Eros, or Necessity and one to four levels. The deprecated Decennial deep_subdivision_method request field is optional and null-only; no named deep-method selector is present.

HellenisticChartProfileResponse transports explicit typed models for:

• score-free planet component receipts;
• Whole Sign aspects and Hellenistic superiority;
• Fortune, Spirit, Valens Eros, and Valens Necessity;
• profection activation;
• current Decennial L1/L2 and Zodiacal Releasing periods;
• observer, policy, included/excluded component, kernel, source, timescale, position-frame, warning, and not_evaluable provenance.

The reachable OpenAPI response graph contains no synthetic score field. The response explicitly excludes Firdaria, medieval almutens, later electional rules, unscoped primary directions, Decennial L3/L4, Hermetic-decan geometry, Valens distribution interpretation, and Triacontaeteris.

Horary Evidence Profile Route

Method	Path	Handler	Discovery family
POST	/v1/horary/evidence-profile	horary_evidence_profile_route	classical-vedic

The request requires a timezone-aware question instant, explicit question id, latitude, longitude, house system, turned-house perspective path, and terminal topic house. The supported public time basis is fixed to the caller's stated question-proposed/figure-erected event under the named Gregorian UTC-to-UT1 conversion contract. An optional aware perfection end enables only the bounded Lilly search; absence remains typed not_evaluable.

The service delegates once to Moira.horary_evidence_at. The response preserves typed question time, strict house geometry, chart policy, turned house, significators, planetary hour, chart sect, all three Lilly hour-agreement paths, finite considerations, optional perfection, provenance, and explicit exclusions. The request cannot supply internal evidence receipts or an arbitrary doctrine bag. The route does not infer a topic and returns no yes/no answer, outcome, timing prose, score, confidence, advice, or recommendation.

Neutral Mundane Event-Chart Profile Route

Method	Path	Handler	Discovery family
POST	/v1/mundane/event-chart-profile	mundane_event_chart_profile_route	predictive

The request is a closed four-way discriminated union for cardinal ingress, primary syzygy, solar/lunar eclipse, or Jupiter-Saturn ecliptic-longitude conjunction. Every branch requires an aware bounded search interval, explicit caller-owned location coordinates/role/source/validity, and an explicit house system. Family-specific selectors preserve all four cardinal roots, both syzygy candidates, a named eclipse chart epoch, or the complete Jupiter-Saturn root sequence with an explicit selected index.

The service uses the engine's existing solvers and reader-bound Track B revalidation adapters before composing the profile. Global event and local projection states remain separate; invalid local evidence cannot rewrite an evaluated global event. The transport accepts no caller provenance bag, infers no capital or subject, collapses no eclipse epochs or conjunction roots, and returns no political, economic, conflict, disaster, weather, national-fate, judgement, prediction, score, outcome, advice, or recommendation fields.

Hellenistic Whole-Sign Aspect Routes

Method	Path	Handler	Kernel
POST	/v1/aspects/hellenistic/whole-sign	whole_sign_aspects_route	No
POST	/v1/aspects/hellenistic/overcoming	overcoming_route	No

Both routes accept caller-supplied tropical ecliptic longitudes in degrees and perform no ephemeris or chart-motion calculation. The whole-sign route returns the admitted aspect relation, aspect direction, sign degrees, typed classification, both compatibility overcoming predicates, and the complete hellenistic_superiority_truth receipt for every relation. The direct overcoming route returns that same aggregate plus both predicates and the winning body, or null when neither body is in the tenth-sign overcoming relation. Direction is explicitly not_evaluable when no aspect angle is supplied or at a conjunction/opposition boundary. Longitudes are normalized modulo 360; names are trimmed, longitudes must be finite, and a whole-sign request is bounded to 2–64 uniquely named bodies.

Church of Light Astrodynes Routes

Method	Path	Handler	Kernel
GET	/v1/astrodynes/doctrine	astrodynes_doctrine_route	No
POST	/v1/astrodynes/geometry	astrodynes_geometry_route	No
POST	/v1/astrodynes/chart	astrodynes_chart_route	Yes

Progressed Astrodynes accepts explicit, kernel-free doctrinal inputs and one kernel-backed chart product. Doctrine and practical responses disclose the source publication discrepancies; executable values follow the manual's stated formulas.

Method	Path	Handler	Kernel
GET	/v1/astrodynes/progressed/doctrine	progressed_astrodynes_doctrine_route	No
POST	/v1/astrodynes/progressed/normal	progressed_astrodynes_normal_route	No
POST	/v1/astrodynes/progressed/dated-aspect	progressed_astrodynes_dated_aspect_route	No
POST	/v1/astrodynes/progressed/major-relation	progressed_astrodynes_major_relation_route	No
POST	/v1/astrodynes/progressed/accessory-relation	progressed_astrodynes_accessory_relation_route	No
POST	/v1/astrodynes/progressed/reenforcement	progressed_astrodynes_reenforcement_route	No
POST	/v1/astrodynes/progressed/practical	progressed_astrodynes_practical_route	No
POST	/v1/astrodynes/progressed/total-influence	progressed_astrodynes_total_influence_route	No
POST	/v1/astrodynes/progressed/compound-total-influence	progressed_astrodynes_compound_total_influence_route	No
POST	/v1/astrodynes/progressed/chart	progressed_astrodynes_chart_backed_route	Yes
POST	/v1/astrodynes/progressed/search	progressed_astrodynes_search_route	Yes
POST	/v1/astrodynes/progressed/integrate	progressed_astrodynes_integrate_route	Yes

/progressed/chart accepts timezone-aware natal and target datetimes, latitude, longitude, house system, and an explicit fallback opt-in. It derives the Church of Light Limiting Date, major ephemeris date, Minor Ephemeris Date, transit date, progressed M.C./Ascendant, four terminal tiers, the natal and normal calculations, accessory relations, reenforcements, and practical distribution. The response preserves the selected time keys, geocentric apparent frame, angle method, natal house frame, requested/effective house systems, and fallback truth.

/progressed/search returns bounded one-degree entry and exit contacts, exact perfections or named closest approaches, optional minor reenforcement power, clipped-boundary truth, and the sampling/refinement policy. Requests are bounded by max_samples.

/progressed/integrate applies composite trapezoidal quadrature to the actual ephemeris-varying instantaneous power/harmony/discord curve. Results are in astrodyne-, harmodyne-, and discordyne-days. The manual's constant-rate 0.75 * peak * duration result remains visible only as a comparator; method, step, sample count, coarse comparison, and error estimate are explicit. The comparator is null for a partial interval whose endpoints are not both the one-degree limits. The integration request requires max_samples >= 3. The engine uses an even fine-interval count with a nested 2:1 coarse mesh; sample_count is the actual number of unique chronology evaluations and never exceeds max_samples.

/geometry requires exactly the ten Astrodyne planets, declinations for those planets plus M.C. and Asc., twelve cusps forming one ordered zodiacal circuit, and explicit M.C./Asc. values matching cusps 10/1. It normalizes longitudes and returns the complete calculation without engine or kernel access.

/chart requires a timezone-aware datetime, latitude, longitude, and house system. Planetary positions and declinations are geocentric apparent; latitude and longitude govern the houses only. House fallback is rejected by default. When allow_house_fallback is true, the response records requested/effective systems and the fallback reason. A fallback figure that places more than two cusps in one sign is rejected explicitly because that allocation lies outside the bounded aggregate doctrine currently validated by the engine.

Both calculation responses expose normalized geometry, fixed policy, all detected relations with distinct admitted and scored flags, derivation truth, body profiles, sign/house checksum truth, Class 5 summary families, relation network, invariant failures, and provenance. Chart-backed geometry also retains the requested datetime/location, Julian date, and true obliquity used for the declination conversion. The fixed Church of Light doctrine is not caller-selectable or blended with conventional dignity tables.

Classical Lots Routes

Method	Path	Handler
GET	/v1/lots/catalog	lots_catalog_route
POST	/v1/lots/chart	lots_chart_route
POST	/v1/lots/chart/dependencies	lots_chart_dependencies_route
POST	/v1/lots/chart/conditions	lots_chart_conditions_route
POST	/v1/lots/chart/condition	lots_chart_condition_route
POST	/v1/lots/chart/profile	lots_chart_profile_route
POST	/v1/lots/chart/network	lots_chart_network_route

POST /v1/lots/chart returns a LotsEvaluation transport aggregate: parts, not_evaluable, aggregate status, evaluated_count, and not_evaluable_count. Each computed part carries typed computation, classification, dependency-completeness, and astrological-condition receipts. Missing optional references therefore produce named not_evaluable entries instead of disappearing from the response. Dependency completeness is not an astrological condition judgment. Chart-backed routes pass the actual Ascendant and Midheaven separately from house cusp 1/10; Whole Sign sign boundaries do not silently replace those angles.

Triplicity Routes

Method	Path	Handler
GET	/v1/triplicity/table	triplicity_table_route
POST	/v1/triplicity/assignment	triplicity_assignment_route
POST	/v1/triplicity/score	triplicity_score_route

Egyptian Bounds Routes

Method	Path	Handler
GET	/v1/egyptian-bounds/table	egyptian_bounds_table_route
POST	/v1/egyptian-bounds/bound	egyptian_bound_route
POST	/v1/egyptian-bounds/classification	egyptian_bound_classification_route
POST	/v1/egyptian-bounds/relation	egyptian_bound_relation_route
POST	/v1/egyptian-bounds/condition	egyptian_bound_condition_route
POST	/v1/egyptian-bounds/aggregate	egyptian_bounds_aggregate_route
POST	/v1/egyptian-bounds/network	egyptian_bounds_network_route

The bounds doctrine selector admits egyptian, ptolemaic, chaldean_day, and chaldean_night. Chaldaean bounds are sect-dependent; the ambiguous value chaldean is rejected. Table and bound-truth responses include the primary-source citation for the selected variant.

Vedic Dignities Routes

Method	Path	Handler
POST	/v1/vedic-dignities/dignity	vedic_dignity_route
POST	/v1/vedic-dignities/relationships	vedic_dignity_relationships_route
POST	/v1/vedic-dignities/condition	vedic_dignity_condition_route
POST	/v1/vedic-dignities/chart-profile	vedic_dignity_chart_profile_route
POST	/v1/vedic-dignities/chart/dignity	vedic_dignity_chart_backed_route
POST	/v1/vedic-dignities/chart/relationships	vedic_dignity_chart_backed_relationships_route
POST	/v1/vedic-dignities/chart/profile	vedic_dignity_chart_backed_profile_route

Ashtakavarga Routes

Method	Path	Handler
POST	/v1/ashtakavarga/result	ashtakavarga_result_route
POST	/v1/ashtakavarga/profile	ashtakavarga_profile_route
POST	/v1/ashtakavarga/sign-profile	ashtakavarga_sign_profile_route
POST	/v1/ashtakavarga/transit-strength	ashtakavarga_transit_strength_route
POST	/v1/ashtakavarga/chart/result	ashtakavarga_chart_result_route
POST	/v1/ashtakavarga/chart/profile	ashtakavarga_chart_profile_route
POST	/v1/ashtakavarga/chart/sign-profile	ashtakavarga_chart_sign_profile_route
POST	/v1/ashtakavarga/chart/transit-strength	ashtakavarga_chart_transit_strength_route

Varga Routes

Method	Path	Handler
POST	/v1/varga/generic	varga_generic_route
POST	/v1/varga/named	varga_named_route
POST	/v1/varga/shodashvarga	varga_shodashvarga_route
POST	/v1/varga/named/batch	varga_named_batch_route
POST	/v1/varga/shodashvarga/batch	varga_shodashvarga_batch_route
POST	/v1/varga/chart/named	varga_chart_named_route
POST	/v1/varga/chart/shodashvarga	varga_chart_shodashvarga_route
POST	/v1/varga/chart/shodashvarga/batch	varga_chart_shodashvarga_batch_route

Decans And Decanates Routes

Method	Path	Handler
POST	/v1/decanates/chaldean-face	chaldean_face_route
POST	/v1/decanates/triplicity	triplicity_decan_route
POST	/v1/decanates/vedic-drekkana	vedic_drekkana_route
POST	/v1/decanates/set	decanate_set_route
POST	/v1/decanates/chart/vedic-drekkana	vedic_drekkana_chart_route
POST	/v1/decanates/chart/set	decanate_set_chart_route

Astrocartography Routes

Method	Path	Handler
POST	/v1/astrocartography/lines	astrocartography_lines_route
POST	/v1/astrocartography/chart/lines	astrocartography_chart_lines_route
POST	/v1/astrocartography/subplanetary	astrocartography_subplanetary_route
POST	/v1/astrocartography/chart/subplanetary	astrocartography_chart_subplanetary_route
POST	/v1/astrocartography/chart/subjects/lines	astrocartography_subject_chart_lines_route
POST	/v1/astrocartography/chart/subjects/subplanetary	astrocartography_subject_chart_subplanetary_route
POST	/v1/astrocartography/fixed-stars	fixed_star_astrocartography_route
POST	/v1/astrocartography/dynamic/transits	dynamic_astrocartography_route

Body-class truth:

• Direct Astrocartography routes are caller-owned coordinate routes. Their labels may name selected planets, minor bodies, fixed stars, or other apparent RA/Dec subjects when the caller supplies valid RA/Dec and sidereal time.
• Chart-backed Astrocartography line routes admit selected chart planets and selected asteroids when the public apparent topocentric RA/Dec path supports the subject. Chart-backed comet lines remain deferred.
• Chart-backed Astrocartography subplanetary routes admit selected chart planets plus selected asteroids and comets through the geocentric ecliptic-to-equatorial path.
• Mixed-subject chart routes accept typed subjects entries for admitted planets, admitted asteroids/comets, fixed stars from the sovereign star registry, lots computed through the Lots engine, caller-supplied ecliptic points, and caller-supplied RA/Dec points. Every subject is resolved into RA/Dec before ACG geometry is computed.
• Lot subjects require explicit observer latitude/longitude because the Lots engine derives ASC, houses, and day/night truth from the chart site.
• Catalog-wide fixed-star, asteroid, comet, and small-body sweeps remain deferred; mixed-subject routes are explicit-selection surfaces.
• Astrocartography provenance includes a subjects list carrying subject class, canonical name, NAIF ID when applicable, and position source.

Track A adds two bounded routes:

• /v1/astrocartography/fixed-stars resolves each requested star through the sovereign star registry, rejects duplicate canonical identities, and returns true-of-date RA/Dec, MC/IC/ASC/DSC lines, zenith/nadir points, and complete source/frame receipts.
• /v1/astrocartography/dynamic/transits accepts only strictly increasing, explicit transit epochs and returns exact snapshots plus adjacent meridian or matched-latitude curve displacement receipts.

Neither route ranks stars or places. Catalog sweeps, interpolation, progressed/directed cyclocartography, destination scores, travel advice, and interpretation remain excluded.

Local Space Routes

Method	Path	Handler
POST	/v1/local-space/positions	local_space_positions_route
POST	/v1/local-space/chart/positions	local_space_chart_positions_route

Geodetic Routes

Method	Path	Handler
POST	/v1/geodetic/location-chart	geodetic_location_chart_route
POST	/v1/geodetic/chart/location-chart	geodetic_chart_location_chart_route
POST	/v1/geodetic/equivalents	geodetic_equivalents_route
POST	/v1/geodetic/chart/equivalents	geodetic_chart_equivalents_route

Galactic Coordinates Routes

Method	Path	Handler
POST	/v1/galactic/equatorial-to-galactic	equatorial_to_galactic_route
POST	/v1/galactic/galactic-to-equatorial	galactic_to_equatorial_route
POST	/v1/galactic/ecliptic-to-galactic	ecliptic_to_galactic_route
POST	/v1/galactic/galactic-to-ecliptic	galactic_to_ecliptic_route
POST	/v1/galactic/reference-points	galactic_reference_points_route
POST	/v1/galactic/cosmic-reference-points	cosmic_reference_points_route
POST	/v1/galactic/chart/positions	galactic_chart_positions_route

/v1/galactic/reference-points preserves the historical five-entry response. Its Super-Galactic Center key is the legacy astrological convention anchored on M87, not the formal supergalactic longitude origin. The typed /v1/galactic/cosmic-reference-points route accepts a finite jd_tt and an optional physical_object, coordinate_landmark, or proxy_reference filter. It returns at most 12 true-ecliptic-of-date directions with the selected anchor, semantic class, source frame and epoch, coordinate and semantic authorities, citations, registry version, and transport-stage receipt. No Local Group barycenter is exposed without a declared mass model.

Galactic Houses Routes

Method	Path	Handler
POST	/v1/galactic-houses/cusps	galactic_house_cusps_route
POST	/v1/galactic-houses/placement	galactic_house_placement_route
POST	/v1/galactic-houses/chart/placements	galactic_house_chart_placements_route

Gauquelin Routes

Method	Path	Handler
POST	/v1/gauquelin/sector	gauquelin_sector_route
POST	/v1/gauquelin/sectors	gauquelin_sectors_route
POST	/v1/gauquelin/chart/sectors	gauquelin_chart_sectors_route

Progressions, Timelords, Dasha, Varshaphal, And Primary Directions

Progression method menus

Three progression endpoints are method-dispatched: the method field selects the technique. The accepted keys are enumerated in the OpenAPI schema (they are Literal types on the request models) and are the single source of truth for the runtime dispatch registries in moira_server/models/progressions.py. Every technique also accepts converse: bool (default false) for the converse direction.

POST /v1/progressions/arc — method, one of:

Key	Doctrinal name
solar_arc	Solar Arc (Sun's arc applied to all bodies)
solar_arc_right_ascension	Solar Arc in Right Ascension
naibod_longitude	Naibod in Longitude
naibod_right_ascension	Naibod in Right Ascension
mean_solar_arc_longitude	Mean Solar Arc in Longitude (Naibod rate)
mean_solar_arc_right_ascension	Mean Solar Arc in Right Ascension
one_degree_longitude	One Degree in Longitude
one_degree_right_ascension	One Degree in Right Ascension
planetary_arc	Planetary Arc (requires arc_body, the reference planet)

POST /v1/progressions/time-key — method, one of:

Key	Doctrinal name
tertiary	Tertiary (synodic month = one year)
tertiary_ii	Tertiary II (tropical-month variant)
minor	Minor (solar year / synodic month)
duodenary	Duodenary (Carter, 2h05m per year)
quotidian_solar	Quotidian Solar (secondary day-for-day)
quotidian_lunar	Quotidian Lunar (lunar-month day-for-day)

POST /v1/progressions/house-frame/arc — method, one of:

Key	Doctrinal name
ascendant_arc	Ascendant Arc (the natal ascendant's daily arc)
vertex_arc	Vertex Arc (the natal vertex's daily arc)

Method	Path	Handler
POST	/v1/progressions/secondary	secondary_progression_route
POST	/v1/progressions/secondary/reduction	secondary_progression_reduction_route
POST	/v1/progressions/secondary-declination	secondary_declination_route
POST	/v1/progressions/secondary-declination/reduction	secondary_declination_reduction_route
POST	/v1/progressions/arc	arc_progression_route
POST	/v1/progressions/arc/reduction	arc_progression_reduction_route
POST	/v1/progressions/time-key	time_key_progression_route
POST	/v1/progressions/time-key/reduction	time_key_progression_reduction_route
POST	/v1/progressions/house-frame	house_frame_route
POST	/v1/progressions/house-frame/reduction	house_frame_reduction_route
POST	/v1/progressions/house-frame/cusps	daily_houses_route
POST	/v1/progressions/house-frame/arc	house_frame_arc_route
POST	/v1/progressions/house-frame/arc/reduction	house_frame_arc_reduction_route
POST	/v1/progressions/profile	progression_profile_route
POST	/v1/progressions/profile/reduction	progression_profile_reduction_route
POST	/v1/progressions/network	progression_network_route
POST	/v1/progressions/network/reduction	progression_network_reduction_route
POST	/v1/profections/annual	annual_profection_route
POST	/v1/profections/monthly	monthly_profection_route
POST	/v1/profections/schedule	profection_schedule_route

/v1/profections/schedule requires timezone-aware natal and current datetimes. It computes completed age at the natal civil anniversary in the natal timezone, rejects pre-birth instants, and requires leap_day_policy="february_28" or "march_1" for a February 29 nativity. An anniversary in a repeated local wall time requires ambiguous_time_policy="earlier_occurrence" or "later_occurrence"; the engine does not guess a fold. An anniversary in a daylight-saving gap fails closed. The natal request's activation_orb applies to both annual and schedule routes. Their responses include age_basis, leap_day_policy, and a typed activation_truth with per-body distances; activated_planets is its compatibility projection.

| POST | /v1/timelords/firdaria/sequence | firdaria_sequence_route | | POST | /v1/timelords/firdaria/groups | firdaria_groups_route | | POST | /v1/timelords/firdaria/current | firdaria_current_route | | POST | /v1/timelords/firdaria/profile | firdaria_profile_route | | POST | /v1/timelords/firdaria/active-pair | firdaria_active_pair_route | | POST | /v1/timelords/decennials/sequence | decennials_sequence_route | | POST | /v1/timelords/decennials/groups | decennials_groups_route | | POST | /v1/timelords/decennials/current | decennials_current_route | | POST | /v1/timelords/decennials/profile | decennials_profile_route | | POST | /v1/timelords/decennials/active-pair | decennials_active_pair_route | | POST | /v1/timelords/decennials/active-path | decennials_active_path_route | | POST | /v1/timelords/zodiacal-releasing/sequence | zr_sequence_route | | POST | /v1/timelords/zodiacal-releasing/groups | zr_groups_route | | POST | /v1/timelords/zodiacal-releasing/current | zr_current_route | | POST | /v1/timelords/zodiacal-releasing/profile | zr_profile_route | | POST | /v1/timelords/zodiacal-releasing/level-pair | zr_level_pair_route |

Every Decennials request is limited to levels 1–2. The deprecated request deep_subdivision_method field accepts only omission or null; the schema advertises no selectable deep-method enum. Response receipts retain a fixed deep_subdivision_method=null compatibility sentinel. Valens and Hephaistio L3/L4 chronology and Valens delineation are closed exclusions, not incomplete REST work.

Decennials period responses preserve time_basis="valens_lived_days_to_360_day_distribution", calendar_projection_basis="elapsed_julian_days_from_natal_jd", sequence_origin_jd, start_distribution_day, end_distribution_day, and distribution_years. Sequence, current, and profile responses repeat the basis and origin at top level. ISO dates and JDs are projections from elapsed lived days, not civil-month anniversary claims.

Every transported Decennial period also preserves its typed sequence_truth, including sect light, each Classic 7 forward arc, the assembled sequence, any ambiguity groups, and evaluation reason.

For /v1/timelords/zodiacal-releasing/profile, profile_level must be less than or equal to the request's generated levels. Empty or unavailable-level profiles fail validation instead of returning an empty aggregate.

Every transported ZR period carries fortune_angularity_truth. When Fortune is omitted its raw status is not_evaluable and raw peak truth is null, while the legacy is_peak_period compatibility field remains false.

| POST | /v1/dasha/vimshottari/sequence | dasha_sequence_route | | POST | /v1/dasha/vimshottari/balance | dasha_balance_route | | POST | /v1/dasha/vimshottari/current | dasha_current_route | | POST | /v1/dasha/vimshottari/profile | dasha_profile_route | | POST | /v1/dasha/vimshottari/lord-pair | dasha_lord_pair_route | | POST | /v1/dasha/alternate/ashtottari/sequence | ashtottari_sequence_route | | POST | /v1/dasha/alternate/ashtottari/profile | ashtottari_profile_route | | POST | /v1/dasha/alternate/ashtottari/chart/sequence | ashtottari_chart_sequence_route | | POST | /v1/dasha/alternate/ashtottari/chart/profile | ashtottari_chart_profile_route | | POST | /v1/dasha/alternate/yogini/sequence | yogini_sequence_route | | POST | /v1/dasha/alternate/yogini/profile | yogini_profile_route | | POST | /v1/dasha/alternate/yogini/chart/sequence | yogini_chart_sequence_route | | POST | /v1/dasha/alternate/yogini/chart/profile | yogini_chart_profile_route | | POST | /v1/dasha/alternate/period-profile | alternate_period_profile_route | | POST | /v1/varshaphal/chart | varshaphal_chart_route | | POST | /v1/varshaphal/judgement/profile | varshaphal_judgement_profile_route | | POST | /v1/varshaphal/judgement/year | varshaphal_year_judgement_route | | POST | /v1/varshaphal/summary | varshaphal_year_summary_route | | POST | /v1/varshaphal/topics | varshaphal_topics_route | | POST | /v1/varshaphal/topics/windows | varshaphal_topic_windows_route | | POST | /v1/varshaphal/mudda/active | varshaphal_mudda_active_route | | POST | /v1/varshaphal/mudda/judgement | varshaphal_mudda_judgement_route | | POST | /v1/varshaphal/tasira/active | varshaphal_tasira_active_route | | POST | /v1/primary-directions/speculum | primary_directions_speculum_route | | POST | /v1/primary-directions/arcs | primary_directions_arcs_route | | POST | /v1/primary-directions/arcs/reduction | primary_directions_arcs_reduction_route | | POST | /v1/primary-directions/relations | primary_directions_relations_route | | POST | /v1/primary-directions/profile | primary_directions_profile_route | | POST | /v1/primary-directions/profile/reduction | primary_directions_profile_reduction_route | | POST | /v1/primary-directions/network | primary_directions_network_route | | POST | /v1/primary-directions/network/reduction | primary_directions_network_reduction_route |

Primary-directions transport contract

The eight paths above are stable. The compact and reduction variants share the same engine computation; reduction responses add resolved preset/policy, key, search-mode, requested observer, and effective house-system truth.

Policy resolution is enum-backed. Canonical preset names are preferred; recognized historical aliases remain adapters and the reduction truth preserves both requested and canonical identity. A supplied preset may not conflict with an explicit method or space. An unqualified Ptolemy in_zodiaco request is ambiguous and is rejected; clients must choose the aspect, antiscia, or parallel preset that names the intended doctrine. The solar key requires an explicit positive natal solar rate. PLACIDUS_MUNDANE and PLACIDIAN_CLASSIC_SEMI_ARC reject in_zodiaco because those runtime methods are mundane-only. Fixed-star targets require conjunction admission, and rapt-parallel direct/converse motion remains specific to the configured rapt relation and target rather than widening the ordinary policy.

The canonical topocentric_zodiacal_aspect_signed_primary_motion preset is the explicit source-scoped exception to ordinary role-exchanged converse. It computes one ordered Topocentric zodiacal-aspect arc with assigned-zero aspect latitude and zodiacal projected perfection, then wraps that arc to (-180, 180) degrees: positive is direct, negative is converse, numerical zero is no event, and the directionally ambiguous 180-degree boundary fails closed. It requires include_converse=true; under this doctrine the flag admits either label from the single ordered construction rather than asking for a role-exchanged second arc. It also requires explicit, non-empty significators and promissors; the unrestricted candidate set contains the antipodal MC/IC pair and therefore cannot carry one deterministic signed label. The ordinary topocentric_zodiacal_aspect preset remains unchanged.

Signed-primary-motion is available only when the transport performs engine_search. The submitted-only relations path and every request carrying submitted_arcs reject that preset because submitted arcs contain a positive magnitude and label, not the ordered raw arc required to derive the sign. Reduction responses identify the signed doctrine and canonical preset exactly. No path or established response field is added or replaced. This narrow preset is not the separately deferred global neo-converse doctrine.

The six engine-search paths (arcs, profile, and network, including their reduction siblings) also accept these additive, typed target/context lists on the search request:

• antiscia_targets: {source_name, kind} where kind is antiscion or contra_antiscion
• ptolemaic_parallel_targets: {source_name, relation} where relation is parallel or contra_parallel
• placidian_rapt_parallel_targets: {source_name}; direct versus converse is owned by the selected rapt-parallel preset
• fixed_star_targets: {star_name} resolved through Moira's sovereign star catalog
• morinus_aspect_contexts: {source_name, maximum_latitude, moving_toward_maximum}

Each list and their combined materialized total are bounded to 256 items. Duplicate derived identities or duplicate Morinus source contexts fail closed. These lists are search materialization inputs, so they cannot accompany submitted_arcs and are not accepted by the submitted-only relations request. Antiscia requires ptolemy_zodiacal_antiscia, Ptolemaic parallels require ptolemy_zodiacal_parallel, rapt targets require the corresponding direct or converse rapt preset, and Morinus contexts require morinus_zodiacal_aspect. Fixed stars compose with any preset whose resolved relation/target policy admits their conjunction branch. Reduction responses preserve the exact resolved target/context vessels and rapt motion; they do not collapse a Morinus path context to its source name.

profile and network accept either engine search inputs or a bounded submitted-arc list; relations is submitted-only. Submitted items are validated and reconstructed as real PrimaryArc vessels; no transport duck type or hidden conversion fallback is used. On the search-capable routes, omission means engine_search. An explicitly supplied empty list means submitted_arcs with no items and returns a valid empty transport response. Lists are bounded to 4,096 items. In an empty profile response, profiles=[], all counts are zero, and strongest_significator / weakest_significator are null; nearest_arc=0.0 and farthest_arc=0.0 are transport compatibility sentinels only and do not represent measured arcs. An empty network response uses nodes=[], edges=[], isolated=[], and most_connected=null; that vessel has no numeric arc extrema.

Natal latitude/longitude construct the natal chart. observer_lat and observer_lon construct directional houses and own the geographic latitude used by primary-direction geometry. Zero is a lawful longitude and is retained. include_relations controls response depth only; it does not change or mutate the engine profile. Arc responses preserve positional relational_kind separately from the compatibility perfection-kind relation_kind field. solar_rate_explicit distinguishes a generated or submitted natal solar rate from the numeric compatibility rate retained on a non-solar submitted arc; only the former can support solar-key conversion.

For every /v1/varshaphal/* request, the timezone offset supplied on natal_dt owns the doctrinal civil birth date and therefore the birth year used by Muntha and Mudda progression. The offset is not transport-only metadata: two representations of the same instant may lawfully name different local civil birth dates. The natal, query, and focus instants are independently reduced from UTC to UT1 before astronomical computation.

Catalog, Star, Small-Body, And Website Routes

Method	Path	Handler
POST	/v1/stars/position	star_position
POST	/v1/stars/bulk	stars_bulk
GET	/v1/stars/list	list_stars
GET	/v1/stars/variable/list	list_variable_stars_route
GET	/v1/stars/variable/{name}	variable_star_catalog_route
POST	/v1/stars/variable/state	variable_star_state_route
POST	/v1/stars/variable/range	variable_star_range_route
POST	/v1/stars/variable/catalog-profile	variable_star_catalog_profile_route
POST	/v1/stars/variable/pair	variable_star_pair_route
GET	/v1/stars/multiple/list	list_multiple_stars_route
GET	/v1/stars/multiple/{name}	multiple_star_catalog_route
POST	/v1/stars/multiple/state	multiple_star_state_route
POST	/v1/asteroids/position	asteroid_position
POST	/v1/asteroids/bulk	asteroids_bulk
GET	/v1/asteroids/list	list_asteroids
GET	/v1/asteroids/subsets	asteroid_subsets
GET	/v1/asteroids/subsets/{subset}/list	asteroid_subset_list
POST	/v1/asteroids/subsets/{subset}/positions	asteroid_subset_positions
GET	/v1/asteroids/families/by-number/{number}	asteroid_family_by_number
GET	/v1/asteroids/families/{family_name}/members	asteroid_family_members
POST	/v1/asteroids/families/chart	asteroid_families_in_chart
POST	/v1/asteroids/families/chart/resonance-network	asteroid_family_resonance_network
POST	/v1/comets/position	comet_position
POST	/v1/comets/bulk	comets_bulk
GET	/v1/comets/list	list_comets
GET	/v1/manazil/catalog	manazil_catalog_route
POST	/v1/manazil/position	manazil_position_route
POST	/v1/manazil/bulk	manazil_bulk_route
GET	/v1/manazil/traditions/{tradition}/mansions/{mansion_index}	manazil_tradition_lookup_route
GET	/v1/nodes/catalog	node_catalog_route
POST	/v1/nodes/planetary/mean	mean_planetary_node_route
POST	/v1/nodes/planetary/mean/bulk	mean_planetary_nodes_bulk_route
POST	/v1/nodes/geometric	geometric_node_route
POST	/v1/orbits/elements	orbital_elements_route
POST	/v1/orbits/distance-extremes	distance_extremes_route
POST	/v1/orbits/class	orbit_class_route
POST	/v1/orbits/class/batch	orbit_class_batch_route
POST	/v1/phenomena/planet	planet_phenomena_route
POST	/v1/phenomena/orbital-events	orbital_phenomena_events_route
POST	/v1/phenomena/proximity	proximity_events_route
POST	/v1/solar-condition/instant	solar_condition_instant_route
POST	/v1/solar-condition/events	solar_condition_events_route
GET	/v1/uranian/catalog	uranian_catalog_route
POST	/v1/uranian/position	uranian_position_route
POST	/v1/uranian/bulk	uranian_bulk_route
GET	/v1/harmonics/presets	harmonic_presets_route
POST	/v1/harmonics/chart	harmonic_chart_route
POST	/v1/harmonics/age-chart	harmonic_age_chart_route
POST	/v1/harmonics/conjunctions	harmonic_conjunctions_route
POST	/v1/harmonics/pattern-score	harmonic_pattern_score_route
POST	/v1/harmonics/aspects	harmonic_aspects_route
POST	/v1/harmonics/sweep	harmonic_sweep_route
POST	/v1/harmonics/fingerprint	harmonic_fingerprint_route
POST	/v1/harmonics/composite	harmonic_composite_route
POST	/v1/harmonics/transit-forecast	harmonic_transit_forecast_route
POST	/v1/harmograms/vector	harmogram_vector_route
POST	/v1/harmograms/zero-aries-vector	harmogram_zero_aries_vector_route
POST	/v1/harmograms/intensity-spectrum	harmogram_intensity_spectrum_route
POST	/v1/harmograms/projection	harmogram_projection_route
POST	/v1/harmograms/trace	harmogram_trace_route
POST	/v1/phase/illuminated-fraction	illuminated_fraction_route
POST	/v1/phase/synodic	synodic_phase_route
POST	/v1/phase/elongation	elongation_route
POST	/v1/phase/angle	phase_angle_route
POST	/v1/phase/angular-diameter	angular_diameter_route
POST	/v1/phase/apparent-magnitude	apparent_magnitude_route
POST	/v1/antiscia/reflect	antiscia_reflect_route
POST	/v1/antiscia/contacts	antiscia_contacts_route
POST	/v1/antiscia/to-point	antiscia_to_point_route
POST	/v1/draconic/longitude	draconic_longitude_route
POST	/v1/draconic/positions	draconic_positions_route
POST	/v1/draconic/chart	draconic_chart_route
POST	/v1/nine-parts/abu-mashar	abu_mashar_nine_parts_route
POST	/v1/planetary-hours/schedule	planetary_hours_schedule_route
POST	/v1/planetary-hours/hour-at	planetary_hours_hour_at_route
POST	/v1/huber/dynamic-intensity	huber_dynamic_intensity_route
POST	/v1/huber/house-zones	huber_house_zones_route
POST	/v1/huber/age-point	huber_age_point_route
POST	/v1/huber/intensity-at	huber_intensity_at_route
POST	/v1/huber/chart-intensity-profile	huber_chart_intensity_profile_route
POST	/v1/huber/age-point-contacts	huber_age_point_contacts_route
POST	/v1/lord-of-the-orb/sequence	lord_of_the_orb_sequence_route
POST	/v1/lord-of-the-orb/current	lord_of_the_orb_current_route
POST	/v1/lord-of-the-turn/profile	lord_of_the_turn_profile_route
GET	/v1/electional/predicate-profiles	electional_predicate_profiles_route
GET	/v1/electional/scorer-profiles	electional_scorer_profiles_route
POST	/v1/electional/windows	electional_windows_route
POST	/v1/electional/moments	electional_moments_route
POST	/v1/electional/scored	electional_scored_route
POST	/v1/electional/western/lunar-ecliptic-direction	lunar_ecliptic_direction_route
POST	/v1/electional/western/ramesey-moon-condition	ramesey_moon_condition_route
POST	/v1/electional/western/sahl-moon-condition	sahl_moon_condition_route
POST	/v1/electional/western/sahl-matter-profile	sahl_matter_profile_route
POST	/v1/electional/western/classical-perfection	lilly_perfection_route
POST	/v1/electional/western/dorotheus-moon-condition	dorotheus_moon_condition_route
POST	/v1/electional/western/dorotheus-rooted-context	dorotheus_rooted_context_route
POST	/v1/electional/western/dorotheus-construction	dorotheus_construction_route
POST	/v1/electional/western/dorotheus-matter-profile	dorotheus_matter_profile_route
POST	/v1/electional/western/profile-windows	western_profile_windows_route
GET	/v1/locations/search	location_search_route
POST	/v1/locations/timezone/validate	timezone_validate_route
GET	/v1/website/chart-wheel/presets	chart_wheel_presets_route
POST	/v1/website/chart-wheel/validate	chart_wheel_validate_route
POST	/v1/website/chart-wheel/packet	chart_wheel_packet_route

Fixed-Star REST Admission Boundary

The admitted fixed-star REST surface is the bounded synchronous /v1/stars/position, /v1/stars/bulk, and /v1/stars/list family.

/v1/stars/position and /v1/stars/bulk return fixed-star longitude, latitude, magnitude, zodiac sign fields, and an explicit provenance object derived from the live FixedStar vessel truth/classification/relation fields. The provenance records the requested datetime, normalized UTC datetime, TT Julian Day, lookup/source/merge state, observer mode, relation basis, condition state, and transport stage sequence.

This admission does not expose heliacal event search, star condition networks, catalog-wide heavy sweeps, or rendered star maps. Explicit selected fixed-star Astrocartography is admitted under /v1/astrocartography/chart/subjects/*; catalog-wide fixed-star Astrocartography sweeps remain deferred.

Deep-Sky REST Admission Boundary

The admitted deep-sky REST surface is the bounded synchronous /v1/deep-sky/* family:

• GET /v1/deep-sky/list
• POST /v1/deep-sky/position
• POST /v1/deep-sky/bulk

The list route searches canonical names, designations, curated aliases, and SIMBAD main identifiers, with an optional released-class filter. Position and bulk routes return true-ecliptic-of-date directions plus the source frame, source epoch, catalog-center semantics, SIMBAD identity and coordinate receipt, catalog version, proper-motion decision, and transport stage sequence. The bulk route accepts at most 60 identities and can either report or reject names outside the released catalog.

The catalog contains 60 Moira-selected, non-Solar-System anchors. An extended object's coordinate is its sourced catalog center, not a point-mass or interpretive claim. Confirmed exoplanet hosts delegate runtime positions to Moira's sovereign star registry. Planetary satellites, asteroids, comets, and interstellar visitors are excluded because they require time-dependent ephemerides rather than frozen J2000 coordinates.

Variable-Star REST Admission Boundary

The admitted variable-star REST surface is the bounded synchronous /v1/stars/variable/* family:

• GET /v1/stars/variable/list
• GET /v1/stars/variable/{name}
• POST /v1/stars/variable/state
• POST /v1/stars/variable/range
• POST /v1/stars/variable/catalog-profile
• POST /v1/stars/variable/pair

Catalog responses include catalog-source provenance over the curated Variable Star Oracle. State, range, catalog-profile, and pair responses include computation provenance recording the Julian Day or datetime context, requested and returned stars, eclipse-threshold policy, phase convention, catalog sources, and stage sequence.

This admission does not expose real-time AAVSO/VSX observation refresh, exhaustive GCVS catalog search, rendered light curves, variable-star positional overlays, secondary-eclipse dedicated products, or multi-period semi-regular models beyond the current dominant-period engine.

Multiple-Star REST Admission Boundary

The admitted multiple-star REST surface is the bounded synchronous /v1/stars/multiple/* family:

• GET /v1/stars/multiple/list
• GET /v1/stars/multiple/{name}
• POST /v1/stars/multiple/state

Catalog and state responses include provenance derived from the Multiple Star Systems Oracle: catalog sources, system type, orbit model, orbital doctrine, Dawes-limit aperture policy, combined-magnitude doctrine, primary-orbit label, period uncertainty, requested aperture, computed Dawes limit, and stage sequence.

This admission does not expose catalog-wide state sweeps, rendered orbit diagrams, multi-aperture observing plans, arbitrary seeing policies, new catalog ingestion, or exhaustive WDS/INT4 exposure.

Asteroid REST Admission Boundary

The admitted asteroid REST surface is the bounded synchronous /v1/asteroids/* family:

• POST /v1/asteroids/position
• POST /v1/asteroids/bulk
• GET /v1/asteroids/list

Position and bulk responses include geocentric tropical ecliptic longitude, latitude, distance, speed, retrograde state, zodiac sign fields, and explicit provenance. The provenance records the requested datetime, normalized UTC datetime, UT Julian Day, requested and returned asteroid identity, returned NAIF ID, kernel source, known-catalog truth, loaded-kernel availability, NAIF convention, frame, and transport stage sequence.

The route family distinguishes a known asteroid identity in ASTEROID_NAIF from a body actually covered by the loaded small-body reader. is_sovereign is only asserted when the returned NAIF ID is present in reader.covered_bodies(); reader presence alone is not treated as asteroid coverage.

This admission does not expose asteroid families, centaur/TNO/main-belt subset routes, catalog-wide asteroid sweeps, topocentric positions, equatorial positions, asteroid photometry, rendered maps, kernel manifest management, or full small-body migration proof. Explicit selected-asteroid Astrocartography is admitted under /v1/astrocartography/chart/subjects/*; catalog-wide asteroid Astrocartography sweeps remain deferred.

Asteroid Subset And Family REST Admission Boundary

The admitted asteroid subset and family REST surface is the bounded synchronous P11-06 extension under /v1/asteroids/*:

• GET /v1/asteroids/subsets
• GET /v1/asteroids/subsets/{subset}/list
• POST /v1/asteroids/subsets/{subset}/positions
• GET /v1/asteroids/families/by-number/{number}
• GET /v1/asteroids/families/{family_name}/members
• POST /v1/asteroids/families/chart
• POST /v1/asteroids/families/chart/resonance-network

Subset routes expose curated Moira identity sets: classical, main_belt, centaurs, and tnos. Subset list responses include body names, NAIF IDs, loaded-kernel availability by returned NAIF ID, subset source module, catalog source, query/limit truth, and stage sequence. Subset position responses delegate to the admitted asteroid position transport and add subset provenance.

Family routes expose Nesvorny/PDS dynamical-family catalog membership. Lookup, member, and chart-grouping views use MPC catalog numbers and Nesvorny family names, not NAIF IDs. Responses record NASA_PDS_ast_nesvorny_families_v2_2015, MPC_catalog_number, moira.asteroid_families, and transport stage sequence.

The chart resonance-network route accepts either numbers as MPC catalog numbers or bodies as asteroid names / small-body NAIF IDs. It computes only the explicitly requested chart bodies, detects admitted ecliptic aspects, filters them through find_resonant_aspects(), groups them with resonance_network(), and returns resolved nodes, resonant edges, per-family network buckets, missing requested identities, and aspect policy provenance.

This admission preserves catalog labels exactly. Similar family labels such as Koronis, Koronis(2), and Karin remain distinct.

This admission does not expose family-wide position sweeps, rendered family maps, asteroid-family astrocartography, arbitrary family catalog search, photometry, topocentric/equatorial subset products, kernel manifest management, or edits to the bundled family catalog.

Comet REST Admission Boundary

The admitted comet REST surface is the bounded synchronous /v1/comets/* family:

• POST /v1/comets/position
• POST /v1/comets/bulk
• GET /v1/comets/list

Position and bulk responses include geocentric tropical ecliptic longitude, latitude, distance, speed, retrograde state, zodiac sign fields, and explicit provenance. The provenance records the requested datetime, normalized UTC datetime, UT Julian Day, requested comet identity, resolved engine comet name, returned comet identity, returned NAIF ID, kernel source, known-catalog truth, loaded-kernel availability, periodic-comet NAIF convention, frame, and transport stage sequence.

The route family distinguishes a known comet identity in COMET_NAIF from a body actually covered by the loaded small-body reader. REST requests may use known comet names or known comet NAIF IDs; numeric IDs are resolved to the engine comet name before comet_at(...) is called. is_sovereign is only asserted when the returned NAIF ID is present in reader.covered_bodies(); reader presence alone is not treated as comet coverage.

This admission does not expose non-periodic comet expansion, comet family or dynamical-class routes, catalog-wide comet sweeps, topocentric positions, equatorial positions, comet photometry, rendered maps, kernel manifest management, or full small-body migration proof. Explicit selected-comet Astrocartography is admitted under /v1/astrocartography/chart/subjects/*; catalog-wide comet Astrocartography sweeps remain deferred.

Manazil REST Admission Boundary

The admitted Arabic lunar mansion REST surface is the bounded synchronous /v1/manazil/* family:

• GET /v1/manazil/catalog
• POST /v1/manazil/position
• POST /v1/manazil/bulk
• GET /v1/manazil/traditions/{tradition}/mansions/{mansion_index}

Catalog responses expose the 28 equal Arabic lunar mansions, the 360 / 28 span, and admitted traditions. Position responses accept direct ecliptic longitude and explicit tropical or sidereal mode. Sidereal mode requires jd_ut and records ayanamsa system/mode in provenance. Bulk responses accept 1 to 500 named longitudes. Tradition lookup responses expose the selected nature/signification for one mansion in one admitted tradition.

The route family preserves Arabic Manazil doctrine separately from Vedic nakshatra doctrine. Variant traditions alter textual attribution only; they do not alter the 28 equal mansion boundaries.

This admission does not expose chart-backed Moon mansion routes, natal mansion profiles, electional scoring, mansion condition networks, heliacal/fixed-star mansion variants, Vedic nakshatra routes, or alternate non-equal mansion boundary systems.

Planetary And Small-Body Nodes REST Admission Boundary

The admitted node REST surface is the bounded synchronous /v1/nodes/* family:

• GET /v1/nodes/catalog
• POST /v1/nodes/planetary/mean
• POST /v1/nodes/planetary/mean/bulk
• POST /v1/nodes/geometric

Mean planetary routes expose kernel-free Meeus / Simon mean orbital element nodes and apsides for Mercury, Venus, Earth, Mars, Jupiter, Saturn, Uranus, and Neptune. Responses include ascending node, descending node, perihelion, aphelion, inclination, eccentricity, semi-major axis, method, JD scale, frame, kernel requirement, source module, validity note, and stage sequence.

The geometric route is an exact adapter over the strict orbital core with a Sun center and TRUE_ECLIPTIC_OF_DATE frame. It accepts planets, Pluto, and loaded sovereign asteroid/comet names when the active reader covers the exact epoch. The request JD is UT1, frame construction is TT, state evaluation is TDB, and the true-date model is admitted only for JD(TT) 2415020.0 through 2488070.0. The response includes canonical/NAIF body identity plus allowlisted time, Horizons gravity, SOFA-derived frame, source-route/hash/coverage, singularity, and undefined-element receipts. It exposes no local kernel path and does not imply availability or reviewed Horizons parity from catalog identity alone.

This admission does not expose lunar true/mean node REST routes, chart-backed node profiles, nodal aspect networks, a catalog-wide node endpoint, rendered node maps, other asteroid/comet route changes, or small-body kernel manifest management.

Orbital Elements REST Admission Boundary

The admitted P-GAP-03 and Stage 6 orbital REST surface is the bounded synchronous /v1/orbits/* family:

• POST /v1/orbits/elements
• POST /v1/orbits/distance-extremes
• POST /v1/orbits/class
• POST /v1/orbits/class/batch

/v1/orbits/elements exposes one epoch's heliocentric fixed-J2000-ecliptic osculating elements for an admitted major planet, asteroid, or comet. The request jd_ut is UT1; the state is evaluated at the bound TDB epoch and epoch_jd is TT. The time block returns all three numerical epochs, Delta T, TDB-minus-TT, source-owned Delta-T policy, and the pinned NAIF naif0012 conversion receipt.

The response preserves the existing element field names and adds path-free, allowlisted provenance for the JPL Horizons gravity policy, exact frame construction, every routed SPK source leg and closed coverage interval, and the conic singularity thresholds. For parabolic and hyperbolic trajectories ($e \ge 1.0$), the open-conic fields semi_major_axis_au, aphelion_distance_au, orbital_period_days, mean_anomaly_deg, and mean_motion_deg_per_day are nullable and return None. It identifies the strict engine entrypoint as osculating_elements, even though transport fixes the policy to center=SUN and frame=J2000_ECLIPTIC.

/v1/orbits/distance-extremes exposes the next heliocentric perihelion and aphelion events after jd_ut on the live heliocentric distance curve for planets and admitted small bodies. The response records that the events are semantic extrema, not a forced chronological pair and not merely algebra from one epoch's osculating ellipse. It adapts the versioned apsidal_passages engine with center=SUN and direction=NEXT. Its legacy perihelion_jd and aphelion_jd fields are TT; the request is UT1 and all sampled states and roots are TDB. If a passage outcome is not FOUND (e.g. open conics lacking an apocenter, or outside coverage window), an OrbitalPassageUnavailableError is mapped cleanly to HTTP 422 (orbital_event_availability).

The distance-extremes time block returns jd_ut, epoch_tt, epoch_tdb, Delta T, TDB-minus-TT, and the same source-owned Delta-T/pinned-NAIF conversion receipt as the elements route. Its allowlisted provenance contains both typed passage outcomes and the search algorithm, gravity policy, fixed route-plan identity, exact route entries and source legs, per-segment evaluation counts, seam-continuity measurements, search interval, fixed numerical policy, and total evaluation count. Local paths and arbitrary exception text are never serialized.

POST /v1/orbits/class and POST /v1/orbits/class/batch compute heliocentric osculating small-body orbit classifications according to official JPL Small-Body Database (SBDB) taxonomy definitions. Classifications include: IEO, ATE, APO, AMO, MCA, IMB, MBA, OMB, TJN, and fallback AST. The response provides:

• The assigned OrbitClassCode and its human-readable title and narrative definition.
• Diagnostic predicate boundary margins evaluating distance to qualifying cutoffs: perihelion distance ($q$), aphelion distance ($Q$), semi-major axis ($a$), and Jupiter orbit intersections ($T_J$).
• Complete provenance including the underlying osculating elements, time conversion, gravity policy, and SPK state-source legs. The batch variant POST /v1/orbits/class/batch accepts up to 128 targets evaluated at the same epoch, provides bounded error isolation per item with path redaction, and echoes the batch request parameters.

This admission does not expose the strict Python API's Moon or EMB heliocentric orbital queries; selectable centers/reference planes; circular/equatorial undefined fields; mean element tables; Uranian mean elements; visual-binary Campbell elements; apparent or light-time-corrected element products; dense ephemeris tables; or kernel-path mutation. Those require a separately versioned transport design.

Generic Phenomena And Solar Conditions REST Admission Boundary

The admitted P-GAP-04 REST surface is the bounded synchronous generic phenomena and solar-condition surface:

• POST /v1/phenomena/planet
• POST /v1/phenomena/orbital-events
• POST /v1/phenomena/proximity
• POST /v1/solar-condition/instant
• POST /v1/solar-condition/events

/v1/phenomena/planet exposes one instant's physical/photometric state for an admitted body: phase angle, illuminated fraction, elongation, angular diameter, and apparent magnitude.

/v1/phenomena/orbital-events exposes a bounded event search over admitted event kinds: greatest eastern/western elongation for Mercury and Venus, and perihelion/aphelion for admitted major bodies. Event responses label both the event kind and the value unit.

/v1/phenomena/proximity exposes angular threshold ingress/egress crossings for an admitted body pair. The response preserves the caller threshold, signed event threshold, event direction, longitudes, latitude, retrograde state, and event label.

/v1/solar-condition/instant exposes classical solar-condition truth at one instant. Sun and Moon inputs are accepted and return absent truth, matching engine behavior. /v1/solar-condition/events exposes bounded cazimi, combust, and under-sunbeams threshold crossings for admitted non-luminary major bodies.

This admission does not expose a catch-all /v1/events route, arbitrary phenomenon predicates, aspect searches, station/lunar-phase/rise-set/ heliacal/eclipse/occultation replacements, dense event tables, small-body proximity sweeps, interpretation text, recommendations, or kernel path mutation.

Uranian REST Admission Boundary

The admitted Uranian / Hamburg School REST surface is the bounded synchronous P12-01 /v1/uranian/* family:

• GET /v1/uranian/catalog
• POST /v1/uranian/position
• POST /v1/uranian/bulk

Catalog responses expose the current nine-name table from moira.uranian, including Transpluto. Position and bulk responses expose apparent geocentric true-ecliptic-of-date longitude and latitude, distance in AU, signed longitude speed, retrograde and sign fields, body group, source family, and body_kind = "hypothetical_body". Provenance identifies the fixed Keplerian source-orbit model, per-body source epoch, and DE-kernel use for Earth/Sun observer geometry only. Catalog metadata does not open a kernel; computed positions use the startup-bound engine reader.

This admission does not expose Uranian midpoint trees, dial products, cosmobiology networks, chart interpretation, physical body substitution, physical TNO computation, or any claim that these hypothetical orbits are JPL/NAIF physical-body states.

Harmonics REST Admission Boundary

The admitted Harmonics REST surface is the bounded P12-02 /v1/harmonics/* family:

• GET /v1/harmonics/presets
• POST /v1/harmonics/chart
• POST /v1/harmonics/age-chart
• POST /v1/harmonics/conjunctions
• POST /v1/harmonics/pattern-score
• POST /v1/harmonics/aspects
• POST /v1/harmonics/sweep
• POST /v1/harmonics/fingerprint
• POST /v1/harmonics/cross-chart-conjunctions
• POST /v1/harmonics/composite (deprecated alias of cross-chart-conjunctions)
• POST /v1/harmonics/transit-forecast

These routes accept caller-supplied named ecliptic longitude maps. Longitude scalars and orb values must be JSON numbers; booleans and numeric strings are rejected rather than coerced. They do not construct charts, derive ephemeris positions, use houses, apply ayanamsa, or generate transit samples. Direct chart, conjunction, pattern-score, and composite requests admit positive finite real harmonic values in the REST range 1..128; 5.5 remains 5.5 and is not truncated to 5. Integer values are ordinary cyclic harmonics. Non-integer values are explicit zero-Aries-anchored continuous multipliers computed from each input's canonical [0, 360) representative. Responses preserve the requested/effective value, input count, sorted positions, the conventional aspect name for an integer preset when known (preset_description is null in computed payloads since 6.9.9; the editorial keyword glosses appear only in /presets, labelled as unsourced), and provenance identifying moira.harmonics, the engine entrypoint, caller-owned longitudes, and (normalized_longitude * harmonic) mod 360.

Age-harmonic responses preserve the derived decimal harmonic, jd_birth, jd_now, and the basis (jd_now - jd_birth) / tropical_year. Age harmonic is not the transport adapter for an arbitrary fractional harmonic request.

Pattern-analysis routes expose one-harmonic conjunctions, one-harmonic pattern scores, harmonic aspect decoding, bounded sweeps, bounded vibrational fingerprints, and bounded cross-chart harmonic comparison. The cross-chart route projects each natal chart onto harmonic H separately and compares chart A bodies with chart B bodies; it does not build a composite chart (the older /composite path and the composite_harmonic entrypoint name are historical). Sweep and fingerprint provenance explicitly labels scores as pattern-density measures rather than interpretive judgments. Aspects, sweeps, and fingerprints retain integer harmonic ranges.

Conjunction-bearing requests retain the compatibility orb field as the configurable H1-reference and projected-chart threshold. Optional orb_policy={"scaling_mode":"addey_inverse_harmonic"} makes the admitted policy selection explicit. Provenance reports the projected limit O_1, its locally equivalent source-circle allowance O_1/H, authority, formula, adapter mode, and the continuous-extension flag. Clients must not divide the projected threshold by H again. Since 6.9.9 the default orb is 12 degrees on the harmonic wheel (12/H on the natal circle), the conjunction orb David Hamblin works his divide-by-H rule with ("The Importance of Harmonics", Astrodienst); it was previously 1 degree. transit-forecast keeps its 1 degree default.

POST /v1/harmonics/transit-forecast evaluates only caller-supplied, strictly time-ordered samples at explicitly requested integer harmonics. It admits complete triples in either one_transit_two_natal or two_transits_one_natal mode when all three projected positions fit within one minimum circular covering arc no wider than the resolved projected orb. It returns consecutive observed windows whose first, peak, and last times are supplied sample witnesses. It performs no interpolation and makes no exact ingress, perfection, egress, or Sirius-parity claim. Forecast transport is bounded to 12 bodies per origin, 512 samples, 16 requested harmonics, and 25,000 candidate evaluations. Timestamp sequences must also have finite adjacent gaps and a finite total span.

This admission does not expose unbounded harmonic sweeps, automatic chart construction, ephemeris sampling, fractional-H forecasting, progression harmonic search, interpolated or exact transit-event solving, harmogram/spectral-analysis products, chart rendering, or interpretive narrative text.

Harmograms REST Admission Boundary

The admitted P-GAP-06 Harmograms REST surface is the bounded /v1/harmograms/* family:

• POST /v1/harmograms/vector
• POST /v1/harmograms/zero-aries-vector
• POST /v1/harmograms/intensity-spectrum
• POST /v1/harmograms/projection
• POST /v1/harmograms/trace

These routes accept caller-supplied named ecliptic longitudes and caller-supplied explicit trace samples. They expose moira.harmograms point-set vectors, Zero-Aries-parts vectors, intensity spectra, projections, and trace series without constructing charts or generating ephemeris samples.

The transport boundary is deliberately bounded: position counts, harmonic domain width, intensity sample count, trace sample count, and trace cell count are all capped by moira_server.models.harmograms. Trace responses preserve series intensity spectra, source vectors, projection terms, and strengths, but do not add judgement language.

This admission does not expose chart-backed harmogram generation, dynamic ephemeris sampling, arbitrary intensity functions, unbounded sweeps, dense rendering meshes, async jobs, harmonic interpretation, recommendation text, or replacement of /v1/harmonics/*.

Phase And Photometry REST Admission Boundary

The admitted Phase / Elongation / Magnitude REST surface is the bounded P12-03 /v1/phase/* family:

• POST /v1/phase/illuminated-fraction
• POST /v1/phase/synodic
• POST /v1/phase/elongation
• POST /v1/phase/angle
• POST /v1/phase/angular-diameter
• POST /v1/phase/apparent-magnitude

/v1/phase/illuminated-fraction is pure scalar mathematics over a supplied phase angle and does not require a kernel. Synodic phase, elongation, phase-angle, angular-diameter, and apparent-magnitude routes are direct one-epoch products over engine-supported bodies and preserve product-specific basis and kernel requirement truth in provenance.

Angular diameter is admitted only for the engine radius-table support set: Sun, Moon, Mercury, Venus, Mars, Jupiter, Saturn, Uranus, Neptune, and Pluto. Apparent V magnitude is admitted only for Moon, Mercury, Venus, Mars, Jupiter, Saturn, Uranus, Neptune, with model-family provenance for Schaefer 1993 lunar phase law or Mallama/Hilton 2018 planetary magnitude models. Sun, Pluto, dwarf planets, asteroids, comets, fixed stars, and variable stars remain excluded from this apparent-magnitude route.

This admission does not expose topocentric phase or magnitude, atmospheric extinction, visual limiting magnitude, visibility scoring, heliacal visibility, eclipse darkening, moon-phase or conjunction event searches, minor-body photometry, fixed-star or variable-star photometry, interpretive astrological phase text, or sky rendering.

Antiscia REST Admission Boundary

The admitted ordinary Antiscia REST surface is the bounded P12-04 /v1/antiscia/* family:

• POST /v1/antiscia/reflect
• POST /v1/antiscia/contacts
• POST /v1/antiscia/to-point

/v1/antiscia/reflect computes direct antiscion and/or contra-antiscion reflections of a caller-supplied finite longitude. Contact routes accept caller-supplied named longitude maps only; they do not construct charts, derive ephemeris positions, use houses, or compute chart motion.

Responses preserve the engine labels Antiscion and Contra-Antiscion, the body1 body whose reflected point forms a contact, the reflected shadow, explicit orb, and increasing-orb ordering. Provenance records moira.antiscia, ordinary_antiscia, the two reflection formulae, not_primary_direction_antiscia, no chart motion, and no ephemeris use.

This admission does not expose primary-direction antiscia, directed arcs, transits, progressions, chart construction, house derivation, antiscia networks, scoring profiles, or interpretive narrative text.

Draconic REST Admission Boundary

The admitted draconic REST surface is the bounded /v1/draconic/* family:

• POST /v1/draconic/longitude
• POST /v1/draconic/positions
• POST /v1/draconic/chart

/v1/draconic/longitude rotates one caller-supplied finite longitude by a caller-supplied anchor longitude under the fixed doctrine formula normalize_degrees(source_longitude - anchor_longitude). It claims no node policy and uses no ephemeris.

/v1/draconic/positions materializes a full draconic chart vessel from a caller-supplied named longitude map, an explicit node_mode (mean or true), and a caller-supplied anchor longitude. The caller owns the anchor truth; the route does not construct charts or derive node positions.

/v1/draconic/chart builds an engine tropical chart for a timezone-aware datetime (with optional bodies and topocentric observer), extracts the North Node selected by node_mode as the anchor, and rotates all chart longitudes into the draconic frame. The source chart is always built node-bearing so the anchor exists; the request include_nodes flag governs only whether node points appear among the transformed output positions.

Responses preserve the engine vessel truth: the anchor block (node_mode, node_name, longitude, rotation_degrees, source, source_zodiac, formula), per-body source and draconic longitudes with sign decomposition, frame (draconic), source_zodiac (tropical), interpretation_scope (longitude_frame_transform_only), and anchor_residual (distance of the included anchor node from 0 Aries, null when the node is not among the output positions). Provenance records moira.draconic, the engine entrypoint, the rotation doctrine and formula, anchor ownership, chart construction ownership, and ephemeris use.

This admission does not expose draconic houses, draconic-to-tropical synastry or contact searches, sidereal source zodiacs, South Node or arbitrary-point anchors, node event searches, or interpretive narrative text.

Nine Parts REST Admission Boundary

The admitted Abu Ma'shar Nine Parts REST surface is the bounded P12-05 /v1/nine-parts/* family:

• POST /v1/nine-parts/abu-mashar

This route accepts a caller-supplied Ascendant longitude, required planetary longitudes, and caller-supplied is_night_chart truth. It does not construct a chart, derive the Ascendant, determine sect, compute houses, or infer night status.

The response preserves the complete NinePartsAggregate shape: nine parts in canonical Abu Ma'shar order, computation truth for each part, dependency relations, condition profiles, aggregate summaries, effective policy, validation results from validate_nine_parts_output, and provenance. Sword and Node remain admitted_extension records with planet_association: null; they are not collapsed into ordinary planetary lots.

Only the full_reversal reversal rule and evidenced_core_plus_admitted_extension historical scope are admitted. This admission does not expose solar-return integration, Al-Sijzi Transfer of Management, longevity integration, comparison bundles against moira.lots, Hellenistic nonomoiria, Vedic Navamsha or D9 routes, or interpretive narrative text.

Planetary Hours REST Admission Boundary

The admitted Planetary Hours REST surface is the bounded P12-06 /v1/planetary-hours/* family:

• POST /v1/planetary-hours/schedule
• POST /v1/planetary-hours/hour-at

These routes accept a caller-supplied Julian Day UT and numeric geographic latitude/longitude. They do not perform timezone lookup, location-name lookup, geocoding, chart construction, or civil-day calendar expansion.

Responses preserve the dedicated moira.planetary_hours.PlanetaryHour vessel fields: hour_number, ruler, jd_start, jd_end, and is_daytime. Provenance explicitly distinguishes this vessel from moira.cycles.PlanetaryHour, records the Chaldean-order and weekday-rulership basis, records reader policy, and states that ISO timestamps, when included, are UTC output only.

The route family surfaces sunrise/sunset resolution failure as a visible validation error. It does not invent sunrise or sunset values, does not use a fixed six-to-six fallback, and does not replace the sunrise-based doctrine with civil-clock approximation.

This admission does not expose moira.cycles planetary-day profiles, electional scoring, recommendation text, annual time-lord techniques, Lord of the Orb calculation, or automatic birth planetary-hour derivation for other lordship systems.

Huber REST Admission Boundary

The admitted Huber REST surface is the direct-cusp P12-07 /v1/huber/* family:

• POST /v1/huber/dynamic-intensity
• POST /v1/huber/house-zones
• POST /v1/huber/age-point
• POST /v1/huber/intensity-at
• POST /v1/huber/chart-intensity-profile
• POST /v1/huber/age-point-contacts

These routes expose moira.huber computations over caller-supplied house frames. The Huber transport layer does not calculate houses, construct charts, derive locations, derive timezones, or substitute house systems. Direct house frames require exactly 12 finite cusp longitudes plus caller-supplied Ascendant, MC, and ARMC anchors required to construct Moira's HouseCusps vessel.

Responses record house_frame_source: caller_supplied, cusp_derivation_owner: caller_supplied, requested/effective house-system truth, fallback truth, whether the effective frame is Koch, and the Huber doctrine preference for Koch houses. Non-Koch direct frames are accepted as computational inputs but are reported as not doctrinally complete Huber house fidelity.

The route family preserves the Dynamic Intensity Curve basis as piecewise_half_cosine_reconstruction and keeps the limitation that the primary-text exact formula has not been independently verified. Age Point contact scans are bounded by maximum point count, maximum age span, minimum step size, and maximum orb.

This admission does not expose chart-backed Huber house derivation, independent house calculation inside Huber transport, psychological interpretation text, counseling, health or clinical claims, chart rendering, unbounded Age Point searches, transit/progression timing outside Age Point mechanics, or generic /v1/special/* computation.

Sothic REST Admission Boundary

The admitted Sothic surface is:

• POST /v1/sothic/egyptian-date
• POST /v1/sothic/predict-epoch
• POST /v1/sothic/rising

egyptian-date exposes the fixed 365-day Egyptian civil calendar with an explicit anchor. The default Censorinus anchor is JD 1772027.5, Julian 0139-07-20, and proleptic Gregorian 0139-07-19; it is a primary-text calendar relation, not a precise observed Sirius timestamp. A caller-supplied epoch is labelled separately.

predict-epoch returns fixed-interval arithmetic in astronomical year numbering. The default is labelled schematic_1460_julian_year and schematic_projection; it does not confirm a historical observation.

rising accepts 1 through 200 astronomical years, observer coordinates, an optional calendar anchor, and an arcus visionis restricted to the published IMCCE Sirius-calculator domain of 6 through 12 degrees. It returns exactly one ordered outcome per requested year: found or not_found_within_window. Each outcome preserves the delegated moira.stars.heliacal_rising_event truth. Catalog, kernel, coverage, and internal failures remain failures and are never serialized as empty success.

This admission does not expose unbounded scans, Sothic epoch searches, drift routes, condition or network projections, alternate Egyptian calendars, historical interpretation, or a second heliacal visibility model.

Lord Of The Orb REST Admission Boundary

The admitted Lord of the Orb REST surface is the bounded P12-10 /v1/lord-of-the-orb/* family:

• POST /v1/lord-of-the-orb/sequence
• POST /v1/lord-of-the-orb/current

These routes expose moira.lord_of_the_orb over a caller-supplied birth_planet, understood as the ruler of the birth planetary hour. The transport layer does not calculate planetary hours, does not construct charts, does not derive the birth-hour ruler, and does not orchestrate Abu Ma'shar's full annual hierarchy.

Sequence responses preserve ordered period records, condition profiles, aggregate benefic/malefic and planet-count summaries, effective cycle policy, validation output, and provenance. Current-period responses map completed age to year of life (age 0 is year 1) and return the active period plus its condition profile.

The admitted cycle variants are continuous_loop and single_cycle. Sequence requests are bounded to at most 252 years, and current-period requests are bounded to ages 0 through 251. Provenance records the caller-supplied birth planet source, the fact that planetary-hour derivation is not owned by this route, Chaldean-order cycle basis, twelve-house modular cycle basis, hierarchy rank 6, and the distinction from moira.lord_of_the_turn.

This admission does not expose birth planetary-hour derivation, chart construction, annual hierarchy orchestration, profections or firdaria integration, natal or solar-return dignity scoring, comparison bundles, interpretive narrative text, or generic /v1/special/* computation.

Lord Of The Turn REST Admission Boundary

The admitted Lord of the Turn REST surface is the bounded P12-11 /v1/lord-of-the-turn/* family:

• POST /v1/lord-of-the-turn/profile

This route exposes moira.lord_of_the_turn.lord_of_turn over caller-supplied Solar Return chart data. It accepts natal Ascendant longitude, completed age, method policy, combust-orb policy, and an SR chart vessel containing SR Ascendant, classical planet longitudes, optional house placements, caller-supplied sect flag, optional retrograde planet list, and optional SR Lot of Fortune longitude.

Responses preserve the integrated condition profile, selected result, profection truth, candidate assessments, method policy, validation output, and provenance. Candidate assessments expose candidate role, SR house, combustion state, retrograde state, blocker reasons, witnessing truth, and binary testimony count. Provenance explicitly records that Solar Return construction, house calculation, ephemeris derivation, automatic sect calculation, and annual hierarchy orchestration are not owned by this route.

The admitted method variants are al_qabisi and egyptian_al_sijzi. Transport provenance preserves Al-Qabisi sequential succession as sequential_succession_no_simultaneous_tiebreak and Egyptian/Al-Sijzi testimony as binary_dignity_type_count_not_weighted_almuten. When house placements are omitted, the response exposes the engine's DOMICILE_ONLY mode rather than implying a full SR condition assessment.

This admission does not expose Solar Return chart construction, house calculation, ephemeris derivation, automatic sect calculation, automatic SR Lot of Fortune calculation, annual hierarchy orchestration, combined annual timing dashboards, interpretive narrative text, or generic /v1/special/* computation.

Electional REST Admission Boundary

The admitted Phase 13 electional REST surface has two deliberately separate products: the bounded generic search subset and one source-owned Western single-moment profile.

The bounded generic search subset is:

• GET /v1/electional/predicate-profiles
• GET /v1/electional/scorer-profiles
• POST /v1/electional/windows
• POST /v1/electional/moments
• POST /v1/electional/scored

/v1/electional/predicate-profiles exposes the server-defined predicate catalogue admitted for REST use. /v1/electional/windows calls moira.electional.find_electional_windows through that catalogue and returns merged scan-witness windows over discrete chart snapshots. /v1/electional/moments calls moira.electional.find_electional_moments through the same catalogue and returns raw qualifying scan-point JDs. /v1/electional/scorer-profiles exposes the server-defined numeric scorer catalogue admitted for REST use. /v1/electional/scored calls moira.electional.find_scored_windows through the admitted predicate and scorer catalogues and returns scored merged windows.

The admitted predicate profiles are:

• body_longitude_range_v1
• body_house_membership_v1
• body_angular_separation_range_v1

The admitted scorer profiles are:

• body_longitude_target_closeness_v1
• body_angular_separation_target_closeness_v1

Responses preserve predicate, policy, scan, validation, bounds, and provenance truth. Window responses preserve merged scan-witness windows. Moment responses preserve raw qualifying scan points. Scored responses preserve the declared scorer profile, finite [0.0, 1.0] numeric-fit scores, returned-window score_rank, and peak_jd as the highest-scored qualifying scan point inside the returned window. Provenance states that these are discrete sampled chart states; these routes do not claim continuous truth, exact event-boundary solving, or exact score-peak solving.

The generic-search REST bounds are intentionally narrow: maximum 31-day search span, 15-minute minimum cadence, maximum 1000 computed scan points, maximum 64 returned windows, maximum 1000 returned raw moments, maximum 12 requested bodies, and at most 8 optional boundary refinement steps for the window route. Boundary refinement, when requested for windows, is bracket evidence, not exact root truth. The raw-moment route requires boundary_refine_steps to be 0 and disables window-count early exit so raw scan points are not truncated by the window grouping helper. For scored windows, max_windows remains chronological early exit; score ranks are over the returned windows only and are not a global optimum claim.

The separately admitted Western doctrine routes are:

• POST /v1/electional/western/lunar-ecliptic-direction
• POST /v1/electional/western/ramesey-moon-condition
• POST /v1/electional/western/sahl-moon-condition
• POST /v1/electional/western/sahl-matter-profile
• POST /v1/electional/western/classical-perfection
• POST /v1/electional/western/dorotheus-moon-condition
• POST /v1/electional/western/dorotheus-rooted-context
• POST /v1/electional/western/dorotheus-construction
• POST /v1/electional/western/dorotheus-matter-profile
• POST /v1/electional/western/profile-windows

The classical-perfection route is a bounded, kernel-backed event analysis under the fixed lilly_1647_perfection_v1 profile. Requests select two distinct traditional planets, a strict day/night boolean, and an increasing UT1 Julian-day interval no longer than 31 days. The profile id is an exact literal; arbitrary bodies, generic lineage names, scoring fields, and advice fields are rejected.

The response preserves initial longitudes and speeds for all seven traditional planets, a deterministic chronological trace of exact Ptolemaic aspects, stations, and sign ingresses, and separate witnesses for direct perfection, translation, collection, prohibition, refranation, and frustration. Each witness exposes its actors, supporting event ids, reception bases, source page, and present, absent, or indeterminate state. Transport provenance names lilly_perfection_at, Moira.lilly_perfection_at, and the exclusions of Sahl, Bonatti, and reflection. The response always declares that it supplies no score, advice, or complete electional judgement. Its policy vessel also names UT1 input/internal TT conversion, apparent geocentric true-ecliptic-of-date longitude, astrometric geocentric longitude rate, canonical Lilly moieties, Egyptian bounds, and sect-active Dorothean triplicity.

The lunar-ecliptic-direction route is a neutral astronomical product rather than a historical doctrine verdict. It accepts one finite jd_ut and returns the Moon's apparent geocentric ecliptic latitude and latitude rate, independent hemisphere and motion classifications, previous/next/nearest exact sign-changing node crossings, their UT1 times and directions, numerical policy, frame, timescale, and an explicit no-doctrinal-region scope.

The single-moment routes accept one finite jd_ut, latitude, longitude, an explicit known house-system code, the fixed profile id for the selected route, and an optional strict boolean unavoidable_time_urgency context where the selected profile admits it. They delegate through the corresponding Moira facade method and return typed source-ordered evaluations: clause and measurement witnesses, triggered and not-evaluable rule identities, the separate non-erasing remedy witness, requested/effective house-system truth, fallback status, reader provenance, and the profile's non-complete-judgement language.

The Sahl matter route requires one exact admitted profile id from the source-specific building, land, planting, sowing, lending, investment, purchase, sale, or business-partnership families. This includes the independent sahl_business_partnership_v1 profile for §§32–35; it is not a Dorothean partnership alias. The route also requires the explicit Sahl burnt-path variant used by its nested general Moon layer. The response contains that complete Moon layer plus every matter clause, role, state, measurement, policy id, citation, triggered gate, unresolved clause, and numerical-completeness flag. It provides no score, ranking, advice, recommendation, or generic house-topic judgement.

The Ramesey remedy witness exposes urgent applicability and tri-state fulfillment separately. Its typed clauses preserve Moon cadence/Ascendant relation, Jupiter/Venus placement or good aspect, Ascendant-cusp fortification, Ascendant-lord fortification, and planetary-hour-lord fortification. Unresolved fortification predicates remain indeterminate and never clear a triggered impediment.

The construction response carries all inherited V.2-V.6 and V.31 layers plus the six V.7 clauses. Its increasing-in-calculation witness exposes the true and IERS 2010 mean lunar longitudes, signed equation, and added/subtracted direction. Its nested rooted context exposes evaluated V.31 bad-place booleans for whole-sign places 3, 6, 8, and 12, plus source-ordered under-rays, made-unfortunate, Ascendant-relation, and bad-place testimonies. The rooted context also exposes distinct V.6.29 ninth-part, Lot-of-Fortune-lord, and next connection indicators; they are not interchangeable outcome-ruler choices. The ecliptic-crossing clause remains not_evaluable because the primary text supplies no crossing region or tolerance. The profile-window route is a bounded discrete scan of explicitly selected statuses, not an exact-transition solver.

The matter-profile route admits the named Dorothean Book V ids from V.8–V.11, V.20–V.22, V.24–V.26, V.43, and V.44: this includes dorotheus_ship_construction_v1, dorotheus_ship_launch_v1, dorotheus_land_travel_v1, dorotheus_sea_travel_v1, dorotheus_partnership_v1, dorotheus_debt_and_payment_v1, and dorotheus_writing_a_will_v1 in addition to the earlier profiles. It exposes source-ordered clauses, named whole-sign angular topics, applicable planetary-strength witnesses, inherited Moon conditions, and an explicit policy vessel. Rooted context is present only where the cited source lawfully supplies it: V.20 partnership and V.21 debt/payment retain their Mercurial root, while V.22, V.24, V.25, V.26, and V.43 return rooted_context: null. V.26 alone accepts a complete radical chart for its named Saturn overlay. Land and sea travel requests require sign_nature_variant. The source_text_unresolved_no_dry_sign_table choice keeps Dorotheus's unenumerated dry-sign class explicit and indeterminate; the separately attributed lilly_1647_elemental_qualities choice applies Lilly 1647's named table. The sea water-sign gate remains Dorotheus-owned. Every remaining source-open sign class, connection interval, compound predicate, and ambiguous passage remains not_evaluable; no route returns a score or recommendation.

The Phase 8 judgement, Phase 9 ranking, and Phase 10 judgement-window routes accept the same policy as dorotheus_sign_nature_variant for these two matter profiles and return it in each judgement selection. It is required for land or sea travel and rejected for every other matter profile, so no authority choice is hidden or silently discarded.

Leasing additionally requires moon_flow_policy, selecting either the current-sign or a bounded fixed-lookback previous-event interval, and the response embeds the resulting moon_connection_flow. Leasing remains numerically_complete: false: the event geometry is now complete, but V.9's surviving text does not assign separation and connection to its four leasing stakes. No profile produces a score or recommendation.

Each single-moment transport names its route semantics, engine and facade entry points, and reports scoring: not_provided, generic_search_integration: not_admitted, recommendation_language: not_provided, and remedy_fulfillment_assessment: tri_state_non_erasing for Ramesey. None of these routes is a generic predicate adapter, and none ranks or recommends a time.

These admissions do not expose arbitrary executable predicates or scorers, generic numeric Western scoring, additional lineage profiles, auspicious/inauspicious labels, recommendation text, unbounded scans, async search jobs, or electional advice language.

Catalog Umbrella Boundary

There is no admitted /v1/catalogs/* route family.

The P11-U1 doctrine decision keeps a future catalog umbrella deferred and restricts any later candidate to discovery-only registry metadata. It may point clients to admitted family-native route prefixes and doctrine documents, but it must not return catalog member records, perform cross-family search, compute positions, expose loaded-kernel coverage lists, join catalog identities, or run catalog-wide sweeps.

Generated Registered Route Inventory

This exact-path inventory is generated from the current FastAPI OpenAPI registry. Narrative sections above explain admission boundaries; this table is the completeness check for registered transport paths.

Method	Path	Tags	Operation ID
GET	/health	meta	health_health_get
GET	/meta/kernel	meta	kernel_meta_meta_kernel_get
GET	/meta/version	meta	version_meta_version_get
GET	/ready	meta	ready_ready_get
POST	/v1/almuten/degree	almuten	almuten_of_degree_route_v1_almuten_degree_post
POST	/v1/almuten/figuris	almuten	almuten_figuris_route_v1_almuten_figuris_post
POST	/v1/antiscia/contacts	antiscia	antiscia_contacts_route_v1_antiscia_contacts_post
POST	/v1/antiscia/reflect	antiscia	antiscia_reflect_route_v1_antiscia_reflect_post
POST	/v1/antiscia/to-point	antiscia	antiscia_to_point_route_v1_antiscia_to_point_post
POST	/v1/ashtakavarga/chart/profile	ashtakavarga	ashtakavarga_chart_profile_route_v1_ashtakavarga_chart_profile_post
POST	/v1/ashtakavarga/chart/result	ashtakavarga	ashtakavarga_chart_result_route_v1_ashtakavarga_chart_result_post
POST	/v1/ashtakavarga/chart/sign-profile	ashtakavarga	ashtakavarga_chart_sign_profile_route_v1_ashtakavarga_chart_sign_profile_post
POST	/v1/ashtakavarga/chart/transit-strength	ashtakavarga	ashtakavarga_chart_transit_strength_route_v1_ashtakavarga_chart_transit_strength_post
POST	/v1/ashtakavarga/kakshya-transit	ashtakavarga	kakshya_transit_route_v1_ashtakavarga_kakshya_transit_post
POST	/v1/ashtakavarga/profile	ashtakavarga	ashtakavarga_profile_route_v1_ashtakavarga_profile_post
POST	/v1/ashtakavarga/result	ashtakavarga	ashtakavarga_result_route_v1_ashtakavarga_result_post
POST	/v1/ashtakavarga/shodhya-pinda	ashtakavarga	shodhya_pinda_route_v1_ashtakavarga_shodhya_pinda_post
POST	/v1/ashtakavarga/sign-profile	ashtakavarga	ashtakavarga_sign_profile_route_v1_ashtakavarga_sign_profile_post
POST	/v1/ashtakavarga/transit-strength	ashtakavarga	ashtakavarga_transit_strength_route_v1_ashtakavarga_transit_strength_post
POST	/v1/aspects/declination-motion-witness	relationship	declination_aspect_motion_witness_route_v1_aspects_declination_motion_witness_post
POST	/v1/aspects/from-declinations	relationship	declination_aspects_from_declinations_route_v1_aspects_from_declinations_post
POST	/v1/aspects/from-longitudes	relationship	aspects_from_longitudes_route_v1_aspects_from_longitudes_post
POST	/v1/aspects/hellenistic/overcoming	hellenistic-aspects	overcoming_route_v1_aspects_hellenistic_overcoming_post
POST	/v1/aspects/hellenistic/whole-sign	hellenistic-aspects	whole_sign_aspects_route_v1_aspects_hellenistic_whole_sign_post
POST	/v1/aspects/moon-connection-flow	relationship	moon_connection_flow_route_v1_aspects_moon_connection_flow_post
POST	/v1/aspects/motion-witness	relationship	aspect_motion_witness_route_v1_aspects_motion_witness_post
POST	/v1/asteroids/bulk	asteroids (fast small-body)	asteroids_bulk_v1_asteroids_bulk_post
GET	/v1/asteroids/families/by-number/{number}	asteroids (fast small-body)	asteroid_family_by_number_v1_asteroids_families_by_number__number__get
POST	/v1/asteroids/families/chart	asteroids (fast small-body)	asteroid_families_in_chart_v1_asteroids_families_chart_post
POST	/v1/asteroids/families/chart/resonance-network	asteroids (fast small-body)	asteroid_family_resonance_network_v1_asteroids_families_chart_resonance_network_post
GET	/v1/asteroids/families/{family_name}/members	asteroids (fast small-body)	asteroid_family_members_v1_asteroids_families__family_name__members_get
GET	/v1/asteroids/list	asteroids (fast small-body)	list_asteroids_v1_asteroids_list_get
POST	/v1/asteroids/position	asteroids (fast small-body)	asteroid_position_v1_asteroids_position_post
GET	/v1/asteroids/subsets	asteroids (fast small-body)	asteroid_subsets_v1_asteroids_subsets_get
GET	/v1/asteroids/subsets/{subset}/list	asteroids (fast small-body)	asteroid_subset_list_v1_asteroids_subsets__subset__list_get
POST	/v1/asteroids/subsets/{subset}/positions	asteroids (fast small-body)	asteroid_subset_positions_v1_asteroids_subsets__subset__positions_post
POST	/v1/astrocartography/chart/lines	astrocartography	astrocartography_chart_lines_route_v1_astrocartography_chart_lines_post
POST	/v1/astrocartography/chart/subjects/lines	astrocartography	astrocartography_subject_chart_lines_route_v1_astrocartography_chart_subjects_lines_post
POST	/v1/astrocartography/chart/subjects/subplanetary	astrocartography	astrocartography_subject_chart_subplanetary_route_v1_astrocartography_chart_subjects_subplanetary_post
POST	/v1/astrocartography/chart/subplanetary	astrocartography	astrocartography_chart_subplanetary_route_v1_astrocartography_chart_subplanetary_post
POST	/v1/astrocartography/dynamic/transits	astrocartography	dynamic_astrocartography_route_v1_astrocartography_dynamic_transits_post
POST	/v1/astrocartography/fixed-stars	astrocartography	fixed_star_astrocartography_route_v1_astrocartography_fixed_stars_post
POST	/v1/astrocartography/lines	astrocartography	astrocartography_lines_route_v1_astrocartography_lines_post
POST	/v1/astrocartography/subplanetary	astrocartography	astrocartography_subplanetary_route_v1_astrocartography_subplanetary_post
POST	/v1/astrodynes/chart	astrodynes	astrodynes_chart_route_v1_astrodynes_chart_post
GET	/v1/astrodynes/doctrine	astrodynes	astrodynes_doctrine_route_v1_astrodynes_doctrine_get
POST	/v1/astrodynes/geometry	astrodynes	astrodynes_geometry_route_v1_astrodynes_geometry_post
POST	/v1/astrodynes/progressed/accessory-relation	astrodynes	progressed_astrodynes_accessory_relation_route_v1_astrodynes_progressed_accessory_relation_post
POST	/v1/astrodynes/progressed/chart	astrodynes	progressed_astrodynes_chart_backed_route_v1_astrodynes_progressed_chart_post
POST	/v1/astrodynes/progressed/compound-total-influence	astrodynes	progressed_astrodynes_compound_total_influence_route_v1_astrodynes_progressed_compound_total_influence_post
POST	/v1/astrodynes/progressed/dated-aspect	astrodynes	progressed_astrodynes_dated_aspect_route_v1_astrodynes_progressed_dated_aspect_post
GET	/v1/astrodynes/progressed/doctrine	astrodynes	progressed_astrodynes_doctrine_route_v1_astrodynes_progressed_doctrine_get
POST	/v1/astrodynes/progressed/integrate	astrodynes	progressed_astrodynes_integrate_route_v1_astrodynes_progressed_integrate_post
POST	/v1/astrodynes/progressed/major-relation	astrodynes	progressed_astrodynes_major_relation_route_v1_astrodynes_progressed_major_relation_post
POST	/v1/astrodynes/progressed/normal	astrodynes	progressed_astrodynes_normal_route_v1_astrodynes_progressed_normal_post
POST	/v1/astrodynes/progressed/practical	astrodynes	progressed_astrodynes_practical_route_v1_astrodynes_progressed_practical_post
POST	/v1/astrodynes/progressed/reenforcement	astrodynes	progressed_astrodynes_reenforcement_route_v1_astrodynes_progressed_reenforcement_post
POST	/v1/astrodynes/progressed/search	astrodynes	progressed_astrodynes_search_route_v1_astrodynes_progressed_search_post
POST	/v1/astrodynes/progressed/total-influence	astrodynes	progressed_astrodynes_total_influence_route_v1_astrodynes_progressed_total_influence_post
POST	/v1/avasthas/evaluate	avasthas	avasthas_route_v1_avasthas_evaluate_post
POST	/v1/batch/charts	batch	batch_charts_route_v1_batch_charts_post
POST	/v1/batch/charts/reduction	batch	batch_charts_reduction_route_v1_batch_charts_reduction_post
POST	/v1/batch/events	batch	batch_events_route_v1_batch_events_post
POST	/v1/batch/progressions	batch	batch_progressions_route_v1_batch_progressions_post
POST	/v1/batch/progressions/reduction	batch	batch_progressions_reduction_route_v1_batch_progressions_reduction_post
POST	/v1/batch/returns	batch	batch_returns_route_v1_batch_returns_post
POST	/v1/batch/transits	batch	batch_transits_route_v1_batch_transits_post
POST	/v1/chart	chart	chart_route_v1_chart_post
POST	/v1/chart-shape/classify	relationship	chart_shape_route_v1_chart_shape_classify_post
POST	/v1/chart/reduction	chart	chart_reduction_route_v1_chart_reduction_post
POST	/v1/comets/bulk	comets (fast small-body)	comets_bulk_v1_comets_bulk_post
GET	/v1/comets/list	comets (fast small-body)	list_comets_v1_comets_list_get
POST	/v1/comets/position	comets (fast small-body)	comet_position_v1_comets_position_post
POST	/v1/composite/chart	relationship	composite_chart_route_v1_composite_chart_post
POST	/v1/composite/transits	relationship	composite_transits_route_v1_composite_transits_post
POST	/v1/dasha/alternate/ashtottari/chart/profile	alternate-dashas	ashtottari_chart_profile_route_v1_dasha_alternate_ashtottari_chart_profile_post
POST	/v1/dasha/alternate/ashtottari/chart/sequence	alternate-dashas	ashtottari_chart_sequence_route_v1_dasha_alternate_ashtottari_chart_sequence_post
POST	/v1/dasha/alternate/ashtottari/profile	alternate-dashas	ashtottari_profile_route_v1_dasha_alternate_ashtottari_profile_post
POST	/v1/dasha/alternate/ashtottari/sequence	alternate-dashas	ashtottari_sequence_route_v1_dasha_alternate_ashtottari_sequence_post
POST	/v1/dasha/alternate/period-profile	alternate-dashas	alternate_period_profile_route_v1_dasha_alternate_period_profile_post
POST	/v1/dasha/alternate/yogini/chart/profile	alternate-dashas	yogini_chart_profile_route_v1_dasha_alternate_yogini_chart_profile_post
POST	/v1/dasha/alternate/yogini/chart/sequence	alternate-dashas	yogini_chart_sequence_route_v1_dasha_alternate_yogini_chart_sequence_post
POST	/v1/dasha/alternate/yogini/profile	alternate-dashas	yogini_profile_route_v1_dasha_alternate_yogini_profile_post
POST	/v1/dasha/alternate/yogini/sequence	alternate-dashas	yogini_sequence_route_v1_dasha_alternate_yogini_sequence_post
POST	/v1/dasha/vimshottari/balance	dasha	dasha_balance_route_v1_dasha_vimshottari_balance_post
POST	/v1/dasha/vimshottari/current	dasha	dasha_current_route_v1_dasha_vimshottari_current_post
POST	/v1/dasha/vimshottari/lord-pair	dasha	dasha_lord_pair_route_v1_dasha_vimshottari_lord_pair_post
POST	/v1/dasha/vimshottari/profile	dasha	dasha_profile_route_v1_dasha_vimshottari_profile_post
POST	/v1/dasha/vimshottari/sequence	dasha	dasha_sequence_route_v1_dasha_vimshottari_sequence_post
POST	/v1/davison/chart	relationship	davison_chart_route_v1_davison_chart_post
POST	/v1/davison/transits	relationship	davison_transits_route_v1_davison_transits_post
POST	/v1/decanates/chaldean-face	decanates	chaldean_face_route_v1_decanates_chaldean_face_post
POST	/v1/decanates/chart/set	decanates	decanate_set_chart_route_v1_decanates_chart_set_post
POST	/v1/decanates/chart/vedic-drekkana	decanates	vedic_drekkana_chart_route_v1_decanates_chart_vedic_drekkana_post
POST	/v1/decanates/set	decanates	decanate_set_route_v1_decanates_set_post
POST	/v1/decanates/triplicity	decanates	triplicity_decan_route_v1_decanates_triplicity_post
POST	/v1/decanates/vedic-drekkana	decanates	vedic_drekkana_route_v1_decanates_vedic_drekkana_post
POST	/v1/deep-sky/bulk	deep-sky	deep_sky_bulk_v1_deep_sky_bulk_post
GET	/v1/deep-sky/list	deep-sky	deep_sky_list_v1_deep_sky_list_get
POST	/v1/deep-sky/position	deep-sky	deep_sky_position_v1_deep_sky_position_post
POST	/v1/dignities/chart	dignities	dignities_chart_route_v1_dignities_chart_post
POST	/v1/dignities/chart/condition	dignities	dignities_chart_condition_route_v1_dignities_chart_condition_post
POST	/v1/dignities/chart/conditions	dignities	dignities_chart_conditions_route_v1_dignities_chart_conditions_post
POST	/v1/dignities/chart/network	dignities	dignities_chart_network_route_v1_dignities_chart_network_post
POST	/v1/dignities/chart/profile	dignities	dignities_chart_profile_route_v1_dignities_chart_profile_post
POST	/v1/dignities/chart/receptions	dignities	dignities_chart_receptions_route_v1_dignities_chart_receptions_post
POST	/v1/draconic/chart	draconic	draconic_chart_route_v1_draconic_chart_post
POST	/v1/draconic/longitude	draconic	draconic_longitude_route_v1_draconic_longitude_post
POST	/v1/draconic/positions	draconic	draconic_positions_route_v1_draconic_positions_post
POST	/v1/eclipses/lunar/global-circumstances	phenomena	lunar_eclipse_global_circumstances_route_v1_eclipses_lunar_global_circumstances_post
POST	/v1/eclipses/lunar/local	phenomena	lunar_eclipse_local_route_v1_eclipses_lunar_local_post
POST	/v1/eclipses/lunar/next	phenomena	next_lunar_eclipse_route_v1_eclipses_lunar_next_post
POST	/v1/eclipses/lunar/previous	phenomena	previous_lunar_eclipse_route_v1_eclipses_lunar_previous_post
POST	/v1/eclipses/lunar/visibility	phenomena	lunar_eclipse_visibility_route_v1_eclipses_lunar_visibility_post
POST	/v1/eclipses/solar/cartography	phenomena	solar_eclipse_cartography_route_v1_eclipses_solar_cartography_post
POST	/v1/eclipses/solar/footprint	phenomena	solar_eclipse_footprint_route_v1_eclipses_solar_footprint_post
POST	/v1/eclipses/solar/global-circumstances	phenomena	solar_eclipse_global_circumstances_route_v1_eclipses_solar_global_circumstances_post
POST	/v1/eclipses/solar/local-visible	phenomena	next_visible_solar_eclipse_route_v1_eclipses_solar_local_visible_post
POST	/v1/eclipses/solar/next	phenomena	next_solar_eclipse_route_v1_eclipses_solar_next_post
POST	/v1/eclipses/solar/path	phenomena	solar_eclipse_path_route_v1_eclipses_solar_path_post
POST	/v1/eclipses/solar/previous	phenomena	previous_solar_eclipse_route_v1_eclipses_solar_previous_post
POST	/v1/egyptian-bounds/aggregate	egyptian-bounds	egyptian_bounds_aggregate_route_v1_egyptian_bounds_aggregate_post
POST	/v1/egyptian-bounds/bound	egyptian-bounds	egyptian_bound_route_v1_egyptian_bounds_bound_post
POST	/v1/egyptian-bounds/classification	egyptian-bounds	egyptian_bound_classification_route_v1_egyptian_bounds_classification_post
POST	/v1/egyptian-bounds/condition	egyptian-bounds	egyptian_bound_condition_route_v1_egyptian_bounds_condition_post
POST	/v1/egyptian-bounds/network	egyptian-bounds	egyptian_bounds_network_route_v1_egyptian_bounds_network_post
POST	/v1/egyptian-bounds/relation	egyptian-bounds	egyptian_bound_relation_route_v1_egyptian_bounds_relation_post
GET	/v1/egyptian-bounds/table	egyptian-bounds	egyptian_bounds_table_route_v1_egyptian_bounds_table_get
POST	/v1/electional/moments	electional	electional_moments_route_v1_electional_moments_post
GET	/v1/electional/predicate-profiles	electional	electional_predicate_profiles_route_v1_electional_predicate_profiles_get
POST	/v1/electional/scored	electional	electional_scored_route_v1_electional_scored_post
GET	/v1/electional/scorer-profiles	electional	electional_scorer_profiles_route_v1_electional_scorer_profiles_get
POST	/v1/electional/western/classical-perfection	electional	lilly_perfection_route_v1_electional_western_classical_perfection_post
POST	/v1/electional/western/dorotheus-construction	electional	dorotheus_construction_route_v1_electional_western_dorotheus_construction_post
POST	/v1/electional/western/dorotheus-matter-profile	electional	dorotheus_matter_profile_route_v1_electional_western_dorotheus_matter_profile_post
POST	/v1/electional/western/dorotheus-moon-condition	electional	dorotheus_moon_condition_route_v1_electional_western_dorotheus_moon_condition_post
POST	/v1/electional/western/dorotheus-rooted-context	electional	dorotheus_rooted_context_route_v1_electional_western_dorotheus_rooted_context_post
POST	/v1/electional/western/judgement	electional	western_electional_judgement_route_v1_electional_western_judgement_post
POST	/v1/electional/western/judgement-windows	electional	western_electional_judgement_windows_route_v1_electional_western_judgement_windows_post
POST	/v1/electional/western/lunar-ecliptic-direction	electional	lunar_ecliptic_direction_route_v1_electional_western_lunar_ecliptic_direction_post
POST	/v1/electional/western/profile-windows	electional	western_profile_windows_route_v1_electional_western_profile_windows_post
POST	/v1/electional/western/ramesey-moon-condition	electional	ramesey_moon_condition_route_v1_electional_western_ramesey_moon_condition_post
POST	/v1/electional/western/ranking	electional	western_electional_ranking_route_v1_electional_western_ranking_post
POST	/v1/electional/western/sahl-matter-profile	electional	sahl_matter_profile_route_v1_electional_western_sahl_matter_profile_post
POST	/v1/electional/western/sahl-moon-condition	electional	sahl_moon_condition_route_v1_electional_western_sahl_moon_condition_post
POST	/v1/electional/windows	electional	electional_windows_route_v1_electional_windows_post
POST	/v1/galactic-houses/chart/placements	galactic-houses	galactic_house_chart_placements_route_v1_galactic_houses_chart_placements_post
POST	/v1/galactic-houses/cusps	galactic-houses	galactic_house_cusps_route_v1_galactic_houses_cusps_post
POST	/v1/galactic-houses/placement	galactic-houses	galactic_house_placement_route_v1_galactic_houses_placement_post
POST	/v1/galactic/chart/positions	galactic	galactic_chart_positions_route_v1_galactic_chart_positions_post
POST	/v1/galactic/cosmic-reference-points	galactic	cosmic_reference_points_route_v1_galactic_cosmic_reference_points_post
POST	/v1/galactic/ecliptic-to-galactic	galactic	ecliptic_to_galactic_route_v1_galactic_ecliptic_to_galactic_post
POST	/v1/galactic/equatorial-to-galactic	galactic	equatorial_to_galactic_route_v1_galactic_equatorial_to_galactic_post
POST	/v1/galactic/galactic-to-ecliptic	galactic	galactic_to_ecliptic_route_v1_galactic_galactic_to_ecliptic_post
POST	/v1/galactic/galactic-to-equatorial	galactic	galactic_to_equatorial_route_v1_galactic_galactic_to_equatorial_post
POST	/v1/galactic/reference-points	galactic	galactic_reference_points_route_v1_galactic_reference_points_post
POST	/v1/gauquelin/chart/sectors	gauquelin	gauquelin_chart_sectors_route_v1_gauquelin_chart_sectors_post
POST	/v1/gauquelin/sector	gauquelin	gauquelin_sector_route_v1_gauquelin_sector_post
POST	/v1/gauquelin/sectors	gauquelin	gauquelin_sectors_route_v1_gauquelin_sectors_post
POST	/v1/geodetic/chart/equivalents	geodetic	geodetic_chart_equivalents_route_v1_geodetic_chart_equivalents_post
POST	/v1/geodetic/chart/location-chart	geodetic	geodetic_chart_location_chart_route_v1_geodetic_chart_location_chart_post
POST	/v1/geodetic/equivalents	geodetic	geodetic_equivalents_route_v1_geodetic_equivalents_post
POST	/v1/geodetic/location-chart	geodetic	geodetic_location_chart_route_v1_geodetic_location_chart_post
POST	/v1/harmograms/intensity-spectrum	harmograms	harmogram_intensity_spectrum_route_v1_harmograms_intensity_spectrum_post
POST	/v1/harmograms/projection	harmograms	harmogram_projection_route_v1_harmograms_projection_post
POST	/v1/harmograms/trace	harmograms	harmogram_trace_route_v1_harmograms_trace_post
POST	/v1/harmograms/vector	harmograms	harmogram_vector_route_v1_harmograms_vector_post
POST	/v1/harmograms/zero-aries-vector	harmograms	harmogram_zero_aries_vector_route_v1_harmograms_zero_aries_vector_post
POST	/v1/harmonics/age-chart	harmonics	harmonic_age_chart_route_v1_harmonics_age_chart_post
POST	/v1/harmonics/aspects	harmonics	harmonic_aspects_route_v1_harmonics_aspects_post
POST	/v1/harmonics/chart	harmonics	harmonic_chart_route_v1_harmonics_chart_post
POST	/v1/harmonics/composite	harmonics	harmonic_composite_route_v1_harmonics_composite_post
POST	/v1/harmonics/conjunctions	harmonics	harmonic_conjunctions_route_v1_harmonics_conjunctions_post
POST	/v1/harmonics/cross-chart-conjunctions	harmonics	harmonic_cross_chart_conjunctions_route_v1_harmonics_cross_chart_conjunctions_post
POST	/v1/harmonics/fingerprint	harmonics	harmonic_fingerprint_route_v1_harmonics_fingerprint_post
POST	/v1/harmonics/pattern-score	harmonics	harmonic_pattern_score_route_v1_harmonics_pattern_score_post
GET	/v1/harmonics/presets	harmonics	harmonic_presets_route_v1_harmonics_presets_get
POST	/v1/harmonics/sweep	harmonics	harmonic_sweep_route_v1_harmonics_sweep_post
POST	/v1/harmonics/transit-forecast	harmonics	harmonic_transit_forecast_route_v1_harmonics_transit_forecast_post
POST	/v1/heliacal/phasis	phenomena	heliacal_phasis_route_v1_heliacal_phasis_post
POST	/v1/heliacal/planet	phenomena	planet_heliacal_event_route_v1_heliacal_planet_post
POST	/v1/heliacal/visibility-event	phenomena	general_visibility_event_route_v1_heliacal_visibility_event_post
POST	/v1/hellenistic/chart-profile	hellenistic-profile	hellenistic_chart_profile_route_v1_hellenistic_chart_profile_post
POST	/v1/hellenistic/circumambulations	hellenistic-systems	circumambulations_route_v1_hellenistic_circumambulations_post
POST	/v1/hellenistic/condition	hellenistic-atoms	hellenistic_condition_route_v1_hellenistic_condition_post
POST	/v1/hellenistic/offices	hellenistic-systems	offices_route_v1_hellenistic_offices_post
POST	/v1/hellenistic/transmissions	hellenistic-systems	transmissions_route_v1_hellenistic_transmissions_post
POST	/v1/hellenistic/twelfth-parts	hellenistic-atoms	twelfth_parts_route_v1_hellenistic_twelfth_parts_post
POST	/v1/horary/evidence-profile	horary	horary_evidence_profile
POST	/v1/houses	chart	houses_route_v1_houses_post
POST	/v1/houses/dynamics	chart	house_dynamics_route_v1_houses_dynamics_post
POST	/v1/houses/dynamics/analytical	chart	analytical_house_dynamics_route_v1_houses_dynamics_analytical_post
POST	/v1/houses/dynamics/armc	chart	house_dynamics_from_armc_route_v1_houses_dynamics_armc_post
POST	/v1/houses/polar-admissibility	chart	houses_polar_admissibility_route_v1_houses_polar_admissibility_post
POST	/v1/houses/reduction	chart	houses_reduction_route_v1_houses_reduction_post
POST	/v1/huber/age-point	huber	huber_age_point_route_v1_huber_age_point_post
POST	/v1/huber/age-point-contacts	huber	huber_age_point_contacts_route_v1_huber_age_point_contacts_post
POST	/v1/huber/chart-intensity-profile	huber	huber_chart_intensity_profile_route_v1_huber_chart_intensity_profile_post
POST	/v1/huber/dynamic-intensity	huber	huber_dynamic_intensity_route_v1_huber_dynamic_intensity_post
POST	/v1/huber/house-zones	huber	huber_house_zones_route_v1_huber_house_zones_post
POST	/v1/huber/intensity-at	huber	huber_intensity_at_route_v1_huber_intensity_at_post
POST	/v1/hyleg/lilly-1647	hyleg	hyleg_lilly_1647_route_v1_hyleg_lilly_1647_post
POST	/v1/hyleg/lilly-1647/alcocoden	hyleg	alcocoden_lilly_1647_route_v1_hyleg_lilly_1647_alcocoden_post
POST	/v1/jaimini/chart/condition	jaimini	jaimini_chart_condition_route_v1_jaimini_chart_condition_post
POST	/v1/jaimini/chart/karakas	jaimini	jaimini_chart_karakas_route_v1_jaimini_chart_karakas_post
POST	/v1/jaimini/chart/pair	jaimini	jaimini_chart_pair_route_v1_jaimini_chart_pair_post
POST	/v1/jaimini/chart/profile	jaimini	jaimini_chart_profile_route_v1_jaimini_chart_profile_post
POST	/v1/jaimini/extended/argala	jaimini	argala_route_v1_jaimini_extended_argala_post
POST	/v1/jaimini/extended/arudhas	jaimini	arudhas_route_v1_jaimini_extended_arudhas_post
POST	/v1/jaimini/extended/chara-dasha	jaimini	chara_dasha_route_v1_jaimini_extended_chara_dasha_post
POST	/v1/jaimini/extended/karakamsa	jaimini	karakamsa_route_v1_jaimini_extended_karakamsa_post
POST	/v1/jaimini/karakas	jaimini	jaimini_karakas_route_v1_jaimini_karakas_post
POST	/v1/jaimini/karakas/condition	jaimini	jaimini_karakas_condition_route_v1_jaimini_karakas_condition_post
POST	/v1/jaimini/karakas/pair	jaimini	jaimini_karakas_pair_route_v1_jaimini_karakas_pair_post
POST	/v1/jaimini/karakas/profile	jaimini	jaimini_karakas_profile_route_v1_jaimini_karakas_profile_post
POST	/v1/local-space/chart/positions	local-space	local_space_chart_positions_route_v1_local_space_chart_positions_post
POST	/v1/local-space/positions	local-space	local_space_positions_route_v1_local_space_positions_post
GET	/v1/locations/search	website-locations	location_search_route_v1_locations_search_get
POST	/v1/locations/timezone/validate	website-locations	timezone_validate_route_v1_locations_timezone_validate_post
POST	/v1/lord-of-the-orb/current	lord-of-the-orb	lord_of_the_orb_current_route_v1_lord_of_the_orb_current_post
POST	/v1/lord-of-the-orb/sequence	lord-of-the-orb	lord_of_the_orb_sequence_route_v1_lord_of_the_orb_sequence_post
POST	/v1/lord-of-the-turn/profile	lord-of-the-turn	lord_of_the_turn_profile_route_v1_lord_of_the_turn_profile_post
GET	/v1/lots/catalog	lots	lots_catalog_route_v1_lots_catalog_get
POST	/v1/lots/chart	lots	lots_chart_route_v1_lots_chart_post
POST	/v1/lots/chart/condition	lots	lots_chart_condition_route_v1_lots_chart_condition_post
POST	/v1/lots/chart/conditions	lots	lots_chart_conditions_route_v1_lots_chart_conditions_post
POST	/v1/lots/chart/dependencies	lots	lots_chart_dependencies_route_v1_lots_chart_dependencies_post
POST	/v1/lots/chart/network	lots	lots_chart_network_route_v1_lots_chart_network_post
POST	/v1/lots/chart/profile	lots	lots_chart_profile_route_v1_lots_chart_profile_post
POST	/v1/lunar-phases	predictive	lunar_phase_route_v1_lunar_phases_post
POST	/v1/manazil/bulk	manazil	manazil_bulk_route_v1_manazil_bulk_post
GET	/v1/manazil/catalog	manazil	manazil_catalog_route_v1_manazil_catalog_get
POST	/v1/manazil/position	manazil	manazil_position_route_v1_manazil_position_post
GET	/v1/manazil/traditions/{tradition}/mansions/{mansion_index}	manazil	manazil_tradition_lookup_route_v1_manazil_traditions__tradition__mansions__mansion_index__get
GET	/v1/meta/routes	meta	route_catalog_v1_meta_routes_get
POST	/v1/midpoints/calculate	relationship	midpoints_route_v1_midpoints_calculate_post
POST	/v1/midpoints/clusters	relationship	midpoint_clusters_route_v1_midpoints_clusters_post
POST	/v1/midpoints/pictures	relationship	midpoint_pictures_route_v1_midpoints_pictures_post
POST	/v1/midpoints/to-point	relationship	midpoints_to_point_route_v1_midpoints_to_point_post
POST	/v1/midpoints/weighting	relationship	midpoint_weighting_route_v1_midpoints_weighting_post
POST	/v1/muhurta/chart/classification	muhurta	muhurta_chart_classification_route_v1_muhurta_chart_classification_post
POST	/v1/muhurta/chart/score	muhurta	muhurta_chart_score_route_v1_muhurta_chart_score_post
POST	/v1/muhurta/direct/classification	muhurta	muhurta_direct_classification_route_v1_muhurta_direct_classification_post
POST	/v1/muhurta/direct/score	muhurta	muhurta_direct_score_route_v1_muhurta_direct_score_post
POST	/v1/muhurta/personal/score	muhurta	muhurta_personal_score_route_v1_muhurta_personal_score_post
POST	/v1/mundane/event-chart-profile	mundane	mundane_event_chart_profile
POST	/v1/nakshatra/bulk	sidereal	nakshatra_bulk_route_v1_nakshatra_bulk_post
POST	/v1/nakshatra/position	sidereal	nakshatra_position_route_v1_nakshatra_position_post
POST	/v1/nine-parts/abu-mashar	nine-parts	abu_mashar_nine_parts_route_v1_nine_parts_abu_mashar_post
GET	/v1/nodes/catalog	nodes	node_catalog_route_v1_nodes_catalog_get
POST	/v1/nodes/geometric	nodes	geometric_node_route_v1_nodes_geometric_post
POST	/v1/nodes/planetary/mean	nodes	mean_planetary_node_route_v1_nodes_planetary_mean_post
POST	/v1/nodes/planetary/mean/bulk	nodes	mean_planetary_nodes_bulk_route_v1_nodes_planetary_mean_bulk_post
POST	/v1/occultations/all-lunar	phenomena	all_lunar_occultations_route_v1_occultations_all_lunar_post
POST	/v1/occultations/close-approaches	phenomena	close_approaches_route_v1_occultations_close_approaches_post
POST	/v1/occultations/lunar	phenomena	lunar_occultations_route_v1_occultations_lunar_post
POST	/v1/occultations/lunar-path	phenomena	lunar_occultation_path_route_v1_occultations_lunar_path_post
POST	/v1/occultations/lunar-path-at	phenomena	lunar_occultation_path_at_route_v1_occultations_lunar_path_at_post
POST	/v1/occultations/lunar-path-topology	phenomena	lunar_occultation_path_topology_route_v1_occultations_lunar_path_topology_post
POST	/v1/occultations/lunar-path-topology-at	phenomena	lunar_occultation_path_topology_at_route_v1_occultations_lunar_path_topology_at_post
POST	/v1/occultations/lunar-star	phenomena	lunar_star_occultations_route_v1_occultations_lunar_star_post
POST	/v1/occultations/lunar-star-path	phenomena	lunar_star_occultation_path_route_v1_occultations_lunar_star_path_post
POST	/v1/occultations/lunar-star-path-at	phenomena	lunar_star_occultation_path_at_route_v1_occultations_lunar_star_path_at_post
POST	/v1/occultations/lunar-star-path-topology	phenomena	lunar_star_occultation_path_topology_route_v1_occultations_lunar_star_path_topology_post
POST	/v1/occultations/lunar-star-path-topology-at	phenomena	lunar_star_occultation_path_topology_at_route_v1_occultations_lunar_star_path_topology_at_post
POST	/v1/orbits/class	orbits	orbit_class_route_v1_orbits_class_post
POST	/v1/orbits/class/batch	orbits	orbit_class_batch_route_v1_orbits_class_batch_post
POST	/v1/orbits/distance-extremes	orbits	distance_extremes_route_v1_orbits_distance_extremes_post
POST	/v1/orbits/elements	orbits	orbital_elements_route_v1_orbits_elements_post
GET	/v1/pancha-pakshi/constitution/uromarisi	pancha-pakshi	pancha_pakshi_uromarisi_constitution_status_route_v1_pancha_pakshi_constitution_uromarisi_get
POST	/v1/pancha-pakshi/context/astronomical-paksha	pancha-pakshi	pancha_pakshi_astronomical_paksha_route_v1_pancha_pakshi_context_astronomical_paksha_post
POST	/v1/pancha-pakshi/context/local-solar	pancha-pakshi	pancha_pakshi_local_solar_context_route_v1_pancha_pakshi_context_local_solar_post
POST	/v1/pancha-pakshi/identity/aksara	pancha-pakshi	pancha_pakshi_aksara_identity_route_v1_pancha_pakshi_identity_aksara_post
POST	/v1/pancha-pakshi/identity/natal-moon	pancha-pakshi	pancha_pakshi_natal_moon_identity_route_v1_pancha_pakshi_identity_natal_moon_post
POST	/v1/pancha-pakshi/mappings/nakshatra-bird	pancha-pakshi	pancha_pakshi_nakshatra_bird_mapping_route_v1_pancha_pakshi_mappings_nakshatra_bird_post
GET	/v1/pancha-pakshi/profiles	pancha-pakshi	pancha_pakshi_profiles_route_v1_pancha_pakshi_profiles_get
GET	/v1/pancha-pakshi/profiles/{profile_id}	pancha-pakshi	pancha_pakshi_profile_route_v1_pancha_pakshi_profiles__profile_id__get
POST	/v1/pancha-pakshi/relationships/directed	pancha-pakshi	pancha_pakshi_directed_relationship_route_v1_pancha_pakshi_relationships_directed_post
POST	/v1/pancha-pakshi/roles/padu	pancha-pakshi	pancha_pakshi_padu_bird_mapping_route_v1_pancha_pakshi_roles_padu_post
POST	/v1/pancha-pakshi/schedule/first-eat-bird	pancha-pakshi	pancha_pakshi_first_eat_bird_mapping_route_v1_pancha_pakshi_schedule_first_eat_bird_post
POST	/v1/pancha-pakshi/schedule/fixed-clock	pancha-pakshi	pancha_pakshi_fixed_clock_materialization_route_v1_pancha_pakshi_schedule_fixed_clock_post
POST	/v1/pancha-pakshi/schedule/fixed-clock/current-cell	pancha-pakshi	pancha_pakshi_fixed_clock_current_cell_route_v1_pancha_pakshi_schedule_fixed_clock_current_cell_post
POST	/v1/pancha-pakshi/schedule/nominal	pancha-pakshi	pancha_pakshi_nominal_schedule_route_v1_pancha_pakshi_schedule_nominal_post
POST	/v1/pancha-pakshi/schedule/solar-proportional	pancha-pakshi	pancha_pakshi_solar_proportional_materialization_route_v1_pancha_pakshi_schedule_solar_proportional_post
POST	/v1/pancha-pakshi/schedule/solar-proportional/current-cell	pancha-pakshi	pancha_pakshi_solar_proportional_current_cell_route_v1_pancha_pakshi_schedule_solar_proportional_current_cell_post
POST	/v1/pancha-pakshi/sookshma/civil-time-select	pancha-pakshi	pancha_pakshi_civil_time_sookshma_selection_route_v1_pancha_pakshi_sookshma_civil_time_select_post
POST	/v1/pancha-pakshi/sookshma/schedule-select	pancha-pakshi	pancha_pakshi_schedule_sookshma_temporal_selection_route_v1_pancha_pakshi_sookshma_schedule_select_post
POST	/v1/pancha-pakshi/sookshma/select	pancha-pakshi	pancha_pakshi_sookshma_temporal_selection_route_v1_pancha_pakshi_sookshma_select_post
POST	/v1/panchanga/chart	panchanga	panchanga_chart_route_v1_panchanga_chart_post
POST	/v1/panchanga/chart/profile	panchanga	panchanga_chart_profile_route_v1_panchanga_chart_profile_post
POST	/v1/panchanga/instant	panchanga	panchanga_instant_route_v1_panchanga_instant_post
POST	/v1/panchanga/instant/profile	panchanga	panchanga_instant_profile_route_v1_panchanga_instant_profile_post
POST	/v1/parans/field/analysis	phenomena	paran_field_analysis_route_v1_parans_field_analysis_post
POST	/v1/parans/field/contours	phenomena	paran_field_contours_route_v1_parans_field_contours_post
POST	/v1/parans/field/paths	phenomena	paran_field_paths_route_v1_parans_field_paths_post
POST	/v1/parans/field/samples	phenomena	paran_field_samples_route_v1_parans_field_samples_post
POST	/v1/parans/field/structure	phenomena	paran_field_structure_route_v1_parans_field_structure_post
POST	/v1/parans/natal	phenomena	natal_paran_search_route_v1_parans_natal_post
POST	/v1/parans/natal-angular-contacts	phenomena	natal_angular_contacts_route_v1_parans_natal_angular_contacts_post
POST	/v1/parans/search	phenomena	paran_search_route_v1_parans_search_post
POST	/v1/parans/site	phenomena	paran_site_route_v1_parans_site_post
GET	/v1/parans/star-canon	phenomena	paran_star_canon_route_v1_parans_star_canon_get
POST	/v1/patterns/chart-profile	relationship	pattern_chart_profile_route_v1_patterns_chart_profile_post
POST	/v1/patterns/coherence	relationship	pattern_coherence_route_v1_patterns_coherence_post
POST	/v1/patterns/find	relationship	patterns_route_v1_patterns_find_post
POST	/v1/patterns/network	relationship	pattern_network_route_v1_patterns_network_post
POST	/v1/phase/angle	phase	phase_angle_route_v1_phase_angle_post
POST	/v1/phase/angular-diameter	phase	angular_diameter_route_v1_phase_angular_diameter_post
POST	/v1/phase/apparent-magnitude	phase	apparent_magnitude_route_v1_phase_apparent_magnitude_post
POST	/v1/phase/elongation	phase	elongation_route_v1_phase_elongation_post
POST	/v1/phase/illuminated-fraction	phase	illuminated_fraction_route_v1_phase_illuminated_fraction_post
POST	/v1/phase/lunar-orientation	phase	lunar_orientation_route_v1_phase_lunar_orientation_post
POST	/v1/phase/synodic	phase	synodic_phase_route_v1_phase_synodic_post
POST	/v1/phenomena/orbital-events	generic-phenomena	orbital_phenomena_events_route_v1_phenomena_orbital_events_post
POST	/v1/phenomena/planet	generic-phenomena	planet_phenomena_route_v1_phenomena_planet_post
POST	/v1/phenomena/proximity	generic-phenomena	proximity_events_route_v1_phenomena_proximity_post
POST	/v1/pipeline/chart	website-pipeline	pipeline_chart_route_v1_pipeline_chart_post
POST	/v1/pipeline/positions/planet	website-pipeline	pipeline_planet_position_route_v1_pipeline_positions_planet_post
POST	/v1/pipeline/positions/sky	website-pipeline	pipeline_sky_position_route_v1_pipeline_positions_sky_post
POST	/v1/planetary-hours/hour-at	planetary-hours	planetary_hours_hour_at_route_v1_planetary_hours_hour_at_post
POST	/v1/planetary-hours/schedule	planetary-hours	planetary_hours_schedule_route_v1_planetary_hours_schedule_post
POST	/v1/positions/frame/heliocentric	positions-frame	frame_heliocentric_route_v1_positions_frame_heliocentric_post
POST	/v1/positions/frame/planetocentric	positions-frame	frame_planetocentric_route_v1_positions_frame_planetocentric_post
POST	/v1/positions/frame/received-light	positions-frame	frame_received_light_route_v1_positions_frame_received_light_post
POST	/v1/positions/frame/ssb	positions-frame	frame_ssb_route_v1_positions_frame_ssb_post
POST	/v1/positions/planet	positions	planet_position_route_v1_positions_planet_post
POST	/v1/positions/planet/reduction	positions	planet_position_reduction_route_v1_positions_planet_reduction_post
POST	/v1/positions/sky	positions	sky_position_route_v1_positions_sky_post
POST	/v1/positions/sky/reduction	positions	sky_position_reduction_route_v1_positions_sky_reduction_post
POST	/v1/primary-directions/arcs	primary-directions	primary_directions_arcs_route_v1_primary_directions_arcs_post
POST	/v1/primary-directions/arcs/reduction	primary-directions	primary_directions_arcs_reduction_route_v1_primary_directions_arcs_reduction_post
POST	/v1/primary-directions/network	primary-directions	primary_directions_network_route_v1_primary_directions_network_post
POST	/v1/primary-directions/network/reduction	primary-directions	primary_directions_network_reduction_route_v1_primary_directions_network_reduction_post
POST	/v1/primary-directions/profile	primary-directions	primary_directions_profile_route_v1_primary_directions_profile_post
POST	/v1/primary-directions/profile/reduction	primary-directions	primary_directions_profile_reduction_route_v1_primary_directions_profile_reduction_post
POST	/v1/primary-directions/relations	primary-directions	primary_directions_relations_route_v1_primary_directions_relations_post
POST	/v1/primary-directions/speculum	primary-directions	primary_directions_speculum_route_v1_primary_directions_speculum_post
POST	/v1/primary-directions/timeline	primary-directions	primary_directions_timeline_route_v1_primary_directions_timeline_post
POST	/v1/profections/annual	timelords	annual_profection_route_v1_profections_annual_post
POST	/v1/profections/monthly	timelords	monthly_profection_route_v1_profections_monthly_post
POST	/v1/profections/schedule	timelords	profection_schedule_route_v1_profections_schedule_post
POST	/v1/progressions/arc	progressions	arc_progression_route_v1_progressions_arc_post
POST	/v1/progressions/arc/reduction	progressions	arc_progression_reduction_route_v1_progressions_arc_reduction_post
POST	/v1/progressions/house-frame	progressions	house_frame_route_v1_progressions_house_frame_post
POST	/v1/progressions/house-frame/arc	progressions	house_frame_arc_route_v1_progressions_house_frame_arc_post
POST	/v1/progressions/house-frame/arc/reduction	progressions	house_frame_arc_reduction_route_v1_progressions_house_frame_arc_reduction_post
POST	/v1/progressions/house-frame/cusps	progressions	daily_houses_route_v1_progressions_house_frame_cusps_post
POST	/v1/progressions/house-frame/reduction	progressions	house_frame_reduction_route_v1_progressions_house_frame_reduction_post
POST	/v1/progressions/network	progressions	progression_network_route_v1_progressions_network_post
POST	/v1/progressions/network/reduction	progressions	progression_network_reduction_route_v1_progressions_network_reduction_post
POST	/v1/progressions/profile	progressions	progression_profile_route_v1_progressions_profile_post
POST	/v1/progressions/profile/reduction	progressions	progression_profile_reduction_route_v1_progressions_profile_reduction_post
POST	/v1/progressions/secondary	progressions	secondary_progression_route_v1_progressions_secondary_post
POST	/v1/progressions/secondary-declination	progressions	secondary_declination_route_v1_progressions_secondary_declination_post
POST	/v1/progressions/secondary-declination/reduction	progressions	secondary_declination_reduction_route_v1_progressions_secondary_declination_reduction_post
POST	/v1/progressions/secondary/reduction	progressions	secondary_progression_reduction_route_v1_progressions_secondary_reduction_post
POST	/v1/progressions/time-key	progressions	time_key_progression_route_v1_progressions_time_key_post
POST	/v1/progressions/time-key/reduction	progressions	time_key_progression_reduction_route_v1_progressions_time_key_reduction_post
POST	/v1/returns/lunar	predictive	lunar_return_route_v1_returns_lunar_post
POST	/v1/returns/planet	predictive	planet_return_route_v1_returns_planet_post
POST	/v1/returns/relocated	predictive, astrocartography	relocated_return_route_v1_returns_relocated_post
POST	/v1/returns/solar	predictive	solar_return_route_v1_returns_solar_post
POST	/v1/rise-set/phenomena	phenomena	rise_set_phenomena_route_v1_rise_set_phenomena_post
POST	/v1/rise-set/transit	phenomena	rise_set_transit_route_v1_rise_set_transit_post
POST	/v1/rise-set/twilight	phenomena	twilight_times_route_v1_rise_set_twilight_post
POST	/v1/sade-sati/status	sade-sati	sade_sati_status_route_v1_sade_sati_status_post
POST	/v1/sade-sati/windows	sade-sati	sade_sati_windows_route_v1_sade_sati_windows_post
POST	/v1/shadbala/chart	shadbala	shadbala_chart_route_v1_shadbala_chart_post
POST	/v1/shadbala/chart/bhava	shadbala	bhava_bala_chart_route_v1_shadbala_chart_bhava_post
POST	/v1/shadbala/chart/condition	shadbala	shadbala_chart_condition_route_v1_shadbala_chart_condition_post
POST	/v1/shadbala/chart/full	shadbala	shadbala_full_route_v1_shadbala_chart_full_post
POST	/v1/shadbala/chart/network	shadbala	shadbala_chart_network_route_v1_shadbala_chart_network_post
POST	/v1/shadbala/chart/profile	shadbala	shadbala_chart_profile_route_v1_shadbala_chart_profile_post
POST	/v1/sidereal/ayanamsa	sidereal	sidereal_ayanamsa_route_v1_sidereal_ayanamsa_post
GET	/v1/sidereal/ayanamsa-systems	sidereal	sidereal_ayanamsa_systems_route_v1_sidereal_ayanamsa_systems_get
POST	/v1/sidereal/convert	sidereal	sidereal_convert_route_v1_sidereal_convert_post
POST	/v1/solar-condition/events	generic-phenomena	solar_condition_events_route_v1_solar_condition_events_post
POST	/v1/solar-condition/instant	generic-phenomena	solar_condition_instant_route_v1_solar_condition_instant_post
POST	/v1/sothic/egyptian-date	sothic	egyptian_date_route_v1_sothic_egyptian_date_post
POST	/v1/sothic/predict-epoch	sothic	predict_epoch_route_v1_sothic_predict_epoch_post
POST	/v1/sothic/rising	sothic	rising_route_v1_sothic_rising_post
POST	/v1/stars/bulk	stars (fixed stars)	stars_bulk_v1_stars_bulk_post
GET	/v1/stars/list	stars (fixed stars)	list_stars_v1_stars_list_get
GET	/v1/stars/multiple/list	stars (fixed stars)	list_multiple_stars_route_v1_stars_multiple_list_get
POST	/v1/stars/multiple/state	stars (fixed stars)	multiple_star_state_route_v1_stars_multiple_state_post
GET	/v1/stars/multiple/{name}	stars (fixed stars)	multiple_star_catalog_route_v1_stars_multiple__name__get
POST	/v1/stars/position	stars (fixed stars)	star_position_v1_stars_position_post
POST	/v1/stars/variable/catalog-profile	stars (fixed stars)	variable_star_catalog_profile_route_v1_stars_variable_catalog_profile_post
GET	/v1/stars/variable/list	stars (fixed stars)	list_variable_stars_route_v1_stars_variable_list_get
POST	/v1/stars/variable/pair	stars (fixed stars)	variable_star_pair_route_v1_stars_variable_pair_post
POST	/v1/stars/variable/range	stars (fixed stars)	variable_star_range_route_v1_stars_variable_range_post
POST	/v1/stars/variable/state	stars (fixed stars)	variable_star_state_route_v1_stars_variable_state_post
GET	/v1/stars/variable/{name}	stars (fixed stars)	variable_star_catalog_route_v1_stars_variable__name__get
POST	/v1/stations/is-retrograde	phenomena	station_state_route_v1_stations_is_retrograde_post
POST	/v1/stations/next	phenomena	next_station_route_v1_stations_next_post
POST	/v1/stations/retrograde-periods	phenomena	retrograde_periods_route_v1_stations_retrograde_periods_post
POST	/v1/stations/search	phenomena	station_search_route_v1_stations_search_post
POST	/v1/stelliums/analyze	stelliums	analyze_stelliums_route_v1_stelliums_analyze_post
POST	/v1/synastry/aspects	relationship	synastry_aspects_route_v1_synastry_aspects_post
POST	/v1/synastry/contacts	relationship	synastry_contacts_route_v1_synastry_contacts_post
POST	/v1/synastry/overlay	relationship	synastry_directional_overlay_route_v1_synastry_overlay_post
POST	/v1/synastry/overlays	relationship	synastry_overlays_route_v1_synastry_overlays_post
POST	/v1/timelords/decennials/active-pair	timelords	decennials_active_pair_route_v1_timelords_decennials_active_pair_post
POST	/v1/timelords/decennials/active-path	timelords	decennials_active_path_route_v1_timelords_decennials_active_path_post
POST	/v1/timelords/decennials/current	timelords	decennials_current_route_v1_timelords_decennials_current_post
POST	/v1/timelords/decennials/groups	timelords	decennials_groups_route_v1_timelords_decennials_groups_post
POST	/v1/timelords/decennials/profile	timelords	decennials_profile_route_v1_timelords_decennials_profile_post
POST	/v1/timelords/decennials/sequence	timelords	decennials_sequence_route_v1_timelords_decennials_sequence_post
POST	/v1/timelords/firdaria/active-pair	timelords	firdaria_active_pair_route_v1_timelords_firdaria_active_pair_post
POST	/v1/timelords/firdaria/current	timelords	firdaria_current_route_v1_timelords_firdaria_current_post
POST	/v1/timelords/firdaria/groups	timelords	firdaria_groups_route_v1_timelords_firdaria_groups_post
POST	/v1/timelords/firdaria/profile	timelords	firdaria_profile_route_v1_timelords_firdaria_profile_post
POST	/v1/timelords/firdaria/sequence	timelords	firdaria_sequence_route_v1_timelords_firdaria_sequence_post
POST	/v1/timelords/zodiacal-releasing/current	timelords	zr_current_route_v1_timelords_zodiacal_releasing_current_post
POST	/v1/timelords/zodiacal-releasing/groups	timelords	zr_groups_route_v1_timelords_zodiacal_releasing_groups_post
POST	/v1/timelords/zodiacal-releasing/level-pair	timelords	zr_level_pair_route_v1_timelords_zodiacal_releasing_level_pair_post
POST	/v1/timelords/zodiacal-releasing/profile	timelords	zr_profile_route_v1_timelords_zodiacal_releasing_profile_post
POST	/v1/timelords/zodiacal-releasing/sequence	timelords	zr_sequence_route_v1_timelords_zodiacal_releasing_sequence_post
POST	/v1/transits/ingresses	predictive	ingress_search_route_v1_transits_ingresses_post
POST	/v1/transits/natal-aspects	predictive	natal_aspect_search_route_v1_transits_natal_aspects_post
POST	/v1/transits/next-ingress	predictive	next_ingress_route_v1_transits_next_ingress_post
POST	/v1/transits/search	predictive	transit_search_route_v1_transits_search_post
POST	/v1/triplicity/assignment	triplicity	triplicity_assignment_route_v1_triplicity_assignment_post
POST	/v1/triplicity/score	triplicity	triplicity_score_route_v1_triplicity_score_post
GET	/v1/triplicity/table	triplicity	triplicity_table_route_v1_triplicity_table_get
POST	/v1/upagrahas/kalavelas	upagrahas	kalavelas_route_v1_upagrahas_kalavelas_post
POST	/v1/upagrahas/sun-based	upagrahas	sun_based_upagrahas_route_v1_upagrahas_sun_based_post
POST	/v1/uranian/bulk	uranian	uranian_bulk_route_v1_uranian_bulk_post
GET	/v1/uranian/catalog	uranian	uranian_catalog_route_v1_uranian_catalog_get
POST	/v1/uranian/position	uranian	uranian_position_route_v1_uranian_position_post
POST	/v1/varga/chart/named	varga	varga_chart_named_route_v1_varga_chart_named_post
POST	/v1/varga/chart/shodashvarga	varga	varga_chart_shodashvarga_route_v1_varga_chart_shodashvarga_post
POST	/v1/varga/chart/shodashvarga/batch	varga	varga_chart_shodashvarga_batch_route_v1_varga_chart_shodashvarga_batch_post
POST	/v1/varga/generic	varga	varga_generic_route_v1_varga_generic_post
POST	/v1/varga/named	varga	varga_named_route_v1_varga_named_post
POST	/v1/varga/named/batch	varga	varga_named_batch_route_v1_varga_named_batch_post
POST	/v1/varga/shodashvarga	varga	varga_shodashvarga_route_v1_varga_shodashvarga_post
POST	/v1/varga/shodashvarga/batch	varga	varga_shodashvarga_batch_route_v1_varga_shodashvarga_batch_post
POST	/v1/varga/vimshopaka	varga	vimshopaka_route_v1_varga_vimshopaka_post
POST	/v1/varshaphal/chart	varshaphal	varshaphal_chart_route_v1_varshaphal_chart_post
POST	/v1/varshaphal/judgement/profile	varshaphal	varshaphal_judgement_profile_route_v1_varshaphal_judgement_profile_post
POST	/v1/varshaphal/judgement/year	varshaphal	varshaphal_year_judgement_route_v1_varshaphal_judgement_year_post
POST	/v1/varshaphal/mudda/active	varshaphal	varshaphal_mudda_active_route_v1_varshaphal_mudda_active_post
POST	/v1/varshaphal/mudda/judgement	varshaphal	varshaphal_mudda_judgement_route_v1_varshaphal_mudda_judgement_post
POST	/v1/varshaphal/summary	varshaphal	varshaphal_year_summary_route_v1_varshaphal_summary_post
POST	/v1/varshaphal/tasira/active	varshaphal	varshaphal_tasira_active_route_v1_varshaphal_tasira_active_post
POST	/v1/varshaphal/topics	varshaphal	varshaphal_topics_route_v1_varshaphal_topics_post
POST	/v1/varshaphal/topics/windows	varshaphal	varshaphal_topic_windows_route_v1_varshaphal_topics_windows_post
POST	/v1/vedic-dignities/chart-profile	vedic-dignities	vedic_dignity_chart_profile_route_v1_vedic_dignities_chart_profile_post
POST	/v1/vedic-dignities/chart/dignity	vedic-dignities	vedic_dignity_chart_backed_route_v1_vedic_dignities_chart_dignity_post
POST	/v1/vedic-dignities/chart/profile	vedic-dignities	vedic_dignity_chart_backed_profile_route_v1_vedic_dignities_chart_profile_post
POST	/v1/vedic-dignities/chart/relationships	vedic-dignities	vedic_dignity_chart_backed_relationships_route_v1_vedic_dignities_chart_relationships_post
POST	/v1/vedic-dignities/condition	vedic-dignities	vedic_dignity_condition_route_v1_vedic_dignities_condition_post
POST	/v1/vedic-dignities/dignity	vedic-dignities	vedic_dignity_route_v1_vedic_dignities_dignity_post
POST	/v1/vedic-dignities/relationships	vedic-dignities	vedic_dignity_relationships_route_v1_vedic_dignities_relationships_post
POST	/v1/vedic/chart-profile	vedic-profile	vedic_chart_profile_route_v1_vedic_chart_profile_post
POST	/v1/visibility/assessment	visibility	visibility_assessment_route_v1_visibility_assessment_post
POST	/v1/visibility/atmospheric-extinction	visibility	atmospheric_extinction_route_v1_visibility_atmospheric_extinction_post
POST	/v1/visibility/physical-assessment	visibility	physical_visibility_assessment_route_v1_visibility_physical_assessment_post
POST	/v1/visibility/physical-event	visibility	physical_visibility_event_route_v1_visibility_physical_event_post
POST	/v1/visibility/point-source-threshold	visibility	point_source_visibility_threshold_route_v1_visibility_point_source_threshold_post
POST	/v1/visibility/tonight	visibility	visibility_tonight_route_v1_visibility_tonight_post
POST	/v1/visibility/twilight-sky-brightness	visibility	twilight_sky_brightness_route_v1_visibility_twilight_sky_brightness_post
POST	/v1/void-of-course/is-active	phenomena	void_of_course_state_route_v1_void_of_course_is_active_post
POST	/v1/void-of-course/next	phenomena	next_void_of_course_route_v1_void_of_course_next_post
POST	/v1/void-of-course/range	phenomena	void_of_course_range_route_v1_void_of_course_range_post
POST	/v1/void-of-course/window	phenomena	void_of_course_window_route_v1_void_of_course_window_post
POST	/v1/website/chart-wheel/packet	website-chart-wheel	chart_wheel_packet_route_v1_website_chart_wheel_packet_post
GET	/v1/website/chart-wheel/presets	website-chart-wheel	chart_wheel_presets_route_v1_website_chart_wheel_presets_get
POST	/v1/website/chart-wheel/validate	website-chart-wheel	chart_wheel_validate_route_v1_website_chart_wheel_validate_post
POST	/v1/website/parans/packet	website-parans	paran_packet_route_v1_website_parans_packet_post
POST	/v1/western/chart-profile	western-profile	western_chart_profile_route_v1_western_chart_profile_post
POST	/v1/yogas/evaluate	yogas	yogas_evaluate_route_v1_yogas_evaluate_post

Documentation Boundary

Use this document for HTTP route presence and family status.

Use wiki/02_standards/API_REFERENCE.md for Python import surfaces, engine classes, engine functions, and canonical result vessels.

Use docs/architecture/MOIRA_SERVER_BOUNDARY.md for the governing rule that the server transports truth and the engine computes truth.

Use docs/architecture/MOIRA_SERVER_ROUTE_ADMISSION_CHECKLIST.md before adding or widening a route family.