Dignities & Sect

Moira Dignities Backend Standard

Governing Principle

The Moira dignities backend is a sovereign computational subsystem. Its definitions, layer boundaries, terminology, invariants, failure doctrine, and determinism rules are stated here and are frozen until explicitly superseded by a revision to this document.

This document reflects current implementation truth as of Phase 11. It describes the subsystem that actually exists in moira/dignities.py; it does not describe aspirational future capabilities.

---

Part I - Architecture Standard

1. Authoritative Computational Definitions

1.1 Core dignity computation

A planetary dignity result in Moira is:

The authoritative per-planet output of DignitiesService.calculate_dignities, computed for a planet admitted by the active essential doctrine from normalised sign state, house placement, sect context, solar proximity, and doctrine admitted under DignityComputationPolicy.

The computational core remains the authority for:

• essential dignity scoring
• accidental dignity scoring
• sect and hayz truth
• solar condition truth
• admitted mutual-reception scoring
• total score composition

Later layers may classify, preserve, aggregate, or inspect this truth. They may not recompute the doctrine independently.

1.2 Essential dignity

An essential dignity in Moira is:

A typed composition of independently evaluated domicile, exaltation, triplicity, bound, face, detriment, fall, and peregrine components.

The returned essential_dignity string and essential_score integer remain the legacy single-label compatibility projection. essential_truth.components is the authoritative non-erasing receipt and may preserve simultaneous positive and negative facts that the compatibility label cannot express.

1.3 Accidental dignity

An accidental dignity in Moira is:

The sum of doctrine-admitted accidental conditions attached to one planet, where each admitted condition contributes a fixed signed score and explicit preserved truth.

The currently embodied accidental dimensions are:

• house strength
• motion state
• solar condition
• admitted mutual reception
• sect / hayz truth
• planetary joy
• oriental / occidental solar-relative phase
• malefic besieging

Every condition admitted by the active accidental policy is assembled as an explicit AccidentalDignityCondition before it contributes to accidental_score. The underlying PlanetarySolarPhaseTruth, SolarProximityTruth, and BesiegingTruth are preserved independently of whether policy admits a compatibility condition or the required chart dependencies are complete.

1.4 Reception

A reception in Moira is:

A directed relational truth in which one planet occupies a sign belonging to another planet under an admitted reception basis.

Reception is formalised with three distinct layers of meaning:

The current default doctrine admits domicile and exaltation reception bases. The current default scoring semantics use only the admitted mutual subset.

1.5 Planetary condition profile

A planetary condition profile in Moira is:

A backend-only integrated structural summary derived from one PlanetaryDignity, combining preserved truth and classifications across the essential, accidental, sect, solar, and reception layers.

PlanetaryConditionProfile is a consumer of dignity truth, not a second dignity engine.

1.6 Chart condition profile

A chart condition profile in Moira is:

A deterministic chart-wide aggregation of per-planet condition profiles, reporting structural counts and totals without adding interpretation.

It includes at least:

• ordered per-planet profiles
• reinforced / mixed / weakened counts
• strengthening / weakening / neutral totals
• strongest / weakest planets under existing structural criteria

1.7 Condition network profile

A condition network profile in Moira is:

A deterministic directed graph projection over admitted reception truth and integrated per-planet condition profiles.

It includes at least:

• one node per planet profile
• one directed edge per admitted reception relation
• unilateral vs mutual edge visibility
• incoming / outgoing / mutual counts per node
• isolated planets
• direct-degree connectivity summaries

This graph is a structural projection only. It is not an interpretive network layer.

---

2. Layer Structure

The backend is organised into one computational core plus ten formalised post-core layers. Each layer consumes outputs already produced below it. No layer reaches upward.

Core      - Authoritative dignity computation (`calculate_dignities`)
Phase  1  - Truth preservation
Phase  2  - Classification
Phase  3  - Inspectability and vessel hardening
Phase  4  - Doctrine / policy surface
Phase  5  - Reception formalisation
Phase  6  - Reception inspectability / hardening
Phase  7  - Integrated planetary condition
Phase  8  - Chart-wide condition intelligence
Phase  9  - Reception / condition network intelligence
Phase 10  - Full-subsystem hardening
Phase 11  - Architecture freeze / validation codex

Layer boundary rules

A layer above the core:

• may consume preserved truth from lower layers
• may classify or aggregate earlier truth
• may add invariant checks that reject internally inconsistent vessels
• may not recompute dignity doctrine independently
• may not alter legacy scoring semantics by reclassification
• may not mutate an earlier-layer vessel in place
• may not introduce interpretation, recommendation, or UI concerns

---

3. Delegated Assumptions

The dignity backend delegates to external modules without redefining them:

