HARMOGRAMS_BACKEND_STANDARD - TheDaniel166/moira GitHub Wiki
Harmograms Backend Standard
Version: 0.1 Date: 2026-06-14 Status: admitted for bounded transport Scope: public backend standard for caller-supplied harmogram vector, intensity-spectrum, projection, and trace products
1. Computational Ownership
The admitted backend owner is moira.harmograms.
Admitted engine entrypoints:
point_set_harmonic_vectorzero_aries_parts_harmonic_vectorintensity_function_spectrumproject_harmogram_strengthharmogram_trace
The REST server is a transport adapter only. It must not reimplement Fourier components, intensity sampling, Zero-Aries parts construction, projection terms, or trace series.
2. Input Ownership
P-GAP-06 accepts caller-supplied named longitudes and caller-supplied trace samples.
It does not:
- construct natal charts
- generate dynamic ephemeris samples
- derive transit, directed, or progressed positions
- apply ayanamsa or house policy
- infer body identities from a catalogue
Every longitude is a finite ecliptic degree value owned by the caller and normalized by the engine.
3. Admitted Products
Admitted products:
- point-set harmonic vectors
- Zero-Aries-parts harmonic vectors
- intensity-function spectra for admitted harmonic aspect families
- projections of source vectors onto intensity spectra
- bounded harmogram traces over explicit time samples
Trace families admitted at transport:
dynamic_zero_aries_partstransit_to_natal_zero_aries_partsdirected_to_natal_zero_aries_partsprogressed_to_natal_zero_aries_parts
The route family exposes computation, not interpretation. Strength values, components, phases, projection terms, and provenance are returned; judgement, advice, recommendation language, and doctrine scoring are not.
4. Policy Semantics
The transport boundary admits only policy combinations that map directly to existing engine policy vessels.
Intensity family determines orb mode:
cosine_bell_harmonic_aspects->cosine_belltop_hat_harmonic_aspects->top_hattriangular_harmonic_aspects->triangulargaussian_harmonic_aspects->gaussian
Conjunction inclusion determines symmetry:
include_conjunction=true->star_symmetricinclude_conjunction=false->conjunction_excluded
Trace family determines chart domain:
dynamic_zero_aries_parts->dynamic_sky_only_tracetransit_to_natal_zero_aries_parts->transit_to_natal_tracedirected_to_natal_zero_aries_parts->directed_or_progressed_traceprogressed_to_natal_zero_aries_parts->directed_or_progressed_trace
The point-set policy and intensity policy must share the same harmonic domain.
5. Bounds
Public transport must be synchronous and bounded.
Admitted limits:
- maximum point-set positions:
32 - maximum relational positions per side:
24 - maximum harmonic number:
128 - maximum harmonic-domain width:
32 - minimum intensity sample count:
256 - maximum intensity sample count:
8192 - maximum orb width:
90degrees - maximum trace samples:
64 - maximum trace cells, defined as
len(samples) * len(harmonic_numbers):256
The server must reject requests that exceed these limits with the standard validation envelope.
6. Response Truth
Responses must expose:
- source vector kind
- vector policy and harmonic domain
- source/body names
- harmonic-zero amplitude
- harmonic components
- intensity policy and realization mode
- projection terms and total strength
- trace sample times and series strengths
- provenance naming
moira.harmogramsand the exact engine entrypoint
Trace responses may use compact serialization, but must preserve the sample source vector and projection terms for each sample.
7. Non-Goals
This standard does not admit:
- chart-backed harmogram generation
- ephemeris-backed dynamic sampling
- arbitrary user-defined intensity functions
- unbounded sweeps
- async jobs
- dense rendering meshes
- harmonic interpretation text
- recommendation language
- chart condition profiles or electional scoring
Future chart-backed or rendering surfaces require separate admission work.