Western technique conventions (W-05)

Status: Implemented v1 conventions · Task: W-05 · Updated: 2026-10-25 · Methods are available when their rule resources are admitted and features registered.

W-06–W-10 each implement one named convention. This directory fixes exactly one variant per technique, names the variants that stay unsupported, and lists the Composer facts each variant consumes. A specification is not a capability: capabilities() keeps reporting a technique as unsupported until its implementation task lands, its fixtures pass and the host registers the feature (W-11).

Admitted identity is the TechniqueIdentity the feature must carry. The same triple is the rulebook manifest entry (technique, version, variant); the payload hash binds the tables that variant reads. A rulebook manifest admits at most one entry per technique, so a second variant of a technique is a second bundle, never a request flag.

Shared rules

These hold in every specification below and are not repeated per technique.

1. One named variant. A different convention is a different version/variant and needs its own fixtures and review. No request field may switch a convention at call time.
2. Derived is not observed. Every transformed longitude carries DerivedPointOrigin with method, version and the admitted source identities. A derived point is never described as a provider position, and geometryChartFrom is never used to disguise one as observed.
3. Unknown derivatives stay null. A technique that supplies speedLongitude must define the derivative of its transformation (harmonics does; composite, directions and progression angles do not). null reaches the shared geometry as phase: 'unknown'; zero is never substituted.
4. Geometry is evaluated, never re-derived. Aspect separation, orb and cusp placement come from the injected GeometryPort. No Western package repeats resolveAspects or house placement.
5. No cross-technique imports. A technique may read another technique’s result through WesternFeatureContext.dependencies; it never imports the package. Shared shapes come from @astrology/western and @astrology/chart-composer as types only.
6. Half-open instants, closed tolerances. Windows are [start, end] for solved events and [start, end) for occupancy; every stated tolerance is inclusive on the side that matters and is carried in the result, not left implicit.
7. Angles are optional inputs. A technique that needs the ascendant or midheaven degrades that factor with missing-angles instead of substituting the natal angle or recomputing one.
8. Fixtures are synthetic and exact. Every example below is defined by an explicit formula over UTC (civil clock time) epoch milliseconds, so it runs without a provider, ephemeris file or network. A real-chart fixture is added only when a reviewer records its source and tolerance.

Cross-cutting prerequisites

P0–P2 are covered by the coordinator integration fixtures. P3 is enforced per supplied composite pair. Derived geometry never fabricates an astronomical snapshot.

Unsupported variants

The following are named here so they are rejected explicitly rather than aliased to a supported variant. Each needs its own specification, fixtures and version:

Review gate

Each supplied production rulebook should record a named source per convention in its manifest sources entry. Implementations and synthetic fixtures verify these specified numerical conventions; they do not replace independent real-chart validation or supply a reviewed production rulebook. The numerical conventions fixed here (year length, Naibod rate, tolerances, bounds) are part of the technique version: changing one is a new version, not an edit to this document.