Changes to those delegated sources propagate into the dignity subsystem. This document does not freeze their independent doctrine.

---

4. Doctrine Surface

4.1 Essential doctrine

The default essential doctrine is the classic fixed-table model encoded in:

• DOMICILE
• EXALTATION
• DETRIMENT
• FALL

EssentialDignityPolicy makes this doctrine explicit without changing the default result.

The admitted opt-in modern doctrine is:

• EssentialDignityDoctrine.MODERN_CO_RULERS

This doctrine extends domicile and detriment only:

The modern doctrine is co-rulership, not replacement. Saturn still holds Aquarius, Jupiter still holds Pisces, and Mars still holds Scorpio under this policy. No modern exaltation or fall table is admitted by the current engine.

4.2 Accidental doctrine

The accidental doctrine surface is explicit through:

• AccidentalDignityPolicy
• SolarConditionPolicy
• MutualReceptionPolicy
• SectHayzPolicy

The default policy is normative:

DignityComputationPolicy() preserves the currently admitted, named doctrine. It must not preserve a legacy behavior after that behavior has been shown to contradict the admitted source.

The accidental inclusion controls include:

Setting one of these fields to False removes that admitted condition from labels, the condition list, and additive scoring without changing the underlying sign, sect, house, or longitude inputs. Atomic truth remains preserved when it can be evaluated independently of policy. Hayz and Halb are separately selectable; when both are enabled, full Hayz takes precedence in the additive label/score while the underlying in_halb truth remains preserved.

4.3 Sect, hayz, and halb doctrine

Sect, Hayz, and Halb doctrine is embodied by:

• SECT
• PREFERRED_HEMISPHERE
• PREFERRED_GENDER
• HalbHayzDoctrine.AL_QABISI_BONATTI_DYKES_2007
• the explicit Mercury phase model

Under the admitted al-Qabisi/Bonatti lineage, Halb is not an exact-two-of-three approximation to Hayz. It is the planet's sect-relative hemisphere condition:

Hayz is Halb plus placement in a sign of the planet's own gender. The admitted gender table treats Sun, Jupiter, and Saturn as masculine; Moon, Venus, and Mars as feminine; and Mercury as neutral. Because no source-owned Mercury gender assignment is admitted, Mercury can receive explicit sect and Halb truth but hayz_evaluable=False and no invented Hayz judgment.

Mercury sect is phase-dependent. Standalone Mercury sect/Halb calls require an explicit mercury_rises_before_sun value. Chart-level dignity computation derives that phase only when both Sun and Mercury are present. It never substitutes a conjunction or another synthetic value for a missing Mercury. Exact Mercury/Sun conjunction returns typed not_evaluable phase, sect, Halb, and Hayz components rather than a false nocturnal default. An explicit Sun is mandatory because chart sect and solar conditions cannot be computed truthfully without it.

DignityHorizonFrame carries the actual Ascendant and Midheaven. When present, the engine identifies the open ecliptic semicircle containing the Midheaven as above the horizon, independently of house-system cusp numbering. Bodies on the Ascendant or Descendant receive typed not_evaluable Halb/Hayz truth; a Sun on that boundary fails chart-sect computation closed. Raw legacy callers that do not yet supply a horizon frame remain explicitly identified by HorizonComputationMethod.LEGACY_HOUSE_NUMBER.

This truth is preserved and classified explicitly even where it does not affect the current additive score.

4.4 Oriental / occidental phase doctrine

planetary_solar_phase_truth() is the governing object for the admitted longitude-only phase model. It applies to Mercury, Venus, Mars, Jupiter, and Saturn and preserves the forward zodiacal arc from the planet to the Sun.

• an arc strictly between 0 and 180 degrees is oriental;
• an arc strictly between 180 and 360 degrees is occidental;
• exact conjunction and exact opposition are direction boundaries and return typed not_evaluable truth;
• luminaries and bodies outside the admitted five-body set return typed not_evaluable truth rather than a fabricated phase.

oriental_occidental() remains the compatibility projection and returns None for every non-evaluable receipt. An Oriental/Occidental condition and score may be assembled only from an evaluated receipt and only when include_oriental_occidental=True. Disabling that policy suppresses the condition and score but does not erase evaluated geometric truth.

4.5 Solar-condition doctrine

solar_proximity_truth() is the governing raw geometric object. It computes the minimum angular distance from the body to the Sun and assigns exactly one exclusive band:

The raw truth is independent of policy admission. The Sun returns typed not_evaluable because solar proximity is not applicable to the Sun itself. The Moon receives raw geometric truth, but the default accidental policy does not assemble a solar condition for either luminary. Explicit include_for_luminaries=True may admit a Moon condition; it never turns the Sun into its own Cazimi condition.

