# 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](HELLENISTIC_API_INVENTORY.generated.md). 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: 531 - Registered OpenAPI operations: 531 (GET 48, POST 483) - Operational/meta paths: 4 - Versioned `/v1` paths: 527 - 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 VED-013 adds `GET /v1/jaimini/extended/profiles`, `POST /v1/jaimini/extended/chara-dasha/profile`, and `POST /v1/jaimini/extended/argala/assessment`. Three Rangacharya recipes and three bounded BPHS/PVR/Rath Argala assessments share canonical engine results with Python/facade consumers. Strict sign/longitude unions retain input precision; explicit references, count grades, directed quarters and unresolved comparison reasons survive transport. Legacy Argala receives an additive computation receipt and direct-input hardening. See the [profile standard](JAIMINI_PROFILE_ASSESSMENT_STANDARD.md) for executable IDs, required nodes, calendar scope and compatibility. VED-012 adds `GET /v1/yogas/extended/catalogue` and `POST /v1/yogas/extended/evaluate`. Discovery exposes four named profiles, 21 admitted rules and BPHS 39.35 as `research_required`. Evaluation requires exactly seven classical `sidereal_longitudes`, `lagna_sidereal_lon` in `[0,360)`, and one to four unique `profile_ids`. Strict `include_absent` defaults to true; false retains formed proofs and all qualifications while preserving complete evaluated counts. Typed source/role/frame/branch evidence and applied-policy receipts survive transport. Extra inputs, coercible booleans and invalid values produce structured 422 validation errors. See the [source-defined yoga standard](YOGA_EXTENSION_STANDARD.md). Legacy `/v1/yogas/evaluate` now exposes condition/formation states and applied policy, retaining indeterminate motion-dependent results when filtered. Its finite-angle normalization and doctrine defaults remain unchanged. VED-008 adds `GET /v1/muhurta/shuddhi/catalogue` and `POST /v1/muhurta/shuddhi/direct` / `POST /v1/muhurta/shuddhi/day`. The [source-profile standard](PANCHANGA_SHUDDHI_STANDARD.md) defines source-separated Panchaka, Tara-cycle, Yoga timing and Karana/Bhadra findings, strict supplied inputs and bounded reader-owned day cells. Typed transport preserves restrictions, exceptions, missing components and numerical uncertainty independently; it does not change existing scores/search. Gochara supplied-position evaluation, integrated profiles, reader-bound epoch and aware-datetime composition, and the cited doctrine catalogue are registered under `/v1/gochara`. See the [Gochara REST standard](GOCHARA_REST_STANDARD.md) for policies, strict numeric/BAV input rules, clock/frame receipts, resource outcomes, partial observation truth and source limitations. Dated forecast windows remain open. The 6 October 2026 Vedic surface closure also strengthens the existing direct yoga, avastha, extended Jaimini, Vimshopaka, Kakshya and Shodhya requests. Their affected numeric fields require finite JSON numbers, and named participant/sign domains reject unknown keys. Avastha exposes its optional `vriddha_fraction` and returns the selected relationship scheme/fraction. Co-lord Arudha requests require both named nodes; eight-karaka Karakamsa requests require Rahu. The [closure ledger](VEDIC_SURFACE_REST_COMPLETENESS_2026-10-06.md) records the exact validated scope and remaining admissions. The 8 October Sayanadi admission adds optional complete context to `POST /v1/avasthas/evaluate`, the nine-subject supplied-input route `POST /v1/avasthas/sayanadi`, and reader-bound birth composition at `POST /v1/avasthas/from-datetime`. Strict discriminated clocks, source-owned name mapping, full arithmetic trace, separate node subjects and explicit sunrise/ghati unavailability preserve canonical engine truth. See the [Sayanadi standard](SAYANADI_ADMISSION_STANDARD.md) and [execution receipt](SAYANADI_VALIDATION_2026-10-08.md). 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 | 6 | | 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` | The four void-of-course responses preserve their legacy window, state, and range fields and add typed `computation_truth`. That receipt names the explicit traditional or modern body policy, directional Ptolemaic targets, exact-perfection rule and residual, tropical sign boundaries, inclusive state rule, scan and bisection policy, UT1/TT/TDB clock binding, apparent geocentric true-ecliptic frame and corrections, and serving DE/LE identity. A sign with no admitted exact aspect reports the sign-entry fallback rather than implying a hidden aspect. These fields describe Moira's declared VOC method; they do not claim that every astrological tradition uses the same definition. | 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](STELLIUM_ANALYSIS_STANDARD.md). ### 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 `POST /v1/panchanga/lunar-month` accepts strict finite `jd_ut1` and named `system`/`ayanamsa_system`/`solver_tolerance_seconds` policy. It preserves three surrounding lunations, solved phase/ingress brackets, month labels and Adhika/Kshaya evidence. Exceptional Purnimanta mappings return typed domain unavailability. [Source and policy standard](LUNAR_MONTH_AND_FESTIVAL_POLICY.md). This is an astronomical month context; festival selection is not yet admitted. The daily product is a separate local-date contract with sunrise-owned Vara, solved angular limb endings and explicit solar unavailability. Its [standard](DAILY_PANCHANGA_STANDARD.md) documents policy, timestamps and a complete request. Existing instant/profile routes retain their current conventions. | 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` | | POST | `/v1/panchanga/day` | `panchanga_day_route` | | POST | `/v1/panchanga/lunar-month` | `panchanga_lunar_month_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. Later admissions extend this family with personal Tara/Chandra scoring and bounded sampled search under `POST /v1/muhurta/personal/score` and `POST /v1/muhurta/search`; see the [personal/search standard](MUHURTA_PERSONAL_SEARCH_STANDARD.md). VED-007 adds `POST /v1/muhurta/named/direct` and `POST /v1/muhurta/named/day`. The first accepts supplied UT1 solar anchors and an explicit Monday=0 weekday. The second derives reader-bound solar anchors for one civil sunrise date, location and timezone. Both return canonical Abhijit/Brahma intervals, source policies, endpoint bounds, separate weekday eligibility and per-window unavailable reasons. Default Brahma uses Arunadatta's fixed-ghati reading; proportional-night compatibility is explicitly selectable. See the [named interval standard](NAMED_MUHURTA_STANDARD.md). Activity-specific guidance, recommendation language, Western doctrine, arbitrary predicates/scorers and async jobs remain outside this Muhurta admission. The separate Ramesey v1 route is a different product. ## 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` | | POST | `/v1/shadbala/chart/bhava` | `bhava_bala_chart_route` | | POST | `/v1/shadbala/chart/full` | `shadbala_full_route` | All six routes include `policy_receipt`: requested/applied ayanamsa, requested/resolved/effective house system, actual polar fallback and optional Hora lord. Unknown house systems reject before computation; supported names and codes resolve through the engine registry. The calculation uses its owning engine's reader, including when the kernel is automatically discovered. See [Vedic REST admission](VEDIC_REST_ADMISSION_STANDARD.md). ## 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` | VED-005 rejects coerced numeric inputs and unknown classical identities, including relationship-map keys. Valid partial classical maps remain admitted; missing entries are not fabricated. Direct ayanamsa labels retain their upstream provenance meaning; chart-backed conversion requires a registered system. The 30-route [Vedic admission contract](VEDIC_REST_ADMISSION_STANDARD.md) also covers dasha, Sade Sati and `/v1/vedic/chart-profile`. Civil dates reject numeric epochs and numeric timestamp strings. The profile exposes evaluated component frames, mixed-frame status, applied dasha year basis and supplied inactive inputs in `policy_receipt`; omitted sections remain omitted. ## 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/d60/sign` | `d60_sign_route` | | POST | `/v1/varga/vimshopaka` | `vimshopaka_route` | | 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` | Every `VargaPointResponse` includes canonical nullable `deity`, applied `d60_method`, `d60_source_references` and `d60_degree_attribution`. Named D60 supplies its corrected deity string; generic divisor 60 and other divisions retain `deity=null`. Full D60 numeric output uses `harmonic` by default, with `pvr_textbook_linear` and `classical_derived_linear` explicitly available on named products; non-D60 points report `d60_method=null`, an empty source array and null degree attribution. Seven named/full Shodashvarga request shapes accept the optional enumeration `d60_method=harmonic|pvr_textbook_linear|classical_derived_linear`. `bphs_santhanam_sign`, unknown methods and null selections fail with HTTP 422 before chart derivation. Generic inputs retain their original contract. Both source full-position selections apply only to D60. Another named selector receives 422; Shodashvarga applies the selected convention only to its D60 entry. Direct source-profile scalar/batch inputs reject booleans, strings and nonfinite numbers without coercion. The result names the dated textbook/linear composition and both positional authorities; the corrected deity table remains Santhanam-owned. Its computed degrees are abstract divisional positions, with `d60_degree_attribution=modern_composed`. `classical_derived_linear` supplies full degrees with BPHS Santhanam sign assignment and Moira's explicit proportional-degree extension. Its receipt reports `d60_degree_attribution=classical_derived`, the reviewed classical and commentarial source chain, and a Moira derivation locator. It does not label a direct classical D60 degree prescription. Harmonic degrees report `generic_harmonic`. Source-profile composition normalizes a shared circular input before other divisions and strength relationships, preserving tiny negative left limits without another division rounding the input to 360. `POST /v1/varga/d60/sign` accepts strict finite `sidereal_longitude` and `method=harmonic|bphs_santhanam_sign|pvr_textbook_linear|classical_derived_linear` (default harmonic). Its typed response contains normalized input longitude, sign index/name/symbol, applied method, `position_scope=sign_only` and `source_reference`. It contains no continuous D60 degree or mapped longitude. The source commentary example, Capricorn 13 degrees 25 minutes, yields Pisces; the harmonic method yields Gemini. Vimshopaka accepts `d60_method` and returns each planet's actual applied method and positional source array. A nondefault selection requires `dashavarga` or `shodashavarga`; other groups report null/empty receipts and reject any nondefault selection. See the [D60 source standard](D60_SOURCE_ADMISSION_STANDARD.md) for edition limits, exact name migration values and weighted effects. ## Bounded Chara Dasha contract `POST /v1/jaimini/extended/chara-dasha` accepts `cycles` as a strict integer 1 or 2, default 1. The seven-body map and finite longitude/epoch inputs are required. `node_longitudes` may be omitted/null; a supplied map must contain exactly Rahu and Ketu. Empty/partial maps and bool/string/float/out-of-bound cycles fail with the standard HTTP 422 validation envelope. The response adds actual `period_count` and canonical `computation` containing `cycle_count`, `lord_mode`, `formulation_id`, `cycle_policy`, `year_basis`, `year_days` and `epoch_basis`. One cycle has 12 periods; two have 24 with retained first-cycle repetition and continuous endpoints. The server copies the engine receipt. The [Chara cycle standard](CHARA_DASHA_CYCLE_STANDARD.md) limits the source claim to the inspected published witness. ## 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` | ### Chart-Wheel Packet Truth `POST /v1/website/chart-wheel/packet` preserves the calculated longitude, wheel angle, and point coordinate for every returned body. Display-label placement is separate: each point reports `label_angle_deg`, `label_position`, and signed `label_displacement_deg`. The deterministic circular placement policy applies `min_label_separation_deg` without changing the underlying point. If the requested separation cannot fit the number of visible labels around 360 degrees, the packet uses the largest geometrically possible separation, emits `label_separation_reduced`, and records both the requested and effective constraints. The additive `computation_truth` object records the chart request's node selection, the chart-wheel configuration override and effective node state, requested and effective house-system policy, orientation source and anchor, aspect tier/orb policy, and the label-placement algorithm and displacement summary. Existing chart, house, zodiac, point, aspect, collision-group, and configuration fields retain their prior shapes. ### 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/avasthas/from-datetime` | avasthas | `avastha_birth_route_v1_avasthas_from_datetime_post` | | `POST` | `/v1/avasthas/sayanadi` | avasthas | `sayanadi_route_v1_avasthas_sayanadi_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/kalachakra/chart/current` | kalachakra-dasha | `chart_current_v1_dasha_kalachakra_chart_current_post` | | `POST` | `/v1/dasha/kalachakra/chart/sequence` | kalachakra-dasha | `chart_sequence_v1_dasha_kalachakra_chart_sequence_post` | | `POST` | `/v1/dasha/kalachakra/current` | kalachakra-dasha | `current_v1_dasha_kalachakra_current_post` | | `GET` | `/v1/dasha/kalachakra/profiles` | kalachakra-dasha | `profiles_v1_dasha_kalachakra_profiles_get` | | `POST` | `/v1/dasha/kalachakra/sequence` | kalachakra-dasha | `sequence_v1_dasha_kalachakra_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` | | `GET` | `/v1/gochara/doctrine-options` | gochara | `doctrine_route_v1_gochara_doctrine_options_get` | | `POST` | `/v1/gochara/evaluate` | gochara | `evaluate_route_v1_gochara_evaluate_post` | | `POST` | `/v1/gochara/from-datetimes` | gochara | `datetimes_route_v1_gochara_from_datetimes_post` | | `POST` | `/v1/gochara/from-epochs` | gochara | `epochs_route_v1_gochara_from_epochs_post` | | `POST` | `/v1/gochara/profile` | gochara | `profile_route_v1_gochara_profile_post` | | `GET` | `/v1/gochara/windows/capabilities` | gochara | `window_capabilities_route_v1_gochara_windows_capabilities_get` | | `POST` | `/v1/gochara/windows/from-datetimes` | gochara | `window_datetimes_route_v1_gochara_windows_from_datetimes_post` | | `POST` | `/v1/gochara/windows/from-epochs` | gochara | `window_epochs_route_v1_gochara_windows_from_epochs_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/argala/assessment` | jaimini | `argala_assessment_route_v1_jaimini_extended_argala_assessment_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/chara-dasha/profile` | jaimini | `chara_profile_route_v1_jaimini_extended_chara_dasha_profile_post` | | `POST` | `/v1/jaimini/extended/karakamsa` | jaimini | `karakamsa_route_v1_jaimini_extended_karakamsa_post` | | `GET` | `/v1/jaimini/extended/profiles` | jaimini | `jaimini_profiles_route_v1_jaimini_extended_profiles_get` | | `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` | | `GET` | `/v1/muhurta/business/catalogue` | muhurta | `business_catalogue_route_v1_muhurta_business_catalogue_get` | | `POST` | `/v1/muhurta/business/compare` | muhurta | `business_compare_route_v1_muhurta_business_compare_post` | | `POST` | `/v1/muhurta/business/datetime` | muhurta | `business_datetime_route_v1_muhurta_business_datetime_post` | | `POST` | `/v1/muhurta/business/direct` | muhurta | `business_direct_route_v1_muhurta_business_direct_post` | | `POST` | `/v1/muhurta/business/windows` | muhurta | `business_windows_route_v1_muhurta_business_windows_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` | | `GET` | `/v1/muhurta/doshas/catalogue` | muhurta | `dosha_catalogue_route_v1_muhurta_doshas_catalogue_get` | | `POST` | `/v1/muhurta/doshas/day` | muhurta | `dosha_day_route_v1_muhurta_doshas_day_post` | | `POST` | `/v1/muhurta/doshas/direct` | muhurta | `dosha_direct_route_v1_muhurta_doshas_direct_post` | | `GET` | `/v1/muhurta/lagna/catalogue` | muhurta | `muhurta_lagna_catalogue_route_v1_muhurta_lagna_catalogue_get` | | `POST` | `/v1/muhurta/lagna/datetime` | muhurta | `muhurta_lagna_datetime_route_v1_muhurta_lagna_datetime_post` | | `POST` | `/v1/muhurta/lagna/direct` | muhurta | `muhurta_lagna_direct_route_v1_muhurta_lagna_direct_post` | | `GET` | `/v1/muhurta/marriage/catalogue` | muhurta | `marriage_catalogue_route_v1_muhurta_marriage_catalogue_get` | | `POST` | `/v1/muhurta/marriage/datetime` | muhurta | `marriage_datetime_route_v1_muhurta_marriage_datetime_post` | | `POST` | `/v1/muhurta/marriage/direct` | muhurta | `marriage_direct_route_v1_muhurta_marriage_direct_post` | | `POST` | `/v1/muhurta/marriage/windows` | muhurta | `marriage_windows_route_v1_muhurta_marriage_windows_post` | | `POST` | `/v1/muhurta/named/day` | muhurta | `named_muhurta_day_route_v1_muhurta_named_day_post` | | `POST` | `/v1/muhurta/named/direct` | muhurta | `named_muhurta_direct_route_v1_muhurta_named_direct_post` | | `POST` | `/v1/muhurta/personal/score` | muhurta | `muhurta_personal_score_route_v1_muhurta_personal_score_post` | | `POST` | `/v1/muhurta/search` | muhurta | `muhurta_search_route_v1_muhurta_search_post` | | `GET` | `/v1/muhurta/shuddhi/catalogue` | muhurta | `shuddhi_catalogue_route_v1_muhurta_shuddhi_catalogue_get` | | `POST` | `/v1/muhurta/shuddhi/day` | muhurta | `shuddhi_day_route_v1_muhurta_shuddhi_day_post` | | `POST` | `/v1/muhurta/shuddhi/direct` | muhurta | `shuddhi_direct_route_v1_muhurta_shuddhi_direct_post` | | `POST` | `/v1/muhurta/special/day` | muhurta | `special_muhurta_day_route_v1_muhurta_special_day_post` | | `POST` | `/v1/muhurta/special/solar` | muhurta | `special_muhurta_solar_route_v1_muhurta_special_solar_post` | | `POST` | `/v1/muhurta/special/yogas` | muhurta | `special_muhurta_yogas_route_v1_muhurta_special_yogas_post` | | `GET` | `/v1/muhurta/travel/catalogue` | muhurta | `travel_catalogue_route_v1_muhurta_travel_catalogue_get` | | `POST` | `/v1/muhurta/travel/datetime` | muhurta | `travel_datetime_route_v1_muhurta_travel_datetime_post` | | `POST` | `/v1/muhurta/travel/direct` | muhurta | `travel_direct_route_v1_muhurta_travel_direct_post` | | `POST` | `/v1/muhurta/travel/windows` | muhurta | `travel_windows_route_v1_muhurta_travel_windows_post` | | `GET` | `/v1/muhurta/vastu/catalogue` | muhurta | `vastu_catalogue_route_v1_muhurta_vastu_catalogue_get` | | `POST` | `/v1/muhurta/vastu/datetime` | muhurta | `vastu_datetime_route_v1_muhurta_vastu_datetime_post` | | `POST` | `/v1/muhurta/vastu/direct` | muhurta | `vastu_direct_route_v1_muhurta_vastu_direct_post` | | `POST` | `/v1/muhurta/vastu/windows` | muhurta | `vastu_windows_route_v1_muhurta_vastu_windows_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/natal-discovery/dispositors` | natal-discovery | `natal_dispositors_route_v1_natal_discovery_dispositors_post` | | `POST` | `/v1/natal-discovery/lunar-context` | natal-discovery | `natal_lunar_context_route_v1_natal_discovery_lunar_context_post` | | `POST` | `/v1/natal-discovery/shape` | natal-discovery | `natal_shape_route_v1_natal_discovery_shape_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/day` | panchanga | `panchanga_day_route_v1_panchanga_day_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/panchanga/lunar-month` | panchanga | `panchanga_lunar_month_route_v1_panchanga_lunar_month_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/d60/sign` | varga | `d60_sign_route_v1_varga_d60_sign_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` | | `GET` | `/v1/yogas/extended/catalogue` | yogas | `yoga_extensions_catalogue_route_v1_yogas_extended_catalogue_get` | | `POST` | `/v1/yogas/extended/evaluate` | yogas | `yoga_extensions_evaluate_route_v1_yogas_extended_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.