1. Calculation foundations
These choices affect every nakshatra, tithi and festival date. Settling them first fixes everything downstream.
Why it matters: The ayanamsa fixes where every nakshatra and rashi boundary sits, so it moves tithi, nakshatra and festival dates. The engine's stored setting is currently Lahiri (selected by Brahmmuni Swami) but marked "not in the PDF — needs Swami verification." The value that exactly reproduces Shri Hari's janmapatrika is Surya-Siddhanta (Revati-paksha).
Why it matters: The વ્રત-ઉત્સવ નિર્ણય document colour-codes each ruling by its source — Satsangijeevan (સ.જી.), Nirnaysindhu / Dharmasindhu (નિ.સિં./ધ.સિં.), Vratparva Vivek (વ્ર.પ.વિ.), and the Bhuj Mandir's own ruling. When two sources give different days, the engine needs one fixed order of precedence.
Why it matters: For a few observances (e.g. Rama Navami and certain Ekadashis) the Vaishnava and Smarta traditions can fall on different civil days. The engine holds both options.
Why it matters: The Ekadashi logic (waiting past Harivasara, the Dashami-vedh rule of ~5 ghadi before sunrise, and a set of numbered scenarios) currently cites the Utsav Nirnay booklet (Brahmmuni Swami) as its source.
2. Calendar & era display
How years and eras are numbered and labelled on the printed output.
Why it matters: The Vikram Samvat year can roll over at Kartik Sud 1 (Kartikadi — the Gujarati custom, just after Diwali) or at Chaitra Sud 1 (Chaitradi). The engine currently treats "Vikram Samvat" as Kartikadi.
Why it matters: The booklet prints a "Shri Swaminarayan Shaka" era count alongside Vikram Samvat and Shaka.
Why it matters: North and South India number the 60-year Jovian cycle one year apart. The engine holds both; we must pick one to print.
Why it matters: Purely a naming choice for Shravan Vad 8 on the printed output.
3. Printed & digital products
What the engine actually produces, and how much editorial detail each output carries.
Why it matters: The materials mention several surfaces — the annual Nirnay booklet (also called tipni / ટીપણી?), a page-a-day rojmel diary, a month calendar, a wall calendar, and a public my-location digital calendar. We need the definitive list.
Why it matters: The source document carries curated ritual prose per festival — deity dress (કેશરી વાઘા), aarti timing (આરતી મધ્યાહ્ને), cradle/hindola in-and-out, thal offerings, and so on. Deciding where these appear sets how large the curated (hand-maintained) content set must be.
Why it matters: Organisation-wide default events currently inherit from Bhuj Mandir; individual temples can override a local date.
Why it matters: A verification report compares the engine's dates against two published sources. When they disagree, one must be the authority.
4. Unresolved determinations needs your method
The engine cannot currently reproduce these from any standard method — they need the authority's exact rule or source.
Why it matters: The printed Vyatipata / Vaidhriti "mahapat" start-and-end times do not match any of the three standard algorithms we tried (drik-siddha and Surya-Siddhanta pata variants). We cannot print these correctly without the exact method.
Why it matters: Each Sankranti traditionally carries a symbolic vehicle/mount (vahan), what it gazes upon, its dress, etc. This is editorial lore, not an astronomical calculation.
Why it matters: Some entries are marked red / "not yet cleared" in the source document, meaning the day is not final. The engine tracks these as uncleared.
Why it matters: When a tithi repeats (vriddhi) or is skipped (kshaya), the older method sometimes emitted two competing civil dates for one observance.
Appendix — Engineering follow-ups
- vyatipata is declared but hardcoded false in the Ganga Dussehra tie-break — compute it, or keep stubbed?
- anumati / raka moonrise-Pratipada guard is a deliberate no-op ("never fires in practice") — leave it or implement?
- kshaya_preference: "first" never differs from the default — remove or reserve?
- document_status is a free-form string with several distinct values — fix a proper enum, and confirm whether any value gates behaviour or is pure metadata.
- moon_sign_strength / unresolved_conditions (Hindola Moon-in-Taurus) captured but never enforced — become a hard filter, or stay metadata?
- both_partial_mode: "greater_extent" generic path is unused (Shivratri / Mahalaya route through evaluators instead) — keep or drop?
- Eclipse Saros number / member fields are hardcoded 0 — populate the Saros data, or drop the fields?
- Bhadra mukha / madhya / puchha sub-windows are carried in the data but only whole-bhadra rejection is coded — is ignition-muhurta selection inside the tail (puchha) required?