Compatibility assembly retains the historical policy fall-through: if a narrower condition is disabled, the same distance may be admitted by an enabled wider condition. This does not alter the exclusive raw band preserved in SolarProximityTruth. Inclusive boundary comparisons use a 1e-12-degree arithmetic tolerance solely to contain floating-point subtraction error; it is not an observational or doctrinal orb.

4.6 Besieging doctrine

besieging_truth() is the governing enclosure object. It requires the complete Classic 7 longitude set plus an explicit or uniquely inferable target identity. It then preserves the nearest distinct classical body in each directed zodiacal direction.

• missing required bodies or target identity return typed not_evaluable;
• a body conjunct the target, a tied nearest neighbour, or an unresolved direction boundary returns typed not_evaluable;
• an evaluated result is besieged only when the two directional neighbours are Mars and Saturn and each is within the configured orb;
• directed neighbour distances occupy (0, 360) degrees; the independently configured eligibility orb remains limited to (0, 180] degrees;
• an evaluated False remains distinct from incomplete dependencies or ambiguous geometry;
• only evaluated True truth may assemble the besieged condition and score.

is_besieged() remains the flattened compatibility projection and therefore returns None for both evaluated absence and non-evaluable truth. Consumers that need to distinguish those states must use besieging_truth().

4.7 Reception doctrine

The formal reception basis currently supported is limited to what the engine already computes cleanly:

• domicile reception
• exaltation reception

No other reception basis is implied by this document.

---

5. Public Surface

The following public backend entry points are authoritative:

No caller should reconstruct hidden doctrine from flattened labels when a structured truth or classification field already exists.

---

6. Terminology Freeze

The following terminology is normative and must not drift casually:

In particular:

• classification must remain descriptive, not interpretive
• inspectability helpers must remain derived only
• condition profiles must remain integrative, not doctrinally independent
• network profiles must remain structural, not interpretive

---

7. Failure Doctrine

The dignity subsystem follows a strict split:

• bad external inputs fail with ValueError
• internally inconsistent result vessels fail with ValueError at construction
• invariant drift is treated as an implementation defect, not a recoverable state

The subsystem may not silently coerce malformed dignity inputs into a valid chart representation.

---

8. Explicit Non-Goals

The dignity backend does not, in this frozen phase:

• perform interpretation
• provide recommendation logic
• build reception-network topology beyond direct structural graphing
• perform chart-wide interpretive synthesis
• redefine doctrine outside the explicit policy surface

---

Part II - Validation Codex

9. Validation Environment

No dignity test may be modified to make the implementation pass. A failing test is treated as an implementation defect unless the test itself is proven wrong.

---

10. Test Surface Register

---

11. Validation Doctrine

11.1 What must be validated per layer

11.2 What validation must not do

• treat a changed score as acceptable because the structured truth became richer
• bypass the policy surface to test an unsupported doctrine
• assert interpretive meaning from structural labels
• accept non-deterministic ordering in profiles, summaries, or network outputs
• weaken failure behavior to make malformed inputs appear tolerated

---

12. Invariant Register

This register is the normative source of truth for subsystem invariants.

INV-CORE - Core dignity invariants

INV-TRUTH - Truth preservation invariants

INV-CLASS - Classification invariants

INV-REC - Reception invariants

INV-COND - Planetary condition invariants

INV-CHART - Chart-wide aggregation invariants

INV-NET - Network invariants

INV-POL - Policy invariants

INV-IN - Input invariants

---

13. Determinism Register

The following ordering guarantees are normative:

Input permutation must not change the semantic output of the public dignity surfaces.

---

14. Guaranteed Failure Conditions

The following inputs must always fail clearly and consistently.

The exact message text may evolve for clarity, but the failure type and semantic reason must remain stable.

---

15. Validation Commands

The minimum validation commands for this subsystem freeze are:

.venv\Scripts\python.exe -m pytest tests\unit\test_moira_dignities_and_lots.py -q
.venv\Scripts\python.exe -m pytest tests\unit\test_rule_engine_validation.py -q -k dignity
.venv\Scripts\python.exe -m pytest tests\unit\test_hellenistic_source_goldens.py -q -k "bound or planetary_joy"

When implementation files change, syntax validation may also be run:

.venv\Scripts\python.exe -m py_compile moira\dignities.py tests\unit\test_moira_dignities_and_lots.py tests\unit\test_hellenistic_source_goldens.py

---

16. Freeze Rule

After this phase, any change to the dignity backend that alters:

• default scores
• default admission behavior
• invariant meaning
• failure semantics
• ordering guarantees
• terminology frozen in Section 6

must be treated as an explicit architecture change and accompanied by a documented revision to this standard.