d2cd5a369f
- Add sanitized Jyotish benchmark suite with fictional/public smoke samples - Include benchmark scripts and markdown reports while excluding raw JSON/CSV outputs - Add open-source Jyotish project comparison research - Add complete technique coverage roadmap - Add privacy-safe PDF chart validation methodology - Update SKILL.md and CHANGELOG with v6.1.9 scope and privacy boundaries Validation: - py_compile benchmarks/jyotish/scripts/*.py passed - quality gate passed with 35 pytest tests and golden case
110 lines
5.0 KiB
Markdown
110 lines
5.0 KiB
Markdown
# PDF Chart Reading Validation Methodology
|
|
|
|
> Version: v6.1.9-public-methodology
|
|
> Purpose: Convert private PDF-chart validation experience into a reusable, privacy-safe quality gate.
|
|
> Privacy boundary: This document intentionally excludes personal birth data, exact chart degrees, life events, raw PDF text, and private full-reading JSON.
|
|
|
|
## 1. When to use this protocol
|
|
|
|
Use this protocol when the input is a PDF, screenshot, or text export from astrology software rather than raw birth data.
|
|
|
|
Typical sources:
|
|
|
|
- Jagannatha Hora / Parashara's Light PDF export
|
|
- Screenshot or OCR of a Vedic chart
|
|
- User-provided text listing D1/D9/Dasha tables
|
|
- Mixed PDF containing chart pages, strength tables, and divisional charts
|
|
|
|
## 2. Validation principle
|
|
|
|
A PDF chart is not automatically trustworthy as machine-readable data. Treat it as a source document that must pass layered checks before interpretation.
|
|
|
|
Validation layers:
|
|
|
|
1. Source extraction: obtain all visible text and page structure.
|
|
2. Identity lock: confirm date, time, timezone, place, ayanamsa, node mode, and chart style.
|
|
3. Core chart lock: confirm D1 ascendant, Moon sign/nakshatra, Rahu/Ketu axis, and visible house layout.
|
|
4. Dasha lock: confirm Mahadasha/Antardasha sequence and current period.
|
|
5. Strength lock: confirm Ashtakavarga/Shadbala/Vimsopaka tables if present.
|
|
6. Engine recomputation: run `full-reading` from extracted birth data.
|
|
7. Difference arbitration: explicitly separate PDF-origin facts, engine-recomputed facts, and unresolved differences.
|
|
8. Interpretation boundary: only use A/B confidence for claims that passed the relevant gate.
|
|
|
|
## 3. Minimum quality gate
|
|
|
|
A PDF input may proceed to interpretation only if these fields are available and internally consistent:
|
|
|
|
| Gate | Required fields | Pass condition |
|
|
|---|---|---|
|
|
| Birth data | Date, local time, timezone, place | No contradiction between PDF pages |
|
|
| D1 core | Ascendant, Moon sign, Rahu/Ketu axis | PDF and recomputed engine agree or difference is explained |
|
|
| D9 core | Navamsa ascendant or full D9 table | Available from PDF or recomputation |
|
|
| Dasha | Current Mahadasha and Antardasha | Period sequence matches Vimshottari calculation within expected boundary tolerance |
|
|
| Node mode | Mean/True node | Explicitly stated or inferred and documented |
|
|
| Ayanamsa | Lahiri/other | Explicitly stated or inferred and documented |
|
|
|
|
If any gate fails, downgrade the reading and state the uncertainty.
|
|
|
|
## 4. Recommended extraction workflow
|
|
|
|
1. Extract text from every page.
|
|
2. Record page-level coverage: which pages contain D1, D9, Dasha, strength tables, transit tables, or divisional charts.
|
|
3. Normalize names: map software-specific labels to engine fields.
|
|
4. Recompute with `scripts/jyotish_engine.py full-reading`.
|
|
5. Compare the following high-impact fields first:
|
|
- Ascendant sign
|
|
- Moon sign and nakshatra
|
|
- Rahu/Ketu signs and node mode
|
|
- Current Vimshottari Mahadasha/Antardasha
|
|
- D9 ascendant and key dignity states
|
|
- SAV total and house scores if Ashtakavarga is present
|
|
- Shadbala ranking if a strength table is present
|
|
6. Create a discrepancy table before interpreting.
|
|
|
|
## 5. Confidence levels
|
|
|
|
| Level | Meaning | Allowed usage |
|
|
|---|---|---|
|
|
| A | PDF and engine agree, or discrepancy has authoritative explanation | Can support direct interpretation |
|
|
| B | One strong source plus secondary partial confirmation | Can support cautious interpretation |
|
|
| C | Single source, OCR uncertain, or chart-image page not fully parsed | Use only as a hypothesis |
|
|
| D | Contradicted or missing | Do not use for prediction |
|
|
|
|
## 6. Common downgrade triggers
|
|
|
|
- PDF text extraction cannot reconstruct chart grid positions.
|
|
- Divisional chart pages appear as images or broken table text.
|
|
- Dasha period boundary differs due to timezone or ayanamsa assumptions.
|
|
- Rahu/Ketu mismatch is caused by Mean Node vs True Node.
|
|
- Shadbala values are from a different software formula or ayanamsa.
|
|
- OCR confuses signs, degrees, or retrograde markers.
|
|
|
|
## 7. Discrepancy table template
|
|
|
|
| Field | PDF value | Engine value | Status | Action |
|
|
|---|---|---|---|---|
|
|
| Birth date/time/place | | | A/B/C/D | |
|
|
| Ayanamsa | | | A/B/C/D | |
|
|
| Node mode | | | A/B/C/D | |
|
|
| D1 ascendant | | | A/B/C/D | |
|
|
| Moon sign/nakshatra | | | A/B/C/D | |
|
|
| Rahu/Ketu axis | | | A/B/C/D | |
|
|
| Current MD/AD | | | A/B/C/D | |
|
|
| D9 ascendant | | | A/B/C/D | |
|
|
| SAV total | | | A/B/C/D | |
|
|
| Shadbala ranking | | | A/B/C/D | |
|
|
|
|
## 8. Privacy rule
|
|
|
|
Never commit private PDF extracts, exact private birth data, private life-event validation, or raw full-reading JSON generated from a user chart to the public repository. If a workflow lesson is useful, extract only the generic method and remove identifying details.
|
|
|
|
## 9. Output requirement
|
|
|
|
When using a PDF chart in a reading, the final report must include:
|
|
|
|
1. Source type: PDF/OCR/text export.
|
|
2. Quality gate summary.
|
|
3. Which fields are A/B/C/D.
|
|
4. Which claims rely on PDF facts vs engine recomputation.
|
|
5. Explicit caveats for any chart-image or OCR-only sections.
|